[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/mm: Add an iterator to optimally walk 
over holes for an allocation
URL   : https://patchwork.freedesktop.org/series/99597/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11176 -> Patchwork_22151


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22151 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22151, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/index.html

Participating hosts (45 -> 41)
--

  Missing(4): fi-kbl-soraka fi-bdw-samus fi-icl-u2 shard-tglu 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22151:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- fi-snb-2520m:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-snb-2520m/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-snb-2520m/igt@i915_selftest@l...@workarounds.html
- fi-snb-2600:[PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-snb-2600/igt@i915_selftest@l...@workarounds.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-snb-2600/igt@i915_selftest@l...@workarounds.html

  
Known issues


  Here are the changes found in Patchwork_22151 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][6] -> [INCOMPLETE][7] ([i915#4547])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][8] -> [DMESG-FAIL][9] ([i915#5026])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@runner@aborted:
- fi-blb-e6850:   NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#2403] / 
[i915#2426] / [i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-adlp-4: [INCOMPLETE][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/bat-adlp-4/igt@i915_selftest@live@gem_contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/bat-adlp-4/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][15] ([i915#1886]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-jsl-1/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][17] ([i915#3921]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][19] ([i915#295]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11176/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22151/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][21] ([i915#295]) -> [PASS][22] +10 
similar issues
   [21]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/mm: Add an iterator to optimally walk 
over holes for an allocation
URL   : https://patchwork.freedesktop.org/series/99597/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/mm: Add an iterator to optimally walk 
over holes for an allocation
URL   : https://patchwork.freedesktop.org/series/99597/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
737921ca12bb drm/mm: Add an iterator to optimally walk over holes for an 
allocation
-:9: WARNING:TYPO_SPELLING: 'efficently' may be misspelled - perhaps 
'efficiently'?
#9: 
size by efficently traversing the rbtree associated with the given
^^

-:132: WARNING:TYPO_SPELLING: 'efficently' may be misspelled - perhaps 
'efficiently'?
#132: FILE: include/drm/drm_mm.h:426:
+ * appropriate holes within the given range by efficently traversing the
^^

-:135: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible 
side-effects?
#135: FILE: include/drm/drm_mm.h:429:
+#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode) 
\
+   for (pos = drm_mm_first_hole(mm, range_start, range_end, size, mode); \
+pos; \
+pos = mode & DRM_MM_INSERT_ONCE ? \
+NULL : drm_mm_next_hole(mm, hole, size, mode))

-:135: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mm' - possible side-effects?
#135: FILE: include/drm/drm_mm.h:429:
+#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode) 
\
+   for (pos = drm_mm_first_hole(mm, range_start, range_end, size, mode); \
+pos; \
+pos = mode & DRM_MM_INSERT_ONCE ? \
+NULL : drm_mm_next_hole(mm, hole, size, mode))

-:135: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'size' - possible 
side-effects?
#135: FILE: include/drm/drm_mm.h:429:
+#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode) 
\
+   for (pos = drm_mm_first_hole(mm, range_start, range_end, size, mode); \
+pos; \
+pos = mode & DRM_MM_INSERT_ONCE ? \
+NULL : drm_mm_next_hole(mm, hole, size, mode))

-:135: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mode' - possible 
side-effects?
#135: FILE: include/drm/drm_mm.h:429:
+#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode) 
\
+   for (pos = drm_mm_first_hole(mm, range_start, range_end, size, mode); \
+pos; \
+pos = mode & DRM_MM_INSERT_ONCE ? \
+NULL : drm_mm_next_hole(mm, hole, size, mode))

total: 0 errors, 2 warnings, 4 checks, 109 lines checked
6b91082aa6e9 drm/i915/gem: Don't try to map and fence large scanout buffers (v5)

[Intel-gfx] [PATCH 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v5)

[Vivek Kasireddy]

On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.

This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.

Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.

Here is the ftrace snippet that shows the source of the ~10ms latency:
  i915_gem_object_pin_to_display_plane() {
0.102 us   |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us   |  i915_vma_instance();
0.178 us   |  i915_vma_misplaced();
  i915_vma_unbind() {
  __i915_active_wait() {
0.082 us   |i915_active_acquire_if_busy();
0.475 us   |  }
  intel_runtime_pm_get() {
0.087 us   |intel_runtime_pm_acquire();
0.259 us   |  }
  __i915_active_wait() {
0.085 us   |i915_active_acquire_if_busy();
0.240 us   |  }
  __i915_vma_evict() {
ggtt_unbind_vma() {
  gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us |  }
10508.516 us |   }

v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.

v3 (Ville):
- Count how many fb objects can be fit into the available holes
  instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.

v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.

v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
  map into the aperture.
- Account for guard pages while calculating the total size required
  for the object.
- Do not subject all objects to the heuristic check and instead
  consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: Tvrtko Ursulin 
Cc: Manasi Navare 
Signed-off-by: Vivek Kasireddy 
---
 drivers/gpu/drm/i915/i915_gem.c | 117 
 1 file changed, 88 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e3a2c2a0e156..752fec2b4c60 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,6 +46,7 @@
 #include "gem/i915_gem_mman.h"
 #include "gem/i915_gem_region.h"
 #include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
 #include "gt/intel_engine_user.h"
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_pm.h"
@@ -876,6 +877,92 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(>vma.lock);
 }
 
+static bool
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+   struct drm_mm_node *hole;
+   u64 hole_start, hole_end, start, end;
+   u64 fence_size, fence_alignment;
+   unsigned int count = 0;
+
+   /*
+* If the required space is larger than the available
+* aperture, we will not able to find a slot for the
+* object and unbinding the object now will be in
+* vain. Worse, doing so may cause us to ping-pong
+* the object in and out of the Global GTT and
+* waste a lot of cycles under the mutex.
+*/
+   if (obj->base.size > ggtt->mappable_end)
+   return true;
+
+   /*
+* If NONBLOCK is set the caller is optimistically
+* trying to cache 

[Intel-gfx] [PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation

[Vivek Kasireddy]

This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficently traversing the rbtree associated with the given
allocator.

It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm drivers to quickly identify holes of a certain
size within a given range.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Vivek Kasireddy 
---
 drivers/gpu/drm/drm_mm.c | 28 
 include/drm/drm_mm.h | 32 
 2 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..416c849c10e5 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm 
*mm, u64 addr, u64 size)
return node;
 }
 
-static struct drm_mm_node *
-first_hole(struct drm_mm *mm,
-  u64 start, u64 end, u64 size,
-  enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode)
 {
switch (mode) {
default:
@@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
hole_stack);
}
 }
+EXPORT_SYMBOL(drm_mm_first_hole);
 
 /**
  * DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
@@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node 
*entry, u64 size)  \
 DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
 DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
 
-static struct drm_mm_node *
-next_hole(struct drm_mm *mm,
- struct drm_mm_node *node,
- u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+drm_mm_next_hole(struct drm_mm *mm,
+struct drm_mm_node *node,
+u64 size,
+enum drm_mm_insert_mode mode)
 {
switch (mode) {
default:
@@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
return >hole_stack == >hole_stack ? NULL : node;
}
 }
+EXPORT_SYMBOL(drm_mm_next_hole);
 
 /**
  * drm_mm_reserve_node - insert an pre-initialized node
@@ -520,7 +522,6 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
 {
struct drm_mm_node *hole;
u64 remainder_mask;
-   bool once;
 
DRM_MM_BUG_ON(range_start > range_end);
 
@@ -533,13 +534,8 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
 
-   once = mode & DRM_MM_INSERT_ONCE;
-   mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
-   for (hole = first_hole(mm, range_start, range_end, size, mode);
-hole;
-hole = once ? NULL : next_hole(mm, hole, size, mode)) {
+   drm_mm_for_each_best_hole(hole, mm, range_start, range_end, size, mode) 
{
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index ac33ba1b18bc..5055447697fa 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -322,6 +322,17 @@ static inline u64 __drm_mm_hole_node_end(const struct 
drm_mm_node *hole_node)
return list_next_entry(hole_node, node_list)->start;
 }
 
+struct drm_mm_node *
+drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode);
+
+struct drm_mm_node *
+drm_mm_next_hole(struct drm_mm *mm,
+struct drm_mm_node *node,
+u64 size,
+enum drm_mm_insert_mode mode);
+
 /**
  * drm_mm_hole_node_end - computes the end of the hole following @node
  * @hole_node: drm_mm_node which implicitly tracks the following hole
@@ -400,6 +411,27 @@ static inline u64 drm_mm_hole_node_end(const struct 
drm_mm_node *hole_node)
 1 : 0; \
 pos = list_next_entry(pos, hole_stack))
 
+/**
+ * drm_mm_for_each_best_hole - iterator to optimally walk over all holes >= 
@size
+ * @pos: _mm_node used internally to track progress
+ * @mm: _mm allocator to walk
+ * @range_start: start of the allowed range for the allocation
+ * @range_end: end of the allowed range for the allocation
+ * @size: size of the allocation
+ * @mode: fine-tune the allocation search
+ *
+ * This iterator walks over all holes suitable for the allocation of given
+ * @size in a very efficient manner. It is implemented by calling
+ * drm_mm_first_hole() and drm_mm_next_hole() which identify the
+ * appropriate holes within the given range by efficently traversing the
+ * rbtree associated with @mm.
+ */
+#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode) 
\
+   

Re: [Intel-gfx] [PATCH 16/19] drm/i915/guc: Use a single pass to calculate regset

[Daniele Ceraolo Spurio]

On 1/26/2022 12:36 PM, Lucas De Marchi wrote:

The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.

However in order to maintain an ordered set of registers to pass to guc,
each register needs to be added and moved in the final array. The second
phase may actually happen in IO memory rather than system memory and
accessing IO memory by simply dereferencing the pointer doesn't work on
all architectures. Other places of the ADS initializaition were
converted to use the dma_buf_map API, but here there may be a lot more
accesses to IO memory. So, instead of following that same approach,
convert the regset initialization to calculate the final array in 1
pass and in the second pass that array is just copied to its final
location, updating the pointers for each engine written to the ADS blob.

One important thing is that struct temp_regset now have
different semantics: `registers` continues to track the registers of a
single engine, however the other fields are updated together, according
to the newly added `storage`, which tracks the memory allocated for
all the registers. So rename some of these fields and add a
__mmio_reg_add(): this function (possibly) allocates memory and operates
on the storage pointer while guc_mmio_reg_add() continues to manage the
registers pointer.

On a Tiger Lake system using enable_guc=3, the following log message is
now seen:

[  187.334310] i915 :00:02.0: [drm:intel_guc_ads_create [i915]] 
Used 4 KB for temporary ADS regset

This change has also been tested on an ARM64 host with DG2 and other
discrete graphics cards.

Cc: Matt Roper 
Cc: Thomas Hellström 
Cc: Daniel Vetter 
Cc: John Harrison 
Cc: Matthew Brost 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Lucas De Marchi 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc.h |   7 ++
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 117 +
  2 files changed, 79 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e2e0df1c3d91..4c852eee3ad8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -152,6 +152,13 @@ struct intel_guc {
struct dma_buf_map ads_map;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
+   /**
+* @ads_regset_count: number of save/restore registers in the ADS for
+* each engine
+*/
+   u32 ads_regset_count[I915_NUM_ENGINES];
+   /** @ads_regset: save/restore regsets in the ADS */
+   struct guc_mmio_reg *ads_regset;
/** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
u32 ads_golden_ctxt_size;
/** @ads_engine_usage_size: size of engine usage in the ADS */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 73ca34de44f7..390101ee3661 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -226,14 +226,13 @@ static void guc_mapping_table_init(struct intel_gt *gt,
  
  /*

   * The save/restore register list must be pre-calculated to a temporary
- * buffer of driver defined size before it can be generated in place
- * inside the ADS.
+ * buffer before it can be copied inside the ADS.
   */
-#define MAX_MMIO_REGS  128 /* Arbitrary size, increase as needed */
  struct temp_regset {
struct guc_mmio_reg *registers;
-   u32 used;
-   u32 size;
+   struct guc_mmio_reg *storage;


I think this could use a comment to distinguish between registers and 
storage. Something like.:


/* ptr to the base of the allocated storage for all engines */
struct guc_mmio_reg *storage;

/* ptr to the section of the storage for the engine currently being 
worked on */

struct guc_mmio_reg *registers;



+   u32 storage_used;
+   u32 storage_max;
  };
  
  static int guc_mmio_reg_cmp(const void *a, const void *b)

@@ -244,18 +243,44 @@ static int guc_mmio_reg_cmp(const void *a, const void *b)
return (int)ra->offset - (int)rb->offset;
  }
  
+static struct guc_mmio_reg * __must_check

+__mmio_reg_add(struct temp_regset *regset, struct guc_mmio_reg *reg)
+{
+   u32 pos = regset->storage_used;
+   struct guc_mmio_reg *slot;
+
+   if (pos >= regset->storage_max) {
+   size_t size = ALIGN((pos + 1) * sizeof(*slot), PAGE_SIZE);
+   struct guc_mmio_reg *r = krealloc(regset->storage,
+ size, GFP_KERNEL);
+   if (!r) {
+   WARN_ONCE(1, "Incomplete regset list: can't add register 
(%d)\n",
+ -ENOMEM);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Use str_yes_no()

[Matt Roper]

On Wed, Jan 26, 2022 at 01:39:43AM -0800, Lucas De Marchi wrote:
> Remove the local yesno() implementation and adopt the str_yes_no() from
> linux/string_helpers.h.
> 
> Signed-off-by: Lucas De Marchi 
> Acked-by: Daniel Vetter 
> Acked-by: Jani Nikula 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 23 +++
>  .../drm/i915/display/intel_display_debugfs.c  | 66 +++
>  .../drm/i915/display/intel_display_trace.h|  6 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 12 ++--
>  drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  3 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  6 +-
>  .../gpu/drm/i915/gem/selftests/huge_pages.c   |  9 +--
>  .../drm/i915/gem/selftests/i915_gem_context.c |  7 +-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 +--
>  .../drm/i915/gt/intel_execlists_submission.c  |  7 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |  3 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 52 ---
>  drivers/gpu/drm/i915/gt/intel_reset.c |  3 +-
>  drivers/gpu/drm/i915/gt/intel_rps.c   | 13 ++--
>  drivers/gpu/drm/i915/gt/intel_sseu.c  |  9 ++-
>  drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c  | 10 +--
>  drivers/gpu/drm/i915/gt/selftest_timeline.c   |  3 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  3 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  4 +-
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +--
>  drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 20 +++---
>  drivers/gpu/drm/i915/i915_debugfs.c   | 15 +++--
>  drivers/gpu/drm/i915/i915_gpu_error.c |  9 +--
>  drivers/gpu/drm/i915/i915_params.c|  5 +-
>  drivers/gpu/drm/i915/i915_utils.h |  5 --
>  drivers/gpu/drm/i915/intel_device_info.c  |  8 ++-
>  drivers/gpu/drm/i915/intel_dram.c | 10 +--
>  drivers/gpu/drm/i915/intel_pm.c   | 10 +--
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c  |  4 +-
>  drivers/gpu/drm/i915/selftests/i915_active.c  |  3 +-
>  31 files changed, 203 insertions(+), 148 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 80bc52425e47..bd453861088e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -3008,7 +3009,7 @@ static int intel_crtc_compute_config(struct intel_crtc 
> *crtc,
>   drm_dbg_kms(_priv->drm,
>   "requested pixel clock (%d kHz) too high (max: %d 
> kHz, double wide: %s)\n",
>   pipe_mode->crtc_clock, clock_limit,
> - yesno(pipe_config->double_wide));
> + str_yes_no(pipe_config->double_wide));
>   return -EINVAL;
>   }
>  
> @@ -5586,7 +5587,7 @@ static void intel_dump_plane_state(const struct 
> intel_plane_state *plane_state)
>   drm_dbg_kms(>drm,
>   "[PLANE:%d:%s] fb: [NOFB], visible: %s\n",
>   plane->base.base.id, plane->base.name,
> - yesno(plane_state->uapi.visible));
> + str_yes_no(plane_state->uapi.visible));
>   return;
>   }
>  
> @@ -5594,7 +5595,7 @@ static void intel_dump_plane_state(const struct 
> intel_plane_state *plane_state)
>   "[PLANE:%d:%s] fb: [FB:%d] %ux%u format = %p4cc modifier = 
> 0x%llx, visible: %s\n",
>   plane->base.base.id, plane->base.name,
>   fb->base.id, fb->width, fb->height, >format->format,
> - fb->modifier, yesno(plane_state->uapi.visible));
> + fb->modifier, str_yes_no(plane_state->uapi.visible));
>   drm_dbg_kms(>drm, "\trotation: 0x%x, scaler: %d\n",
>   plane_state->hw.rotation, plane_state->scaler_id);
>   if (plane_state->uapi.visible)
> @@ -5617,7 +5618,7 @@ static void intel_dump_pipe_config(const struct 
> intel_crtc_state *pipe_config,
>  
>   drm_dbg_kms(_priv->drm, "[CRTC:%d:%s] enable: %s %s\n",
>   crtc->base.base.id, crtc->base.name,
> - yesno(pipe_config->hw.enable), context);
> + str_yes_no(pipe_config->hw.enable), context);
>  
>   if (!pipe_config->hw.enable)
>   goto dump_planes;
> @@ -5625,7 +5626,7 @@ static void intel_dump_pipe_config(const struct 
> intel_crtc_state *pipe_config,
>   snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
>   drm_dbg_kms(_priv->drm,
>   "active: %s, output_types: %s (0x%x), output format: %s\n",
> - yesno(pipe_config->hw.active),
> + str_yes_no(pipe_config->hw.active),
>   buf, pipe_config->output_types,
>  

Re: [Intel-gfx] [PATCH v2 04/11] drm/i915: Use str_enable_disable()

[Matt Roper]

On Wed, Jan 26, 2022 at 01:39:44AM -0800, Lucas De Marchi wrote:
> Remove the local enabledisable() implementation and adopt the
> str_enable_disable() from linux/string_helpers.h.
> 
> Signed-off-by: Lucas De Marchi 
> Acked-by: Daniel Vetter 
> Acked-by: Jani Nikula 

There's an open-coded version of this in display/intel_pps.c,
intel_pps_backlight_power().  Up to you whether you squash it into this
patch or convert it as a follow-up.  Either way.

Reviewed-by: Matt Roper 


> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c   | 4 +++-
>  drivers/gpu/drm/i915/display/intel_display_power.c | 4 +++-
>  drivers/gpu/drm/i915/display/intel_dp.c| 8 
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c  | 3 ++-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c  | 4 +++-
>  drivers/gpu/drm/i915/i915_utils.h  | 5 -
>  6 files changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2f20abc5122d..4b35a8597632 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -25,6 +25,8 @@
>   *
>   */
>  
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -2152,7 +2154,7 @@ static void 
> intel_dp_sink_set_msa_timing_par_ignore_state(struct intel_dp *intel
>  enable ? DP_MSA_TIMING_PAR_IGNORE_EN : 0) <= 0)
>   drm_dbg_kms(>drm,
>   "Failed to %s MSA_TIMING_PAR_IGNORE in the sink\n",
> - enabledisable(enable));
> + str_enable_disable(enable));
>  }
>  
>  static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 369317805d24..1f77cb9edddf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -3,6 +3,8 @@
>   * Copyright © 2019 Intel Corporation
>   */
>  
> +#include 
> +
>  #include "i915_drv.h"
>  #include "i915_irq.h"
>  #include "intel_cdclk.h"
> @@ -5302,7 +5304,7 @@ static void gen9_dbuf_slice_set(struct drm_i915_private 
> *dev_priv,
>   state = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
>   drm_WARN(_priv->drm, enable != state,
>"DBuf slice %d power %s timeout!\n",
> -  slice, enabledisable(enable));
> +  slice, str_enable_disable(enable));
>  }
>  
>  void gen9_dbuf_slices_update(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 62c1535d696d..933fc316ea53 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1987,7 +1987,7 @@ void intel_dp_sink_set_decompression_state(struct 
> intel_dp *intel_dp,
>   if (ret < 0)
>   drm_dbg_kms(>drm,
>   "Failed to %s sink decompression state\n",
> - enabledisable(enable));
> + str_enable_disable(enable));
>  }
>  
>  static void
> @@ -2463,7 +2463,7 @@ void intel_dp_configure_protocol_converter(struct 
> intel_dp *intel_dp,
>   if (drm_dp_dpcd_writeb(_dp->aux,
>  DP_PROTOCOL_CONVERTER_CONTROL_0, tmp) != 1)
>   drm_dbg_kms(>drm, "Failed to %s protocol converter HDMI 
> mode\n",
> - enabledisable(intel_dp->has_hdmi_sink));
> + str_enable_disable(intel_dp->has_hdmi_sink));
>  
>   tmp = crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
>   intel_dp->dfp.ycbcr_444_to_420 ? 
> DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
> @@ -2472,7 +2472,7 @@ void intel_dp_configure_protocol_converter(struct 
> intel_dp *intel_dp,
>  DP_PROTOCOL_CONVERTER_CONTROL_1, tmp) != 1)
>   drm_dbg_kms(>drm,
>   "Failed to %s protocol converter YCbCr 4:2:0 
> conversion mode\n",
> - enabledisable(intel_dp->dfp.ycbcr_444_to_420));
> + str_enable_disable(intel_dp->dfp.ycbcr_444_to_420));
>  
>   tmp = 0;
>   if (intel_dp->dfp.rgb_to_ycbcr) {
> @@ -2510,7 +2510,7 @@ void intel_dp_configure_protocol_converter(struct 
> intel_dp *intel_dp,
>   if (drm_dp_pcon_convert_rgb_to_ycbcr(_dp->aux, tmp) < 0)
>   drm_dbg_kms(>drm,
>  "Failed to %s protocol converter RGB->YCbCr 
> conversion mode\n",
> -enabledisable(tmp));
> +str_enable_disable(tmp));
>  }
>  
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index de89d40abd38..31c3c3bceb95 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ 

Re: [Intel-gfx] [PATCH v2 05/11] drm/i915: Use str_enabled_disabled()

[Matt Roper]

On Wed, Jan 26, 2022 at 01:39:45AM -0800, Lucas De Marchi wrote:
> Remove the local enableddisabled() implementation and adopt the
> str_enabled_disabled() from linux/string_helpers.h.
> 
> Signed-off-by: Lucas De Marchi 
> Acked-by: Daniel Vetter 
> Acked-by: Jani Nikula 

There's two open-coded versions of this in intel_dp_hdcp.c
(intel_dp_mst_hdcp_stream_encryption() and
intel_dp_mst_hdcp2_stream_encryption()) that you might want to convert
as well.  Up to you whether you squash them into this patch or convert
them as a separate patch.  Either way,

Reviewed-by: Matt Roper 


> ---
>  drivers/gpu/drm/i915/display/intel_backlight.c   |  3 ++-
>  drivers/gpu/drm/i915/display/intel_display.c | 16 
>  .../gpu/drm/i915/display/intel_display_debugfs.c |  8 
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c |  7 ---
>  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c  |  3 ++-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c|  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c|  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c   |  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c|  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c|  4 ++--
>  drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
>  drivers/gpu/drm/i915/i915_driver.c   |  4 +++-
>  drivers/gpu/drm/i915/i915_utils.h|  6 +-
>  drivers/gpu/drm/i915/intel_pm.c  |  4 ++--
>  14 files changed, 33 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 98f7ea44042f..c8e1fc53a881 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "intel_backlight.h"
>  #include "intel_connector.h"
> @@ -1633,7 +1634,7 @@ int intel_backlight_setup(struct intel_connector 
> *connector, enum pipe pipe)
>   drm_dbg_kms(_priv->drm,
>   "Connector %s backlight initialized, %s, brightness 
> %u/%u\n",
>   connector->base.name,
> - enableddisabled(panel->backlight.enabled),
> + str_enabled_disabled(panel->backlight.enabled),
>   panel->backlight.level, panel->backlight.max);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index bd453861088e..8920bdb53b7b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3110,8 +3110,8 @@ static void intel_panel_sanitize_ssc(struct 
> drm_i915_private *dev_priv)
>   if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
>   drm_dbg_kms(_priv->drm,
>   "SSC %s by BIOS, overriding VBT which says 
> %s\n",
> - enableddisabled(bios_lvds_use_ssc),
> - 
> enableddisabled(dev_priv->vbt.lvds_use_ssc));
> + str_enabled_disabled(bios_lvds_use_ssc),
> + 
> str_enabled_disabled(dev_priv->vbt.lvds_use_ssc));
>   dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
>   }
>   }
> @@ -5648,7 +5648,7 @@ static void intel_dump_pipe_config(const struct 
> intel_crtc_state *pipe_config,
>   pipe_config->bigjoiner ? "master" : "no");
>  
>   drm_dbg_kms(_priv->drm, "splitter: %s, link count %d, overlap %d\n",
> - enableddisabled(pipe_config->splitter.enable),
> + str_enabled_disabled(pipe_config->splitter.enable),
>   pipe_config->splitter.link_count,
>   pipe_config->splitter.pixel_overlap);
>  
> @@ -5736,7 +5736,7 @@ static void intel_dump_pipe_config(const struct 
> intel_crtc_state *pipe_config,
>   drm_dbg_kms(_priv->drm,
>   "pch pfit: " DRM_RECT_FMT ", %s, force thru: %s\n",
>   DRM_RECT_ARG(_config->pch_pfit.dst),
> - enableddisabled(pipe_config->pch_pfit.enabled),
> + str_enabled_disabled(pipe_config->pch_pfit.enabled),
>   str_yes_no(pipe_config->pch_pfit.force_thru));
>  
>   drm_dbg_kms(_priv->drm, "ips: %i, double wide: %i\n",
> @@ -10300,7 +10300,7 @@ static void readout_plane_state(struct 
> drm_i915_private *dev_priv)
>   drm_dbg_kms(_priv->drm,
>   "[PLANE:%d:%s] hw state readout: %s, pipe %c\n",
>   plane->base.base.id, plane->base.name,
> - enableddisabled(visible), pipe_name(pipe));
> + str_enabled_disabled(visible), pipe_name(pipe));
>   }
>  
>   for_each_intel_crtc(_priv->drm, crtc) {
> @@ -10346,7 

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Use str_on_off()

[Matt Roper]

On Wed, Jan 26, 2022 at 01:39:46AM -0800, Lucas De Marchi wrote:
> Remove the local onoff() implementation and adopt the
> str_on_off() from linux/string_helpers.h.
> 
> Signed-off-by: Lucas De Marchi 
> Acked-by: Daniel Vetter 
> Acked-by: Jani Nikula 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/g4x_dp.c  | 6 --
>  drivers/gpu/drm/i915/display/intel_display.c   | 7 ---
>  drivers/gpu/drm/i915/display/intel_display_trace.h | 3 ++-
>  drivers/gpu/drm/i915/display/intel_dpll.c  | 3 ++-
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c  | 7 +--
>  drivers/gpu/drm/i915/display/intel_fdi.c   | 8 +---
>  drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 3 ++-
>  drivers/gpu/drm/i915/gt/intel_rc6.c| 5 +++--
>  drivers/gpu/drm/i915/i915_utils.h  | 5 -
>  drivers/gpu/drm/i915/vlv_suspend.c | 3 ++-
>  10 files changed, 29 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c 
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index f37677df6ebf..3e729bff1232 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -5,6 +5,8 @@
>   * DisplayPort support for G4x,ILK,SNB,IVB,VLV,CHV (HSW+ handled by the DDI 
> code).
>   */
>  
> +#include 
> +
>  #include "g4x_dp.h"
>  #include "intel_audio.h"
>  #include "intel_backlight.h"
> @@ -191,7 +193,7 @@ static void assert_dp_port(struct intel_dp *intel_dp, 
> bool state)
>   I915_STATE_WARN(cur_state != state,
>   "[ENCODER:%d:%s] state assertion failure (expected %s, 
> current %s)\n",
>   dig_port->base.base.base.id, dig_port->base.base.name,
> - onoff(state), onoff(cur_state));
> + str_on_off(state), str_on_off(cur_state));
>  }
>  #define assert_dp_port_disabled(d) assert_dp_port((d), false)
>  
> @@ -201,7 +203,7 @@ static void assert_edp_pll(struct drm_i915_private 
> *dev_priv, bool state)
>  
>   I915_STATE_WARN(cur_state != state,
>   "eDP PLL state assertion failure (expected %s, current 
> %s)\n",
> - onoff(state), onoff(cur_state));
> + str_on_off(state), str_on_off(cur_state));
>  }
>  #define assert_edp_pll_enabled(d) assert_edp_pll((d), true)
>  #define assert_edp_pll_disabled(d) assert_edp_pll((d), false)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8920bdb53b7b..49f994f36fce 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -377,7 +377,7 @@ static void wait_for_pipe_scanline_moving(struct 
> intel_crtc *crtc, bool state)
>   if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
>   drm_err(_priv->drm,
>   "pipe %c scanline %s wait timed out\n",
> - pipe_name(pipe), onoff(state));
> + pipe_name(pipe), str_on_off(state));
>  }
>  
>  static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
> @@ -435,7 +435,7 @@ void assert_transcoder(struct drm_i915_private *dev_priv,
>   I915_STATE_WARN(cur_state != state,
>   "transcoder %s assertion failure (expected %s, current 
> %s)\n",
>   transcoder_name(cpu_transcoder),
> - onoff(state), onoff(cur_state));
> + str_on_off(state), str_on_off(cur_state));
>  }
>  
>  static void assert_plane(struct intel_plane *plane, bool state)
> @@ -447,7 +447,8 @@ static void assert_plane(struct intel_plane *plane, bool 
> state)
>  
>   I915_STATE_WARN(cur_state != state,
>   "%s assertion failure (expected %s, current %s)\n",
> - plane->base.name, onoff(state), onoff(cur_state));
> + plane->base.name, str_on_off(state),
> + str_on_off(cur_state));
>  }
>  
>  #define assert_plane_enabled(p) assert_plane(p, true)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h 
> b/drivers/gpu/drm/i915/display/intel_display_trace.h
> index dcdd242fffd9..2dd5a4b7f5d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_trace.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
> @@ -9,6 +9,7 @@
>  #if !defined(__INTEL_DISPLAY_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ)
>  #define __INTEL_DISPLAY_TRACE_H__
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -161,7 +162,7 @@ TRACE_EVENT(intel_memory_cxsr,
>  ),
>  
>   TP_printk("%s->%s, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, 
> scanline=%u, pipe C: frame=%u, scanline=%u",
> -   onoff(__entry->old), onoff(__entry->new),
> +   str_on_off(__entry->old), str_on_off(__entry->new),
> __entry->frame[PIPE_A], 

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Dave Airlie]

