All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masanari Iida <standby24x7@gmail.com>
To: linux-kernel@vger.kernel.org, daniel.vetter@intel.com,
	trivial@kernel.org, jani.nikula@linux.intel.com,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	rdunlap@infradead.org
Cc: corbet@lwn.net, Masanari Iida <standby24x7@gmail.com>
Subject: [PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c
Date: Tue,  5 Jan 2016 12:29:17 +0900	[thread overview]
Message-ID: <1451964557-1145-1-git-send-email-standby24x7@gmail.com> (raw)

This patch fix some spelling typos found in Documentation/Docbook
gpu/ch04s03.html.  This file was generated from comments within
source, so I have to fix typos in i915_gem_fence.c.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
 drivers/gpu/drm/i915/i915_gem_fence.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c b/drivers/gpu/drm/i915/i915_gem_fence.c
index 5981985..a2b938e 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -34,8 +34,8 @@
  * set of these objects.
  *
  * Fences are used to detile GTT memory mappings. They're also connected to the
- * hardware frontbuffer render tracking and hence interract with frontbuffer
- * conmpression. Furthermore on older platforms fences are required for tiled
+ * hardware frontbuffer render tracking and hence interact with frontbuffer
+ * compression. Furthermore on older platforms fences are required for tiled
  * objects used by the display engine. They can also be used by the render
  * engine - they're required for blitter commands and are optional for render
  * commands. But on gen4+ both display (with the exception of fbc) and rendering
@@ -46,8 +46,8 @@
  *
  * Finally note that because fences are such a restricted resource they're
  * dynamically associated with objects. Furthermore fence state is committed to
- * the hardware lazily to avoid unecessary stalls on gen2/3. Therefore code must
- * explictly call i915_gem_object_get_fence() to synchronize fencing status
+ * the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore code must
+ * explicitly call i915_gem_object_get_fence() to synchronize fencing status
  * for cpu access. Also note that some code wants an unfenced view, for those
  * cases the fence can be removed forcefully with i915_gem_object_put_fence().
  *
@@ -527,7 +527,7 @@ void i915_gem_restore_fences(struct drm_device *dev)
  * required.
  *
  * When bit 17 is XORed in, we simply refuse to tile at all.  Bit
- * 17 is not just a page offset, so as we page an objet out and back in,
+ * 17 is not just a page offset, so as we page an object out and back in,
  * individual pages in it will have different bit 17 addresses, resulting in
  * each 64 bytes being swapped with its neighbor!
  *
-- 
2.7.0.rc3


WARNING: multiple messages have this Message-ID (diff)
From: Masanari Iida <standby24x7@gmail.com>
To: linux-kernel@vger.kernel.org, daniel.vetter@intel.com,
	trivial@kernel.org, jani.nikula@linux.intel.com,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	rdunlap@infradead.org
Cc: Masanari Iida <standby24x7@gmail.com>, corbet@lwn.net
Subject: [PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c
Date: Tue,  5 Jan 2016 12:29:17 +0900	[thread overview]
Message-ID: <1451964557-1145-1-git-send-email-standby24x7@gmail.com> (raw)

This patch fix some spelling typos found in Documentation/Docbook
gpu/ch04s03.html.  This file was generated from comments within
source, so I have to fix typos in i915_gem_fence.c.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
 drivers/gpu/drm/i915/i915_gem_fence.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c b/drivers/gpu/drm/i915/i915_gem_fence.c
index 5981985..a2b938e 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -34,8 +34,8 @@
  * set of these objects.
  *
  * Fences are used to detile GTT memory mappings. They're also connected to the
- * hardware frontbuffer render tracking and hence interract with frontbuffer
- * conmpression. Furthermore on older platforms fences are required for tiled
+ * hardware frontbuffer render tracking and hence interact with frontbuffer
+ * compression. Furthermore on older platforms fences are required for tiled
  * objects used by the display engine. They can also be used by the render
  * engine - they're required for blitter commands and are optional for render
  * commands. But on gen4+ both display (with the exception of fbc) and rendering
@@ -46,8 +46,8 @@
  *
  * Finally note that because fences are such a restricted resource they're
  * dynamically associated with objects. Furthermore fence state is committed to
- * the hardware lazily to avoid unecessary stalls on gen2/3. Therefore code must
- * explictly call i915_gem_object_get_fence() to synchronize fencing status
+ * the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore code must
+ * explicitly call i915_gem_object_get_fence() to synchronize fencing status
  * for cpu access. Also note that some code wants an unfenced view, for those
  * cases the fence can be removed forcefully with i915_gem_object_put_fence().
  *
@@ -527,7 +527,7 @@ void i915_gem_restore_fences(struct drm_device *dev)
  * required.
  *
  * When bit 17 is XORed in, we simply refuse to tile at all.  Bit
- * 17 is not just a page offset, so as we page an objet out and back in,
+ * 17 is not just a page offset, so as we page an object out and back in,
  * individual pages in it will have different bit 17 addresses, resulting in
  * each 64 bytes being swapped with its neighbor!
  *
-- 
2.7.0.rc3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

             reply	other threads:[~2016-01-05  3:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05  3:29 Masanari Iida [this message]
2016-01-05  3:29 ` [PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c Masanari Iida
2016-01-05  8:20 ` ✗ warning: Fi.CI.BAT Patchwork
2016-01-05 17:57 ` [PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c Randy Dunlap
2016-01-05 17:57   ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1451964557-1145-1-git-send-email-standby24x7@gmail.com \
    --to=standby24x7@gmail.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=trivial@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.