iris: Fix typos.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9382>

src/gallium/drivers/iris/iris_blorp.c

@@ -275,7 +275,7 @@ iris_blorp_exec(struct blorp_batch *blorp_batch,
 #endif
 
    /* Flush the render cache in cases where the same surface is reinterpreted
-    * with a differernt format, which blorp does for stencil and depth data
+    * with a different format, which blorp does for stencil and depth data
     * among other things.  Invalidation of sampler caches and flushing of any
     * caches which had previously written the source surfaces should already
     * have been handled by the caller.

src/gallium/drivers/iris/iris_bufmgr.c

@@ -1048,7 +1048,7 @@ iris_bo_map_cpu(struct pipe_debug_callback *dbg,
        * contents, and so long as we only read from the CPU mmap we do not
        * need to write those cachelines back afterwards.
        *
-       * On LLC, the emprical evidence suggests that writes from the GPU
+       * On LLC, the empirical evidence suggests that writes from the GPU
        * that bypass the LLC (i.e. for scanout) do *invalidate* the CPU
        * cachelines. (Other reads, such as the display engine, bypass the
        * LLC entirely requiring us to keep dirty pixels for the scanout
@@ -1272,7 +1272,7 @@ iris_bo_wait_rendering(struct iris_bo *bo)
  * handle. Userspace must make sure this race does not occur if such precision
  * is important.
  *
- * Note that some kernels have broken the inifite wait for negative values
+ * Note that some kernels have broken the infinite wait for negative values
  * promise, upgrade to latest stable kernels if this is the case.
  */
 int

src/gallium/drivers/iris/iris_bufmgr.h

@@ -170,7 +170,7 @@ struct iris_bo {
    uint64_t kflags;
 
    /**
-    * Kenel-assigned global name for this object
+    * Kernel-assigned global name for this object
     *
     * List contains both flink named and prime fd'd objects
     */

src/gallium/drivers/iris/iris_clear.c

@@ -281,7 +281,7 @@ fast_clear_color(struct iris_context *ice,
    if (!color_changed && box->depth == 1 && aux_state == ISL_AUX_STATE_CLEAR)
       return;
 
-   /* Ivybrigde PRM Vol 2, Part 1, "11.7 MCS Buffer for Render Target(s)":
+   /* Ivybridge PRM Vol 2, Part 1, "11.7 MCS Buffer for Render Target(s)":
     *
     *    "Any transition from any value in {Clear, Render, Resolve} to a
     *    different value in {Clear, Render, Resolve} requires end of pipe

src/gallium/drivers/iris/iris_program.c

@@ -810,7 +810,7 @@ iris_setup_binding_table(const struct gen_device_info *devinfo,
       bt->used_mask[IRIS_SURFACE_GROUP_RENDER_TARGET] =
          BITFIELD64_MASK(num_render_targets);
 
-      /* Setup render target read surface group inorder to support non-coherent
+      /* Setup render target read surface group in order to support non-coherent
        * framebuffer fetch on Gen8
        */
       if (devinfo->gen == 8 && info->outputs_read) {

src/gallium/drivers/iris/iris_screen.c

@@ -754,7 +754,7 @@ iris_init_identifier_bo(struct iris_screen *screen)
 struct pipe_screen *
 iris_screen_create(int fd, const struct pipe_screen_config *config)
 {
-   /* Here are the i915 features we need for Iris (in chronoligical order) :
+   /* Here are the i915 features we need for Iris (in chronological order) :
     *    - I915_PARAM_HAS_EXEC_NO_RELOC     (3.10)
     *    - I915_PARAM_HAS_EXEC_HANDLE_LUT   (3.10)
     *    - I915_PARAM_HAS_EXEC_BATCH_FIRST  (4.13)

src/gallium/drivers/iris/iris_state.c

@@ -387,7 +387,7 @@ flush_before_state_base_change(struct iris_batch *batch)
    /* Flush before emitting STATE_BASE_ADDRESS.
     *
     * This isn't documented anywhere in the PRM.  However, it seems to be
-    * necessary prior to changing the surface state base adress.  We've
+    * necessary prior to changing the surface state base address.  We've
     * seen issues in Vulkan where we get GPU hangs when using multi-level
     * command buffers which clear depth, reset state base address, and then
     * go render stuff.