On Tue, 1 Feb 2022 at 07:06, Daniel Vetter  wrote:
>
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
> 35  Daniel Vetter
> 23  Linus Torvalds
> 10  Hans de Goede
>  9  Dave Airlie
>  6  Peter Rosin

Acked-by: Dave Airlie 

[Intel-gfx] ✗ Fi.CI.BAT: failure for discrete card 64K page support (rev5)

[Patchwork]

== Series Details ==

Series: discrete card 64K page support (rev5)
URL   : https://patchwork.freedesktop.org/series/99119/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11175 -> Patchwork_22150


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22150 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22150, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/index.html

Participating hosts (45 -> 43)
--

  Missing(2): fi-bdw-samus fi-pnv-d510 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22150:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gtt:
- fi-bsw-kefka:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-bsw-kefka/igt@i915_selftest@l...@gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-bsw-kefka/igt@i915_selftest@l...@gtt.html
- bat-adlp-4: [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/bat-adlp-4/igt@i915_selftest@l...@gtt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/bat-adlp-4/igt@i915_selftest@l...@gtt.html
- fi-skl-guc: [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-skl-guc/igt@i915_selftest@l...@gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-skl-guc/igt@i915_selftest@l...@gtt.html
- fi-kbl-8809g:   [PASS][7] -> [DMESG-FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-kbl-8809g/igt@i915_selftest@l...@gtt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-kbl-8809g/igt@i915_selftest@l...@gtt.html
- fi-kbl-7567u:   [PASS][9] -> [DMESG-FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-kbl-7567u/igt@i915_selftest@l...@gtt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-kbl-7567u/igt@i915_selftest@l...@gtt.html
- fi-glk-j4005:   [PASS][11] -> [DMESG-FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-glk-j4005/igt@i915_selftest@l...@gtt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-glk-j4005/igt@i915_selftest@l...@gtt.html
- fi-bsw-nick:[PASS][13] -> [DMESG-FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-bsw-nick/igt@i915_selftest@l...@gtt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-bsw-nick/igt@i915_selftest@l...@gtt.html
- fi-cfl-8109u:   [PASS][15] -> [DMESG-FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-cfl-8109u/igt@i915_selftest@l...@gtt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-cfl-8109u/igt@i915_selftest@l...@gtt.html
- fi-cfl-8700k:   [PASS][17] -> [DMESG-FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-cfl-8700k/igt@i915_selftest@l...@gtt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-cfl-8700k/igt@i915_selftest@l...@gtt.html
- fi-bxt-dsi: [PASS][19] -> [DMESG-FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-bxt-dsi/igt@i915_selftest@l...@gtt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-bxt-dsi/igt@i915_selftest@l...@gtt.html
- fi-icl-u2:  [PASS][21] -> [DMESG-FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-icl-u2/igt@i915_selftest@l...@gtt.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-icl-u2/igt@i915_selftest@l...@gtt.html
- fi-cml-u2:  [PASS][23] -> [DMESG-FAIL][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-cml-u2/igt@i915_selftest@l...@gtt.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-cml-u2/igt@i915_selftest@l...@gtt.html
- fi-bsw-n3050:   [PASS][25] -> [DMESG-FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-bsw-n3050/igt@i915_selftest@l...@gtt.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-bsw-n3050/igt@i915_selftest@l...@gtt.html
- fi-cfl-guc: [PASS][27] -> [DMESG-FAIL][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11175/fi-cfl-guc/igt@i915_selftest@l...@gtt.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22150/fi-cfl-guc/igt@i915_selftest@l...@gtt.html
- fi-skl-6700k2:  [PASS][29] -> [DMESG-FAIL][30]
   [29]: 

Re: [Intel-gfx] [PATCH] drm/i915: Introduce G12 subplatform of DG2

[Sripada, Radhakrishna]

> -Original Message-
> From: Intel-gfx  On Behalf Of Matt
> Roper
> Sent: Thursday, January 20, 2022 3:50 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915: Introduce G12 subplatform of DG2
> 
> Another fork of the DG2 design has appeared, known as "DG2-G12;" let's
> add it as a new subplatform.  As with G11, the GT stepping resets back
> to A0 (so a DG2-G12 A0 is similar, but not identical, to a DG2-G10 C0)
> but the display steppings continue to use the same numbering scheme as
> G10 and G11.
> 
> Some existing DG2 workarounds are starting to be extended to the DG2-G12
> subplatform.  So far only workarounds that were "permanent" for both
> DG2-G10 and DG2-G11 have been tagged for DG2-G12, but more
> stepping-specific workarounds are likely to show up in the future.
> 
> Bspec: 44477
Reviewed-by: Radhakrishna Sripada 

> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h | 19 +++
>  drivers/gpu/drm/i915/intel_device_info.h|  3 ++-
>  drivers/gpu/drm/i915/intel_step.c   |  7 +++
>  4 files changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 6a4372c3a3c5..2d2e3ae9c997 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2077,7 +2077,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>   }
> 
>   if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_B0,
> STEP_FOREVER) ||
> - IS_DG2_G11(engine->i915)) {
> + IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915)) {
>   /* Wa_22013037850:dg2 */
>   wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW,
>   DISABLE_128B_EVICTION_COMMAND_UDW);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 890f1f6fbc49..a2fe5a0a7acd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1262,6 +1262,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
>   IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G10)
>  #define IS_DG2_G11(dev_priv) \
>   IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G11)
> +#define IS_DG2_G12(dev_priv) \
> + IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G12)
>  #define IS_ADLS_RPLS(dev_priv) \
>   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_S,
> INTEL_SUBPLATFORM_RPL_S)
>  #define IS_ADLP_N(dev_priv) \
> @@ -1378,16 +1380,17 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
>   (IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
> 
>  /*
> - * DG2 hardware steppings are a bit unusual.  The hardware design was forked
> - * to create two variants (G10 and G11) which have distinct workaround sets.
> - * The G11 fork of the DG2 design resets the GT stepping back to "A0" for its
> - * first iteration, even though it's more similar to a G10 B0 stepping in 
> terms
> - * of functionality and workarounds.  However the display stepping does not
> - * reset in the same manner --- a specific stepping like "B0" has a 
> consistent
> - * meaning regardless of whether it belongs to a G10 or G11 DG2.
> + * DG2 hardware steppings are a bit unusual.  The hardware design was forked
> to
> + * create three variants (G10, G11, and G12) which each have distinct
> + * workaround sets.  The G11 and G12 forks of the DG2 design reset the GT
> + * stepping back to "A0" for their first iterations, even though they're more
> + * similar to a G10 B0 stepping and G10 C0 stepping respectively in terms of
> + * functionality and workarounds.  However the display stepping does not 
> reset
> + * in the same manner --- a specific stepping like "B0" has a consistent
> + * meaning regardless of whether it belongs to a G10, G11, or G12 DG2.
>   *
>   * TLDR:  All GT workarounds and stepping-specific logic must be applied in
> - * relation to a specific subplatform (G10 or G11), whereas display 
> workarounds
> + * relation to a specific subplatform (G10/G11/G12), whereas display
> workarounds
>   * and stepping-specific logic will be applied with a general DG2-wide 
> stepping
>   * number.
>   */
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 3699b1c539ea..364abcc7aa54 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -96,7 +96,7 @@ enum intel_platform {
>   * it is fine for the same bit to be used on multiple parent platforms.
>   */
> 
> -#define INTEL_SUBPLATFORM_BITS (2)
> +#define INTEL_SUBPLATFORM_BITS (3)
>  #define INTEL_SUBPLATFORM_MASK (BIT(INTEL_SUBPLATFORM_BITS) - 1)
> 
>  /* HSW/BDW/SKL/KBL/CFL */
> @@ -109,6 +109,7 @@ enum intel_platform {
>  /* DG2 */
>  #define INTEL_SUBPLATFORM_G100
>  #define 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for discrete card 64K page support (rev5)

[Patchwork]

== Series Details ==

Series: discrete card 64K page support (rev5)
URL   : https://patchwork.freedesktop.org/series/99119/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for discrete card 64K page support (rev5)

[Patchwork]

== Series Details ==

Series: discrete card 64K page support (rev5)
URL   : https://patchwork.freedesktop.org/series/99119/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
640354f70085 drm/i915: add needs_compact_pt flag
7dc2679d906a drm/i915: enforce min GTT alignment for discrete cards
-:298: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#298: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:457:
+   if (offset < hole_start + 
aligned_size)

-:310: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#310: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:481:
+   if (offset + aligned_size > 
hole_end)

-:328: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#328: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:497:
+   if (offset < hole_start + 
aligned_size)

-:340: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#340: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:520:
+   if (offset + aligned_size > 
hole_end)

-:358: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#358: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:536:
+   if (offset < hole_start + 
aligned_size)

-:370: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#370: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:560:
+   if (offset + aligned_size > 
hole_end)

-:388: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#388: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:576:
+   if (offset < hole_start + 
aligned_size)

-:400: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#400: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:599:
+   if (offset + aligned_size > 
hole_end)

total: 0 errors, 8 warnings, 0 checks, 434 lines checked
969ac009dcff drm/i915: support 64K GTT pages for discrete cards
0fa221774a2e drm/i915: add gtt misalignment test
9d2612a88ac0 drm/i915/uapi: document behaviour for DG2 64K support

[Intel-gfx] [PATCH v7 4/5] drm/i915: add gtt misalignment test

[Robert Beckett]

add test to check handling of misaligned offsets and sizes

v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot 
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 128 ++
 1 file changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..9afea008192d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
  *
  */
 
+#include "gt/intel_gtt.h"
 #include 
 #include 
 
 #include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
 #include "gem/selftests/mock_context.h"
 #include "gt/intel_context.h"
 #include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,120 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
 }
 
+static int misaligned_case(struct i915_address_space *vm, struct 
intel_memory_region *mr,
+  u64 addr, u64 size, unsigned long flags)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int err = 0;
+   u64 expected_vma_size, expected_node_size;
+
+   obj = i915_gem_object_create_region(mr, size, 0, 0);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   vma = i915_vma_instance(obj, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_put;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, addr | flags);
+   if (err)
+   goto err_put;
+   i915_vma_unpin(vma);
+
+   if (!drm_mm_node_allocated(>node)) {
+   err = -EINVAL;
+   goto err_put;
+   }
+
+   if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+   err = -EINVAL;
+   goto err_put;
+   }
+
+   expected_vma_size = round_up(size, 1 << 
(ffs(vma->resource->page_sizes_gtt) - 1));
+   expected_node_size = expected_vma_size;
+
+   if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+   /* compact-pt should expand lmem node to 2MB */
+   expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+   expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+   }
+
+   if (vma->size != expected_vma_size || vma->node.size != 
expected_node_size) {
+   err = i915_vma_unbind_unlocked(vma);
+   err = -EBADSLT;
+   goto err_put;
+   }
+
+   err = i915_vma_unbind_unlocked(vma);
+   if (err)
+   goto err_put;
+
+   GEM_BUG_ON(drm_mm_node_allocated(>node));
+
+err_put:
+   i915_gem_object_put(obj);
+   cleanup_freed_objects(vm->i915);
+   return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+   struct intel_memory_region *mr;
+   enum intel_region_id id;
+   unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+   int err = 0;
+   u64 hole_size = hole_end - hole_start;
+
+   if (i915_is_ggtt(vm))
+   flags |= PIN_GLOBAL;
+
+   for_each_memory_region(mr, vm->i915, id) {
+   u64 min_alignment = i915_vm_min_alignment(vm, (enum 
intel_memory_type)id);
+   u64 size = min_alignment;
+   u64 addr = round_up(hole_start + (hole_size / 2), 
min_alignment);
+
+   /* we can't test < 4k alignment due to flags being encoded in 
lower bits */
+   if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+   err = misaligned_case(vm, mr, addr + (min_alignment / 
2), size, flags);
+   /* misaligned should error with -EINVAL*/
+   if (!err)
+   err = -EBADSLT;
+   if (err != -EINVAL)
+   return err;
+   }
+
+   /* test for vma->size expansion to min page size */
+   err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+   if (min_alignment > hole_size) {
+   if (!err)
+   err = -EBADSLT;
+   else if (err == -ENOSPC)
+   err = 0;
+   }
+   if (err)
+   return err;
+
+   /* test for intermediate size not expanding vma->size for large 
alignments */
+   err = misaligned_case(vm, mr, addr, size / 2, flags);
+   if (min_alignment > hole_size) {
+   if (!err)
+   err = -EBADSLT;
+   else 

[Intel-gfx] [PATCH v7 5/5] drm/i915/uapi: document behaviour for DG2 64K support

[Robert Beckett]

From: Matthew Auld 

On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.

v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Acked-by: Jordan Justen 
Reviewed-by: Ramalingam C 
Reviewed-by: Thomas Hellström 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
 include/uapi/drm/i915_drm.h | 44 -
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
 * When the EXEC_OBJECT_PINNED flag is specified this is populated by
 * the user with the GTT offset at which this object will be pinned.
+*
 * When the I915_EXEC_NO_RELOC flag is specified this must contain the
 * presumed_offset of the object.
+*
 * During execbuffer2 the kernel populates it with the value of the
 * current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
 */
__u64 offset;
 
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects.  Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+*   1) The entire PDE (which covers a 2MB virtual address range), must
+*   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+*   PDE is forbidden by the hardware.
+*
+*   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+*   objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
 */
__u64 size;
/**
-- 
2.25.1

[Intel-gfx] [PATCH v7 3/5] drm/i915: support 64K GTT pages for discrete cards

[Robert Beckett]

From: Matthew Auld 

discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.

v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot 

Signed-off-by: Matthew Auld 
Signed-off-by: Stuart Summers 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  60 ++
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 108 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   1 +
 4 files changed, 169 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
 }
 
+static int igt_ppgtt_compact(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct drm_i915_gem_object *obj;
+   int err;
+
+   /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+   if (!HAS_64K_PAGES(i915)) {
+   pr_info("device lacks compact 64K page support, skipping\n");
+   return 0;
+   }
+
+   if (!HAS_LMEM(i915)) {
+   pr_info("device lacks LMEM support, skipping\n");
+   return 0;
+   }
+
+   /* We want the range to cover multiple page-table boundaries. */
+   obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err)
+   goto out_put;
+
+   if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+   pr_info("LMEM compact unable to allocate huge-page(s)\n");
+   goto out_unpin;
+   }
+
+   /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+   obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+   err = igt_write_huge(i915, obj);
+   if (err)
+   pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+
+   if (err == -ENOMEM)
+   err = 0;
+
+   return err;
+}
+
 static int igt_tmpfs_fallback(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct 
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+   SUBTEST(igt_ppgtt_compact),
};
 
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * 
const vm,
   start, end, lvl);
} else {
unsigned int count;
+   unsigned int pte = gen8_pd_index(start, 0);
+   unsigned int num_ptes;
u64 *vaddr;
 
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * 
const vm,
atomic_read(>used));
GEM_BUG_ON(!count || count >= atomic_read(>used));
 
+   num_ptes = count;
+   if (pt->is_compact) {
+   GEM_BUG_ON(num_ptes % 16);
+   GEM_BUG_ON(pte % 16);
+   num_ptes /= 16;
+   pte /= 16;
+   }
+
vaddr = px_vaddr(pt);
-   memset64(vaddr + gen8_pd_index(start, 0),
+   memset64(vaddr + pte,
 vm->scratch[0]->encode,
-count);
+num_ptes);
 
  

[Intel-gfx] [PATCH v7 2/5] drm/i915: enforce min GTT alignment for discrete cards

[Robert Beckett]

From: Matthew Auld 

For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.

We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.

For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.

v3:
* use needs_compact_pt flag to discriminate between
  64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
  if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
  have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 .../i915/gem/selftests/i915_gem_client_blt.c  | 21 ++--
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 12 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 18 
 drivers/gpu/drm/i915/i915_vma.c   |  9 ++
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
 5 files changed, 115 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+   u64 align;
u32 width;
u32 height;
 };
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct 
rnd_state *prng)
goto err_free;
}
 
-   hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+   t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+   t->align = max(t->align,
+  i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+   hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
-   hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+   hole_size += 2 * t->align; /* padding on either side */
 
mutex_lock(>ce->vm->mutex);
memset(, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(>ce->vm->mm, ,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
  0, U64_MAX,
  DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct 
rnd_state *prng)
goto err_put;
}
 
-   t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+   t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
 
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
 static int tiled_blits_prepare(struct tiled_blits *t,
   struct rnd_state *prng)
 {
-   u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+   u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
 
 static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
 {
-   u64 offset =
-   round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+   u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
 
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct 
rnd_state *prng)
 
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+>buffers[2], t->hole + t->align,
 >buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space 
*vm, int subclass)
 
GEM_BUG_ON(!vm->total);
drm_mm_init(>mm, 0, vm->total);
+
+   memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+   

[Intel-gfx] [PATCH v7 0/5] discrete card 64K page support

[Robert Beckett]

This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from 
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:

- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for lmem buffers
- enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert
- expand vma reservation to round up to 2MB on DG2 in i915_vma_insert
- add alignment test

v2: rebase and fix for async vma that landed
v3:
* fix uapi doc typos
* add needs_compact_pt flag patch
* cleanup vma expansion to use vm->min_alignment instead of hard coding
v4:
* fix err return in igt_ppgtt_compact test
* placate ci robot with explicit enum conversion in misaligned_pin
* remove some blank lines
v5:
* fix obj alignment requirements querying for internal buffers that
  have no memory region associated. (fixes v3 bug)
v6:
* use NEEDS_COMPACT_PT inead of hard coding in misalignment test
* tiled_blits_create correctly pick largest required alignment
* minor doc formatting
v7:
* use i915_vma_unbind_unlocked in misalignment test

Reviewed-by: Thomas Hellström 

Matthew Auld (3):
  drm/i915: enforce min GTT alignment for discrete cards
  drm/i915: support 64K GTT pages for discrete cards
  drm/i915/uapi: document behaviour for DG2 64K support

Ramalingam C (1):
  drm/i915: add needs_compact_pt flag

Robert Beckett (1):
  drm/i915: add gtt misalignment test

 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  60 +
 .../i915/gem/selftests/i915_gem_client_blt.c  |  21 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 108 -
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  12 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  21 ++
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |  11 +-
 drivers/gpu/drm/i915/i915_pci.c   |   2 +
 drivers/gpu/drm/i915/i915_vma.c   |   9 +
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 224 +++---
 include/uapi/drm/i915_drm.h   |  44 +++-
 12 files changed, 462 insertions(+), 52 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v7 1/5] drm/i915: add needs_compact_pt flag

[Robert Beckett]

From: Ramalingam C 

Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.

With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.

v6:
* minor doc formatting

Suggested-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_drv.h  | 11 ---
 drivers/gpu/drm/i915/i915_pci.c  |  2 ++
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 /*
  * Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
  */
 #define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
 
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
 #define HAS_IPC(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ipc)
 
 #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+   .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+   .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+   func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
-- 
2.25.1

Re: [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message

[Lucas De Marchi]

On Tue, Feb 01, 2022 at 09:12:05AM -0800, Jose Souza wrote:

On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:

Only x86 and in some cases PPC have support added in drm_cache.c for the
clflush class of functions. However warning once is sufficient to taint
the log instead of spamming it with "Architecture has no drm_cache.c
support" every few millisecond. Switch to WARN_ONCE() so we still get
the log message, but only once, together with the warning. E.g:

[ cut here ]
Architecture has no drm_cache.c support
WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 
drm_clflush_sg+0x40/0x50 [drm]
...

v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err()


Reviewed-by: José Roberto de Souza 

But while at it, why not add a drm_device parameter to this function so we can 
use drm_WARN_ONCE()?
Anyways, it is better than before.


I thought about that, but it didn't seem justifiable because:

1) drm_WARN_ONCE will basically add dev_driver_string() to the log.
However the warning message here is basically helping the bootstrap of
additional archs. They shouldn't be seen on anything properly supported.

2) This seems all to be a layer below drm anyway and could even be used
in places outside easy access to a drm pointer.

So, it seems the benefit of using the subsystem-specific drm_WARN_ONCE
doesn't justify the hassle of changing the callers, possibly adding
additional back pointers to have access to the drm device pointer.

thanks
Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.IGT: failure for Compile out integrated

[Patchwork]

== Series Details ==

Series: Compile out integrated
URL   : https://patchwork.freedesktop.org/series/99570/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11172_full -> Patchwork_22149_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22149_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22149_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22149_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@fence-restore-untiled:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl4/igt@i915_susp...@fence-restore-untiled.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl8/igt@i915_susp...@fence-restore-untiled.html

  * igt@kms_setmode@basic:
- shard-skl:  NOTRUN -> [WARN][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl4/igt@kms_setm...@basic.html

  
Known issues


  Here are the changes found in Patchwork_22149_full that come from known 
issues:

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][4], [PASS][5], [PASS][6], [PASS][7], 
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], 
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [FAIL][19], 
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
[PASS][50], [PASS][51])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl10/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl10/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl10/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/shard-skl10/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl4/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/shard-skl4/boot.html
   [36]: 

Re: [Intel-gfx] [RFC 0/2] Compile out integrated

[Lucas De Marchi]

On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote:

On Tue, 01 Feb 2022, Lucas De Marchi  wrote:

On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Quicky and dirty hack based on some old ideas. Thought maybe the approach might
interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so
big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked
into that side.

3884664  4496816720 4341065  423d49 i915.ko.tip
3599989  4290346688 4035711  3d947f i915.ko.noigp


By these numbers probably it's hard to justify. Another thing to consider
is that it's very common to have on the same system both
integrated and discrete - doing this would remove at compile time any
chance of driving the integrated one.


I guess the point was, the arm systems won't have integrated, and it's
anyway going to be a separate build.


so probably the focus and argument here should not be about size
reduction. From patch 1 I see:

+config DRM_I915_INTEGRATED_GPU_SUPPORT
+   bool "Support integrated GPUs"
+   default y
+   depends on DRM_I915
+   help
+ Include support for integrated GPUs.

If it's something that depends on arch rather than providing an
option in menuconfig, then I think it could be some interesting
investigation. However, I can't see how it would help with removing
some code paths in the driver (e.g. the clflush() calls we were talking
about in another patch series) since the code elimination would all
happen at link time.

Lucas De Marchi




BR,
Jani.




Lucas De Marchi



Note debug kconfig so everything is inflated. Whether or not the relative gain
would change with production kconfig I am not sure.

P.S.
I was a bit curious there were no build errors around functions no longer used
so either there were none (would mean patch is not really that effective), or
something changed with compiler warnings/smarts. Haven't looked into it.

Tvrtko Ursulin (2):
 igp kconfig
 jsl/ehl

drivers/gpu/drm/i915/Kconfig  |   5 +
drivers/gpu/drm/i915/Kconfig.platforms|   7 +
.../drm/i915/display/intel_ddi_buf_trans.c|   4 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
drivers/gpu/drm/i915/i915_drv.h   | 128 +++---
drivers/gpu/drm/i915/i915_pci.c   |  44 +-
6 files changed, 134 insertions(+), 56 deletions(-)
create mode 100644 drivers/gpu/drm/i915/Kconfig.platforms

--
2.32.0



--
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Do not spam log with missing arch support

[Souza, Jose]

On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Following what was done in drm_cache.c, when the stub for
> remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip
> remap_io_mapping() for non-x86 platforms"), it included a log message
> with pr_err().  However just the warning is already enough and switching
> to WARN_ONCE() allows us to keep the log message while avoiding log
> spam.

Reviewed-by: José Roberto de Souza 

But same suggestion as the first patch in this series about drm_WARN_ONCE().

> 
> Signed-off-by: Lucas De Marchi 
> ---
> 
> v3: No changes from previous version, just submitting to the right
> mailing list
> 
>  drivers/gpu/drm/i915/i915_mm.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 3ad22bbe80eb..04c8974d822b 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -23,8 +23,7 @@ int remap_io_mapping(struct vm_area_struct *vma,
>unsigned long addr, unsigned long pfn, unsigned long size,
>struct io_mapping *iomap)
>  {
> - pr_err("Architecture has no %s() and shouldn't be calling this 
> function\n", __func__);
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
>   return 0;
>  }
>  #endif

Re: [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message

[Souza, Jose]

On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Only x86 and in some cases PPC have support added in drm_cache.c for the
> clflush class of functions. However warning once is sufficient to taint
> the log instead of spamming it with "Architecture has no drm_cache.c
> support" every few millisecond. Switch to WARN_ONCE() so we still get
> the log message, but only once, together with the warning. E.g:
> 
>   [ cut here ]
>   Architecture has no drm_cache.c support
>   WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 
> drm_clflush_sg+0x40/0x50 [drm]
>   ...
> 
> v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err()

Reviewed-by: José Roberto de Souza 

But while at it, why not add a drm_device parameter to this function so we can 
use drm_WARN_ONCE()?
Anyways, it is better than before.

> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Lucas De Marchi 
> ---
> 
> v3: No changes from previous version, just submitting to the right
> mailing list
> 
>  drivers/gpu/drm/drm_cache.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index f19d9acbe959..2c3fa5677f7e 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -112,8 +112,7 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>   kunmap_atomic(page_virtual);
>   }
>  #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
>  #endif
>  }
>  EXPORT_SYMBOL(drm_clflush_pages);
> @@ -143,8 +142,7 @@ drm_clflush_sg(struct sg_table *st)
>   if (wbinvd_on_all_cpus())
>   pr_err("Timed out waiting for cache flush\n");
>  #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
>  #endif
>  }
>  EXPORT_SYMBOL(drm_clflush_sg);
> @@ -177,8 +175,7 @@ drm_clflush_virt_range(void *addr, unsigned long length)
>   if (wbinvd_on_all_cpus())
>   pr_err("Timed out waiting for cache flush\n");
>  #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
>  #endif
>  }
>  EXPORT_SYMBOL(drm_clflush_virt_range);

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix header test for !CONFIG_X86

[Souza, Jose]

On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Architectures others than x86 have a stub implementation calling
> WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
> the header-test target will fail with:
> 
>   HDRTEST drivers/gpu/drm/i915/i915_mm.h
> In file included from :
> ./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
> ./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of 
> function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
>26 |  WARN_ON_ONCE(1);
>   |  ^~~~
> 
> v2: Do not include  since call to pr_err() has been
> removed

Reviewed-by: José Roberto de Souza 

> 
> Fixes: 67c430bbaae1 ("drm/i915: Skip remap_io_mapping() for non-x86 
> platforms")
> Cc: Siva Mullati 
> Signed-off-by: Lucas De Marchi 
> ---
> 
> v3: No changes from previous version, just submitting to the right
> mailing list
> 
>  drivers/gpu/drm/i915/i915_mm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 76f1d53bdf34..3ad22bbe80eb 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -6,6 +6,7 @@
>  #ifndef __I915_MM_H__
>  #define __I915_MM_H__
>  
> +#include 
>  #include 
>  
>  struct vm_area_struct;

Re: [Intel-gfx] [RFC 0/2] Compile out integrated

[Jani Nikula]

On Tue, 01 Feb 2022, Lucas De Marchi  wrote:
> On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote:
>>From: Tvrtko Ursulin 
>>
>>Quicky and dirty hack based on some old ideas. Thought maybe the approach 
>>might
>>interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not 
>>so
>>big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't 
>>looked
>>into that side.
>>
>> 3884664  4496816720 4341065  423d49 i915.ko.tip
>> 3599989  4290346688 4035711  3d947f i915.ko.noigp
>
> By these numbers probably it's hard to justify. Another thing to consider
> is that it's very common to have on the same system both
> integrated and discrete - doing this would remove at compile time any
> chance of driving the integrated one.

I guess the point was, the arm systems won't have integrated, and it's
anyway going to be a separate build.

BR,
Jani.


>
> Lucas De Marchi
>
>>
>>Note debug kconfig so everything is inflated. Whether or not the relative gain
>>would change with production kconfig I am not sure.
>>
>>P.S.
>>I was a bit curious there were no build errors around functions no longer used
>>so either there were none (would mean patch is not really that effective), or
>>something changed with compiler warnings/smarts. Haven't looked into it.
>>
>>Tvrtko Ursulin (2):
>>  igp kconfig
>>  jsl/ehl
>>
>> drivers/gpu/drm/i915/Kconfig  |   5 +
>> drivers/gpu/drm/i915/Kconfig.platforms|   7 +
>> .../drm/i915/display/intel_ddi_buf_trans.c|   4 +-
>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
>> drivers/gpu/drm/i915/i915_drv.h   | 128 +++---
>> drivers/gpu/drm/i915/i915_pci.c   |  44 +-
>> 6 files changed, 134 insertions(+), 56 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/Kconfig.platforms
>>
>>-- 
>>2.32.0
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [RFC 0/2] Compile out integrated

[Lucas De Marchi]

On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Quicky and dirty hack based on some old ideas. Thought maybe the approach might
interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so
big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked
into that side.

3884664  4496816720 4341065  423d49 i915.ko.tip
3599989  4290346688 4035711  3d947f i915.ko.noigp


By these numbers probably it's hard to justify. Another thing to consider
is that it's very common to have on the same system both
integrated and discrete - doing this would remove at compile time any
chance of driving the integrated one.

Lucas De Marchi



Note debug kconfig so everything is inflated. Whether or not the relative gain
would change with production kconfig I am not sure.

P.S.
I was a bit curious there were no build errors around functions no longer used
so either there were none (would mean patch is not really that effective), or
something changed with compiler warnings/smarts. Haven't looked into it.

Tvrtko Ursulin (2):
 igp kconfig
 jsl/ehl

drivers/gpu/drm/i915/Kconfig  |   5 +
drivers/gpu/drm/i915/Kconfig.platforms|   7 +
.../drm/i915/display/intel_ddi_buf_trans.c|   4 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
drivers/gpu/drm/i915/i915_drv.h   | 128 +++---
drivers/gpu/drm/i915/i915_pci.c   |  44 +-
6 files changed, 134 insertions(+), 56 deletions(-)
create mode 100644 drivers/gpu/drm/i915/Kconfig.platforms

--
2.32.0

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/: Re-work clflush_write32

[Tvrtko Ursulin]

On 01/02/2022 15:41, Michael Cheng wrote:
Ah, thanks for the clarification! While discussion goes on about the 
route you suggested, could we land these patches (after addressing the 
reviews) to unblock compiling i915 on arm?


I am 60-40 to no, since follow up can be hard. I'd prefer a little bit 
of discussion before merging.


Also, what will be the Arm implementation of drm_clflush_virt_range? 
Noob question - why is i915 the only driver calling it? Do other GPUs 
never need to flush CPU cache?


Regards,

Tvrtko


On 2022-02-01 1:25 a.m., Tvrtko Ursulin wrote:


On 31/01/2022 17:02, Michael Cheng wrote:

Hey Tvrtko,

Are you saying when adding drm_clflush_virt_range(addr, sizeof(addr), 
this function forces an x86 code path only? If that is the case, 
drm_clflush_virt_range(addr, sizeof(addr) currently has ifdefs that 
seperate out x86 and powerpc, so we can add an ifdef for arm in the 
near future when needed.


No, I was noticing that the change you are making in this patch, while 
it indeed fixes a build failure, it is a code path which does not get 
executed on Arm at all.


So what effectively happens is a single assembly instruction gets 
replaced with a function call on all integrated GPUs up to and 
including Tigerlake.


That was the slightly annoying part I was referring to and asking 
whether it was discussed before.


Sadly I don't think there is a super nice solution apart from 
duplicating drm_clflush_virt_range as for example i915_clflush_range 
and having it static inline. That would allow the integrated GPU code 
path to remain of the same performance profile, while solving the Arm 
problem. However it would be code duplication so might be frowned upon.


I'd be tempted to go that route but it is something which needs a bit 
of discussion if that hasn't happened already.


Regards,

Tvrtko


On 2022-01-31 6:55 a.m., Tvrtko Ursulin wrote:

On 28/01/2022 22:10, Michael Cheng wrote:

Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.

Signed-off-by: Michael Cheng 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
  static void clflush_write32(u32 *addr, u32 value, unsigned int 
flushes)

  {
  if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
-    if (flushes & CLFLUSH_BEFORE) {
-    clflushopt(addr);
-    mb();
-    }
+    if (flushes & CLFLUSH_BEFORE)
+    drm_clflush_virt_range(addr, sizeof(addr));
    *addr = value;
  @@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 
value, unsigned int flushes)

   * to ensure ordering of clflush wrt to the system.
   */
  if (flushes & CLFLUSH_AFTER)
-    clflushopt(addr);
+    drm_clflush_virt_range(addr, sizeof(addr));
  } else
  *addr = value;
  }


Slightly annoying thing here (maybe in some other patches from the 
series as well) is that the change adds a function call to x86 only 
code path, because relocations are not supported on discrete as per:


static in
eb_validate_vma(...)
    /* Relocations are disallowed for all platforms after 
TGL-LP. This

 * also covers all platforms with local memory.
 */

    if (entry->relocation_count &&
    GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
    return -EINVAL;

How acceptable would be, for the whole series, to introduce a static 
inline i915 cluflush wrapper and so be able to avoid functions calls 
on x86? Is this something that has been discussed and discounted 
already?


Regards,

Tvrtko

P.S. Hmm I am now reminded of my really old per platform build 
patches. With them you would be able to compile out large portions 
of the driver when building for ARM. Probably like a 3rd if my 
memory serves me right.

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Daniel Vetter]

On Tue, Feb 1, 2022 at 3:52 PM Helge Deller  wrote:
>
> On 2/1/22 14:45, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 12:01 PM Helge Deller  wrote:
> >> On 2/1/22 11:36, Daniel Vetter wrote:
> >>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller  wrote:
> 
>  On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
> 
>  you have two trivial copy-n-paste errors in this patch which still 
>  prevent the
>  console acceleration.
> >>>
> >>> Duh :-(
> >>>
> >>> But before we dig into details I think the big picture would be
> >>> better. I honestly don't like the #ifdef pile here that much.
> >>
> >> Me neither.
> >> The ifdefs give a better separation, but prevents that the compiler
> >> checks the various paths when building.
> >>
> >>> I wonder whether your approach, also with GETVX/YRES adjusted
> >>> somehow, wouldn't look cleaner?
> >> I think so.
> >> You wouldn't even need to touch GETVX/YRES because the compiler
> >> will optimize/reduce it from
> >>
> >> #define GETVYRES(s,i) ({   \
> >> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> >> (i)->var.yres : (i)->var.yres_virtual; })
> >>
> >> to just become:
> >>
> >> #define GETVYRES(s,i) ((i)->var.yres)
> >
> > Yeah, but you need to roll out your helper to all the callsites. But
> > since you #ifdef out info->scrollmode we should catch them all I
> > guess.
>
> Right. That was the only reason why I ifdef'ed it out.
> Technically we don't need that ifdef.
>
> >>> Like I said in the cover letter I got mostly distracted with fbcon
> >>> locking last week, not really with this one here at all, so maybe
> >>> going with your 4 (or 2 if we squash them like I did here) patches is
> >>> neater?
> >>
> >> The benefit of my patch series was, that it could be easily backported 
> >> first,
> >> and then cleaned up afterwards. Even a small additional backport patch to 
> >> disable
> >> the fbcon acceleration for DRM in the old releases would be easy.
> >> But I'm not insisting on backporting the patches, if we find good way 
> >> forward.
> >>
> >> So, either with the 4 (or 2) patches would be OK for me (or even your 
> >> approach).
> >
> > The idea behind the squash was that it's then impossible to backport
> > without the Kconfig,
>
> Yes, my proposal was to simply revert the 2 patches and immediatly send
> the Kconfig patch to disable it again.
>
> > and so we'll only enable this code when people
> > intentionally want it. Maybe I'm too paranoid?
>
> I think you are too paranoid :-)
> If all patches incl. the Kconfig patch are backported then people shouldn't
> do it wrong.
>
> > Anyway, you feel like finishing off your approach? Or should I send
> > out v2 of this with the issues fixed you spotted? Like I said either
> > is fine with me.
>
> Ok, then let me try to finish my approach until tomorrow, and then you
> check if you can and want to add your locking and other patches on top of it.
> In the end I leave the decision which approach to take to you.
> Ok?

Sounds good, and yeah rough idea is that the maintainers + revert +
Kconfig should go in for rc3 or rc4 if we hit another bump, and the
locking stuff then in for -next (since it needs a backmerge and is
defo tricky stuff).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Improve error message when insufficient privilege

[Dixit, Ashutosh]

On Tue, 01 Feb 2022 07:19:46 -0800, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin 
>
> Print out end user friendly help text when the running user has
> insufficient privilege for accessing system wide performance counters.

Reviewed-by: Ashutosh Dixit 

> Signed-off-by: Tvrtko Ursulin 
> Issue: https://gitlab.freedesktop.org/drm/intel/-/issues/5018
> ---
>  tools/intel_gpu_top.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
> index 81c724d1fe1c..0404a5881b40 100644
> --- a/tools/intel_gpu_top.c
> +++ b/tools/intel_gpu_top.c
> @@ -1761,6 +1761,15 @@ int main(int argc, char **argv)
>   if (ret) {
>   fprintf(stderr,
>   "Failed to initialize PMU! (%s)\n", strerror(errno));
> + if (errno == EACCES && geteuid())
> + fprintf(stderr,
> +"\n"
> +"When running as a normal user CAP_PERFMON is required to access 
> performance\n"
> +"monitoring. See \"man 7 capabilities\", \"man 8 setcap\", or contact your\n"
> +"distribution vendor for assistance.\n"
> +"\n"
> +"More information can be found at 'Perf events and tool security' 
> document:\n"
> +"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n;);
>   ret = EXIT_FAILURE;
>   goto err;
>   }
> --
> 2.32.0
>

Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference

[Jani Nikula]

Thanks for the patch, adding some Cc's from the commit that regressed.

BR,
Jani.

On Tue, 01 Feb 2022, Lukasz Bartosik  wrote:
> From: Łukasz Bartosik 
>
> Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
> The root cause is null pointer defeference of bi_next
> in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
>
> BUG: kernel NULL pointer dereference, address: 002e
> PGD 0 P4D 0
> Oops: 0002 [#1] PREEMPT SMP NOPTI
> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U5.17.0-rc1
> Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
> RIP: 0010:tgl_get_bw_info+0x2de/0x510
> ...
> [2.554467] Call Trace:
> [2.554467]  
> [2.554467]  intel_bw_init_hw+0x14a/0x434
> [2.554467]  ? _printk+0x59/0x73
> [2.554467]  ? _dev_err+0x77/0x91
> [2.554467]  i915_driver_hw_probe+0x329/0x33e
> [2.554467]  i915_driver_probe+0x4c8/0x638
> [2.554467]  i915_pci_probe+0xf8/0x14e
> [2.554467]  ? _raw_spin_unlock_irqrestore+0x12/0x2c
> [2.554467]  pci_device_probe+0xaa/0x142
> [2.554467]  really_probe+0x13f/0x2f4
> [2.554467]  __driver_probe_device+0x9e/0xd3
> [2.554467]  driver_probe_device+0x24/0x7c
> [2.554467]  __driver_attach+0xba/0xcf
> [2.554467]  ? driver_attach+0x1f/0x1f
> [2.554467]  bus_for_each_dev+0x8c/0xc0
> [2.554467]  bus_add_driver+0x11b/0x1f7
> [2.554467]  driver_register+0x60/0xea
> [2.554467]  ? mipi_dsi_bus_init+0x16/0x16
> [2.554467]  i915_init+0x2c/0xb9
> [2.554467]  ? mipi_dsi_bus_init+0x16/0x16
> [2.554467]  do_one_initcall+0x12e/0x2b3
> [2.554467]  do_initcall_level+0xd6/0xf3
> [2.554467]  do_initcalls+0x4e/0x79
> [2.554467]  kernel_init_freeable+0xed/0x14d
> [2.554467]  ? rest_init+0xc1/0xc1
> [2.554467]  kernel_init+0x1a/0x120
> [2.554467]  ret_from_fork+0x1f/0x30
> [2.554467]  
> ...
> Kernel panic - not syncing: Fatal exception
>
> Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
> Signed-off-by: Łukasz Bartosik 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 2da4aacc956b..bd0ed68b7faa 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -404,15 +404,17 @@ static int tgl_get_bw_info(struct drm_i915_private 
> *dev_priv, const struct intel
>   int clpchgroup;
>   int j;
>  
> - if (i < num_groups - 1)
> - bi_next = _priv->max_bw[i + 1];
> -
>   clpchgroup = (sa->deburst * qi.deinterleave / num_channels) << 
> i;
>  
> - if (i < num_groups - 1 && clpchgroup < clperchgroup)
> - bi_next->num_planes = (ipqdepth - clpchgroup) / 
> clpchgroup + 1;
> - else
> - bi_next->num_planes = 0;
> + if (i < num_groups - 1) {
> + bi_next = _priv->max_bw[i + 1];
> +
> + if (clpchgroup < clperchgroup)
> + bi_next->num_planes = (ipqdepth - clpchgroup) /
> +clpchgroup + 1;
> + else
> + bi_next->num_planes = 0;
> + }
>  
>   bi->num_qgv_points = qi.num_points;
>   bi->num_psf_gv_points = qi.num_psf_points;

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/: Re-work clflush_write32

[Michael Cheng]

Ah, thanks for the clarification! While discussion goes on about the 
route you suggested, could we land these patches (after addressing the 
reviews) to unblock compiling i915 on arm?


On 2022-02-01 1:25 a.m., Tvrtko Ursulin wrote:


On 31/01/2022 17:02, Michael Cheng wrote:

Hey Tvrtko,

Are you saying when adding drm_clflush_virt_range(addr, sizeof(addr), 
this function forces an x86 code path only? If that is the case, 
drm_clflush_virt_range(addr, sizeof(addr) currently has ifdefs that 
seperate out x86 and powerpc, so we can add an ifdef for arm in the 
near future when needed.


No, I was noticing that the change you are making in this patch, while 
it indeed fixes a build failure, it is a code path which does not get 
executed on Arm at all.


So what effectively happens is a single assembly instruction gets 
replaced with a function call on all integrated GPUs up to and 
including Tigerlake.


That was the slightly annoying part I was referring to and asking 
whether it was discussed before.


Sadly I don't think there is a super nice solution apart from 
duplicating drm_clflush_virt_range as for example i915_clflush_range 
and having it static inline. That would allow the integrated GPU code 
path to remain of the same performance profile, while solving the Arm 
problem. However it would be code duplication so might be frowned upon.


I'd be tempted to go that route but it is something which needs a bit 
of discussion if that hasn't happened already.


Regards,

Tvrtko


On 2022-01-31 6:55 a.m., Tvrtko Ursulin wrote:

On 28/01/2022 22:10, Michael Cheng wrote:

Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.

Signed-off-by: Michael Cheng 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
  static void clflush_write32(u32 *addr, u32 value, unsigned int 
flushes)

  {
  if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
-    if (flushes & CLFLUSH_BEFORE) {
-    clflushopt(addr);
-    mb();
-    }
+    if (flushes & CLFLUSH_BEFORE)
+    drm_clflush_virt_range(addr, sizeof(addr));
    *addr = value;
  @@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 
value, unsigned int flushes)

   * to ensure ordering of clflush wrt to the system.
   */
  if (flushes & CLFLUSH_AFTER)
-    clflushopt(addr);
+    drm_clflush_virt_range(addr, sizeof(addr));
  } else
  *addr = value;
  }


Slightly annoying thing here (maybe in some other patches from the 
series as well) is that the change adds a function call to x86 only 
code path, because relocations are not supported on discrete as per:


static in
eb_validate_vma(...)
    /* Relocations are disallowed for all platforms after 
TGL-LP. This

 * also covers all platforms with local memory.
 */

    if (entry->relocation_count &&
    GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
    return -EINVAL;

How acceptable would be, for the whole series, to introduce a static 
inline i915 cluflush wrapper and so be able to avoid functions calls 
on x86? Is this something that has been discussed and discounted 
already?


Regards,

Tvrtko

P.S. Hmm I am now reminded of my really old per platform build 
patches. With them you would be able to compile out large portions 
of the driver when building for ARM. Probably like a 3rd if my 
memory serves me right.

[Intel-gfx] [PATCH i-g-t] intel_gpu_top: Improve error message when insufficient privilege

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Print out end user friendly help text when the running user has
insufficient privilege for accessing system wide performance counters.

Signed-off-by: Tvrtko Ursulin 
Issue: https://gitlab.freedesktop.org/drm/intel/-/issues/5018
---
 tools/intel_gpu_top.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 81c724d1fe1c..0404a5881b40 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1761,6 +1761,15 @@ int main(int argc, char **argv)
if (ret) {
fprintf(stderr,
"Failed to initialize PMU! (%s)\n", strerror(errno));
+   if (errno == EACCES && geteuid())
+   fprintf(stderr,
+"\n"
+"When running as a normal user CAP_PERFMON is required to access performance\n"
+"monitoring. See \"man 7 capabilities\", \"man 8 setcap\", or contact your\n"
+"distribution vendor for assistance.\n"
+"\n"
+"More information can be found at 'Perf events and tool security' document:\n"
+"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n;);
ret = EXIT_FAILURE;
goto err;
}
-- 
2.32.0

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Geert Uytterhoeven]

On Mon, Jan 31, 2022 at 10:06 PM Daniel Vetter  wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
> 35  Daniel Vetter
> 23  Linus Torvalds
> 10  Hans de Goede
>  9  Dave Airlie
>  6  Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.

> Signed-off-by: Daniel Vetter 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Helge Deller]

On 2/1/22 14:45, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 12:01 PM Helge Deller  wrote:
>> On 2/1/22 11:36, Daniel Vetter wrote:
>>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller  wrote:

 On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.

 you have two trivial copy-n-paste errors in this patch which still prevent 
 the
 console acceleration.
>>>
>>> Duh :-(
>>>
>>> But before we dig into details I think the big picture would be
>>> better. I honestly don't like the #ifdef pile here that much.
>>
>> Me neither.
>> The ifdefs give a better separation, but prevents that the compiler
>> checks the various paths when building.
>>
>>> I wonder whether your approach, also with GETVX/YRES adjusted
>>> somehow, wouldn't look cleaner?
>> I think so.
>> You wouldn't even need to touch GETVX/YRES because the compiler
>> will optimize/reduce it from
>>
>> #define GETVYRES(s,i) ({   \
>> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
>> (i)->var.yres : (i)->var.yres_virtual; })
>>
>> to just become:
>>
>> #define GETVYRES(s,i) ((i)->var.yres)
>
> Yeah, but you need to roll out your helper to all the callsites. But
> since you #ifdef out info->scrollmode we should catch them all I
> guess.

Right. That was the only reason why I ifdef'ed it out.
Technically we don't need that ifdef.

>>> Like I said in the cover letter I got mostly distracted with fbcon
>>> locking last week, not really with this one here at all, so maybe
>>> going with your 4 (or 2 if we squash them like I did here) patches is
>>> neater?
>>
>> The benefit of my patch series was, that it could be easily backported first,
>> and then cleaned up afterwards. Even a small additional backport patch to 
>> disable
>> the fbcon acceleration for DRM in the old releases would be easy.
>> But I'm not insisting on backporting the patches, if we find good way 
>> forward.
>>
>> So, either with the 4 (or 2) patches would be OK for me (or even your 
>> approach).
>
> The idea behind the squash was that it's then impossible to backport
> without the Kconfig,

Yes, my proposal was to simply revert the 2 patches and immediatly send
the Kconfig patch to disable it again.

> and so we'll only enable this code when people
> intentionally want it. Maybe I'm too paranoid?

I think you are too paranoid :-)
If all patches incl. the Kconfig patch are backported then people shouldn't
do it wrong.

> Anyway, you feel like finishing off your approach? Or should I send
> out v2 of this with the issues fixed you spotted? Like I said either
> is fine with me.

Ok, then let me try to finish my approach until tomorrow, and then you
check if you can and want to add your locking and other patches on top of it.
In the end I leave the decision which approach to take to you.
Ok?

Helge

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Jani Nikula]

On Mon, 31 Jan 2022, Daniel Vetter  wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
> 35  Daniel Vetter
> 23  Linus Torvalds
> 10  Hans de Goede
>  9  Dave Airlie
>  6  Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Cc: Linus Torvalds 
> Cc: Linux Fbdev development list 
> Cc: Pavel Machek 
> Cc: Sam Ravnborg 
> Cc: Greg Kroah-Hartman 
> Cc: Javier Martinez Canillas 
> Cc: DRI Development 
> Cc: Linux Kernel Mailing List 
> Cc: Claudio Suarez 
> Cc: Tomi Valkeinen 
> Cc: Geert Uytterhoeven 
> Cc: Thomas Zimmermann 
> Cc: Daniel Vetter 
> Cc: Sven Schnelle 
> Cc: Gerd Hoffmann 
> Signed-off-by: Daniel Vetter 

Acked-by: Jani Nikula 

> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
>  W:   http://floatingpoint.sourceforge.net/emulator/index.html
>  F:   arch/x86/math-emu/
>  
> +FRAMEBUFFER CORE
> +M:   Daniel Vetter 
> +F:   drivers/video/fbdev/core/
> +S:   Odd Fixes
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +
>  FRAMEBUFFER LAYER
>  M:   Helge Deller 
>  L:   linux-fb...@vger.kernel.org

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk()

[Lisovskiy, Stanislav]

On Tue, Feb 01, 2022 at 03:45:35PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 01, 2022 at 01:18:18PM +0200, Lisovskiy, Stanislav wrote:
> > On Tue, Feb 01, 2022 at 12:05:13PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 01, 2022 at 10:52:39AM +0200, Lisovskiy, Stanislav wrote:
> > > > On Tue, Jan 18, 2022 at 11:23:50AM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do 
> > > > > is
> > > > > somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is 
> > > > > no
> > > > > (at least documented) dbuf min cdclk limit on pre-skl so let's just 
> > > > > get
> > > > > rid of all this confusion.
> > > > > 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > 
> > > > I think we constantly have a bit contradictional attitude towards such 
> > > > situation.
> > > > >From one perspective you can say, that those kind of "leagcy" 
> > > > >callbacks are
> > > > pointless, from the other hand one might say. that we need to have a 
> > > > unified
> > > > approach for all platforms and I think we got, some legacy handlers for 
> > > > old
> > > > platforms for similar purpose as well.
> > > > I'm fine with both approaches, however for example when I was submitting
> > > > that patch, I was asked by reviewer to add this kind of legacy 
> > > > callback, so that we have
> > > > a "uniform" approach.
> > > > We just then need to have some standard agreement on those, which 
> > > > doesn't
> > > > depend on today's cosmic radiation levels :)
> > > 
> > > Yes in general I prefer a unified approach across all platforms.
> > > But in this case there is nothing to do for the old platforms as they
> > > don't have any kind of dbuf cdclk limit, or if there is one we don't
> > > know what it is since it's not documented.
> > > 
> > > So the only thing the code was really doing was conflating the
> > > per-pipe cdclk limit (which is handled elsewhere for all platforms
> > > in a  unified fashion) with something that doesn't even exist.
> > > 
> > > Also I don't think it was even correct anyway since it was
> > > using the per-pipe cdclk_state->min_cdclk[] already during
> > > intel_cdclk_atomic_check(), but cdclk_state->min_cdclk[]
> > > isn't even computed until intel_modeset_calc_cdclk() which 
> > > is called later. So I guess it was basically just computing 
> > > the max of the min_cdclk[] for all the pipes for the _old_
> > > state, not the new state.
> > 
> > No, I think actually the idea was that it was first calculating
> > new_bw_state->min_cdclk, based on plane and dbuf bandwidth requirements
> > in intel_atomic_check_cdclk,
> 
> Well intel_bw_calc_min_cdclk() did none of that. Like I said it
> just took the max of the _old_ per-pipe cdclk_state->min_cdclk[]
> values and stored that as the *new* bw min cdclk, which later
> would get consulted by intel_compute_min_cdclk().

Yeah, because it was a stub basically just for "uniformity".

Stan


> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Javier Martinez Canillas]

On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
> 
> $ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
> 35  Daniel Vetter
> 23  Linus Torvalds
> 10  Hans de Goede
>  9  Dave Airlie
>  6  Peter Rosin
> 
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
> 
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
> 
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Cc: Linus Torvalds 
> Cc: Linux Fbdev development list 
> Cc: Pavel Machek 
> Cc: Sam Ravnborg 
> Cc: Greg Kroah-Hartman 
> Cc: Javier Martinez Canillas 
> Cc: DRI Development 
> Cc: Linux Kernel Mailing List 
> Cc: Claudio Suarez 
> Cc: Tomi Valkeinen 
> Cc: Geert Uytterhoeven 
> Cc: Thomas Zimmermann 
> Cc: Daniel Vetter 
> Cc: Sven Schnelle 
> Cc: Gerd Hoffmann 
> Signed-off-by: Daniel Vetter 
> ---

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

[Intel-gfx] ✓ Fi.CI.BAT: success for Compile out integrated

[Patchwork]

== Series Details ==

Series: Compile out integrated
URL   : https://patchwork.freedesktop.org/series/99570/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11172 -> Patchwork_22149


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/index.html

Participating hosts (45 -> 44)
--

  Additional (1): fi-pnv-d510 
  Missing(2): shard-tglu fi-bdw-samus 

Known issues


  Here are the changes found in Patchwork_22149 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][1] -> [FAIL][2] ([i915#4547])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271]) +57 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271]) +62 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-bsw-nick/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][5] -> [INCOMPLETE][6] ([i915#3303])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@vga-edid-read:
- fi-bsw-nick:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-bsw-nick/igt@kms_chamel...@vga-edid-read.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_ctx_exec@basic:
- fi-bsw-nick:[DMESG-WARN][9] ([i915#3428]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-bsw-nick/igt@gem_ctx_e...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-bsw-nick/igt@gem_ctx_e...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [DMESG-FAIL][11] ([i915#5026]) -> [DMESG-FAIL][12] 
([i915#4528] / [i915#5026])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
  [i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026


Build changes
-

  * Linux: CI_DRM_11172 -> Patchwork_22149

  CI-20190529: 20190529
  CI_DRM_11172: 466c37c518256a1c79ed5f6ed4d3db1866c17910 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6337: 7c9c034619ef9dbfbfe041fbf3973a1cf1ac7a22 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22149: 528a41163c0e7f41362b7fcbb2b0934797df1e21 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

528a41163c0e jsl/ehl
15e05554122b igp kconfig

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22149/index.html

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk()

[Ville Syrjälä]

On Tue, Feb 01, 2022 at 01:18:18PM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Feb 01, 2022 at 12:05:13PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 01, 2022 at 10:52:39AM +0200, Lisovskiy, Stanislav wrote:
> > > On Tue, Jan 18, 2022 at 11:23:50AM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
> > > > somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
> > > > (at least documented) dbuf min cdclk limit on pre-skl so let's just get
> > > > rid of all this confusion.
> > > > 
> > > > Signed-off-by: Ville Syrjälä 
> > > 
> > > I think we constantly have a bit contradictional attitude towards such 
> > > situation.
> > > >From one perspective you can say, that those kind of "leagcy" callbacks 
> > > >are
> > > pointless, from the other hand one might say. that we need to have a 
> > > unified
> > > approach for all platforms and I think we got, some legacy handlers for 
> > > old
> > > platforms for similar purpose as well.
> > > I'm fine with both approaches, however for example when I was submitting
> > > that patch, I was asked by reviewer to add this kind of legacy callback, 
> > > so that we have
> > > a "uniform" approach.
> > > We just then need to have some standard agreement on those, which doesn't
> > > depend on today's cosmic radiation levels :)
> > 
> > Yes in general I prefer a unified approach across all platforms.
> > But in this case there is nothing to do for the old platforms as they
> > don't have any kind of dbuf cdclk limit, or if there is one we don't
> > know what it is since it's not documented.
> > 
> > So the only thing the code was really doing was conflating the
> > per-pipe cdclk limit (which is handled elsewhere for all platforms
> > in a  unified fashion) with something that doesn't even exist.
> > 
> > Also I don't think it was even correct anyway since it was
> > using the per-pipe cdclk_state->min_cdclk[] already during
> > intel_cdclk_atomic_check(), but cdclk_state->min_cdclk[]
> > isn't even computed until intel_modeset_calc_cdclk() which 
> > is called later. So I guess it was basically just computing 
> > the max of the min_cdclk[] for all the pipes for the _old_
> > state, not the new state.
> 
> No, I think actually the idea was that it was first calculating
> new_bw_state->min_cdclk, based on plane and dbuf bandwidth requirements
> in intel_atomic_check_cdclk,

Well intel_bw_calc_min_cdclk() did none of that. Like I said it
just took the max of the _old_ per-pipe cdclk_state->min_cdclk[]
values and stored that as the *new* bw min cdclk, which later
would get consulted by intel_compute_min_cdclk().

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Daniel Vetter]

On Tue, Feb 1, 2022 at 12:01 PM Helge Deller  wrote:
> On 2/1/22 11:36, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 11:16 AM Helge Deller  wrote:
> >>
> >> On 1/31/22 22:05, Daniel Vetter wrote:
> >>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>> option.
> >>
> >> you have two trivial copy-n-paste errors in this patch which still prevent 
> >> the
> >> console acceleration.
> >
> > Duh :-(
> >
> > But before we dig into details I think the big picture would be
> > better. I honestly don't like the #ifdef pile here that much.
>
> Me neither.
> The ifdefs give a better separation, but prevents that the compiler
> checks the various paths when building.
>
> > I wonder whether your approach, also with GETVX/YRES adjusted
> > somehow, wouldn't look cleaner?
> I think so.
> You wouldn't even need to touch GETVX/YRES because the compiler
> will optimize/reduce it from
>
> #define GETVYRES(s,i) ({   \
> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> (i)->var.yres : (i)->var.yres_virtual; })
>
> to just become:
>
> #define GETVYRES(s,i) ((i)->var.yres)

Yeah, but you need to roll out your helper to all the callsites. But
since you #ifdef out info->scrollmode we should catch them all I
guess.

> > Like I said in the cover letter I got mostly distracted with fbcon
> > locking last week, not really with this one here at all, so maybe
> > going with your 4 (or 2 if we squash them like I did here) patches is
> > neater?
>
> The benefit of my patch series was, that it could be easily backported first,
> and then cleaned up afterwards. Even a small additional backport patch to 
> disable
> the fbcon acceleration for DRM in the old releases would be easy.
> But I'm not insisting on backporting the patches, if we find good way forward.
>
> So, either with the 4 (or 2) patches would be OK for me (or even your 
> approach).

The idea behind the squash was that it's then impossible to backport
without the Kconfig, and so we'll only enable this code when people
intentionally want it. Maybe I'm too paranoid?

Anyway, you feel like finishing off your approach? Or should I send
out v2 of this with the issues fixed you spotted? Like I said either
is fine with me.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Compile out integrated

[Patchwork]

== Series Details ==

Series: Compile out integrated
URL   : https://patchwork.freedesktop.org/series/99570/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Compile out integrated

[Patchwork]

== Series Details ==

Series: Compile out integrated
URL   : https://patchwork.freedesktop.org/series/99570/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
15e05554122b igp kconfig
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:18: WARNING:EMBEDDED_FILENAME: It's generally not useful to have the filename 
in the file
#18: FILE: drivers/gpu/drm/i915/Kconfig:150:
+source "drivers/gpu/drm/i915/Kconfig.platforms"

-:25: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#25: 
new file mode 100644

-:30: WARNING:CONFIG_DESCRIPTION: please write a help paragraph that fully 
describes the config symbol
#30: FILE: drivers/gpu/drm/i915/Kconfig.platforms:1:
+config DRM_I915_INTEGRATED_GPU_SUPPORT
+   bool "Support integrated GPUs"
+   default y
+   depends on DRM_I915
+   help
+ Include support for integrated GPUs.
+

-:50: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#50: FILE: drivers/gpu/drm/i915/i915_drv.h:1126:
+#define IS_GRAPHICS_VER(i915, from, until) \
+({ \
+   const unsigned int s_ = 12; \
+   const unsigned int e_ = UINT_MAX; \
+   unsigned int res_; \
+ \
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
+   res_ = GRAPHICS_VER(i915) >= (from) && \
+  GRAPHICS_VER(i915) <= (until); \
+   else \
+   res_ = 0; \
+ \
+   (res_); \
+})

-:50: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'from' - possible 
side-effects?
#50: FILE: drivers/gpu/drm/i915/i915_drv.h:1126:
+#define IS_GRAPHICS_VER(i915, from, until) \
+({ \
+   const unsigned int s_ = 12; \
+   const unsigned int e_ = UINT_MAX; \
+   unsigned int res_; \
+ \
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
+   res_ = GRAPHICS_VER(i915) >= (from) && \
+  GRAPHICS_VER(i915) <= (until); \
+   else \
+   res_ = 0; \
+ \
+   (res_); \
+})

-:50: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'until' - possible 
side-effects?
#50: FILE: drivers/gpu/drm/i915/i915_drv.h:1126:
+#define IS_GRAPHICS_VER(i915, from, until) \
+({ \
+   const unsigned int s_ = 12; \
+   const unsigned int e_ = UINT_MAX; \
+   unsigned int res_; \
+ \
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
+   res_ = GRAPHICS_VER(i915) >= (from) && \
+  GRAPHICS_VER(i915) <= (until); \
+   else \
+   res_ = 0; \
+ \
+   (res_); \
+})

-:55: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#55: FILE: drivers/gpu/drm/i915/i915_drv.h:1131:
+ \$

-:56: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#56: FILE: drivers/gpu/drm/i915/i915_drv.h:1132:
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
   ^

-:56: ERROR:SPACING: spaces required around that '?' (ctx:VxW)
#56: FILE: drivers/gpu/drm/i915/i915_drv.h:1132:
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
   ^

-:56: ERROR:SPACING: spaces required around that ':' (ctx:VxW)
#56: FILE: drivers/gpu/drm/i915/i915_drv.h:1132:
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
 ^

-:61: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#61: FILE: drivers/gpu/drm/i915/i915_drv.h:1137:
+ \$

-:145: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible 
side-effects?
#145: FILE: drivers/gpu/drm/i915/i915_drv.h:1274:
+#define IS_JSL_EHL(dev_priv)   (IS_IGP_PLATFORM(dev_priv, INTEL_JASPERLAKE) || 
\
+   IS_IGP_PLATFORM(dev_priv, INTEL_ELKHARTLAKE))

-:162: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#162: FILE: drivers/gpu/drm/i915/i915_drv.h:1288:
+   (IS_ALDERLAKE_S(dev_priv) && IS_SUBPLATFORM(dev_priv, 
INTEL_ALDERLAKE_S, INTEL_SUBPLATFORM_RPL_S))

-:165: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#165: FILE: drivers/gpu/drm/i915/i915_drv.h:1290:
+   (IS_ALDERLAKE_P(dev_priv) && IS_SUBPLATFORM(dev_priv, 
INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_N))

-:207: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#207: FILE: drivers/gpu/drm/i915/i915_drv.h:1327:
+   (IS_COFFEELAKE(dev_priv) && IS_SUBPLATFORM(dev_priv, INTEL_COFFEELAKE, 
INTEL_SUBPLATFORM_ULT))

-:210: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#210: FILE: drivers/gpu/drm/i915/i915_drv.h:1329:
+   (IS_COFFEELAKE(dev_priv) && IS_SUBPLATFORM(dev_priv, INTEL_COFFEELAKE, 
INTEL_SUBPLATFORM_ULX))

total: 3 errors, 10 warnings, 4 checks, 506 lines checked
528a41163c0e jsl/ehl
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 27 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Enabling 64k page size and flat ccs (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Enabling 64k page size and flat ccs (rev5)
URL   : https://patchwork.freedesktop.org/series/95686/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11172 -> Patchwork_22148


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22148 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22148, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/index.html

Participating hosts (44 -> 42)
--

  Additional (1): fi-pnv-d510 
  Missing(3): fi-icl-u2 fi-bdw-samus fi-kbl-8809g 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22148:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gtt:
- fi-bsw-kefka:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-bsw-kefka/igt@i915_selftest@l...@gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-bsw-kefka/igt@i915_selftest@l...@gtt.html
- fi-bwr-2160:[PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-bwr-2160/igt@i915_selftest@l...@gtt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-bwr-2160/igt@i915_selftest@l...@gtt.html
- fi-skl-guc: [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-skl-guc/igt@i915_selftest@l...@gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-skl-guc/igt@i915_selftest@l...@gtt.html
- fi-blb-e6850:   NOTRUN -> [DMESG-FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-blb-e6850/igt@i915_selftest@l...@gtt.html
- fi-kbl-7567u:   [PASS][8] -> [DMESG-FAIL][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-kbl-7567u/igt@i915_selftest@l...@gtt.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-kbl-7567u/igt@i915_selftest@l...@gtt.html
- fi-glk-j4005:   [PASS][10] -> [DMESG-FAIL][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-glk-j4005/igt@i915_selftest@l...@gtt.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-glk-j4005/igt@i915_selftest@l...@gtt.html
- fi-bsw-nick:NOTRUN -> [INCOMPLETE][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-bsw-nick/igt@i915_selftest@l...@gtt.html
- fi-cfl-8109u:   [PASS][13] -> [DMESG-FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-cfl-8109u/igt@i915_selftest@l...@gtt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-cfl-8109u/igt@i915_selftest@l...@gtt.html
- fi-snb-2520m:   [PASS][15] -> [DMESG-FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-snb-2520m/igt@i915_selftest@l...@gtt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-snb-2520m/igt@i915_selftest@l...@gtt.html
- fi-cfl-8700k:   [PASS][17] -> [DMESG-FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-cfl-8700k/igt@i915_selftest@l...@gtt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-cfl-8700k/igt@i915_selftest@l...@gtt.html
- fi-cml-u2:  [PASS][19] -> [DMESG-FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-cml-u2/igt@i915_selftest@l...@gtt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-cml-u2/igt@i915_selftest@l...@gtt.html
- fi-ilk-650: [PASS][21] -> [DMESG-FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-ilk-650/igt@i915_selftest@l...@gtt.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-ilk-650/igt@i915_selftest@l...@gtt.html
- fi-bsw-n3050:   [PASS][23] -> [DMESG-FAIL][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-bsw-n3050/igt@i915_selftest@l...@gtt.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-bsw-n3050/igt@i915_selftest@l...@gtt.html
- fi-cfl-guc: [PASS][25] -> [DMESG-FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-cfl-guc/igt@i915_selftest@l...@gtt.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-cfl-guc/igt@i915_selftest@l...@gtt.html
- fi-skl-6700k2:  [PASS][27] -> [DMESG-FAIL][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11172/fi-skl-6700k2/igt@i915_selftest@l...@gtt.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22148/fi-skl-6700k2/igt@i915_selftest@l...@gtt.html
   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dg2: Enabling 64k page size and flat ccs (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Enabling 64k page size and flat ccs (rev5)
URL   : https://patchwork.freedesktop.org/series/95686/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Enabling 64k page size and flat ccs (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Enabling 64k page size and flat ccs (rev5)
URL   : https://patchwork.freedesktop.org/series/95686/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7f652d8d712c drm/i915: add needs_compact_pt flag
f93c6346dd31 drm/i915: enforce min GTT alignment for discrete cards
-:298: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#298: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:457:
+   if (offset < hole_start + 
aligned_size)

-:310: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#310: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:481:
+   if (offset + aligned_size > 
hole_end)

-:328: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#328: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:497:
+   if (offset < hole_start + 
aligned_size)

-:340: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#340: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:520:
+   if (offset + aligned_size > 
hole_end)

-:358: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#358: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:536:
+   if (offset < hole_start + 
aligned_size)

-:370: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#370: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:560:
+   if (offset + aligned_size > 
hole_end)

-:388: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#388: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:576:
+   if (offset < hole_start + 
aligned_size)

-:400: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#400: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:599:
+   if (offset + aligned_size > 
hole_end)

total: 0 errors, 8 warnings, 0 checks, 434 lines checked
7373e84047bf drm/i915: support 64K GTT pages for discrete cards
29fc5ce90221 drm/i915: add gtt misalignment test
08193c9fbdc7 drm/i915/gtt: allow overriding the pt alignment
441f25ff52f8 drm/i915/gtt: add xehpsdv_ppgtt_insert_entry
a8710e64c4a8 drm/i915/migrate: add acceleration support for DG2
d4227abc52e4 drm/i915/uapi: document behaviour for DG2 64K support
d49ca1a2fc0d Doc/gpu/rfc/i915: i915 DG2 64k pagesize uAPI
-:24: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#24: 
new file mode 100644

-:29: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#29: FILE: Documentation/gpu/rfc/i915_dg2.rst:1:
+

total: 0 errors, 2 warnings, 0 checks, 34 lines checked
19bfdb83b514 drm/i915/xehpsdv: Add has_flat_ccs to device info
9dad7bbc9b86 drm/i915/lmem: Enable lmem for platforms with Flat CCS
90946c4b0096 drm/i915/gt: Clear compress metadata for Xe_HP platforms
035ac563c069 drm/i915: Introduce new Tile 4 format
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape

total: 0 errors, 1 warnings, 0 checks, 17 lines checked
41874785a443 drm/i915/dg2: Tile 4 plane format support
-:13: WARNING:TYPO_SPELLING: 'assocating' may be misspelled - perhaps 
'associating'?
#13: 
v2: - Moved Tile4 assocating struct for modifier/display to
  ^^

total: 0 errors, 1 warnings, 0 checks, 159 lines checked
a4ae214f55c2 drm/i915/dg2: Add DG2 unified compression
a5ef8bfef402 uapi/drm/dg2: Introduce format modifier for DG2 clear color
c529f71d7954 drm/i915/dg2: Flat CCS Support
62e5cdbc9a5d drm/i915/Flat-CCS: Document on Flat-CCS memory compression
f0e7ebd7ff02 Doc/gpu/rfc/i915: i915 DG2 flat-CCS uAPI

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: Return some errors instead of trying memcpy move

[Thomas Hellström]

On 2/1/22 10:16, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   drm/i915/ttm: Return some errors instead of trying memcpy move
*URL:*  https://patchwork.freedesktop.org/series/99553/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22145/index.html



  CI Bug Log - changes from CI_DRM_11168_full -> Patchwork_22145_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_22145_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22145_full, please notify your bug team to 
allow them
to document this new failure mode, which will reduce false positives 
in CI.



Participating hosts (11 -> 13)

Additional (2): shard-rkl shard-dg1


Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_22145_full:



  IGT changes


Possible regressions

  * igt@gem_ctx_persistence@smoketest:
  o shard-apl: PASS


-> FAIL




Suppressed

The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.

 *

igt@kms_scaling_modes@scaling-mode-full-aspect:

  o {shard-rkl}: NOTRUN -> SKIP


 *

igt@kms_scaling_modes@scaling-mode-none:

  o {shard-dg1}: NOTRUN -> SKIP




These are unrelated.

/Thomas

Re: [Intel-gfx] [RFC 2/2] jsl/ehl

[Jani Nikula]

On Tue, 01 Feb 2022, Tvrtko Ursulin  wrote:
> From: Tvrtko Ursulin 

Should be split out and posted independently.

Maybe we should consider s/IS_PLATFORM/__IS_PLATFORM/g too.

BR,
Jani.

>
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c  | 2 +-
>  drivers/gpu/drm/i915/i915_drv.h| 2 ++
>  3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 0c32210bf503..37b48f7ab4fd 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1621,9 +1621,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder 
> *encoder)
>   else
>   encoder->get_buf_trans = tgl_get_dkl_buf_trans;
>   } else if (DISPLAY_VER(i915) == 11) {
> - if (IS_PLATFORM(i915, INTEL_JASPERLAKE))
> + if (IS_JASPERLAKE(i915))
>   encoder->get_buf_trans = jsl_get_combo_buf_trans;
> - else if (IS_PLATFORM(i915, INTEL_ELKHARTLAKE))
> + else if (IS_ELKHARTLAKE(i915))
>   encoder->get_buf_trans = ehl_get_combo_buf_trans;
>   else if (intel_phy_is_combo(i915, phy))
>   encoder->get_buf_trans = icl_get_combo_buf_trans;
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 6723c3de5a80..0d9b970c453f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2443,7 +2443,7 @@ static void icl_wrpll_params_populate(struct 
> skl_wrpll_params *params,
>  static bool
>  ehl_combo_pll_div_frac_wa_needed(struct drm_i915_private *i915)
>  {
> - return ((IS_PLATFORM(i915, INTEL_ELKHARTLAKE) &&
> + return ((IS_ELKHARTLAKE(i915) &&
>IS_JSL_EHL_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER)) ||
>IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) &&
>i915->dpll.ref_clks.nssc == 38400;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1d22d72163c1..241acd884135 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1271,6 +1271,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_COFFEELAKE(dev_priv)  IS_IGP_PLATFORM(dev_priv, 
> INTEL_COFFEELAKE)
>  #define IS_COMETLAKE(dev_priv)   IS_IGP_PLATFORM(dev_priv, 
> INTEL_COMETLAKE)
>  #define IS_ICELAKE(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_ICELAKE)
> +#define IS_JASPERLAKE(dev_priv)  IS_IGP_PLATFORM(dev_priv, 
> INTEL_JASPERLAKE)
> +#define IS_ELKHARTLAKE(dev_priv) IS_IGP_PLATFORM(dev_priv, 
> INTEL_ELKHARTLAKE)
>  #define IS_JSL_EHL(dev_priv) (IS_IGP_PLATFORM(dev_priv, INTEL_JASPERLAKE) || 
> \
>   IS_IGP_PLATFORM(dev_priv, INTEL_ELKHARTLAKE))
>  #define IS_TIGERLAKE(dev_priv)   IS_IGP_PLATFORM(dev_priv, 
> INTEL_TIGERLAKE)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Move the power domain->well mappings to intel_display_power_map.c

[Jani Nikula]

On Tue, 01 Feb 2022, Jani Nikula  wrote:
> On Mon, 31 Jan 2022, Imre Deak  wrote:
>> On Mon, Jan 31, 2022 at 02:15:25PM +0200, Jani Nikula wrote:
>>> On Fri, 28 Jan 2022, Imre Deak  wrote:
>>> > Move the list of platform specific power domain -> power well
>>> > definitions to intel_display_power_map.c. While at it group the
>>> > platforms' power domain macros with the corresponding power well lists
>>> > and keep all the power domain lists in the same order (matching the enum
>>> > order).
>>> >
>>> > No functional changes.
>>> >
>>> > Signed-off-by: Imre Deak 
>>> 
>>> The commit message should explain the why.
>>> 
>>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h 
>>> > b/drivers/gpu/drm/i915/display/intel_display_power.h
>>> > index b30e6133c66d0..a0e68ae691021 100644
>>> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
>>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
>>> > @@ -197,6 +197,7 @@ struct intel_display_power_domain_set {
>>> >   for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
>>> >   for_each_if(BIT_ULL(domain) & (mask))
>>> >  
>>> > +/* intel_display_power.c */
>>> >  int intel_power_domains_init(struct drm_i915_private *dev_priv);
>>> >  void intel_power_domains_cleanup(struct drm_i915_private *dev_priv);
>>> >  void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
>>> > resume);
>>> > @@ -316,4 +317,8 @@ void chv_phy_powergate_lanes(struct intel_encoder 
>>> > *encoder,
>>> >  bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum 
>>> > dpio_phy phy,
>>> > enum dpio_channel ch, bool override);
>>> >  
>>> > +/* intel_display_power_map.c */
>>> > +const char *
>>> > +intel_display_power_domain_str(enum intel_display_power_domain domain);
>>> > +
>>> >  #endif /* __INTEL_DISPLAY_POWER_H__ */
>>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_internal.h 
>>> > b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
>>> > new file mode 100644
>>> > index 0..3fc7c7d0bc9e9
>>> > --- /dev/null
>>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
>>> > @@ -0,0 +1,93 @@
>>> > +/* SPDX-License-Identifier: MIT */
>>> > +/*
>>> > + * Copyright © 2022 Intel Corporation
>>> > + */
>>> > +
>>> > +#ifndef __INTEL_DISPLAY_POWER_INTERNAL_H__
>>> > +#define __INTEL_DISPLAY_POWER_INTERNAL_H__
>>> > +
>>> > +#include "i915_reg_defs.h"
>>> > +
>>> > +#include "intel_display.h"
>>> > +#include "intel_display_power.h"
>>> > +
>>> > +struct i915_power_well_regs;
>>> > +
>>> > +/* Power well structure for haswell */
>>> > +struct i915_power_well_desc {
>>> > + const char *name;
>>> > + bool always_on;
>>> > + u64 domains;
>>> > + /* unique identifier for this power well */
>>> > + enum i915_power_well_id id;
>>> > + /*
>>> > +  * Arbitraty data associated with this power well. Platform and power
>>> > +  * well specific.
>>> > +  */
>>> > + union {
>>> > + struct {
>>> > + /*
>>> > +  * request/status flag index in the PUNIT power well
>>> > +  * control/status registers.
>>> > +  */
>>> > + u8 idx;
>>> > + } vlv;
>>> > + struct {
>>> > + enum dpio_phy phy;
>>> > + } bxt;
>>> > + struct {
>>> > + /*
>>> > +  * request/status flag index in the power well
>>> > +  * constrol/status registers.
>>> > +  */
>>> > + u8 idx;
>>> > + /* Mask of pipes whose IRQ logic is backed by the pw */
>>> > + u8 irq_pipe_mask;
>>> > + /*
>>> > +  * Instead of waiting for the status bit to ack enables,
>>> > +  * just wait a specific amount of time and then consider
>>> > +  * the well enabled.
>>> > +  */
>>> > + u16 fixed_enable_delay;
>>> > + /* The pw is backing the VGA functionality */
>>> > + bool has_vga:1;
>>> > + bool has_fuses:1;
>>> > + /*
>>> > +  * The pw is for an ICL+ TypeC PHY port in
>>> > +  * Thunderbolt mode.
>>> > +  */
>>> > + bool is_tc_tbt:1;
>>> > + } hsw;
>>> > + };
>>> > + const struct i915_power_well_ops *ops;
>>> > +};
>>> > +
>>> > +struct i915_power_well {
>>> > + const struct i915_power_well_desc *desc;
>>> > + /* power well enable/disable usage count */
>>> > + int count;
>>> > + /* cached hw enabled state */
>>> > + bool hw_enabled;
>>> > +};
>>> > +
>>> > +/* intel_display_power.c */
>>> 
>>> I've put a lot of effort into splitting our (display) codebase towards
>>> having a 1-to-1 mapping between .c and .h files. This patch adds an odd
>>> split between two headers and two compilation units, and I don't think
>>> it's pretty.
>>
>> This header includes 

Re: [Intel-gfx] [PATCH 10/19] drm/i915: Convert the u64 power well domains mask to a bitmap

[Jani Nikula]

On Fri, 28 Jan 2022, Imre Deak  wrote:
> To remove the aliasing of the power domain enum values in a follow-up
> patch in this patchset (requiring a bigger mask) and allow for defining
> additional power domains in the future (at least some upcoming TypeC
> changes requires this) convert the u64 i915_power_well_desc::domains
> mask to a bitmap.
>
> For simplicity I changed the for_each_power_domain_well() macros to
> accept one domain only instead of a mask, as there isn't any current
> user passing multiple domains.
>
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  65 -
>  .../drm/i915/display/intel_display_power.c| 123 +++---
>  .../drm/i915/display/intel_display_power.h|  16 ++-
>  .../display/intel_display_power_internal.h|   2 +-
>  .../i915/display/intel_display_power_map.c|   4 +-
>  5 files changed, 119 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3094cfc668c81..d0b9618383ce3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2372,66 +2372,71 @@ intel_legacy_aux_to_power_domain(enum aux_ch aux_ch)
>   }
>  }
>  
> -static u64 get_crtc_power_domains(struct intel_crtc_state *crtc_state)
> +static void get_crtc_power_domains(struct intel_crtc_state *crtc_state,
> +intel_power_domain_mask_t *mask)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>   struct drm_encoder *encoder;
>   enum pipe pipe = crtc->pipe;
> - u64 mask;
> +
> + bitmap_zero(mask->bits, POWER_DOMAIN_NUM);
>  
>   if (!crtc_state->hw.active)
> - return 0;
> + return;
>  
> - mask = BIT_ULL(POWER_DOMAIN_PIPE(pipe));
> - mask |= BIT_ULL(POWER_DOMAIN_TRANSCODER(cpu_transcoder));
> + set_bit(POWER_DOMAIN_PIPE(pipe), mask->bits);
> + set_bit(POWER_DOMAIN_TRANSCODER(cpu_transcoder), mask->bits);
>   if (crtc_state->pch_pfit.enabled ||
>   crtc_state->pch_pfit.force_thru)
> - mask |= BIT_ULL(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
> + set_bit(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe), mask->bits);
>  
>   drm_for_each_encoder_mask(encoder, _priv->drm,
> crtc_state->uapi.encoder_mask) {
>   struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
>  
> - mask |= BIT_ULL(intel_encoder->power_domain);
> + set_bit(intel_encoder->power_domain, mask->bits);
>   }
>  
>   if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> - mask |= BIT_ULL(POWER_DOMAIN_AUDIO_MMIO);
> + set_bit(POWER_DOMAIN_AUDIO_MMIO, mask->bits);
>  
>   if (crtc_state->shared_dpll)
> - mask |= BIT_ULL(POWER_DOMAIN_DISPLAY_CORE);
> + set_bit(POWER_DOMAIN_DISPLAY_CORE, mask->bits);
>  
>   if (crtc_state->dsc.compression_enable)
> - mask |= BIT_ULL(intel_dsc_power_domain(crtc, cpu_transcoder));
> -
> - return mask;
> + set_bit(intel_dsc_power_domain(crtc, cpu_transcoder), 
> mask->bits);
>  }
>  
> -static u64
> -modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state)
> +static void
> +modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state,
> +intel_power_domain_mask_t *old_domains)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum intel_display_power_domain domain;
> - u64 domains, new_domains, old_domains;
> + intel_power_domain_mask_t domains, new_domains;
>  
> - domains = get_crtc_power_domains(crtc_state);
> + get_crtc_power_domains(crtc_state, );
>  
> - new_domains = domains & ~crtc->enabled_power_domains.mask;
> - old_domains = crtc->enabled_power_domains.mask & ~domains;
> + bitmap_andnot(new_domains.bits,
> +   domains.bits,
> +   crtc->enabled_power_domains.mask.bits,
> +   POWER_DOMAIN_NUM);
> + bitmap_andnot(old_domains->bits,
> +   crtc->enabled_power_domains.mask.bits,
> +   domains.bits,
> +   POWER_DOMAIN_NUM);
>  
> - for_each_power_domain(domain, new_domains)
> + for_each_power_domain(domain, _domains)
>   intel_display_power_get_in_set(dev_priv,
>  >enabled_power_domains,
>  domain);
> -
> - return old_domains;
>  }
>  
>  static void modeset_put_crtc_power_domains(struct intel_crtc *crtc,
> -u64 domains)
> +   

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk()

[Lisovskiy, Stanislav]

On Tue, Feb 01, 2022 at 12:05:13PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 01, 2022 at 10:52:39AM +0200, Lisovskiy, Stanislav wrote:
> > On Tue, Jan 18, 2022 at 11:23:50AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
> > > somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
> > > (at least documented) dbuf min cdclk limit on pre-skl so let's just get
> > > rid of all this confusion.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > I think we constantly have a bit contradictional attitude towards such 
> > situation.
> > >From one perspective you can say, that those kind of "leagcy" callbacks are
> > pointless, from the other hand one might say. that we need to have a unified
> > approach for all platforms and I think we got, some legacy handlers for old
> > platforms for similar purpose as well.
> > I'm fine with both approaches, however for example when I was submitting
> > that patch, I was asked by reviewer to add this kind of legacy callback, so 
> > that we have
> > a "uniform" approach.
> > We just then need to have some standard agreement on those, which doesn't
> > depend on today's cosmic radiation levels :)
> 
> Yes in general I prefer a unified approach across all platforms.
> But in this case there is nothing to do for the old platforms as they
> don't have any kind of dbuf cdclk limit, or if there is one we don't
> know what it is since it's not documented.
> 
> So the only thing the code was really doing was conflating the
> per-pipe cdclk limit (which is handled elsewhere for all platforms
> in a  unified fashion) with something that doesn't even exist.
> 
> Also I don't think it was even correct anyway since it was
> using the per-pipe cdclk_state->min_cdclk[] already during
> intel_cdclk_atomic_check(), but cdclk_state->min_cdclk[]
> isn't even computed until intel_modeset_calc_cdclk() which 
> is called later. So I guess it was basically just computing 
> the max of the min_cdclk[] for all the pipes for the _old_
> state, not the new state.

No, I think actually the idea was that it was first calculating
new_bw_state->min_cdclk, based on plane and dbuf bandwidth requirements
in intel_atomic_check_cdclk, however then the final decision which
cdclk to choose was is done in intel_cdclk.c, which calculated 
new_cdclk_state->min_cdclk
and then we just choose maximum of those.
And intel_compute_min_cdclk is the final arbiter:

static int intel_compute_min_cdclk(struct intel_cdclk_state *cdclk_state)
{
struct intel_atomic_state *state = cdclk_state->base.state;
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_bw_state *bw_state = NULL;
struct intel_crtc *crtc;
struct intel_crtc_state *crtc_state;
int min_cdclk, i;
enum pipe pipe;

for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
int ret;

min_cdclk = intel_crtc_compute_min_cdclk(crtc_state);
if (min_cdclk < 0)
return min_cdclk;

bw_state = intel_atomic_get_bw_state(state);
if (IS_ERR(bw_state))
return PTR_ERR(bw_state);

if (cdclk_state->min_cdclk[crtc->pipe] == min_cdclk)
continue;

cdclk_state->min_cdclk[crtc->pipe] = min_cdclk;

ret = intel_atomic_lock_global_state(_state->base);
if (ret)
return ret;
}

min_cdclk = cdclk_state->force_min_cdclk;
for_each_pipe(dev_priv, pipe) {
min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk);

if (!bw_state)
continue;

min_cdclk = max(bw_state->min_cdclk, min_cdclk);
}

return min_cdclk;
}

Stan

> 
> -- 
> Ville Syrjälä
> Intel

[Intel-gfx] [RFC 2/2] jsl/ehl

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c  | 2 +-
 drivers/gpu/drm/i915/i915_drv.h| 2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
index 0c32210bf503..37b48f7ab4fd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
@@ -1621,9 +1621,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder 
*encoder)
else
encoder->get_buf_trans = tgl_get_dkl_buf_trans;
} else if (DISPLAY_VER(i915) == 11) {
-   if (IS_PLATFORM(i915, INTEL_JASPERLAKE))
+   if (IS_JASPERLAKE(i915))
encoder->get_buf_trans = jsl_get_combo_buf_trans;
-   else if (IS_PLATFORM(i915, INTEL_ELKHARTLAKE))
+   else if (IS_ELKHARTLAKE(i915))
encoder->get_buf_trans = ehl_get_combo_buf_trans;
else if (intel_phy_is_combo(i915, phy))
encoder->get_buf_trans = icl_get_combo_buf_trans;
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 6723c3de5a80..0d9b970c453f 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -2443,7 +2443,7 @@ static void icl_wrpll_params_populate(struct 
skl_wrpll_params *params,
 static bool
 ehl_combo_pll_div_frac_wa_needed(struct drm_i915_private *i915)
 {
-   return ((IS_PLATFORM(i915, INTEL_ELKHARTLAKE) &&
+   return ((IS_ELKHARTLAKE(i915) &&
 IS_JSL_EHL_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER)) ||
 IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) &&
 i915->dpll.ref_clks.nssc == 38400;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1d22d72163c1..241acd884135 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1271,6 +1271,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_COFFEELAKE(dev_priv)IS_IGP_PLATFORM(dev_priv, 
INTEL_COFFEELAKE)
 #define IS_COMETLAKE(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_COMETLAKE)
 #define IS_ICELAKE(dev_priv)   IS_IGP_PLATFORM(dev_priv, INTEL_ICELAKE)
+#define IS_JASPERLAKE(dev_priv)IS_IGP_PLATFORM(dev_priv, 
INTEL_JASPERLAKE)
+#define IS_ELKHARTLAKE(dev_priv)   IS_IGP_PLATFORM(dev_priv, 
INTEL_ELKHARTLAKE)
 #define IS_JSL_EHL(dev_priv)   (IS_IGP_PLATFORM(dev_priv, INTEL_JASPERLAKE) || 
\
IS_IGP_PLATFORM(dev_priv, INTEL_ELKHARTLAKE))
 #define IS_TIGERLAKE(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_TIGERLAKE)
-- 
2.32.0

[Intel-gfx] [RFC 1/2] igp kconfig

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Kconfig   |   5 +
 drivers/gpu/drm/i915/Kconfig.platforms |   7 ++
 drivers/gpu/drm/i915/i915_drv.h| 126 +++--
 drivers/gpu/drm/i915/i915_pci.c|  44 -
 4 files changed, 129 insertions(+), 53 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/Kconfig.platforms

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 2ac220bfd0ed..e8c2549ca433 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -145,6 +145,11 @@ config DRM_I915_PXP
  protected session and manage the status of the alive software session,
  as well as its life cycle.
 
+menu "Platform support"
+depends on DRM_I915
+source "drivers/gpu/drm/i915/Kconfig.platforms"
+endmenu
+
 menu "drm/i915 Debugging"
 depends on DRM_I915
 depends on EXPERT
diff --git a/drivers/gpu/drm/i915/Kconfig.platforms 
b/drivers/gpu/drm/i915/Kconfig.platforms
new file mode 100644
index ..731be430cfad
--- /dev/null
+++ b/drivers/gpu/drm/i915/Kconfig.platforms
@@ -0,0 +1,7 @@
+config DRM_I915_INTEGRATED_GPU_SUPPORT
+   bool "Support integrated GPUs"
+   default y
+   depends on DRM_I915
+   help
+ Include support for integrated GPUs.
+
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..1d22d72163c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1118,8 +1118,26 @@ static inline struct intel_gt *to_gt(struct 
drm_i915_private *i915)
 #define GRAPHICS_VER(i915) (INTEL_INFO(i915)->graphics.ver)
 #define GRAPHICS_VER_FULL(i915)
IP_VER(INTEL_INFO(i915)->graphics.ver, \
   INTEL_INFO(i915)->graphics.rel)
+
+#ifdef CONFIG_DRM_I915_INTEGRATED_GPU_SUPPORT
 #define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
+#else
+#define IS_GRAPHICS_VER(i915, from, until) \
+({ \
+   const unsigned int s_ = 12; \
+   const unsigned int e_ = UINT_MAX; \
+   unsigned int res_; \
+ \
+   if ((s_ > (from) ? (s_): (from)) <= ((e_) < (until)? (e_): (until))) \
+   res_ = GRAPHICS_VER(i915) >= (from) && \
+  GRAPHICS_VER(i915) <= (until); \
+   else \
+   res_ = 0; \
+ \
+   (res_); \
+})
+#endif
 
 #define MEDIA_VER(i915)(INTEL_INFO(i915)->media.ver)
 #define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media.arch, \
@@ -1213,49 +1231,53 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
return ((mask << (msb - pb)) & (mask << (msb - s))) & BIT(msb);
 }
 
+#define IS_IGP_PLATFORM(dev_priv, p) \
+   (IS_ENABLED(CONFIG_DRM_I915_INTEGRATED_GPU_SUPPORT) && \
+IS_PLATFORM(dev_priv, p))
+
 #define IS_MOBILE(dev_priv)(INTEL_INFO(dev_priv)->is_mobile)
 #define IS_DGFX(dev_priv)   (INTEL_INFO(dev_priv)->is_dgfx)
 
-#define IS_I830(dev_priv)  IS_PLATFORM(dev_priv, INTEL_I830)
-#define IS_I845G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I845G)
-#define IS_I85X(dev_priv)  IS_PLATFORM(dev_priv, INTEL_I85X)
-#define IS_I865G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I865G)
-#define IS_I915G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I915G)
-#define IS_I915GM(dev_priv)IS_PLATFORM(dev_priv, INTEL_I915GM)
-#define IS_I945G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I945G)
-#define IS_I945GM(dev_priv)IS_PLATFORM(dev_priv, INTEL_I945GM)
-#define IS_I965G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I965G)
-#define IS_I965GM(dev_priv)IS_PLATFORM(dev_priv, INTEL_I965GM)
-#define IS_G45(dev_priv)   IS_PLATFORM(dev_priv, INTEL_G45)
-#define IS_GM45(dev_priv)  IS_PLATFORM(dev_priv, INTEL_GM45)
+#define IS_I830(dev_priv)  IS_IGP_PLATFORM(dev_priv, INTEL_I830)
+#define IS_I845G(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_I845G)
+#define IS_I85X(dev_priv)  IS_IGP_PLATFORM(dev_priv, INTEL_I85X)
+#define IS_I865G(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_I865G)
+#define IS_I915G(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_I915G)
+#define IS_I915GM(dev_priv)IS_IGP_PLATFORM(dev_priv, INTEL_I915GM)
+#define IS_I945G(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_I945G)
+#define IS_I945GM(dev_priv)IS_IGP_PLATFORM(dev_priv, INTEL_I945GM)
+#define IS_I965G(dev_priv) IS_IGP_PLATFORM(dev_priv, INTEL_I965G)
+#define IS_I965GM(dev_priv)IS_IGP_PLATFORM(dev_priv, INTEL_I965GM)
+#define IS_G45(dev_priv)   IS_IGP_PLATFORM(dev_priv, INTEL_G45)
+#define IS_GM45(dev_priv)  IS_IGP_PLATFORM(dev_priv, INTEL_GM45)
 #define IS_G4X(dev_priv)   (IS_G45(dev_priv) || IS_GM45(dev_priv))
-#define IS_PINEVIEW(dev_priv)  IS_PLATFORM(dev_priv, INTEL_PINEVIEW)
-#define IS_G33(dev_priv)   IS_PLATFORM(dev_priv, INTEL_G33)
-#define IS_IRONLAKE(dev_priv)  IS_PLATFORM(dev_priv, INTEL_IRONLAKE)
+#define 

[Intel-gfx] [RFC 0/2] Compile out integrated

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Quicky and dirty hack based on some old ideas. Thought maybe the approach might
interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so
big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked
into that side.

 3884664  4496816720 4341065  423d49 i915.ko.tip
 3599989  4290346688 4035711  3d947f i915.ko.noigp

Note debug kconfig so everything is inflated. Whether or not the relative gain
would change with production kconfig I am not sure.

P.S.
I was a bit curious there were no build errors around functions no longer used
so either there were none (would mean patch is not really that effective), or
something changed with compiler warnings/smarts. Haven't looked into it.

Tvrtko Ursulin (2):
  igp kconfig
  jsl/ehl

 drivers/gpu/drm/i915/Kconfig  |   5 +
 drivers/gpu/drm/i915/Kconfig.platforms|   7 +
 .../drm/i915/display/intel_ddi_buf_trans.c|   4 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 128 +++---
 drivers/gpu/drm/i915/i915_pci.c   |  44 +-
 6 files changed, 134 insertions(+), 56 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/Kconfig.platforms

-- 
2.32.0

Re: [Intel-gfx] [PULL] drm-misc-next

[Thomas Zimmermann]

Hi

Am 01.02.22 um 09:17 schrieb Maarten Lankhorst:

Op 01-02-2022 om 07:38 schreef Dave Airlie:

On Thu, 27 Jan 2022 at 21:57, Maarten Lankhorst
 wrote:

Hi Dave & Daniel,

First pull for v5.18

I was trying to be all efficient and get this pulled in time for once.


However it broke building on my arm test build.

The new DP helper Kconfig is wrong somewhere.

I've attached the .config, but it appears I get DRM_DP_HELPER set to M
but ANALOGIX_DP set to Y and it fails to link because the dp helper
should be Y.

Regards,
Dave.

Below should likely fix it?

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6a251e3aa779..f27cfd2a9726 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -66,6 +66,7 @@ config DRM_EXYNOS_DP
bool "Exynos specific extensions for Analogix DP driver"
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON
select DRM_ANALOGIX_DP
+   select DRM_DP_HELPER
default DRM_EXYNOS
select DRM_PANEL
help
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d59dca5efb52..fa5cfda4e90e 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_PANEL
select VIDEOMODE_HELPERS
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
+   select DRM_DP_HELPER if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI


Thanks a lot. This fixes the build for me.

Best regards
Thomas





--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH 09/19] drm/i915: Convert the power well descriptor domain mask to a list

[Jani Nikula]

On Fri, 28 Jan 2022, Imre Deak  wrote:
> The next patch converts the i915_power_well_desc::domain mask from a u64
> mask to a bitmap. I didn't find a reasonably simple way to initialize
> bitmaps statically, so prepare for the next patch here by converting the
> masks to a list and initing the masks from these lists during module
> loading.

I think "list" is a very specific thing in the kernel, and I find the
list naming here confusing.

I'll try to give the initialization thing some thought.

BR,
Jani.

>
> Signed-off-by: Imre Deak 
> ---
>  .../drm/i915/display/intel_display_power.c|   12 +-
>  .../display/intel_display_power_internal.h|6 +-
>  .../i915/display/intel_display_power_map.c| 1426 +
>  3 files changed, 756 insertions(+), 688 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 69b75752258d9..a370ef8376410 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -40,11 +40,11 @@
>  
>  #define for_each_power_domain_well(__dev_priv, __power_well, __domain_mask)  
> \
>   for_each_power_well(__dev_priv, __power_well)   
> \
> - for_each_if((__power_well)->desc->domains & (__domain_mask))
> + for_each_if((__power_well)->domains & (__domain_mask))
>  
>  #define for_each_power_domain_well_reverse(__dev_priv, __power_well, 
> __domain_mask) \
>   for_each_power_well_reverse(__dev_priv, __power_well)   
> \
> - for_each_if((__power_well)->desc->domains & (__domain_mask))
> + for_each_if((__power_well)->domains & (__domain_mask))
>  
>  struct i915_power_well_regs {
>   i915_reg_t bios;
> @@ -465,7 +465,7 @@ static u64 async_put_domains_mask(struct 
> i915_power_domains *power_domains);
>  static int power_well_async_ref_count(struct drm_i915_private *dev_priv,
> struct i915_power_well *power_well)
>  {
> - int refs = hweight64(power_well->desc->domains &
> + int refs = hweight64(power_well->domains &
>async_put_domains_mask(_priv->power_domains));
>  
>   drm_WARN_ON(_priv->drm, refs > power_well->count);
> @@ -3805,7 +3805,7 @@ static void intel_power_domains_dump_info(struct 
> drm_i915_private *i915)
>   drm_dbg(>drm, "%-25s %d\n",
>   power_well->desc->name, power_well->count);
>  
> - for_each_power_domain(domain, power_well->desc->domains)
> + for_each_power_domain(domain, power_well->domains)
>   drm_dbg(>drm, "  %-23s %d\n",
>   intel_display_power_domain_str(domain),
>   power_domains->domain_use_count[domain]);
> @@ -3847,7 +3847,7 @@ static void intel_power_domains_verify_state(struct 
> drm_i915_private *i915)
>   power_well->count, enabled);
>  
>   domains_count = 0;
> - for_each_power_domain(domain, power_well->desc->domains)
> + for_each_power_domain(domain, power_well->domains)
>   domains_count += 
> power_domains->domain_use_count[domain];
>  
>   if (power_well->count != domains_count) {
> @@ -3962,7 +3962,7 @@ void intel_display_power_debug(struct drm_i915_private 
> *i915, struct seq_file *m
>   seq_printf(m, "%-25s %d\n", power_well->desc->name,
>  power_well->count);
>  
> - for_each_power_domain(power_domain, power_well->desc->domains)
> + for_each_power_domain(power_domain, power_well->domains)
>   seq_printf(m, "  %-23s %d\n",
>  intel_display_power_domain_str(power_domain),
>  
> power_domains->domain_use_count[power_domain]);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_internal.h 
> b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> index fd1abb64a8a47..49f6155e62c47 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
> @@ -16,7 +16,10 @@ struct i915_power_well_regs;
>  /* Power well structure for haswell */
>  struct i915_power_well_desc {
>   const char *name;
> - u64 domains;
> + const struct i915_power_domain_list {
> + const enum intel_display_power_domain *list;
> + u8 count;
> + } *domain_list;
>   /* Mask of pipes whose IRQ logic is backed by the pw */
>   u16 irq_pipe_mask:4;
>   u16 always_on:1;
> @@ -65,6 +68,7 @@ struct i915_power_well_desc {
>  
>  struct i915_power_well {
>   const struct i915_power_well_desc *desc;
> + u64 domains;
>   /* power well enable/disable usage count */
>   int count;
>   /* cached hw enabled state */
> 

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Helge Deller]

On 2/1/22 11:36, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller  wrote:
>>
>> On 1/31/22 22:05, Daniel Vetter wrote:
>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>> option.
>>
>> you have two trivial copy-n-paste errors in this patch which still prevent 
>> the
>> console acceleration.
>
> Duh :-(
>
> But before we dig into details I think the big picture would be
> better. I honestly don't like the #ifdef pile here that much.

Me neither.
The ifdefs give a better separation, but prevents that the compiler
checks the various paths when building.

> I wonder whether your approach, also with GETVX/YRES adjusted
> somehow, wouldn't look cleaner?
I think so.
You wouldn't even need to touch GETVX/YRES because the compiler
will optimize/reduce it from

#define GETVYRES(s,i) ({   \
(s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
(i)->var.yres : (i)->var.yres_virtual; })

to just become:

#define GETVYRES(s,i) ((i)->var.yres)

> Like I said in the cover letter I got mostly distracted with fbcon
> locking last week, not really with this one here at all, so maybe
> going with your 4 (or 2 if we squash them like I did here) patches is
> neater?

The benefit of my patch series was, that it could be easily backported first,
and then cleaned up afterwards. Even a small additional backport patch to 
disable
the fbcon acceleration for DRM in the old releases would be easy.
But I'm not insisting on backporting the patches, if we find good way forward.

So, either with the 4 (or 2) patches would be OK for me (or even your approach).

Helge

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Move the power domain->well mappings to intel_display_power_map.c

[Jani Nikula]

On Mon, 31 Jan 2022, Imre Deak  wrote:
> On Mon, Jan 31, 2022 at 02:15:25PM +0200, Jani Nikula wrote:
>> On Fri, 28 Jan 2022, Imre Deak  wrote:
>> > Move the list of platform specific power domain -> power well
>> > definitions to intel_display_power_map.c. While at it group the
>> > platforms' power domain macros with the corresponding power well lists
>> > and keep all the power domain lists in the same order (matching the enum
>> > order).
>> >
>> > No functional changes.
>> >
>> > Signed-off-by: Imre Deak 
>> 
>> The commit message should explain the why.
>> 
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h 
>> > b/drivers/gpu/drm/i915/display/intel_display_power.h
>> > index b30e6133c66d0..a0e68ae691021 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
>> > @@ -197,6 +197,7 @@ struct intel_display_power_domain_set {
>> >for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
>> >for_each_if(BIT_ULL(domain) & (mask))
>> >  
>> > +/* intel_display_power.c */
>> >  int intel_power_domains_init(struct drm_i915_private *dev_priv);
>> >  void intel_power_domains_cleanup(struct drm_i915_private *dev_priv);
>> >  void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
>> > resume);
>> > @@ -316,4 +317,8 @@ void chv_phy_powergate_lanes(struct intel_encoder 
>> > *encoder,
>> >  bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum 
>> > dpio_phy phy,
>> >  enum dpio_channel ch, bool override);
>> >  
>> > +/* intel_display_power_map.c */
>> > +const char *
>> > +intel_display_power_domain_str(enum intel_display_power_domain domain);
>> > +
>> >  #endif /* __INTEL_DISPLAY_POWER_H__ */
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_internal.h 
>> > b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
>> > new file mode 100644
>> > index 0..3fc7c7d0bc9e9
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_internal.h
>> > @@ -0,0 +1,93 @@
>> > +/* SPDX-License-Identifier: MIT */
>> > +/*
>> > + * Copyright © 2022 Intel Corporation
>> > + */
>> > +
>> > +#ifndef __INTEL_DISPLAY_POWER_INTERNAL_H__
>> > +#define __INTEL_DISPLAY_POWER_INTERNAL_H__
>> > +
>> > +#include "i915_reg_defs.h"
>> > +
>> > +#include "intel_display.h"
>> > +#include "intel_display_power.h"
>> > +
>> > +struct i915_power_well_regs;
>> > +
>> > +/* Power well structure for haswell */
>> > +struct i915_power_well_desc {
>> > +  const char *name;
>> > +  bool always_on;
>> > +  u64 domains;
>> > +  /* unique identifier for this power well */
>> > +  enum i915_power_well_id id;
>> > +  /*
>> > +   * Arbitraty data associated with this power well. Platform and power
>> > +   * well specific.
>> > +   */
>> > +  union {
>> > +  struct {
>> > +  /*
>> > +   * request/status flag index in the PUNIT power well
>> > +   * control/status registers.
>> > +   */
>> > +  u8 idx;
>> > +  } vlv;
>> > +  struct {
>> > +  enum dpio_phy phy;
>> > +  } bxt;
>> > +  struct {
>> > +  /*
>> > +   * request/status flag index in the power well
>> > +   * constrol/status registers.
>> > +   */
>> > +  u8 idx;
>> > +  /* Mask of pipes whose IRQ logic is backed by the pw */
>> > +  u8 irq_pipe_mask;
>> > +  /*
>> > +   * Instead of waiting for the status bit to ack enables,
>> > +   * just wait a specific amount of time and then consider
>> > +   * the well enabled.
>> > +   */
>> > +  u16 fixed_enable_delay;
>> > +  /* The pw is backing the VGA functionality */
>> > +  bool has_vga:1;
>> > +  bool has_fuses:1;
>> > +  /*
>> > +   * The pw is for an ICL+ TypeC PHY port in
>> > +   * Thunderbolt mode.
>> > +   */
>> > +  bool is_tc_tbt:1;
>> > +  } hsw;
>> > +  };
>> > +  const struct i915_power_well_ops *ops;
>> > +};
>> > +
>> > +struct i915_power_well {
>> > +  const struct i915_power_well_desc *desc;
>> > +  /* power well enable/disable usage count */
>> > +  int count;
>> > +  /* cached hw enabled state */
>> > +  bool hw_enabled;
>> > +};
>> > +
>> > +/* intel_display_power.c */
>> 
>> I've put a lot of effort into splitting our (display) codebase towards
>> having a 1-to-1 mapping between .c and .h files. This patch adds an odd
>> split between two headers and two compilation units, and I don't think
>> it's pretty.
>
> This header includes struct definitions used by intel_display_power.c
> and intel_display_power_map.c. I don't see why this would be a 

Re: [Intel-gfx] [PATCH v5 07/19] drm/i915/migrate: add acceleration support for DG2

[Matthew Auld]

On 01/02/2022 10:41, Ramalingam C wrote:

From: Matthew Auld 

This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).

v2: Rebased [Ram]

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 


This version seems to be missing your review feedback, which I 
incorporated here[1].


[1] https://patchwork.freedesktop.org/series/97544/


---
  drivers/gpu/drm/i915/gt/intel_migrate.c | 179 +++-
  1 file changed, 147 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 18b44af56969..cac791155244 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -32,6 +32,38 @@ static bool engine_supports_migration(struct intel_engine_cs 
*engine)
return true;
  }
  
+static void xehpsdv_toggle_pdes(struct i915_address_space *vm,

+   struct i915_page_table *pt,
+   void *data)
+{
+   struct insert_pte_data *d = data;
+
+   /*
+* Insert a dummy PTE into every PT that will map to LMEM to ensure
+* we have a correctly setup PDE structure for later use.
+*/
+   vm->insert_page(vm, 0, d->offset, I915_CACHE_NONE, PTE_LM);
+   GEM_BUG_ON(!pt->is_compact);
+   d->offset += SZ_2M;
+}
+
+static void xehpsdv_insert_pte(struct i915_address_space *vm,
+  struct i915_page_table *pt,
+  void *data)
+{
+   struct insert_pte_data *d = data;
+
+   /*
+* We are playing tricks here, since the actual pt, from the hw
+* pov, is only 256bytes with 32 entries, or 4096bytes with 512
+* entries, but we are still guaranteed that the physical
+* alignment is 64K underneath for the pt, and we are careful
+* not to access the space in the void.
+*/
+   vm->insert_page(vm, px_dma(pt), d->offset, I915_CACHE_NONE, PTE_LM);
+   d->offset += SZ_64K;
+}
+
  static void insert_pte(struct i915_address_space *vm,
   struct i915_page_table *pt,
   void *data)
@@ -74,7 +106,12 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
 * i.e. within the same non-preemptible window so that we do not switch
 * to another migration context that overwrites the PTE.
 *
-* TODO: Add support for huge LMEM PTEs
+* On platforms with HAS_64K_PAGES support we have three windows, and
+* dedicate two windows just for mapping lmem pages(smem <-> smem is not
+* a thing), since we are forced to use 64K GTT pages underneath which
+* requires also modifying the PDE. An alternative might be to instead
+* map the PD into the GTT, and then on the fly toggle the 4K/64K mode
+* in the PDE from the same batch that also modifies the PTEs.
 */
  
  	vm = i915_ppgtt_create(gt, I915_BO_ALLOC_PM_EARLY);

@@ -86,6 +123,9 @@ static struct i915_address_space *migrate_vm(struct intel_gt 
*gt)
goto err_vm;
}
  
+	if (HAS_64K_PAGES(gt->i915))

+   stash.pt_sz = I915_GTT_PAGE_SIZE_64K;
+
/*
 * Each engine instance is assigned its own chunk in the VM, so
 * that we can run multiple instances concurrently
@@ -105,14 +145,20 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
 * We copy in 8MiB chunks. Each PDE covers 2MiB, so we need
 * 4x2 page directories for source/destination.
 */
-   sz = 2 * CHUNK_SZ;
+   if (HAS_64K_PAGES(gt->i915))
+   sz = 3 * CHUNK_SZ;
+   else
+   sz = 2 * CHUNK_SZ;
d.offset = base + sz;
  
  		/*

 * We need another page directory setup so that we can write
 * the 8x512 PTE in each chunk.
 */
-   sz += (sz >> 12) * sizeof(u64);
+   if (HAS_64K_PAGES(gt->i915))
+   sz += (sz / SZ_2M) * SZ_64K;
+   else
+   sz += (sz >> 12) * sizeof(u64);
  
  		err = i915_vm_alloc_pt_stash(>vm, , sz);

if (err)
@@ -133,7 +179,18 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
goto err_vm;
  
  		/* Now allow the GPU to rewrite the PTE via its own ppGTT */

-   vm->vm.foreach(>vm, base, d.offset - base, insert_pte, );
+   if (HAS_64K_PAGES(gt->i915)) {
+   vm->vm.foreach(>vm, base, d.offset - base,
+  xehpsdv_insert_pte, );
+   d.offset = base + CHUNK_SZ;
+   vm->vm.foreach(>vm,
+  d.offset,
+  

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Greg Kroah-Hartman]

On Tue, Feb 01, 2022 at 11:19:54AM +0100, Thomas Zimmermann wrote:
> 
> 
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> > 
> > $ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
> >  35  Daniel Vetter
> >  23  Linus Torvalds
> >  10  Hans de Goede
> >   9  Dave Airlie
> >   6  Peter Rosin
> > 
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> > 
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> > 
> > Cc: Dave Airlie 
> > Cc: Jani Nikula 
> > Cc: Linus Torvalds 
> > Cc: Linux Fbdev development list 
> > Cc: Pavel Machek 
> > Cc: Sam Ravnborg 
> > Cc: Greg Kroah-Hartman 
> > Cc: Javier Martinez Canillas 
> > Cc: DRI Development 
> > Cc: Linux Kernel Mailing List 
> > Cc: Claudio Suarez 
> > Cc: Tomi Valkeinen 
> > Cc: Geert Uytterhoeven 
> > Cc: Thomas Zimmermann 
> > Cc: Daniel Vetter 
> > Cc: Sven Schnelle 
> > Cc: Gerd Hoffmann 
> > Signed-off-by: Daniel Vetter 
> 
> Acked-by: Thomas Zimmermann 

Acked-by: Greg Kroah-Hartman 

[Intel-gfx] [PATCH v5 18/19] drm/i915/Flat-CCS: Document on Flat-CCS memory compression

[Ramalingam C]

Documents the Flat-CCS feature and kernel handling required along with
modifiers used.

Signed-off-by: Ramalingam C 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 47 +
 1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3e1cf224cdf0..5bdab0b3c735 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -596,6 +596,53 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
 }
 
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is 
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exaust the lmem, if the object's placements support smem, then we 
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem 
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ *
+ *
+ * Flat-CCS Modifiers for different compression formats
+ * 
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat 
CCS
+ * render compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is
+ * used. Render compression uses 128 byte compression blocks
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS
+ * media compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is
+ * used. Media compression uses 256 byte compression blocks.
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat
+ * CCS clear color render compression formats. Unified compression format for
+ * clear color render compression. The genral layout is a tiled layout using
+ * 4Kb tiles i.e Tile4 layout.
+ */
+
 static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
 {
/* Mask the 3 LSB to use the PPGTT address space */
-- 
2.20.1

[Intel-gfx] [PATCH v5 17/19] drm/i915/dg2: Flat CCS Support

[Ramalingam C]

From: Anshuman Gupta 

DG2 onwards discrete gfx has support for new flat CCS mapping,
which brings in display feature in to avoid Aux walk for compressed
surface. This support build on top of Flat CCS support added in XEHPSDV.
FLAT CCS surface base address should be 64k aligned,
Compressed displayable surfaces must use tile4 format.

HAS: 1407880786
B.Spec : 7655
B.Spec : 53902

Cc: Mika Kahola 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Juha-Pekka Heikkilä 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  4 ++-
 drivers/gpu/drm/i915/display/intel_fb.c   | 32 +--
 .../drm/i915/display/skl_universal_plane.c| 16 ++
 3 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 189767cef356..2828ae612179 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8588,7 +8588,9 @@ static void 
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
 
/*
 * The layout of the fast clear color value expected by HW
-* (the DRM ABI requiring this value to be located in fb at 
offset 0 of plane#2):
+* (the DRM ABI requiring this value to be located in fb at
+* offset 0 of cc plane, plane #2 previous generations or
+* plane #1 for flat ccs):
 * - 4 x 4 bytes per-channel value
 *   (in surface type specific float/int format provided by the 
fb user)
 * - 8 bytes native color value used by the display
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 3df6ef5ffec5..e94923e9dbb1 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -107,6 +107,21 @@ static const struct drm_format_info gen12_ccs_cc_formats[] 
= {
  .hsub = 1, .vsub = 1, .has_alpha = true },
 };
 
+static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+};
+
 struct intel_modifier_desc {
u64 modifier;
struct {
@@ -150,6 +165,8 @@ static const struct intel_modifier_desc intel_modifiers[] = 
{
.plane_caps = INTEL_PLANE_CAP_TILING_4 | 
INTEL_PLANE_CAP_CCS_RC_CC,
 
.ccs.cc_planes = BIT(1),
+
+   FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
}, {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
.display_ver = { 13, 13 },
@@ -399,17 +416,13 @@ bool intel_fb_plane_supports_modifier(struct intel_plane 
*plane, u64 modifier)
 static bool format_is_yuv_semiplanar(const struct intel_modifier_desc *md,
 const struct drm_format_info *info)
 {
-   int yuv_planes;
-
if (!info->is_yuv)
return false;
 
-   if (plane_caps_contain_any(md->plane_caps, INTEL_PLANE_CAP_CCS_MASK))
-   yuv_planes = 4;
+   if (hweight8(md->ccs.planar_aux_planes) == 2)
+   return info->num_planes == 4;
else
-   yuv_planes = 2;
-
-   return info->num_planes == yuv_planes;
+   return info->num_planes == 2;
 }
 
 /**
@@ -534,12 +547,13 @@ static unsigned int gen12_ccs_aux_stride(struct 
intel_framebuffer *fb, int ccs_p
 
 int skl_main_to_aux_plane(const struct drm_framebuffer *fb, int main_plane)
 {
+   const struct intel_modifier_desc *md = lookup_modifier(fb->modifier);
struct drm_i915_private *i915 = to_i915(fb->dev);
 
-   if (intel_fb_is_ccs_modifier(fb->modifier))
+   if (md->ccs.packed_aux_planes | md->ccs.planar_aux_planes)
return main_to_ccs_plane(fb, main_plane);
else if (DISPLAY_VER(i915) < 11 &&
-intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+format_is_yuv_semiplanar(md, fb->format))
return 1;
else
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index b4dced1907c5..18e50583abaa 100644
--- 

[Intel-gfx] [PATCH v5 16/19] uapi/drm/dg2: Introduce format modifier for DG2 clear color

[Ramalingam C]

From: Mika Kahola 

DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.

v2:
  Display version is fixed. [Imre]
  KDoc is enhanced for cc modifier. [Nanley & Lionel]

Signed-off-by: Mika Kahola 
cc: Anshuman Gupta 
Signed-off-by: Juha-Pekka Heikkilä 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/display/intel_fb.c|  8 
 drivers/gpu/drm/i915/display/skl_universal_plane.c |  9 -
 include/uapi/drm/drm_fourcc.h  | 10 ++
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 4d4d01963f15..3df6ef5ffec5 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -144,6 +144,12 @@ static const struct intel_modifier_desc intel_modifiers[] 
= {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
.display_ver = { 13, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
+   }, {
+   .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC,
+   .display_ver = { 13, 13 },
+   .plane_caps = INTEL_PLANE_CAP_TILING_4 | 
INTEL_PLANE_CAP_CCS_RC_CC,
+
+   .ccs.cc_planes = BIT(1),
}, {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
.display_ver = { 13, 13 },
@@ -559,6 +565,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
else
return 512;
case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
case I915_FORMAT_MOD_4_TILED:
/*
@@ -763,6 +770,7 @@ unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
return 16 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index c38ae0876c15..b4dced1907c5 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -772,6 +772,8 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
return PLANE_CTL_TILED_4 |
PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE |
PLANE_CTL_CLEAR_COLOR_DISABLE;
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
+   return PLANE_CTL_TILED_4 | 
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return PLANE_CTL_TILED_Y | 
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
@@ -2358,10 +2360,15 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
break;
case PLANE_CTL_TILED_YF: /* aka PLANE_CTL_TILED_4 on XE_LPD+ */
if (HAS_4TILE(dev_priv)) {
-   if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
+   u32 rc_mask = PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
+
+   if ((val & rc_mask) == rc_mask)
fb->modifier = 
I915_FORMAT_MOD_4_TILED_DG2_RC_CCS;
else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
fb->modifier = 
I915_FORMAT_MOD_4_TILED_DG2_MC_CCS;
+   else if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
+   fb->modifier = 
I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC;
else
fb->modifier = I915_FORMAT_MOD_4_TILED;
} else {
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b8fb7b44c03c..697614ea4b84 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -605,6 +605,16 @@ extern "C" {
  */
 #define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11)
 
+/*
+ * Intel color control surfaces (CCS) for DG2 clear color render compression.
+ *
+ * DG2 uses a unified compression format for clear color render compression.
+ * The general layout is a tiled layout using 4Kb tiles i.e. Tile4 layout.
+ *
+ * Fast clear color value expected by HW is located in fb at offset 0 of 
plane#1
+ */
+#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
+
 /*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *
-- 
2.20.1

[Intel-gfx] [PATCH v5 15/19] drm/i915/dg2: Add DG2 unified compression

[Ramalingam C]

From: Matt Roper 

DG2 unifies render compression and media compression into a single
format for the first time.  The programming and buffer layout is
supposed to match compression on older gen12 platforms, but the actual
compression algorithm is different from any previous platform; as such,
we need a new framebuffer modifier to represent buffers in this format,
but otherwise we can re-use the existing gen12 compression driver logic.

v2:
  Display version fix [Imre]

Signed-off-by: Matt Roper 
cc: Radhakrishna Sripada 
Signed-off-by: Mika Kahola  (v2)
cc: Anshuman Gupta 
Signed-off-by: Juha-Pekka Heikkilä 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/display/intel_fb.c   | 13 ++
 .../drm/i915/display/skl_universal_plane.c| 26 ---
 include/uapi/drm/drm_fourcc.h | 22 
 3 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 94c57facbb46..4d4d01963f15 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -141,6 +141,14 @@ struct intel_modifier_desc {
 
 static const struct intel_modifier_desc intel_modifiers[] = {
{
+   .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
+   .display_ver = { 13, 13 },
+   .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
+   }, {
+   .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
+   .display_ver = { 13, 13 },
+   .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_RC,
+   }, {
.modifier = I915_FORMAT_MOD_4_TILED,
.display_ver = { 13, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_4,
@@ -550,6 +558,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
case I915_FORMAT_MOD_4_TILED:
/*
 * Each 4K tile consists of 64B(8*8) subtiles, with
@@ -752,6 +762,9 @@ unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+   return 16 * 1024;
default:
MISSING_CASE(fb->modifier);
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 5299dfe68802..c38ae0876c15 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -764,6 +764,14 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
return PLANE_CTL_TILED_Y;
case I915_FORMAT_MOD_4_TILED:
return PLANE_CTL_TILED_4;
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+   return PLANE_CTL_TILED_4 |
+   PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
+   PLANE_CTL_CLEAR_COLOR_DISABLE;
+   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+   return PLANE_CTL_TILED_4 |
+   PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE |
+   PLANE_CTL_CLEAR_COLOR_DISABLE;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return PLANE_CTL_TILED_Y | 
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
@@ -2094,6 +2102,10 @@ static bool gen12_plane_has_mc_ccs(struct 
drm_i915_private *i915,
if (IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
return false;
 
+   /* Wa_14013215631 */
+   if (IS_DG2_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
+   return false;
+
return plane_id < PLANE_SPRITE4;
 }
 
@@ -2335,9 +2347,10 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
case PLANE_CTL_TILED_Y:
plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
-   fb->modifier = DISPLAY_VER(dev_priv) >= 12 ?
-   I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS :
-   I915_FORMAT_MOD_Y_TILED_CCS;
+   if (DISPLAY_VER(dev_priv) >= 12)
+   fb->modifier = 
I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS;
+   else
+   fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS;
else
@@ -2345,7 +2358,12 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,

[Intel-gfx] [PATCH v5 14/19] drm/i915/dg2: Tile 4 plane format support

[Ramalingam C]

From: Stanislav Lisovskiy 

Tile4 in bspec format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.

v2: - Moved Tile4 assocating struct for modifier/display to
  the beginning(Imre Deak)
- Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
  checks(Imre Deak)
- Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
  (Imre Deak)

v3: - Rebased patch on top of new changes related to plane_caps.
- Added static assert to check that PLANE_CTL_TILING_YF
  matches PLANE_CTL_TILING_4(Nanley Chery)
- Fixed naming and layout description for Tile 4 in drm uapi
  header(Nanley Chery)

v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)

Reviewed-by: Imre Deak 
Cc: Matt Roper 
Cc: Maarten Lankhorst 
Signed-off-by: Stanislav Lisovskiy 
Signed-off-by: Matt Roper 
Signed-off-by: Juha-Pekka Heikkilä 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  1 +
 drivers/gpu/drm/i915/display/intel_fb.c   | 15 +++-
 drivers/gpu/drm/i915/display/intel_fb.h   |  1 +
 drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
 .../drm/i915/display/intel_plane_initial.c|  1 +
 .../drm/i915/display/skl_universal_plane.c| 23 ---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_pci.c   |  1 +
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 drivers/gpu/drm/i915/intel_device_info.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   |  1 +
 11 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 75de794185b2..189767cef356 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7737,6 +7737,7 @@ static int intel_atomic_check_async(struct 
intel_atomic_state *state, struct int
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
+   case I915_FORMAT_MOD_4_TILED:
break;
default:
drm_dbg_kms(>drm,
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 23cfe2e5ce2a..94c57facbb46 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -135,11 +135,16 @@ struct intel_modifier_desc {
 INTEL_PLANE_CAP_CCS_MC)
 #define INTEL_PLANE_CAP_TILING_MASK(INTEL_PLANE_CAP_TILING_X | \
 INTEL_PLANE_CAP_TILING_Y | \
-INTEL_PLANE_CAP_TILING_Yf)
+INTEL_PLANE_CAP_TILING_Yf | \
+INTEL_PLANE_CAP_TILING_4)
 #define INTEL_PLANE_CAP_TILING_NONE0
 
 static const struct intel_modifier_desc intel_modifiers[] = {
{
+   .modifier = I915_FORMAT_MOD_4_TILED,
+   .display_ver = { 13, 13 },
+   .plane_caps = INTEL_PLANE_CAP_TILING_4,
+   }, {
.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
.display_ver = { 12, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_Y | INTEL_PLANE_CAP_CCS_MC,
@@ -545,6 +550,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_4_TILED:
+   /*
+* Each 4K tile consists of 64B(8*8) subtiles, with
+* same shape as Y Tile(i.e 4*16B OWords)
+*/
+   return 128;
case I915_FORMAT_MOD_Y_TILED_CCS:
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return 128;
@@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64 
fb_modifier)
return I915_TILING_Y;
case INTEL_PLANE_CAP_TILING_X:
return I915_TILING_X;
+   case INTEL_PLANE_CAP_TILING_4:
case INTEL_PLANE_CAP_TILING_Yf:
case INTEL_PLANE_CAP_TILING_NONE:
return I915_TILING_NONE;
@@ -737,6 +749,7 @@ unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h 
b/drivers/gpu/drm/i915/display/intel_fb.h
index ba9df8986c1e..12386f13a4e0 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -27,6 +27,7 @@ struct intel_plane_state;
 #define INTEL_PLANE_CAP_TILING_X   BIT(3)
 #define 

[Intel-gfx] [PATCH v5 13/19] drm/i915: Introduce new Tile 4 format

[Ramalingam C]

From: Stanislav Lisovskiy 

This tiling layout uses 4KB tiles in a row-major layout. It has the same
shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
only differs from Tile Y at the 256B granularity in between. At this
granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape
of 64B x 8 rows.

Reviewed-by: Imre Deak 
Acked-by: Nanley Chery 
Signed-off-by: Stanislav Lisovskiy 
---
 include/uapi/drm/drm_fourcc.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index fc0c1454d275..b73fe6797fc3 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -572,6 +572,17 @@ extern "C" {
  */
 #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
 
+/*
+ * Intel Tile 4 layout
+ *
+ * This is a tiled layout using 4KB tiles in a row-major layout. It has the 
same
+ * shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
+ * only differs from Tile Y at the 256B granularity in between. At this
+ * granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a 
shape
+ * of 64B x 8 rows.
+ */
+#define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
+
 /*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *
-- 
2.20.1

[Intel-gfx] [PATCH v5 12/19] drm/i915/gt: Clear compress metadata for Xe_HP platforms

[Ramalingam C]

From: Ayaz A Siddiqui 

Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.

Flat CCS memory can not be directly accessed by S/W.
Address of CCS buffer associated main BO is automatically calculated
by device itself. KMD/UMD can only access this buffer indirectly using
XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.

v2: Fixed issues with platform naming [Lucas]
v3: Rebased [Ram]
Used the round_up funcs [Bob]

Cc: CQ Tang 
Signed-off-by: Ayaz A Siddiqui 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  14 +++
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 114 ++-
 2 files changed, 125 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f8253012d166..07bf5a1753bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -203,6 +203,20 @@
 #define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
 #define GFX_OP_DRAWRECT_INFO_I965  ((0x7900<<16)|0x2)
 
+#define XY_CTRL_SURF_INSTR_SIZE5
+#define MI_FLUSH_DW_SIZE   3
+#define XY_CTRL_SURF_COPY_BLT  ((2 << 29) | (0x48 << 22) | 3)
+#define   SRC_ACCESS_TYPE_SHIFT21
+#define   DST_ACCESS_TYPE_SHIFT20
+#define   CCS_SIZE_SHIFT   8
+#define   XY_CTRL_SURF_MOCS_SHIFT  25
+#define   NUM_CCS_BYTES_PER_BLOCK  256
+#define   NUM_CCS_BLKS_PER_XFER1024
+#define   INDIRECT_ACCESS  0
+#define   DIRECT_ACCESS1
+#define  MI_FLUSH_LLC  BIT(9)
+#define  MI_FLUSH_CCS  BIT(16)
+
 #define COLOR_BLT_CMD  (2 << 29 | 0x40 << 22 | (5 - 2))
 #define XY_COLOR_BLT_CMD   (2 << 29 | 0x50 << 22)
 #define SRC_COPY_BLT_CMD   (2 << 29 | 0x43 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index cac791155244..3e1cf224cdf0 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -16,6 +16,8 @@ struct insert_pte_data {
 };
 
 #define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
+#define GET_CCS_SIZE(i915, size)   (HAS_FLAT_CCS(i915) ? \
+   DIV_ROUND_UP(size, 
NUM_CCS_BYTES_PER_BLOCK) : 0)
 
 static bool engine_supports_migration(struct intel_engine_cs *engine)
 {
@@ -594,19 +596,105 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
 }
 
+static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
+{
+   /* Mask the 3 LSB to use the PPGTT address space */
+   *cmd++ = MI_FLUSH_DW | flags;
+   *cmd++ = lower_32_bits(dst);
+   *cmd++ = upper_32_bits(dst);
+
+   return cmd;
+}
+
+static u32 calc_ctrl_surf_instr_size(struct drm_i915_private *i915, int size)
+{
+   u32 num_cmds, num_blks, total_size;
+
+   if (!GET_CCS_SIZE(i915, size))
+   return 0;
+
+   /*
+* XY_CTRL_SURF_COPY_BLT transfers CCS in 256 byte
+* blocks. one XY_CTRL_SURF_COPY_BLT command can
+* trnasfer upto 1024 blocks.
+*/
+   num_blks = GET_CCS_SIZE(i915, size);
+   num_cmds = (num_blks + (NUM_CCS_BLKS_PER_XFER - 1)) >> 10;
+   total_size = (XY_CTRL_SURF_INSTR_SIZE) * num_cmds;
+
+   /*
+* We need to add a flush before and after
+* XY_CTRL_SURF_COPY_BLT
+*/
+   total_size += 2 * MI_FLUSH_DW_SIZE;
+   return total_size;
+}
+
+static u32 *_i915_ctrl_surf_copy_blt(u32 *cmd, u64 src_addr, u64 dst_addr,
+u8 src_mem_access, u8 dst_mem_access,
+int src_mocs, int dst_mocs,
+u16 num_ccs_blocks)
+{
+   int i = num_ccs_blocks;
+
+   /*
+* The XY_CTRL_SURF_COPY_BLT instruction is used to copy the CCS
+* data in and out of the CCS region.
+*
+* We can copy at most 1024 blocks of 256 bytes using one
+* XY_CTRL_SURF_COPY_BLT instruction.
+*
+* In case we need to copy more than 1024 blocks, we need to add
+* another instruction to the same batch buffer.
+*
+* 1024 blocks of 256 bytes of CCS represent a total 256KB of CCS.
+*
+* 256 KB of CCS represents 256 * 256 KB = 64 MB of LMEM.
+*/
+   do {
+   /*
+* We use logical AND with 1023 since the size field
+* takes values which is in the range of 0 - 1023
+*/
+   *cmd++ = ((XY_CTRL_SURF_COPY_BLT) |
+ (src_mem_access << SRC_ACCESS_TYPE_SHIFT) |
+ (dst_mem_access << DST_ACCESS_TYPE_SHIFT) |
+  

[Intel-gfx] [PATCH v5 11/19] drm/i915/lmem: Enable lmem for platforms with Flat CCS

[Ramalingam C]

From: Abdiel Janulgue 

A portion of device memory is reserved for Flat CCS so usable
device memory will be reduced by size of Flat CCS. Size of
Flat CCS is specified in “XEHPSDV_FLAT_CCS_BASE_ADDR”.
So to get effective device memory we need to subtract
total device memory by Flat CCS memory size.

v2:
  Addressed the small bar related issue [Matt]
  Removed a reduntant check [Matt]

Cc: Matthew Auld 
Signed-off-by: Abdiel Janulgue 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_gt.c  | 19 
 drivers/gpu/drm/i915/gt/intel_gt.h  |  1 +
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 24 +++--
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 4 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f59933abbb3a..e40d98cb3a2d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -911,6 +911,25 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt, 
i915_reg_t reg)
return intel_uncore_read_fw(gt->uncore, reg);
 }
 
+u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg)
+{
+   int type;
+   u8 sliceid, subsliceid;
+
+   for (type = 0; type < NUM_STEERING_TYPES; type++) {
+   if (intel_gt_reg_needs_read_steering(gt, reg, type)) {
+   intel_gt_get_valid_steering(gt, type, ,
+   );
+   return intel_uncore_read_with_mcr_steering(gt->uncore,
+  reg,
+  sliceid,
+  subsliceid);
+   }
+   }
+
+   return intel_uncore_read(gt->uncore, reg);
+}
+
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p)
 {
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 2dad46c3eff2..0f571c8ee22b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -85,6 +85,7 @@ static inline bool intel_gt_needs_read_steering(struct 
intel_gt *gt,
 }
 
 u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
+u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
 
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p);
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 21215a080088..f1d37b46b505 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -205,8 +205,28 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
if (!IS_DGFX(i915))
return ERR_PTR(-ENODEV);
 
-   /* Stolen starts from GSMBASE on DG1 */
-   lmem_size = intel_uncore_read64(uncore, GEN12_GSMBASE);
+   if (HAS_FLAT_CCS(i915)) {
+   u64 tile_stolen, flat_ccs_base_addr_reg, flat_ccs_base;
+
+   lmem_size = pci_resource_len(pdev, 2);
+   flat_ccs_base_addr_reg = intel_gt_read_register(gt, 
XEHPSDV_FLAT_CCS_BASE_ADDR);
+   flat_ccs_base = (flat_ccs_base_addr_reg >> 
XEHPSDV_CCS_BASE_SHIFT) * SZ_64K;
+
+   if (GEM_WARN_ON(lmem_size < flat_ccs_base))
+   return ERR_PTR(-ENODEV);
+
+   tile_stolen = lmem_size - flat_ccs_base;
+
+   /* If the FLAT_CCS_BASE_ADDR register is not populated, flag an 
error */
+   if (tile_stolen == lmem_size)
+   DRM_ERROR("CCS_BASE_ADDR register did not have expected 
value\n");
+
+   lmem_size -= tile_stolen;
+   } else {
+   /* Stolen starts from GSMBASE without CCS */
+   lmem_size = intel_uncore_read64(>uncore, GEN12_GSMBASE);
+   }
+
 
io_start = pci_resource_start(pdev, 2);
if (GEM_WARN_ON(lmem_size > pci_resource_len(pdev, 2)))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0f36af8dc3a1..9b5423572fe9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11651,6 +11651,9 @@ enum skl_power_gate {
 #define   SGGI_DIS REG_BIT(15)
 #define   SGR_DIS  REG_BIT(13)
 
+#define XEHPSDV_FLAT_CCS_BASE_ADDR _MMIO(0x4910)
+#define   XEHPSDV_CCS_BASE_SHIFT   8
+
 /* gamt regs */
 #define GEN8_L3_LRA_1_GPGPU _MMIO(0x4dd4)
 #define   GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW  0x67F1427F /* max/min for 
LRA1/2 */
-- 
2.20.1

[Intel-gfx] [PATCH v5 10/19] drm/i915/xehpsdv: Add has_flat_ccs to device info

[Ramalingam C]

From: CQ Tang 

Platforms of XeHP and beyond support 3D surface (buffer) compression and
various compression formats. This is accomplished by an additional
compression control state (CCS) stored for each surface.

Gen 12 devices(TGL family and DG1) stores compression states in a separate
region of memory. It is managed by user-space and has an associated set of
user-space managed page tables used by hardware for address translation.

In Xe HP and beyond (XEHPSDV, DG2, etc), there is a new feature introduced
i.e Flat CCS. It replaced AUX page tables with a flat indexed region of
device memory for storing compression states.

Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Signed-off-by: CQ Tang 
Signed-off-by: Ramalingam C 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h  | 6 ++
 drivers/gpu/drm/i915/i915_pci.c  | 1 +
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4afdfa5fd3b3..384977798c8e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1528,6 +1528,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
 #define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
 
+/*
+ * Platform has the dedicated compression control state for each lmem surfaces
+ * stored in lmem to support the 3D and media compression formats.
+ */
+#define HAS_FLAT_CCS(dev_priv)   (INTEL_INFO(dev_priv)->has_flat_ccs)
+
 #define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
 
 #define HAS_POOLED_EU(dev_priv)(INTEL_INFO(dev_priv)->has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ce6ae6a3cbdf..3976482582b8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1003,6 +1003,7 @@ static const struct intel_device_info adl_p_info = {
XE_HP_PAGE_SIZES, \
.dma_mask_size = 46, \
.has_64bit_reloc = 1, \
+   .has_flat_ccs = 1, \
.has_global_mocs = 1, \
.has_gt_uc = 1, \
.has_llc = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index d8da40d01dca..ef7c7c988b7b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -133,6 +133,7 @@ enum intel_ppgtt_type {
func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
+   func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_guc_deprivilege); \
-- 
2.20.1

[Intel-gfx] [PATCH v5 09/19] Doc/gpu/rfc/i915: i915 DG2 64k pagesize uAPI

[Ramalingam C]

Details of the 64k pagesize support added as part of DG2 enabling and its
implicit impact on the uAPI.

v2: improvised the Flat-CCS documentation [Danvet & CQ]
v3: made only for 64k pagesize support

Signed-off-by: Ramalingam C 
cc: Daniel Vetter 
cc: Matthew Auld 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
 Documentation/gpu/rfc/i915_dg2.rst | 25 +
 Documentation/gpu/rfc/index.rst|  3 +++
 2 files changed, 28 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_dg2.rst

diff --git a/Documentation/gpu/rfc/i915_dg2.rst 
b/Documentation/gpu/rfc/i915_dg2.rst
new file mode 100644
index ..f4eb5a219897
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_dg2.rst
@@ -0,0 +1,25 @@
+
+I915 DG2 RFC Section
+
+
+Upstream plan
+=
+Plan to upstream the DG2 enabling is:
+
+* Merge basic HW enabling for DG2 (Still without pciid)
+* Merge the 64k support for lmem
+* Merge the flat CCS enabling patches
+* Add the pciid for DG2 and enable the DG2 in CI
+
+
+64K page support for lmem
+=
+On DG2 hw, local-memory supports minimum GTT page size of 64k only. 4k is not
+supported anymore.
+
+DG2 hw doesn't support the 64k (lmem) and 4k (smem) pages in the same ppgtt
+Page table. Refer the struct drm_i915_gem_create_ext for the implication of
+handling the 64k page size.
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
+:functions: drm_i915_gem_create_ext
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 91e93a705230..afb320ed4028 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -20,6 +20,9 @@ host such documentation:
 
 i915_gem_lmem.rst
 
+.. toctree::
+i915_dg2.rst
+
 .. toctree::
 
 i915_scheduler.rst
-- 
2.20.1

[Intel-gfx] [PATCH v5 08/19] drm/i915/uapi: document behaviour for DG2 64K support

[Ramalingam C]

From: Matthew Auld 

On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.

v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Acked-by: Jordan Justen 
Reviewed-by: Ramalingam C 
Reviewed-by: Thomas Hellström 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
 include/uapi/drm/i915_drm.h | 44 -
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
 * When the EXEC_OBJECT_PINNED flag is specified this is populated by
 * the user with the GTT offset at which this object will be pinned.
+*
 * When the I915_EXEC_NO_RELOC flag is specified this must contain the
 * presumed_offset of the object.
+*
 * During execbuffer2 the kernel populates it with the value of the
 * current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
 */
__u64 offset;
 
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects.  Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+*   1) The entire PDE (which covers a 2MB virtual address range), must
+*   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+*   PDE is forbidden by the hardware.
+*
+*   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+*   objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
 */
__u64 size;
/**
-- 
2.20.1

[Intel-gfx] [PATCH v5 07/19] drm/i915/migrate: add acceleration support for DG2

[Ramalingam C]

From: Matthew Auld 

This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).

v2: Rebased [Ram]

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 179 +++-
 1 file changed, 147 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 18b44af56969..cac791155244 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -32,6 +32,38 @@ static bool engine_supports_migration(struct intel_engine_cs 
*engine)
return true;
 }
 
+static void xehpsdv_toggle_pdes(struct i915_address_space *vm,
+   struct i915_page_table *pt,
+   void *data)
+{
+   struct insert_pte_data *d = data;
+
+   /*
+* Insert a dummy PTE into every PT that will map to LMEM to ensure
+* we have a correctly setup PDE structure for later use.
+*/
+   vm->insert_page(vm, 0, d->offset, I915_CACHE_NONE, PTE_LM);
+   GEM_BUG_ON(!pt->is_compact);
+   d->offset += SZ_2M;
+}
+
+static void xehpsdv_insert_pte(struct i915_address_space *vm,
+  struct i915_page_table *pt,
+  void *data)
+{
+   struct insert_pte_data *d = data;
+
+   /*
+* We are playing tricks here, since the actual pt, from the hw
+* pov, is only 256bytes with 32 entries, or 4096bytes with 512
+* entries, but we are still guaranteed that the physical
+* alignment is 64K underneath for the pt, and we are careful
+* not to access the space in the void.
+*/
+   vm->insert_page(vm, px_dma(pt), d->offset, I915_CACHE_NONE, PTE_LM);
+   d->offset += SZ_64K;
+}
+
 static void insert_pte(struct i915_address_space *vm,
   struct i915_page_table *pt,
   void *data)
@@ -74,7 +106,12 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
 * i.e. within the same non-preemptible window so that we do not switch
 * to another migration context that overwrites the PTE.
 *
-* TODO: Add support for huge LMEM PTEs
+* On platforms with HAS_64K_PAGES support we have three windows, and
+* dedicate two windows just for mapping lmem pages(smem <-> smem is not
+* a thing), since we are forced to use 64K GTT pages underneath which
+* requires also modifying the PDE. An alternative might be to instead
+* map the PD into the GTT, and then on the fly toggle the 4K/64K mode
+* in the PDE from the same batch that also modifies the PTEs.
 */
 
vm = i915_ppgtt_create(gt, I915_BO_ALLOC_PM_EARLY);
@@ -86,6 +123,9 @@ static struct i915_address_space *migrate_vm(struct intel_gt 
*gt)
goto err_vm;
}
 
+   if (HAS_64K_PAGES(gt->i915))
+   stash.pt_sz = I915_GTT_PAGE_SIZE_64K;
+
/*
 * Each engine instance is assigned its own chunk in the VM, so
 * that we can run multiple instances concurrently
@@ -105,14 +145,20 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
 * We copy in 8MiB chunks. Each PDE covers 2MiB, so we need
 * 4x2 page directories for source/destination.
 */
-   sz = 2 * CHUNK_SZ;
+   if (HAS_64K_PAGES(gt->i915))
+   sz = 3 * CHUNK_SZ;
+   else
+   sz = 2 * CHUNK_SZ;
d.offset = base + sz;
 
/*
 * We need another page directory setup so that we can write
 * the 8x512 PTE in each chunk.
 */
-   sz += (sz >> 12) * sizeof(u64);
+   if (HAS_64K_PAGES(gt->i915))
+   sz += (sz / SZ_2M) * SZ_64K;
+   else
+   sz += (sz >> 12) * sizeof(u64);
 
err = i915_vm_alloc_pt_stash(>vm, , sz);
if (err)
@@ -133,7 +179,18 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
goto err_vm;
 
/* Now allow the GPU to rewrite the PTE via its own ppGTT */
-   vm->vm.foreach(>vm, base, d.offset - base, insert_pte, );
+   if (HAS_64K_PAGES(gt->i915)) {
+   vm->vm.foreach(>vm, base, d.offset - base,
+  xehpsdv_insert_pte, );
+   d.offset = base + CHUNK_SZ;
+   vm->vm.foreach(>vm,
+  d.offset,
+  2 * CHUNK_SZ,
+  xehpsdv_toggle_pdes, );
+   } else {
+   vm->vm.foreach(>vm, base, 

[Intel-gfx] [PATCH v5 04/19] drm/i915: add gtt misalignment test

[Ramalingam C]

From: Robert Beckett 

add test to check handling of misaligned offsets and sizes

v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot 
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 128 ++
 1 file changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..c23b1e5cc436 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
  *
  */
 
+#include "gt/intel_gtt.h"
 #include 
 #include 
 
 #include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
 #include "gem/selftests/mock_context.h"
 #include "gt/intel_context.h"
 #include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,120 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
 }
 
+static int misaligned_case(struct i915_address_space *vm, struct 
intel_memory_region *mr,
+  u64 addr, u64 size, unsigned long flags)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int err = 0;
+   u64 expected_vma_size, expected_node_size;
+
+   obj = i915_gem_object_create_region(mr, size, 0, 0);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   vma = i915_vma_instance(obj, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_put;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, addr | flags);
+   if (err)
+   goto err_put;
+   i915_vma_unpin(vma);
+
+   if (!drm_mm_node_allocated(>node)) {
+   err = -EINVAL;
+   goto err_put;
+   }
+
+   if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+   err = -EINVAL;
+   goto err_put;
+   }
+
+   expected_vma_size = round_up(size, 1 << 
(ffs(vma->resource->page_sizes_gtt) - 1));
+   expected_node_size = expected_vma_size;
+
+   if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+   /* compact-pt should expand lmem node to 2MB */
+   expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+   expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+   }
+
+   if (vma->size != expected_vma_size || vma->node.size != 
expected_node_size) {
+   err = i915_vma_unbind(vma);
+   err = -EBADSLT;
+   goto err_put;
+   }
+
+   err = i915_vma_unbind(vma);
+   if (err)
+   goto err_put;
+
+   GEM_BUG_ON(drm_mm_node_allocated(>node));
+
+err_put:
+   i915_gem_object_put(obj);
+   cleanup_freed_objects(vm->i915);
+   return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+   struct intel_memory_region *mr;
+   enum intel_region_id id;
+   unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+   int err = 0;
+   u64 hole_size = hole_end - hole_start;
+
+   if (i915_is_ggtt(vm))
+   flags |= PIN_GLOBAL;
+
+   for_each_memory_region(mr, vm->i915, id) {
+   u64 min_alignment = i915_vm_min_alignment(vm, (enum 
intel_memory_type)id);
+   u64 size = min_alignment;
+   u64 addr = round_up(hole_start + (hole_size / 2), 
min_alignment);
+
+   /* we can't test < 4k alignment due to flags being encoded in 
lower bits */
+   if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+   err = misaligned_case(vm, mr, addr + (min_alignment / 
2), size, flags);
+   /* misaligned should error with -EINVAL*/
+   if (!err)
+   err = -EBADSLT;
+   if (err != -EINVAL)
+   return err;
+   }
+
+   /* test for vma->size expansion to min page size */
+   err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+   if (min_alignment > hole_size) {
+   if (!err)
+   err = -EBADSLT;
+   else if (err == -ENOSPC)
+   err = 0;
+   }
+   if (err)
+   return err;
+
+   /* test for intermediate size not expanding vma->size for large 
alignments */
+   err = misaligned_case(vm, mr, addr, size / 2, flags);
+   if (min_alignment > hole_size) {
+   if (!err)
+   err = -EBADSLT;
+   else if (err == -ENOSPC)
+   err = 0;

[Intel-gfx] [PATCH v5 06/19] drm/i915/gtt: add xehpsdv_ppgtt_insert_entry

[Ramalingam C]

From: Matthew Auld 

If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 
Reviewed-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 50 ++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 62471730266c..f574da00eff1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -715,13 +715,56 @@ static void gen8_ppgtt_insert_entry(struct 
i915_address_space *vm,
gen8_pdp_for_page_index(vm, idx);
struct i915_page_directory *pd =
i915_pd_entry(pdp, gen8_pd_index(idx, 2));
+   struct i915_page_table *pt = i915_pt_entry(pd, gen8_pd_index(idx, 1));
gen8_pte_t *vaddr;
 
-   vaddr = px_vaddr(i915_pt_entry(pd, gen8_pd_index(idx, 1)));
+   GEM_BUG_ON(pt->is_compact);
+
+   vaddr = px_vaddr(pt);
vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
clflush_cache_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
 }
 
+static void __xehpsdv_ppgtt_insert_entry_lm(struct i915_address_space *vm,
+   dma_addr_t addr,
+   u64 offset,
+   enum i915_cache_level level,
+   u32 flags)
+{
+   u64 idx = offset >> GEN8_PTE_SHIFT;
+   struct i915_page_directory * const pdp =
+   gen8_pdp_for_page_index(vm, idx);
+   struct i915_page_directory *pd =
+   i915_pd_entry(pdp, gen8_pd_index(idx, 2));
+   struct i915_page_table *pt = i915_pt_entry(pd, gen8_pd_index(idx, 1));
+   gen8_pte_t *vaddr;
+
+   GEM_BUG_ON(!IS_ALIGNED(addr, SZ_64K));
+   GEM_BUG_ON(!IS_ALIGNED(offset, SZ_64K));
+
+   if (!pt->is_compact) {
+   vaddr = px_vaddr(pd);
+   vaddr[gen8_pd_index(idx, 1)] |= GEN12_PDE_64K;
+   pt->is_compact = true;
+   }
+
+   vaddr = px_vaddr(pt);
+   vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+}
+
+static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
+  dma_addr_t addr,
+  u64 offset,
+  enum i915_cache_level level,
+  u32 flags)
+{
+   if (flags & PTE_LM)
+   return __xehpsdv_ppgtt_insert_entry_lm(vm, addr, offset,
+  level, flags);
+
+   return gen8_ppgtt_insert_entry(vm, addr, offset, level, flags);
+}
+
 static int gen8_init_scratch(struct i915_address_space *vm)
 {
u32 pte_flags;
@@ -921,7 +964,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 
ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
-   ppgtt->vm.insert_page = gen8_ppgtt_insert_entry;
+   if (HAS_64K_PAGES(gt->i915))
+   ppgtt->vm.insert_page = xehpsdv_ppgtt_insert_entry;
+   else
+   ppgtt->vm.insert_page = gen8_ppgtt_insert_entry;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
ppgtt->vm.foreach = gen8_ppgtt_foreach;
-- 
2.20.1

[Intel-gfx] [PATCH v5 05/19] drm/i915/gtt: allow overriding the pt alignment

[Ramalingam C]

From: Matthew Auld 

On some platforms we have alignment restrictions when accessing LMEM
from the GTT. In the next patch few patches we need to be able to modify
the page-tables directly via the GTT itself.

Suggested-by: Ramalingam C 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 10 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c | 16 
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e6ce0be6d484..2c62411eb52c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -200,6 +200,14 @@ void *__px_vaddr(struct drm_i915_gem_object *p);
 struct i915_vm_pt_stash {
/* preallocated chains of page tables/directories */
struct i915_page_table *pt[2];
+   /*
+* Optionally override the alignment/size of the physical page that
+* contains each PT. If not set defaults back to the usual
+* I915_GTT_PAGE_SIZE_4K. This does not influence the other paging
+* structures. MUST be a power-of-two. ONLY applicable on discrete
+* platforms.
+*/
+   int pt_sz;
 };
 
 struct i915_vma_ops {
@@ -591,7 +599,7 @@ void free_scratch(struct i915_address_space *vm);
 
 struct drm_i915_gem_object *alloc_pt_dma(struct i915_address_space *vm, int 
sz);
 struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int 
sz);
-struct i915_page_table *alloc_pt(struct i915_address_space *vm);
+struct i915_page_table *alloc_pt(struct i915_address_space *vm, int sz);
 struct i915_page_directory *alloc_pd(struct i915_address_space *vm);
 struct i915_page_directory *__alloc_pd(int npde);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c 
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 043652dc6892..d91e2beb7517 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -12,7 +12,7 @@
 #include "gen6_ppgtt.h"
 #include "gen8_ppgtt.h"
 
-struct i915_page_table *alloc_pt(struct i915_address_space *vm)
+struct i915_page_table *alloc_pt(struct i915_address_space *vm, int sz)
 {
struct i915_page_table *pt;
 
@@ -20,7 +20,7 @@ struct i915_page_table *alloc_pt(struct i915_address_space 
*vm)
if (unlikely(!pt))
return ERR_PTR(-ENOMEM);
 
-   pt->base = vm->alloc_pt_dma(vm, I915_GTT_PAGE_SIZE_4K);
+   pt->base = vm->alloc_pt_dma(vm, sz);
if (IS_ERR(pt->base)) {
kfree(pt);
return ERR_PTR(-ENOMEM);
@@ -221,17 +221,25 @@ int i915_vm_alloc_pt_stash(struct i915_address_space *vm,
   u64 size)
 {
unsigned long count;
-   int shift, n;
+   int shift, n, pt_sz;
 
shift = vm->pd_shift;
if (!shift)
return 0;
 
+   pt_sz = stash->pt_sz;
+   if (!pt_sz)
+   pt_sz = I915_GTT_PAGE_SIZE_4K;
+   else
+   GEM_BUG_ON(!IS_DGFX(vm->i915));
+
+   GEM_BUG_ON(!is_power_of_2(pt_sz));
+
count = pd_count(size, shift);
while (count--) {
struct i915_page_table *pt;
 
-   pt = alloc_pt(vm);
+   pt = alloc_pt(vm, pt_sz);
if (IS_ERR(pt)) {
i915_vm_free_pt_stash(vm, stash);
return PTR_ERR(pt);
-- 
2.20.1

[Intel-gfx] [PATCH v5 03/19] drm/i915: support 64K GTT pages for discrete cards

[Ramalingam C]

From: Matthew Auld 

discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.

v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot 

Signed-off-by: Matthew Auld 
Signed-off-by: Stuart Summers 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  60 ++
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 108 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   1 +
 4 files changed, 169 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
 }
 
+static int igt_ppgtt_compact(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct drm_i915_gem_object *obj;
+   int err;
+
+   /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+   if (!HAS_64K_PAGES(i915)) {
+   pr_info("device lacks compact 64K page support, skipping\n");
+   return 0;
+   }
+
+   if (!HAS_LMEM(i915)) {
+   pr_info("device lacks LMEM support, skipping\n");
+   return 0;
+   }
+
+   /* We want the range to cover multiple page-table boundaries. */
+   obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err)
+   goto out_put;
+
+   if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+   pr_info("LMEM compact unable to allocate huge-page(s)\n");
+   goto out_unpin;
+   }
+
+   /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+   obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+   err = igt_write_huge(i915, obj);
+   if (err)
+   pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+
+   if (err == -ENOMEM)
+   err = 0;
+
+   return err;
+}
+
 static int igt_tmpfs_fallback(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct 
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+   SUBTEST(igt_ppgtt_compact),
};
 
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * 
const vm,
   start, end, lvl);
} else {
unsigned int count;
+   unsigned int pte = gen8_pd_index(start, 0);
+   unsigned int num_ptes;
u64 *vaddr;
 
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * 
const vm,
atomic_read(>used));
GEM_BUG_ON(!count || count >= atomic_read(>used));
 
+   num_ptes = count;
+   if (pt->is_compact) {
+   GEM_BUG_ON(num_ptes % 16);
+   GEM_BUG_ON(pte % 16);
+   num_ptes /= 16;
+   pte /= 16;
+   }
+
vaddr = px_vaddr(pt);
-   memset64(vaddr + gen8_pd_index(start, 0),
+   memset64(vaddr + pte,
 vm->scratch[0]->encode,
-count);
+num_ptes);
 
  

[Intel-gfx] [PATCH v5 02/19] drm/i915: enforce min GTT alignment for discrete cards

[Ramalingam C]

From: Matthew Auld 

For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.

We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.

For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.

v3:
* use needs_compact_pt flag to discriminate between
  64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
  if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
  have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 .../i915/gem/selftests/i915_gem_client_blt.c  | 21 ++--
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 12 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 18 
 drivers/gpu/drm/i915/i915_vma.c   |  9 ++
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
 5 files changed, 115 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+   u64 align;
u32 width;
u32 height;
 };
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct 
rnd_state *prng)
goto err_free;
}
 
-   hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+   t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+   t->align = max(t->align,
+  i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+   hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
-   hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+   hole_size += 2 * t->align; /* padding on either side */
 
mutex_lock(>ce->vm->mutex);
memset(, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(>ce->vm->mm, ,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
  0, U64_MAX,
  DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct 
rnd_state *prng)
goto err_put;
}
 
-   t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+   t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
 
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
 static int tiled_blits_prepare(struct tiled_blits *t,
   struct rnd_state *prng)
 {
-   u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+   u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
 
 static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
 {
-   u64 offset =
-   round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+   u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
 
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct 
rnd_state *prng)
 
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+>buffers[2], t->hole + t->align,
 >buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space 
*vm, int subclass)
 
GEM_BUG_ON(!vm->total);
drm_mm_init(>mm, 0, vm->total);
+
+   memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+   

[Intel-gfx] [PATCH v5 01/19] drm/i915: add needs_compact_pt flag

[Ramalingam C]

Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.

With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.

v6:
* minor doc formatting

Suggested-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_drv.h  | 11 ---
 drivers/gpu/drm/i915/i915_pci.c  |  2 ++
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 /*
  * Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
  */
 #define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
 
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
 #define HAS_IPC(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ipc)
 
 #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+   .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+   .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+   func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
-- 
2.20.1

[Intel-gfx] [PATCH v5 00/19] drm/i915/dg2: Enabling 64k page size and flat ccs

[Ramalingam C]

This series introduces the enabling patches for new memory compression
feature Flat CCS and 64k page support for i915 local memory, along with
documentation on the uAPI impact. Included the details of the feature and
the implications on the uAPI below. Which is also added into
Documentation/gpu/rfc/i915_dg2.rst

DG2 64K page size support:
=

On discrete platforms, starting from DG2, we have to contend with GTT
page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
objects.  Specifically the hardware only supports 64K or larger GTT
page sizes for such memory. The kernel will already ensure that all
I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
sizes underneath.

Note that the returned size here will always reflect any required
rounding up done by the kernel, i.e 4K will now become 64K on devices
such as DG2.

Special DG2 GTT address alignment requirement:

The GTT alignment will also need to be at least 2M for such objects.

Note that due to how the hardware implements 64K GTT page support, we
have some further complications:

1) The entire PDE (which covers a 2MB virtual address range), must
contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
PDE is forbidden by the hardware.

2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
objects.

To keep things simple for userland, we mandate that any GTT mappings
must be aligned to and rounded up to 2MB. As this only wastes virtual
address space and avoids userland having to copy any needlessly
complicated PDE sharing scheme (coloring) and only affects DG2, this
is deemed to be a good compromise.

Flat CCS support for lmem
=
On Xe-HP and later devices, we use dedicated compression control state
(CCS) stored in local memory for each surface, to support the 3D and
media compression formats.

The memory required for the CCS of the entire local memory is 1/256 of
the local memory size. So before the kernel boot, the required memory is
reserved for the CCS data and a secure register will be programmed with
the CCS base address.

Flat CCS data needs to be cleared when a lmem object is allocated. And
CCS data can be copied in and out of CCS region through
XY_CTRL_SURF_COPY_BLT. CPU can’t access the CCS data directly.

When we exaust the lmem, if the object’s placements support smem, then
we can directly decompress the compressed lmem object into smem and
start using it from smem itself.

But when we need to swapout the compressed lmem object into a smem
region though objects’ placement doesn’t support smem, then we copy the
lmem content as it is into smem region along with ccs data (using
XY_CTRL_SURF_COPY_BLT). When the object is referred, lmem content will
be swaped in along with restoration of the CCS data (using
XY_CTRL_SURF_COPY_BLT) at corresponding location.

Flat-CCS Modifiers for different compression formats

I915_FORMAT_MOD_4_TILED_DG2_RC_CCS - used to indicate the buffers of
Flat CCS render compression formats. Though the general layout is same
as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression
algorithm is used. Render compression uses 128 byte compression blocks

I915_FORMAT_MOD_4_TILED_DG2_MC_CCS -used to indicate the buffers of Flat
CCS media compression formats. Though the general layout is same as
I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm
is used. Media compression uses 256 byte compression blocks.

I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC - used to indicate the buffers of
Flat CCS clear color render compression formats. Unified compression
format for clear color render compression. The genral layout is a tiled
layout using 4Kb tiles i.e Tile4 layout. Fast clear color value expected
by HW is located in fb at offset 0 of plane#1

v2:
  Fixed some formatting issues and platform naming issues
  Added some more documentation on Flat-CCS

v3:
  Plane programming is handled for flat-ccs and clear color
  Tile4 and flat ccs modifier patches are rebased on table based
modifier reference method
  Three patches are squashed
  Y tile is pruned for DG2.
  flat_ccs_cc plane format info is added
  Added mesa, compute and media ppl for required uAPI ack.

v4:
  Rebasing of the patches

v5:
  KDoc is enhanced for cc modifier. [Nanley & Lionel]
  inbuild macro usage for functional fix [Bob]
  Addressed review comments from Matt
  Platform coverage fix for modifiers [Imre]

Abdiel Janulgue (1):
  drm/i915/lmem: Enable lmem for platforms with Flat CCS

Anshuman Gupta (1):
  drm/i915/dg2: Flat CCS Support

Ayaz A Siddiqui (1):
  drm/i915/gt: Clear compress metadata for Xe_HP platforms

CQ Tang (1):
  drm/i915/xehpsdv: Add has_flat_ccs to device info

Matt Roper (1):
  drm/i915/dg2: Add DG2 unified compression

Matthew Auld (6):
  drm/i915: enforce min GTT alignment for discrete cards
  drm/i915: support 64K GTT pages for discrete cards
  drm/i915/gtt: allow overriding the 

Re: [Intel-gfx] [PATCH 09/20] drm/i915/buddy: tweak 2big check

[Thomas Hellström]

On Wed, 2022-01-26 at 15:21 +, Matthew Auld wrote:
> Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
> allocation doesn't fit within the pfn range, like with mappable lmem.
> The hugepages selftest, for example, needs this to know if a smaller
> size is needed.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 

Reviewed-by: Thomas Hellström 

> ---
>  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> index bc725a92fc5c..7c24cc6608e3 100644
> --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> @@ -81,7 +81,7 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> lpfn = pages;
> }
>  
> -   if (size > mm->size) {
> +   if (size > lpfn << PAGE_SHIFT) {
> err = -E2BIG;
> goto err_free_res;
> }

Re: [Intel-gfx] [PATCH 08/20] drm/i915/buddy: adjust res->start

[Thomas Hellström]

On Wed, 2022-01-26 at 15:21 +, Matthew Auld wrote:
> Differentiate between mappable vs non-mappable resources, also if
> this
> is an actual range allocation ensure we set res->start as the
> starting
> pfn. Later when we need to do non-mappable -> mappable moves then we
> want TTM to see that the current placement is not compatible, which
> should result in an actual move, instead of being turned into a noop.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 

Reviewed-by: Thomas Hellström 


> ---
>  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> index 6e5842155898..bc725a92fc5c 100644
> --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> @@ -140,6 +140,13 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> mutex_unlock(>lock);
> }
>  
> +   if (place->lpfn - place->fpfn == n_pages)
> +   bman_res->base.start = place->fpfn;
> +   else if (lpfn <= bman->visible_size)
> +   bman_res->base.start = 0;
> +   else
> +   bman_res->base.start = bman->visible_size;
> +
> *res = _res->base;
> return 0;
>  

Re: [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean

[Thomas Zimmermann]

Am 31.01.22 um 22:05 schrieb Daniel Vetter:

It's only one flag and slightly tidier code.

Signed-off-by: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Tetsuo Handa 
Cc: Greg Kroah-Hartman 
Cc: Du Cheng 
Cc: Thomas Zimmermann 
Cc: Claudio Suarez 


Acked-by: Thomas Zimmermann 


---
  drivers/video/fbdev/core/fbcon.c | 11 +--
  drivers/video/fbdev/core/fbcon.h |  4 +---
  2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index affb40658fee..fa30e1909164 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct 
fb_info *info,
  
  	ops->currcon = fg_console;
  
-	if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {

+   if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
  
  		if (ret)

@@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct 
fb_info *info,
"error code %d\n", ret);
}
  
-	ops->flags |= FBCON_FLAGS_INIT;

+   ops->initialized = true;
ops->graphics = 0;
fbcon_set_disp(info, >var, unit);
  
@@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)

 * We need to do it in fbcon_init() to prevent screen corruption.
 */
if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
-   if (info->fbops->fb_set_par &&
-   !(ops->flags & FBCON_FLAGS_INIT)) {
+   if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
  
  			if (ret)

@@ -,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
"error code %d\n", ret);
}
  
-		ops->flags |= FBCON_FLAGS_INIT;

+   ops->initialized = true;
}
  
  	ops->graphics = 0;

@@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (con_is_visible(vc))
fbcon_del_cursor_work(info);
  
-	ops->flags &= ~FBCON_FLAGS_INIT;

+   ops->initialized = false;
  finished:
  
  	fbcon_free_font(p, free_font);

diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index dce5ce41093e..b18d0cbf73b6 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -18,8 +18,6 @@
  
  #include 
  
-#define FBCON_FLAGS_INIT 1

-
 /*
  *This is the interface between the low-level console driver and the
  *low-level frame buffer device
@@ -77,7 +75,7 @@ struct fbcon_ops {
intblank_state;
intgraphics;
intsave_graphics; /* for debug enter/leave */
-   intflags;
+   bool   initialized;


This will add 3 bytes of padding. Maybe you can put the bool elsewhere.


introtate;
intcur_rotate;
char  *cursor_data;


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Daniel Vetter]

On Tue, Feb 1, 2022 at 11:16 AM Helge Deller  wrote:
>
> On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.

Duh :-(

But before we dig into details I think the big picture would be
better. I honestly don't like the #ifdef pile here that much. I wonder
whether your approach, also with GETVX/YRES adjusted somehow, wouldn't
look cleaner? Like I said in the cover letter I got mostly distracted
with fbcon locking last week, not really with this one here at all, so
maybe going with your 4 (or 2 if we squash them like I did here)
patches is neater?

Cheers, Daniel

>
> > diff --git a/drivers/video/fbdev/core/fbcon.c 
> > b/drivers/video/fbdev/core/fbcon.c
> > index 2ff90061c7f3..39dc18a5de86 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> >   ops->graphics = 0;
> >
> > - /*
> > -  * No more hw acceleration for fbcon.
> > -  *
> > -  * FIXME: Garbage collect all the now dead code after sufficient time
> > -  * has passed.
> > -  */
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> > + !(info->flags & FBINFO_HWACCEL_DISABLED))
> > + p->scrollmode = SCROLL_MOVE;
> > + else /* default to something safe */
> > + p->scrollmode = SCROLL_REDRAW;
> > +#else
> >   p->scrollmode = SCROLL_REDRAW;
> > +#endif
> >
> >   /*
> >*  ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display 
> > *p,
> >  {
> >   struct fbcon_ops *ops = info->fbcon_par;
> >   int fh = vc->vc_font.height;
> > + int cap = info->flags;
> > + u16 t = 0;
> > + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > +   info->fix.xpanstep);
> > + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> >   int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> >   int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> >  info->var.xres_virtual);
> > + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > + divides(ypan, vc->vc_font.height) && vyres > yres;
> > + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > + divides(ywrap, vc->vc_font.height) &&
> > + divides(vc->vc_font.height, vyres) &&
> > + divides(vc->vc_font.height, yres);
> > + int reading_fast = cap & FBINFO_READS_FAST;
> > + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> > + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> >
> >   p->vrows = vyres/fh;
> >   if (yres > (fh * (vc->vc_rows + 1)))
> >   p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> >   if ((yres % fh) && (vyres % fh < yres % fh))
> >   p->vrows--;
> > +
> > + if (good_wrap || good_pan) {
> > + if (reading_fast || fast_copyarea)
> > + p->scrollmode = good_wrap ?
> > + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> > + else
> > + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> > + SCROLL_PAN_REDRAW;
> > + } else {
> > + if (reading_fast || (fast_copyarea && !fast_imageblit))
> > + p->scrollmode = SCROLL_MOVE;
> > + else
> > + p->scrollmode = SCROLL_REDRAW;
> > + }
> > +
> > +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + p->scrollmode = SCROLL_REDRAW;
> > +#endif
> >  }
> >
> >  #define PITCH(w) (((w) + 7) >> 3)
> >
>
> still reviewing the other patches...
>
> Helge



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Helge Deller]

On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
> 35  Daniel Vetter
> 23  Linus Torvalds
> 10  Hans de Goede
>  9  Dave Airlie
>  6  Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.

Yes, agreed.

Acked-by: Helge Deller 

Since the code is used by drm and existing fbdev drivers,
please just make sure to not break fbdev...

Thanks!
Helge

>
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Cc: Linus Torvalds 
> Cc: Linux Fbdev development list 
> Cc: Pavel Machek 
> Cc: Sam Ravnborg 
> Cc: Greg Kroah-Hartman 
> Cc: Javier Martinez Canillas 
> Cc: DRI Development 
> Cc: Linux Kernel Mailing List 
> Cc: Claudio Suarez 
> Cc: Tomi Valkeinen 
> Cc: Geert Uytterhoeven 
> Cc: Thomas Zimmermann 
> Cc: Daniel Vetter 
> Cc: Sven Schnelle 
> Cc: Gerd Hoffmann 
> Signed-off-by: Daniel Vetter 
> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
>  W:   http://floatingpoint.sourceforge.net/emulator/index.html
>  F:   arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M:   Daniel Vetter 
> +F:   drivers/video/fbdev/core/
> +S:   Odd Fixes
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +
>  FRAMEBUFFER LAYER
>  M:   Helge Deller 
>  L:   linux-fb...@vger.kernel.org
>

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Helge Deller]

On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.

you have two trivial copy-n-paste errors in this patch which still prevent the
console acceleration.

> diff --git a/drivers/video/fbdev/core/fbcon.c 
> b/drivers/video/fbdev/core/fbcon.c
> index 2ff90061c7f3..39dc18a5de86 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>
>   ops->graphics = 0;
>
> - /*
> -  * No more hw acceleration for fbcon.
> -  *
> -  * FIXME: Garbage collect all the now dead code after sufficient time
> -  * has passed.
> -  */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION

should be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION


> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> + !(info->flags & FBINFO_HWACCEL_DISABLED))
> + p->scrollmode = SCROLL_MOVE;
> + else /* default to something safe */
> + p->scrollmode = SCROLL_REDRAW;
> +#else
>   p->scrollmode = SCROLL_REDRAW;
> +#endif
>
>   /*
>*  ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>  {
>   struct fbcon_ops *ops = info->fbcon_par;
>   int fh = vc->vc_font.height;
> + int cap = info->flags;
> + u16 t = 0;
> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> +   info->fix.xpanstep);
> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>   int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>   int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>  info->var.xres_virtual);
> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> + divides(ypan, vc->vc_font.height) && vyres > yres;
> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> + divides(ywrap, vc->vc_font.height) &&
> + divides(vc->vc_font.height, vyres) &&
> + divides(vc->vc_font.height, yres);
> + int reading_fast = cap & FBINFO_READS_FAST;
> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
>
>   p->vrows = vyres/fh;
>   if (yres > (fh * (vc->vc_rows + 1)))
>   p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>   if ((yres % fh) && (vyres % fh < yres % fh))
>   p->vrows--;
> +
> + if (good_wrap || good_pan) {
> + if (reading_fast || fast_copyarea)
> + p->scrollmode = good_wrap ?
> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> + else
> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> + SCROLL_PAN_REDRAW;
> + } else {
> + if (reading_fast || (fast_copyarea && !fast_imageblit))
> + p->scrollmode = SCROLL_MOVE;
> + else
> + p->scrollmode = SCROLL_REDRAW;
> + }
> +
> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION

same here... it needs to be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION


> + p->scrollmode = SCROLL_REDRAW;
> +#endif
>  }
>
>  #define PITCH(w) (((w) + 7) >> 3)
>

still reviewing the other patches...

Helge

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

[Thomas Zimmermann]

Am 31.01.22 um 22:05 schrieb Daniel Vetter:

Ever since Tomi extracted the core code in 2014 it's been defacto me
maintaining this, with help from others from dri-devel and sometimes
Linus (but those are mostly merge conflicts):

$ git shortlog -ns  drivers/video/fbdev/core/ | head -n5
 35  Daniel Vetter
 23  Linus Torvalds
 10  Hans de Goede
  9  Dave Airlie
  6  Peter Rosin

I think ideally we'd also record that the various firmware fb drivers
(efifb, vesafb, ...) are also maintained in drm-misc because for the
past few years the patches have either been to fix handover issues
with drm drivers, or caused handover issues with drm drivers. So any
other tree just doesn't make sense. But also, there's plenty of
outdated MAINTAINER entries for these with people and git trees that
haven't been active in years, so maybe let's just leave them alone.
And furthermore distros are now adopting simpledrm as the firmware fb
driver, so hopefully the need to care about the fbdev firmware drivers
will go down going forward.

Note that drm-misc is group maintained, I expect that to continue like
we've done before, so no new expectations that patches all go through
my hands. That would be silly. This also means I'm happy to put any
other volunteer's name in the M: line, but otherwise git log says I'm
the one who's stuck with this.

Cc: Dave Airlie 
Cc: Jani Nikula 
Cc: Linus Torvalds 
Cc: Linux Fbdev development list 
Cc: Pavel Machek 
Cc: Sam Ravnborg 
Cc: Greg Kroah-Hartman 
Cc: Javier Martinez Canillas 
Cc: DRI Development 
Cc: Linux Kernel Mailing List 
Cc: Claudio Suarez 
Cc: Tomi Valkeinen 
Cc: Geert Uytterhoeven 
Cc: Thomas Zimmermann 
Cc: Daniel Vetter 
Cc: Sven Schnelle 
Cc: Gerd Hoffmann 
Signed-off-by: Daniel Vetter 


Acked-by: Thomas Zimmermann 


---
  MAINTAINERS | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..49809eaa3096 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7573,6 +7573,12 @@ S:   Maintained
  W:http://floatingpoint.sourceforge.net/emulator/index.html
  F:arch/x86/math-emu/
  
+FRAMEBUFFER CORE

+M: Daniel Vetter 
+F: drivers/video/fbdev/core/
+S: Odd Fixes
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
  FRAMEBUFFER LAYER
  M:Helge Deller 
  L:linux-fb...@vger.kernel.org


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

[Intel-gfx] ✗ Fi.CI.IGT: failure for Minor Fixes and Refactoring for HDMI PCON stuff (rev2)

[Patchwork]

== Series Details ==

Series: Minor Fixes and Refactoring for HDMI PCON stuff (rev2)
URL   : https://patchwork.freedesktop.org/series/99311/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11168_full -> Patchwork_22146_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22146_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22146_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (11 -> 13)
--

  Additional (2): shard-rkl shard-dg1 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22146_full:

### CI changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * boot:
- {shard-dg1}:NOTRUN -> ([FAIL][1], [PASS][2], [PASS][3])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22146/shard-dg1-12/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22146/shard-dg1-12/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22146/shard-dg1-12/boot.html

  

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@mock@requests:
- shard-skl:  [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-skl6/igt@i915_selftest@m...@requests.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22146/shard-skl1/igt@i915_selftest@m...@requests.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_scaling_modes@scaling-mode-full-aspect:
- {shard-tglu}:   NOTRUN -> [SKIP][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22146/shard-tglu-2/igt@kms_scaling_mo...@scaling-mode-full-aspect.html

  * igt@kms_scaling_modes@scaling-mode-none:
- {shard-rkl}:NOTRUN -> [SKIP][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22146/shard-rkl-2/igt@kms_scaling_mo...@scaling-mode-none.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_copy_image@arb_copy_image-formats --samples=4:
- pig-glk-j5005:  NOTRUN -> [FAIL][8]
   [8]: None

  
Known issues


  Here are the changes found in Patchwork_22146_full that come from known 
issues:

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [FAIL][24], 
[PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33]) ([i915#4392]) -> ([PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], 
[PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk4/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk1/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk1/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk1/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk2/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk9/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk9/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk9/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk7/boot.html
   [28]: 

Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration

[Helge Deller]

On 2/1/22 11:16, Helge Deller wrote:
> On 1/31/22 22:05, Daniel Vetter wrote:
>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>> option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
>
>> diff --git a/drivers/video/fbdev/core/fbcon.c 
>> b/drivers/video/fbdev/core/fbcon.c
>> index 2ff90061c7f3..39dc18a5de86 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>>  ops->graphics = 0;
>>
>> -/*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> +if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
>> +!(info->flags & FBINFO_HWACCEL_DISABLED))
>> +p->scrollmode = SCROLL_MOVE;
>> +else /* default to something safe */
>> +p->scrollmode = SCROLL_REDRAW;
>> +#else
>>  p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>
>>  /*
>>   *  ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>>  {
>>  struct fbcon_ops *ops = info->fbcon_par;
>>  int fh = vc->vc_font.height;
>> +int cap = info->flags;
>> +u16 t = 0;
>> +int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> +  info->fix.xpanstep);
>> +int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>>  int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>>  int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> +int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> +divides(ypan, vc->vc_font.height) && vyres > yres;
>> +int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> +divides(ywrap, vc->vc_font.height) &&
>> +divides(vc->vc_font.height, vyres) &&
>> +divides(vc->vc_font.height, yres);
>> +int reading_fast = cap & FBINFO_READS_FAST;
>> +int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> +!(cap & FBINFO_HWACCEL_DISABLED);
>> +int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> +!(cap & FBINFO_HWACCEL_DISABLED);
>>
>>  p->vrows = vyres/fh;
>>  if (yres > (fh * (vc->vc_rows + 1)))
>>  p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>>  if ((yres % fh) && (vyres % fh < yres % fh))
>>  p->vrows--;
>> +
>> +if (good_wrap || good_pan) {
>> +if (reading_fast || fast_copyarea)
>> +p->scrollmode = good_wrap ?
>> +SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> +else
>> +p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> +SCROLL_PAN_REDRAW;
>> +} else {
>> +if (reading_fast || (fast_copyarea && !fast_imageblit))
>> +p->scrollmode = SCROLL_MOVE;
>> +else
>> +p->scrollmode = SCROLL_REDRAW;
>> +}
>> +
>> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION

actually:
#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION

>
>
>> +p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>  }
>>
>>  #define PITCH(w) (((w) + 7) >> 3)
>>
>
> still reviewing the other patches...
>
> Helge
>

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk()

[Ville Syrjälä]

On Tue, Feb 01, 2022 at 10:52:39AM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Jan 18, 2022 at 11:23:50AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
> > somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
> > (at least documented) dbuf min cdclk limit on pre-skl so let's just get
> > rid of all this confusion.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> I think we constantly have a bit contradictional attitude towards such 
> situation.
> >From one perspective you can say, that those kind of "leagcy" callbacks are
> pointless, from the other hand one might say. that we need to have a unified
> approach for all platforms and I think we got, some legacy handlers for old
> platforms for similar purpose as well.
> I'm fine with both approaches, however for example when I was submitting
> that patch, I was asked by reviewer to add this kind of legacy callback, so 
> that we have
> a "uniform" approach.
> We just then need to have some standard agreement on those, which doesn't
> depend on today's cosmic radiation levels :)

Yes in general I prefer a unified approach across all platforms.
But in this case there is nothing to do for the old platforms as they
don't have any kind of dbuf cdclk limit, or if there is one we don't
know what it is since it's not documented.

So the only thing the code was really doing was conflating the
per-pipe cdclk limit (which is handled elsewhere for all platforms
in a  unified fashion) with something that doesn't even exist.

Also I don't think it was even correct anyway since it was
using the per-pipe cdclk_state->min_cdclk[] already during
intel_cdclk_atomic_check(), but cdclk_state->min_cdclk[]
isn't even computed until intel_modeset_calc_cdclk() which 
is called later. So I guess it was basically just computing 
the max of the min_cdclk[] for all the pipes for the _old_
state, not the new state.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915/ttm: Return some errors instead of trying memcpy move

[Matthew Auld]

On 01/02/2022 07:03, Thomas Hellström wrote:

The i915_ttm_accel_move() function may return error codes that should
be propagated further up the stack rather than consumed assuming that
the accel move failed and could be replaced with a memcpy move.

For -EINTR, -ERESTARTSYS and -EAGAIN, just propagate those codes, rather
than retrying with a memcpy move.

Fixes: 2b0a750caf33 ("drm/i915/ttm: Failsafe migration blits")
Cc: Matthew Auld 
Signed-off-by: Thomas Hellström 

Reviewed-by: Matthew Auld 

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Re-work invalidate_csb_entries

[Tvrtko Ursulin]

On 31/01/2022 14:15, Mika Kuoppala wrote:

Tvrtko Ursulin  writes:


On 28/01/2022 22:10, Michael Cheng wrote:

Re-work invalidate_csb_entries to use drm_clflush_virt_range. This will
prevent compiler errors when building for non-x86 architectures.

Signed-off-by: Michael Cheng 
---
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 960a9aaf4f3a..90b5daf9433d 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1647,8 +1647,8 @@ cancel_port_requests(struct intel_engine_execlists * 
const execlists,
   
   static void invalidate_csb_entries(const u64 *first, const u64 *last)

   {
-   clflush((void *)first);
-   clflush((void *)last);
+   drm_clflush_virt_range((void *)first, sizeof(*first));
+   drm_clflush_virt_range((void *)last, sizeof(*last));


How about dropping the helper and from the single call site do:

drm_clflush_virt_range([0], num_entries * sizeof(buf[0]));

One less function call and CSB is a single cacheline before Gen11 ayway,
two afterwards, so overall better conversion I think. How does that sound?


It would definitely work. Now trying to remember why it went into
explicit clflushes: iirc as this is gpu/cpu coherency, the
wbinvd_on_all_cpus we get with *virt_range would then be just
unnecessary perf hit.


Right, apart that AFAICS wbinvd_on_all_cpus does not run on the 
X86_FEATURE_CLFLUSH path of drm_clflush_virt_range, which made me think 
invalidate_csb_entries might have been an a) optimisation which used the 
knowledge CSB is at most two cachelines large, and b) there is no need 
for the memory barrier since as you say it is about CPU/GPU effect so 
CPU ordering is not a concern.


Anyway, larger hammer probably does not harm much, apart that it really 
should be one call to drm_clflush_virt_range.


Regards,

Tvrtko

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm-misc-next (rev2)

[Patchwork]

== Series Details ==

Series: drm-misc-next (rev2)
URL   : https://patchwork.freedesktop.org/series/31921/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11169 -> Patchwork_22147


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22147 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22147, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/index.html

Participating hosts (42 -> 43)
--

  Additional (2): fi-kbl-soraka fi-icl-u2 
  Missing(1): fi-pnv-d510 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22147:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11169/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  
Known issues


  Here are the changes found in Patchwork_22147 that come from known issues:

### CI changes ###

 Possible fixes 

  * boot:
- fi-kbl-8809g:   [FAIL][3] -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11169/fi-kbl-8809g/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-kbl-8809g/boot.html
- fi-skl-6700k2:  [FAIL][5] -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11169/fi-skl-6700k2/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-skl-6700k2/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> [SKIP][7] ([fdo#109271]) +28 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([fdo#109315]) +17 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][11] ([i915#4962]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-kbl-8809g/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-skl-6700k2:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([i915#4613]) +3 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-skl-6700k2:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22147/fi-skl-6700k2/igt@gem_lmem_swapp...@random-engines.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +3 
similar issues
 

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/: Re-work clflush_write32

[Tvrtko Ursulin]

On 31/01/2022 17:02, Michael Cheng wrote:

Hey Tvrtko,

Are you saying when adding drm_clflush_virt_range(addr, sizeof(addr), 
this function forces an x86 code path only? If that is the case, 
drm_clflush_virt_range(addr, sizeof(addr) currently has ifdefs that 
seperate out x86 and powerpc, so we can add an ifdef for arm in the near 
future when needed.


No, I was noticing that the change you are making in this patch, while 
it indeed fixes a build failure, it is a code path which does not get 
executed on Arm at all.


So what effectively happens is a single assembly instruction gets 
replaced with a function call on all integrated GPUs up to and including 
Tigerlake.


That was the slightly annoying part I was referring to and asking 
whether it was discussed before.


Sadly I don't think there is a super nice solution apart from 
duplicating drm_clflush_virt_range as for example i915_clflush_range and 
having it static inline. That would allow the integrated GPU code path 
to remain of the same performance profile, while solving the Arm 
problem. However it would be code duplication so might be frowned upon.


I'd be tempted to go that route but it is something which needs a bit of 
discussion if that hasn't happened already.


Regards,

Tvrtko


On 2022-01-31 6:55 a.m., Tvrtko Ursulin wrote:

On 28/01/2022 22:10, Michael Cheng wrote:

Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.

Signed-off-by: Michael Cheng 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
  static void clflush_write32(u32 *addr, u32 value, unsigned int 
flushes)

  {
  if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
-    if (flushes & CLFLUSH_BEFORE) {
-    clflushopt(addr);
-    mb();
-    }
+    if (flushes & CLFLUSH_BEFORE)
+    drm_clflush_virt_range(addr, sizeof(addr));
    *addr = value;
  @@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 
value, unsigned int flushes)

   * to ensure ordering of clflush wrt to the system.
   */
  if (flushes & CLFLUSH_AFTER)
-    clflushopt(addr);
+    drm_clflush_virt_range(addr, sizeof(addr));
  } else
  *addr = value;
  }


Slightly annoying thing here (maybe in some other patches from the 
series as well) is that the change adds a function call to x86 only 
code path, because relocations are not supported on discrete as per:


static in
eb_validate_vma(...)
    /* Relocations are disallowed for all platforms after TGL-LP. 
This

 * also covers all platforms with local memory.
 */

    if (entry->relocation_count &&
    GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
    return -EINVAL;

How acceptable would be, for the whole series, to introduce a static 
inline i915 cluflush wrapper and so be able to avoid functions calls 
on x86? Is this something that has been discussed and discounted already?


Regards,

Tvrtko

P.S. Hmm I am now reminded of my really old per platform build 
patches. With them you would be able to compile out large portions of 
the driver when building for ARM. Probably like a 3rd if my memory 
serves me right.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: Return some errors instead of trying memcpy move

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: Return some errors instead of trying memcpy move
URL   : https://patchwork.freedesktop.org/series/99553/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11168_full -> Patchwork_22145_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22145_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22145_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (11 -> 13)
--

  Additional (2): shard-rkl shard-dg1 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22145_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_persistence@smoketest:
- shard-apl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-apl6/igt@gem_ctx_persiste...@smoketest.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22145/shard-apl4/igt@gem_ctx_persiste...@smoketest.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_scaling_modes@scaling-mode-full-aspect:
- {shard-rkl}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22145/shard-rkl-1/igt@kms_scaling_mo...@scaling-mode-full-aspect.html

  * igt@kms_scaling_modes@scaling-mode-none:
- {shard-dg1}:NOTRUN -> [SKIP][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22145/shard-dg1-15/igt@kms_scaling_mo...@scaling-mode-none.html

  
Known issues


  Here are the changes found in Patchwork_22145_full that come from known 
issues:

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], 
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [FAIL][20], 
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], 
[PASS][27], [PASS][28], [PASS][29]) ([i915#4392]) -> ([PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk4/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk4/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk4/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk1/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk1/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk2/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk9/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk9/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk9/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk8/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk8/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk8/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk7/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk7/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk6/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk6/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk5/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11168/shard-glk5/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22145/shard-glk9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22145/shard-glk9/boot.html
   [32]: 

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

[Tvrtko Ursulin]

On 31/01/2022 22:27, Stephen Rothwell wrote:

Hi all,

After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/i915/i915_vma.c: In function 'i915_vma_bind':
drivers/gpu/drm/i915/i915_vma.c:451:25: error: 'ret' undeclared (first use in 
this function); did you mean 'net'?
   451 | ret = 
i915_gem_object_wait_moving_fence(vma->obj, true);
   | ^~~
   | net

Caused by commit

   2e872d87cbf2 ("drm/i915: delete shadow "ret" variable")

I have reverted that commit for today.


Dropping was the right call - I have since removed it from 
drm-intel-fixes as well.


Root cause was a bad Fixes: tag in that patch which caused it to be 
wrongly cherry-picked and I did not build test before pushing.


We can't edit the wrong Fixes: tag now, so for future reference only, 
2e872d87cbf2 ("drm/i915: delete shadow "ret" variable") should not be 
backported to 5.17 by anyone.


Wrong tag:
Fixes: f6c466b84cfa ("drm/i915: Add support for moving fence waiting")

Correct tag should have been:
Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")

Regards,

Tvrtko

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm-misc-next (rev2)

[Patchwork]

== Series Details ==

Series: drm-misc-next (rev2)
URL   : https://patchwork.freedesktop.org/series/31921/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
887f74cb4db5 drm-misc-next
-:50: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 1 errors, 0 warnings, 0 checks, 14 lines checked

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk()

[Lisovskiy, Stanislav]

On Tue, Jan 18, 2022 at 11:23:50AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
> somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
> (at least documented) dbuf min cdclk limit on pre-skl so let's just get
> rid of all this confusion.
> 
> Signed-off-by: Ville Syrjälä 

I think we constantly have a bit contradictional attitude towards such 
situation.
>From one perspective you can say, that those kind of "leagcy" callbacks are
pointless, from the other hand one might say. that we need to have a unified
approach for all platforms and I think we got, some legacy handlers for old
platforms for similar purpose as well.
I'm fine with both approaches, however for example when I was submitting
that patch, I was asked by reviewer to add this kind of legacy callback, so 
that we have
a "uniform" approach.
We just then need to have some standard agreement on those, which doesn't
depend on today's cosmic radiation levels :)

Reviewed-by: Stanislav Lisovskiy 


> ---
>  drivers/gpu/drm/i915/display/intel_bw.c| 49 ++
>  drivers/gpu/drm/i915/display/intel_bw.h|  1 -
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 31 +-
>  3 files changed, 5 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 93feab671c29..a3f169686f14 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -715,7 +715,7 @@ static void skl_crtc_calc_dbuf_bw(struct intel_bw_state 
> *bw_state,
>   }
>  }
>  
> -int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
> +int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   struct intel_bw_state *new_bw_state = NULL;
> @@ -726,6 +726,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>   enum pipe pipe;
>   int i;
>  
> + if (DISPLAY_VER(dev_priv) < 9)
> + return 0;
> +
>   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
>   new_bw_state = intel_atomic_get_bw_state(state);
>   if (IS_ERR(new_bw_state))
> @@ -770,50 +773,6 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>   return 0;
>  }
>  
> -int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct intel_bw_state *new_bw_state = NULL;
> - struct intel_bw_state *old_bw_state = NULL;
> - const struct intel_crtc_state *crtc_state;
> - struct intel_crtc *crtc;
> - int min_cdclk = 0;
> - enum pipe pipe;
> - int i;
> -
> - for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - new_bw_state = intel_atomic_get_bw_state(state);
> - if (IS_ERR(new_bw_state))
> - return PTR_ERR(new_bw_state);
> -
> - old_bw_state = intel_atomic_get_old_bw_state(state);
> - }
> -
> - if (!old_bw_state)
> - return 0;
> -
> - for_each_pipe(dev_priv, pipe) {
> - struct intel_cdclk_state *cdclk_state;
> -
> - cdclk_state = intel_atomic_get_new_cdclk_state(state);
> - if (!cdclk_state)
> - return 0;
> -
> - min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk);
> - }
> -
> - new_bw_state->min_cdclk = min_cdclk;
> -
> - if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> - int ret = intel_atomic_lock_global_state(_bw_state->base);
> -
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -
>  int intel_bw_atomic_check(struct intel_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index 46c6eecbd917..57eb755d298a 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -65,6 +65,5 @@ void intel_bw_crtc_update(struct intel_bw_state *bw_state,
>  int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask);
>  int intel_bw_calc_min_cdclk(struct intel_atomic_state *state);
> -int skl_bw_calc_min_cdclk(struct intel_atomic_state *state);
>  
>  #endif /* __INTEL_BW_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 7e20967307df..078dc6e1ee34 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -70,7 +70,6 @@ struct intel_cdclk_funcs {
>   void (*set_cdclk)(struct drm_i915_private *i915,
> const struct intel_cdclk_config *cdclk_config,
> 

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix header test for !CONFIG_X86

[Siva Mullati]

Reviewed-by: Siva Mullati 

On 31/01/22 10:29 pm, Lucas De Marchi wrote:
> Architectures others than x86 have a stub implementation calling
> WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
> the header-test target will fail with:
>
>   HDRTEST drivers/gpu/drm/i915/i915_mm.h
> In file included from :
> ./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
> ./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of 
> function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
>26 |  WARN_ON_ONCE(1);
>   |  ^~~~
>
> v2: Do not include  since call to pr_err() has been
> removed
>
> Fixes: 67c430bbaae1 ("drm/i915: Skip remap_io_mapping() for non-x86 
> platforms")
> Cc: Siva Mullati 
> Signed-off-by: Lucas De Marchi 
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
>  drivers/gpu/drm/i915/i915_mm.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 76f1d53bdf34..3ad22bbe80eb 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -6,6 +6,7 @@
>  #ifndef __I915_MM_H__
>  #define __I915_MM_H__
>  
> +#include 
>  #include 
>  
>  struct vm_area_struct;