[Intel-gfx] [v3] drm/edid: check basic audio support on CEA extension block

[Lee Shawn C]

From: Cooper Chiou 

Tag code stored in bit7:5 for CTA block byte[3] is not the same as
CEA extension block definition. Only check CEA block has
basic audio support.

v3: update commit message.

Cc: sta...@vger.kernel.org
Cc: Jani Nikula 
Cc: Shawn C Lee 
Cc: intel-gfx 
Signed-off-by: Cooper Chiou 
Signed-off-by: Lee Shawn C 
Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 561f53831e29..f07af6786cec 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4859,7 +4859,8 @@ bool drm_detect_monitor_audio(struct edid *edid)
if (!edid_ext)
goto end;
 
-   has_audio = ((edid_ext[3] & EDID_BASIC_AUDIO) != 0);
+   has_audio = (edid_ext[0] == CEA_EXT &&
+   (edid_ext[3] & EDID_BASIC_AUDIO) != 0);
 
if (has_audio) {
DRM_DEBUG_KMS("Monitor has basic audio support\n");
-- 
2.17.1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Correctly free guc capture struct on error

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Correctly free guc capture struct on error
URL   : https://patchwork.freedesktop.org/series/101716/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22666_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#5327])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb6/igt@gem_...@block-copy-compressed.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb8/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@vecs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][4] ([i915#4547])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-skl7/igt@gem_exec_capture@p...@vecs0.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +126 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-skl8/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-glk1/igt@gem_exec_fair@basic-p...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-glk3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2849])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][13] ([i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-tglb3/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-skl1/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-skl8/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#4270])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-tglb7/igt@gem_...@fail-invalid-protected-context.html

  * igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4270]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb3/igt@gem_...@verify-pxp-stale-buf-optout-execution.html

  * igt@gem_render_copy@y-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#768])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb3/igt@gem_render_c...@y-tiled-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109290])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb4/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-iclb: NOTRUN -> [DMESG-WARN][20] ([i915#4991])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-iclb3/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][21] ([i915#2724])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/shard-snb4/igt@gem_userptr_bl...@vma-merge.html

  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Correctly free guc capture struct on error

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Correctly free guc capture struct on error
URL   : https://patchwork.freedesktop.org/series/101716/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22666


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 41)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(10): fi-kbl-soraka shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@coherency:
- {bat-rpls-2}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/bat-rpls-2/igt@i915_selftest@l...@coherency.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271]) +54 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#5341])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][10] ([i915#4391]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

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

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][14] ([i915#5338]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [DMESG-WARN][16] ([i915#295] / [i915#5341]) -> 
[PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22666/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

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

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/guc: Correctly free guc capture struct on error

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Correctly free guc capture struct on error
URL   : https://patchwork.freedesktop.org/series/101716/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] [PATCH] drm/i915/guc: Correctly free guc capture struct on error

[Daniele Ceraolo Spurio]

On error the "new" allocation is not freed, so add the required kfree.

Fixes: 247f8071d5893 ("drm/i915/guc: Pre-allocate output nodes for extraction")
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index afdcbe63e9eb1..c4e25966d3e9f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1040,6 +1040,7 @@ guc_capture_alloc_one_node(struct intel_guc *guc)
if (!new->reginfo[i].regs) {
while (i)
kfree(new->reginfo[--i].regs);
+   kfree(new);
return NULL;
}
}
-- 
2.25.1

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

[Chery, Nanley G]

Hi all,

Found an error in this description..

> From: Stanislav Lisovskiy 
> stanislav.lisovs...@intel.com
>
> 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.
>

256B should be 512B (same feedback for the modifier description).

Regards,
Nanley

> Reviewed-by: Imre Deak imre.d...@intel.com
> Acked-by: Nanley Chery 
> nanley.g.ch...@intel.com
> Signed-off-by: Stanislav Lisovskiy 
> stanislav.lisovs...@intel.com
> ---
>  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
>   *
>

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

[Chery, Nanley G]

> -Original Message-
> From: Deak, Imre 
> Sent: Monday, March 21, 2022 6:20 AM
> To: Chery, Nanley G ; Juha-Pekka Heikkila 
> 
> Cc: Nanley Chery ; C, Ramalingam 
> ; intel-gfx ;
> Auld, Matthew ; dri-devel 
> 
> Subject: Re: [Intel-gfx] [PATCH v5 16/19] uapi/drm/dg2: Introduce format 
> modifier for DG2 clear color
> 
> Hi Nanley, JP,
> 
> On Tue, Feb 15, 2022 at 09:34:22PM +0200, Juha-Pekka Heikkila wrote:
> > [...]
> > > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > What's unified about DG2's compression format? If this doesn't
> > > > > > > > > affect the layout, maybe we should drop this sentence.
> 
> Unified here probably refers to the fact the DG2 render engine is
> capable of generating both a render and a media compressed surface as
> opposed to earlier platforms. The display engine still needs to know
> which compression format the FB uses, hence we need both an RC and MC
> modifier. Based on this I also think we can drop the mention of unified
> compression.
> 
> > > > > > > > > > + * The general layout is a tiled layout using 4Kb tiles 
> > > > > > > > > > i.e. Tile4 layout.
> > > > > > > > > > + *
> > > > > > > > >
> > > > > > > > > This also needs a pitch aligned to four tiles, right? I think 
> > > > > > > > > we
> > > > > > > > > can save some effort by referencing the DG2_RC_CCS modifier 
> > > > > > > > > here.
> > > > > > > > >
> > > > > > > > > > + * Fast clear color value expected by HW is located in fb 
> > > > > > > > > > at offset 0 of plane#1
> > > > > > > > >
> > > > > > > > > Why is the expected offset hardcoded to 0 instead of relying 
> > > > > > > > > on
> > > > > > > > > the offset provided by the modifier API? This looks like a 
> > > > > > > > > bug.
> > > > > > > >
> > > > > > > > Hi Nanley,
> > > > > > > >
> > > > > > > > can you elaborate a bit, which offset from modifier API that
> > > > > > > > applies to cc surface?
> > > > > > >
> > > > > > > Hi Juha-Pekka,
> > > > > > >
> > > > > > > On the kernel-side of things, I'm thinking of 
> > > > > > > drm_mode_fb_cmd2::offsets[1].
> > > > > >
> > > > > > Hi Nanley,
> > > > > >
> > > > > > this offset is coming from userspace on creation of framebuffer, at
> > > > > > that moment from userspace caller can point to offset of desire.
> > > > > > Normally offset[0] is set at 0 and then offset[n] at plane n start
> > > > > > which is not stated to have to be exactly after plane n-1 end. Or 
> > > > > > did I
> > > > > > misunderstand what you meant?
> > > > >
> > > > > Perhaps, at least, I'm not sure what you're meaning to say. This
> > > > > modifier description seems to say that the drm_mode_fb_cmd2::offsets
> > > > > value for the clear color plane must be zero. Are you saying that it's
> > > > > correct? This doesn't match the GEN12_RC_CCS_CC behavior and doesn't
> > > > > match mesa's expectations.
> > > >
> > > > It doesn't say "drm_mode_fb_cmd2::offsets value for the clear color 
> > > > plane must
> > > > be zero", it says "Fast clear color value expected by HW is located in 
> > > > fb at offset 0
> > > > of plane#1".
> > >
> > > Yes, it doesn't say that exactly, but that's what it seems to say. With 
> > > every other
> > > modifier, it's implied that the data for the plane begins at the offset 
> > > specified
> > > through the modifier API. So, explicitly mentioning it here (and with 
> > > that wording)
> > > conveys a new requirement.
> >
> > I don't have objections on changing this description but for reference gen12
> > version of the same says "The main surface is Y-tiled and is at plane index
> > 0 whereas CCS is linear and at index 1. The clear color is stored at index
> > 2, and the pitch should be ignored.", only plane indexes are mentioned. I
> > anyway wrote neither of these descriptions.
> >
> > > > Plane#1 location is pointed by drm_mode_fb_cmd2::offsets[1] and there's
> > > > nothing stated about that offset.
> > >
> > > Technically, plane #1's location is specified to be the combination of 
> > > ::handles[1]
> > > and ::offsets[1]. In practice though, I can imagine that there are areas 
> > > of the stack
> > > that are implicitly requiring that all ::handles[] entries match.
> 
> The FB modifier API requires all ::handles[] 

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

[Chery, Nanley G]

> -Original Message-
> From: Deak, Imre 
> Sent: Friday, March 18, 2022 10:40 AM
> To: Chery, Nanley G 
> Cc: juhapekka.heikk...@gmail.com; Nanley Chery ; C, 
> Ramalingam ; intel-gfx  g...@lists.freedesktop.org>; Auld, Matthew ; 
> dri-devel 
> Subject: Re: [Intel-gfx] [PATCH v5 15/19] drm/i915/dg2: Add DG2 unified 
> compression
> 
> On Thu, Feb 17, 2022 at 05:15:15PM +, Chery, Nanley G wrote:
> > > >> [...]
> > > >> --- a/include/uapi/drm/drm_fourcc.h
> > > >> +++ b/include/uapi/drm/drm_fourcc.h
> > > >> @@ -583,6 +583,28 @@ extern "C" {
> > > >>*/
> > > >>   #define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
> > > >>
> > > >> +/*
> > > >> + * Intel color control surfaces (CCS) for DG2 render compression.
> > > >> + *
> > > >> + * DG2 uses a new compression format for render compression. The 
> > > >> general
> > > >> + * layout is the same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
> > > >> + * but a new hashing/compression algorithm is used, so a fresh 
> > > >> modifier must
> > > >> + * be associated with buffers of this type. Render compression uses 
> > > >> 128 byte
> > > >> + * compression blocks.
> > > >
> > > > I think I've seen a way to configure the compression block size on TGL
> > > > at least. I can't find the spec text for that at the moment though...
> > > > Could we omit these mentions?
> > >
> > > Not sure why general possibility of changing compression block size is 
> > > relevant?
> > > All hw features can be changed but this defines how this modifier is being
> > > implemented.
> >
> > I was concerned about compatibility between the different modes, but I've
> > looked into the restrictions here and don't see any problems with this.
> >
> > > Say you take I915_FORMAT_MOD_4_TILED_DG2_RC_CCS framebuffer including
> > > control surface and copy it out, then come back and restore framebuffer 
> > > with
> > > same information. It is expected to be valid?
> >
> > > /Juha-Pekka
> > >
> > > >> + */
> > > >> +#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS fourcc_mod_code(INTEL, 10)
> > > >> +
> > > >
> > > > How about something like:
> > > >
> > > > The main surface is Tile 4 and at plane index 0. The CCS plane is
> > > > hidden from userspace. The main surface pitch is required to be a
> > > > multiple of four Tile 4 widths. The CCS is configured with the render
> > > > compression format associated with the main surface format.
> >
> > Actually, let's omit the last sentence. CCS has always been affected
> > by the main surface format, so I don't think there's a need to mention it
> > specifically for the DG2 modifier.
> >
> > We do need to mention the 4-tile-wide pitch requirement though.
> 
> Agreed, the DG2 layout of planes and the tile format used - both
> different wrt. the GEN12_RC_CCS format - should be described here.
> 
> > -Nanley
> >
> > > > I think the CCS is technically accessible via the blitter engine,
> > > > so the part about the plane being "hidden" may need some tweaking.
> 
> Maybe outside of the GEM object? Capturing all the above would you be ok
> with the following?:
> 
> Intel color control surfaces (CCS) for DG2 render compression.
> 
> The main surface is Tile 4 and at plane index 0. The CCS data is stored
> outside of the GEM object in a reserved memory area dedicated for the
> storage of the CCS data from all GEM objects. The main surface pitch is
> required to be a multiple of four Tile 4 widths.
> 
> 
> Intel color control surfaces (CCS) for DG2 media compression.
> 
> The main surface is Tile 4 and at plane index 0. For semi-planar formats
> like NV12, the UV plane is Tile 4 at plane index 1. The CCS data both for
> the main and semi-planar UV planes are stored outside of the GEM object

This kind of implies that the Y plane is the main surface, but it's not more
"main" than the UV plane right? Seems like we should specifically call out the
Y plane for clarity. Maybe something like:

For semi-planar formats like NV12, the Y and UV planes are Tile 4 and are 
located at plane indices 0 and 1, respectively. The CCS for all planes are 
stored 
outside of the GEM object

> in a reserved memory area dedicated for the storage of the CCS data from
> all GEM objects. The main surface pitch is required to be a multiple of
> four Tile 4 widths.
> 

Looks good to me. Main suggestion I have here is to substitute 
"from all GEM objects" with "for all compressible GEM objects".
Happy to look at further revisions, but with that change at least,
Acked-by: Nanley Chery 

> > > > -Nanley
> > > >
> > > >> +/*
> > > >> + * Intel color control surfaces (CCS) for DG2 media compression.
> > > >> + *
> > > >> + * DG2 uses a new compression format for media compression. The
> > > >> +general
> > > >> + * layout is the same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
> > > >> + * but a new hashing/compression algorithm is used, so a fresh
> > > >> +modifier must
> > > >> + * be associated with buffers of this type. Media compression uses
> > > >> +256 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/dg2: Load DMC

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/dg2: Load DMC
URL   : https://patchwork.freedesktop.org/series/101710/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22663_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@smoketest:
- shard-tglb: [PASS][1] -> [FAIL][2] ([i915#5099])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb1/igt@gem_ctx_persiste...@smoketest.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-tglb8/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#3063])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb2/igt@gem_...@in-flight-contexts-immediate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-tglb2/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-iclb8/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][7] ([i915#4525])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-iclb8/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-kbl4/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +65 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-skl2/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-apl3/igt@gem_exec_suspend@basic...@smem.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-apl8/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][19] ([i915#4613])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-tglb8/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-skl10/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-apl3/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][22] ([i915#4270])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/shard-tglb6/igt@gem_...@fail-invalid-protected-context.html

  * igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-iclb: NOTRUN -> [SKIP][23] ([i915#4270]) +2 similar issues
   [23]: 

Re: [Intel-gfx] [PATCH] drm/i915/adlp: Fix register corruption after DDI clock enabling

[Runyan, Arthur J]

> -Original Message-
> From: Deak, Imre 
> Sent: Wednesday, March 23, 2022 1:18 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hogander, Jouni ; Runyan, Arthur J
> 
> Subject: [PATCH] drm/i915/adlp: Fix register corruption after DDI clock
> enabling
> 
> Accessing the DDI_BUF_CTL register without the port's DDI clock being
> enabled (to set/clear the TypeC PHY ownership for the port) can lead to a
> corrupted value read during any i915 register access right after the DDI clock
> is enabled.
> 
> The root cause is the way clock synchronization works for this register,
> controlled by the CHICKEN_DCPR_1 DDI_CLOCK_REG_ACCESS flag. Correctly
> this flag should be cleared on ADLP (see the Bspec link below), however after
> bootup the flag is set.
> 
> One easily reproducible issue is an unclaimed register access of the
> PWR_WELL_CTL_DDI2 register, programmed right after DDI clock enabling to
> enable the port's DDI_IO power well (see the HSDES, VLK links below).
> With the correct setting above this problem can't be reproduced.
> 
> Bspec: 49189
> HSDES: 18019028154
> VLK: 28328, 28655
> 
> Cc: Jouni Högander 
> Cc: Arthur J Runyan 
> Signed-off-by: Imre Deak 
Acked-by: Arthur J Runyan 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  drivers/gpu/drm/i915/intel_pm.c | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index a0d652f19ff93..d83bd7a75c788
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5939,6 +5939,7 @@
>  #define   ICL_DELAY_PMRSPREG_BIT(22)
>  #define   DISABLE_FLR_SRCREG_BIT(15)
>  #define   MASK_WAKEMEM   REG_BIT(13)
> +#define   DDI_CLOCK_REG_ACCESS   REG_BIT(7)
> 
>  #define GEN11_CHICKEN_DCPR_2 _MMIO(0x46434)
>  #define   DCPR_MASK_MAXLATENCY_MEMUP_CLR REG_BIT(27)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c index 2c3cd4d775daf..4291963013c51
> 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7470,6 +7470,9 @@ static void adlp_init_clock_gating(struct
> drm_i915_private *dev_priv)
> 
>   /* Wa_22011091694:adlp */
>   intel_de_rmw(dev_priv, GEN9_CLKGATE_DIS_5, 0,
> DPCE_GATING_DIS);
> +
> + /* Bspec/49189 Initialize Sequence */
> + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> DDI_CLOCK_REG_ACCESS, 0);
>  }
> 
>  static void dg1_init_clock_gating(struct drm_i915_private *dev_priv)
> --
> 2.30.2

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/adlp: Fix register corruption after DDI clock enabling

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Fix register corruption after DDI clock enabling
URL   : https://patchwork.freedesktop.org/series/101712/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22665


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22665 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22665, 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_22665/index.html

Participating hosts (46 -> 42)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(9): fi-kbl-soraka shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan 
fi-ctg-p8600 shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][7] ([fdo#109271]) +54 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#5341])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

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

  
 Possible fixes 

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

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [DMESG-WARN][16] ([i915#295] / [i915#5341]) -> 
[PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22665/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Extend DP HDR support to hsw+

[Patchwork]

== Series Details ==

Series: drm/i915/display: Extend DP HDR support to hsw+
URL   : https://patchwork.freedesktop.org/series/101708/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22662_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@vecs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][3] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-skl8/igt@gem_exec_capture@p...@vecs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][4] -> [FAIL][5] ([i915#2846])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-kbl4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-kbl4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2849])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][14] ([i915#4613])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-tglb2/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-skl4/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-apl6/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#4270])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-tglb6/igt@gem_...@fail-invalid-protected-context.html

  * igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb7/igt@gem_...@verify-pxp-stale-buf-optout-execution.html

  * igt@gem_render_copy@y-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#768])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb7/igt@gem_render_c...@y-tiled-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#109290])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb5/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-iclb: NOTRUN -> [DMESG-WARN][21] ([i915#4991])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-iclb7/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][22] ([i915#2724])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/shard-snb5/igt@gem_userptr_bl...@vma-merge.html

  * 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/adlp: Fix register corruption after DDI clock enabling

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Fix register corruption after DDI clock enabling
URL   : https://patchwork.freedesktop.org/series/101712/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/adlp: Fix register corruption after DDI clock enabling

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Fix register corruption after DDI clock enabling
URL   : https://patchwork.freedesktop.org/series/101712/
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.BAT: failure for drm/i915/rps: Centralize computation of freq caps (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/rps: Centralize computation of freq caps (rev4)
URL   : https://patchwork.freedesktop.org/series/101606/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22664


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22664 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22664, 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_22664/index.html

Participating hosts (46 -> 41)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(10): fi-kbl-soraka shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][7] ([fdo#109271]) +54 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#5341])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][11] ([i915#4391]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

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

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][15] ([i915#5338]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22664/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][17] ([i915#3576]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [18]: 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dg2: DC states for DG2

[Tolakanahalli Pradeep, Madhumitha]

On Wed, 2022-03-23 at 12:01 -0700, Anusha Srivatsa wrote:
> DG2 has same DC states as DG1 - upto DC5.
> 
> Bspec: 49193
> 
> Cc: Madhumitha Tolakanahalli Pradeep
> 
> Signed-off-by: Anusha Srivatsa 

Reviewed-by: Madhumitha Tolakanahalli Pradeep
 

> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 3dc859032bac..349cc4bcea8a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4782,7 +4782,7 @@ static u32 get_allowed_dc_mask(const struct
> drm_i915_private *dev_priv,
> if (!HAS_DISPLAY(dev_priv))
> return 0;
>  
> -   if (IS_DG1(dev_priv))
> +   if (IS_DG1(dev_priv) || IS_DG2(dev_priv))
> max_dc = 3;
> else if (DISPLAY_VER(dev_priv) >= 12)
> max_dc = 4;

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/rps: Centralize computation of freq caps (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/rps: Centralize computation of freq caps (rev4)
URL   : https://patchwork.freedesktop.org/series/101606/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/rps: Centralize computation of freq caps (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/rps: Centralize computation of freq caps (rev4)
URL   : https://patchwork.freedesktop.org/series/101606/
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.BAT: success for series starting with [1/2] drm/i915/dg2: Load DMC

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/dg2: Load DMC
URL   : https://patchwork.freedesktop.org/series/101710/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22663


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 42)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(9): fi-kbl-soraka shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan 
fi-ctg-p8600 shard-rkl shard-dg1 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][5] ([fdo#109271]) +54 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [PASS][6] -> [INCOMPLETE][7] ([i915#4418])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050:   [PASS][8] -> [DMESG-FAIL][9] ([i915#2927] / 
[i915#3428])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#5341])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- bat-dg1-6:  NOTRUN -> [FAIL][13] ([i915#4312] / [i915#5257])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/bat-dg1-6/igt@run...@aborted.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#1436] / 
[i915#3428] / [i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][15] ([i915#5127]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][17] ([i915#4391]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22663/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

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

Re: [Intel-gfx] [PATCH 00/22] drm: Review of mode copies

[Abhinav Kumar]

On 3/23/2022 3:39 AM, Dmitry Baryshkov wrote:

On 22/03/2022 01:37, Ville Syrjälä wrote:

On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:

On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
 wrote:


On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:

   drm: Add drm_mode_init()
   drm/bridge: Use drm_mode_copy()
   drm/imx: Use drm_mode_duplicate()
   drm/panel: Use drm_mode_duplicate()
   drm/vc4: Use drm_mode_copy()

These have been pushed to drm-misc-next.


   drm/amdgpu: Remove pointless on stack mode copies
   drm/amdgpu: Use drm_mode_init() for on-stack modes
   drm/amdgpu: Use drm_mode_copy()

amdgpu ones are reviewed, but I'll leave them for the
AMD folks to push to whichever tree they prefer.


I pulled patches 2, 4, 5 into my tree.


Thanks.


For 3, I'm happy to have it
land via drm-misc with the rest of the mode_init changes if you'd
prefer.


Either way works for me. I don't yet have reviews yet for
the other drivers, so I'll proably hold off for a bit more
at least. And the i915 patch I'll be merging via drm-intel.


   drm/radeon: Use drm_mode_copy()
   drm/gma500: Use drm_mode_copy()
   drm/tilcdc: Use drm_mode_copy()
   drm/i915: Use drm_mode_copy()


Those are now all in.

Which leaves us with these stragglers:

   drm/hisilicon: Use drm_mode_init() for on-stack modes



   drm/msm: Nuke weird on stack mode copy
   drm/msm: Use drm_mode_init() for on-stack modes
   drm/msm: Use drm_mode_copy()


These three patches went beneath my radar for some reason.

I have just sent a replacement for the first patch ([1]). Other two 
patches can be pulled in msm/msm-next (or msm/msm-fixes) during the next 
development cycle if that works for you.


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


Agree with this approach.

We can replace the first patch with 
https://patchwork.freedesktop.org/series/101682/.


Thanks

Abhinav




   drm/mtk: Use drm_mode_init() for on-stack modes
   drm/rockchip: Use drm_mode_copy()
   drm/sti: Use drm_mode_copy()
   drm: Use drm_mode_init() for on-stack modes
   drm: Use drm_mode_copy()

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: More fixed_mode refactoring

[Patchwork]

== Series Details ==

Series: drm/i915: More fixed_mode refactoring
URL   : https://patchwork.freedesktop.org/series/101707/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22661_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#5327])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb7/igt@gem_...@block-copy-compressed.html

  * igt@gem_eio@in-flight-1us:
- shard-tglb: [PASS][2] -> [TIMEOUT][3] ([i915#3063])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb8/igt@gem_...@in-flight-1us.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-tglb8/igt@gem_...@in-flight-1us.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][6] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb5/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_capture@pi@vcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][7] ([i915#4547])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-skl6/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb7/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([i915#1895] / 
[i915#5304])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb5/igt@gem_exec_whis...@basic-queues-forked-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb7/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-tglb3/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-skl3/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][13] ([i915#2658])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-skl6/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@create-regular-context-2:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#4270])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb5/igt@gem_...@create-regular-context-2.html

  * igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][15] ([i915#4270])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-tglb2/igt@gem_...@fail-invalid-protected-context.html

  * igt@gem_userptr_blits@input-checking:
- shard-iclb: NOTRUN -> [DMESG-WARN][16] ([i915#4991])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb5/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][17] ([i915#2724])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-snb7/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen7_exec_parse@basic-offset:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109289])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb7/igt@gen7_exec_pa...@basic-offset.html

  * igt@gen9_exec_parse@bb-start-out:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#2856])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb7/igt@gen9_exec_pa...@bb-start-out.html

  * igt@i915_pm_rpm@pc8-residency:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#109293] / [fdo#109506])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/shard-iclb5/igt@i915_pm_...@pc8-residency.html

  * igt@kms_atomic@plane-primary-overlay-mutable-zpos:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#404])
   [21]: 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/2] drm/i915/dg2: Load DMC

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/dg2: Load DMC
URL   : https://patchwork.freedesktop.org/series/101710/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Extend DP HDR support to hsw+

[Patchwork]

== Series Details ==

Series: drm/i915/display: Extend DP HDR support to hsw+
URL   : https://patchwork.freedesktop.org/series/101708/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22662


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 42)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(9): fi-kbl-soraka shard-tglu fi-hsw-4200u fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 shard-rkl shard-dg1 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][5] ([fdo#109271]) +54 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][6] -> [INCOMPLETE][7] ([i915#2373] / 
[i915#4983])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#5341])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][11] ([i915#5127]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][13] ([i915#4391]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

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

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- {bat-adlm-1}:   [INCOMPLETE][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22662/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [DMESG-WARN][19] ([i915#295] / [i915#5341]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [20]: 

[Intel-gfx] [PATCH] drm/i915/adlp: Fix register corruption after DDI clock enabling

[Imre Deak]

Accessing the DDI_BUF_CTL register without the port's DDI clock being
enabled (to set/clear the TypeC PHY ownership for the port) can lead to
a corrupted value read during any i915 register access right after the
DDI clock is enabled.

The root cause is the way clock synchronization works for this register,
controlled by the CHICKEN_DCPR_1 DDI_CLOCK_REG_ACCESS flag. Correctly
this flag should be cleared on ADLP (see the Bspec link below), however
after bootup the flag is set.

One easily reproducible issue is an unclaimed register access of the
PWR_WELL_CTL_DDI2 register, programmed right after DDI clock enabling to
enable the port's DDI_IO power well (see the HSDES, VLK links below).
With the correct setting above this problem can't be reproduced.

Bspec: 49189
HSDES: 18019028154
VLK: 28328, 28655

Cc: Jouni Högander 
Cc: Arthur J Runyan 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a0d652f19ff93..d83bd7a75c788 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5939,6 +5939,7 @@
 #define   ICL_DELAY_PMRSP  REG_BIT(22)
 #define   DISABLE_FLR_SRC  REG_BIT(15)
 #define   MASK_WAKEMEM REG_BIT(13)
+#define   DDI_CLOCK_REG_ACCESS REG_BIT(7)
 
 #define GEN11_CHICKEN_DCPR_2   _MMIO(0x46434)
 #define   DCPR_MASK_MAXLATENCY_MEMUP_CLR   REG_BIT(27)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2c3cd4d775daf..4291963013c51 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7470,6 +7470,9 @@ static void adlp_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
/* Wa_22011091694:adlp */
intel_de_rmw(dev_priv, GEN9_CLKGATE_DIS_5, 0, DPCE_GATING_DIS);
+
+   /* Bspec/49189 Initialize Sequence */
+   intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, DDI_CLOCK_REG_ACCESS, 0);
 }
 
 static void dg1_init_clock_gating(struct drm_i915_private *dev_priv)
-- 
2.30.2

Re: [Intel-gfx] [PATCH 12/22] drm/msm: Use drm_mode_copy()

[Abhinav Kumar]

On 2/18/2022 2:03 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.

Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.

Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.

@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}

@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, )
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)

@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(, )
|
- memcpy(, E, S)
+ drm_mode_copy(, E)
)

@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode

Cc: Rob Clark 
Cc: Sean Paul 
Cc: Abhinav Kumar 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 

Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
  drivers/gpu/drm/msm/dp/dp_display.c  | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 34a6940d12c5..57592052af23 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -157,7 +157,7 @@ static void dpu_encoder_phys_cmd_mode_set(
DPU_ERROR("invalid args\n");
return;
}
-   phys_enc->cached_mode = *adj_mode;
+   drm_mode_copy(_enc->cached_mode, adj_mode);
DPU_DEBUG_CMDENC(cmd_enc, "caching mode:\n");
drm_mode_debug_printmodeline(adj_mode);
  
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c

index e7813c6f7bd9..d5deca07b65a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -370,7 +370,7 @@ static void dpu_encoder_phys_vid_mode_set(
struct dpu_encoder_irq *irq;
  
  	if (adj_mode) {

-   phys_enc->cached_mode = *adj_mode;
+   drm_mode_copy(_enc->cached_mode, adj_mode);
drm_mode_debug_printmodeline(adj_mode);
DPU_DEBUG_VIDENC(phys_enc, "caching mode:\n");
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 7cc4d21f2091..2ed6028ca8d6 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -825,7 +825,7 @@ static int dp_display_set_mode(struct msm_dp *dp_display,
  
  	dp = container_of(dp_display, struct dp_display_private, dp_display);
  
-	dp->panel->dp_mode.drm_mode = mode->drm_mode;

+   drm_mode_copy(>panel->dp_mode.drm_mode, >drm_mode);
dp->panel->dp_mode.bpp = mode->bpp;
dp->panel->dp_mode.capabilities = mode->capabilities;
dp_panel_init_panel_info(dp->panel);

Re: [Intel-gfx] [PATCH 11/22] drm/msm: Use drm_mode_init() for on-stack modes

[Abhinav Kumar]

On 2/18/2022 2:03 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(, );
+
S1

@@
expression decl.E;
@@
- &*E
+ E

Cc: Rob Clark 
Cc: Sean Paul 
Cc: Abhinav Kumar 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 

Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index ddd9d89cd456..e7813c6f7bd9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -248,12 +248,13 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
unsigned long lock_flags;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
  
+	drm_mode_init(, _enc->cached_mode);

+
if (!phys_enc->hw_ctl->ops.setup_intf_cfg) {
DPU_ERROR("invalid encoder %d\n", phys_enc != NULL);
return;
}
  
-	mode = phys_enc->cached_mode;

if (!phys_enc->hw_intf->ops.setup_timing_gen) {
DPU_ERROR("timing engine setup is not supported\n");
return;
@@ -652,7 +653,9 @@ static int dpu_encoder_phys_vid_get_frame_count(
  {
struct intf_status s = {0};
u32 fetch_start = 0;
-   struct drm_display_mode mode = phys_enc->cached_mode;
+   struct drm_display_mode mode;
+
+   drm_mode_init(, _enc->cached_mode);
  
  	if (!dpu_encoder_phys_vid_is_master(phys_enc))

return -EINVAL;

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/display: Extend DP HDR support to hsw+

[Patchwork]

== Series Details ==

Series: drm/i915/display: Extend DP HDR support to hsw+
URL   : https://patchwork.freedesktop.org/series/101708/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

Re: [Intel-gfx] [PATCH] drm/i915/rps: Centralize computation of freq caps

[Dixit, Ashutosh]

On Wed, 23 Mar 2022 00:03:23 -0700, Nilawar, Badal wrote:
>
> > +/* "Caps" frequencies should be converted to MHz using intel_gpu_freq() */
> > +void intel_rps_get_freq_caps(struct intel_rps *rps, struct 
> > intel_rps_freq_caps *capSis)
>
> Since this function is covering gen6 and above it would be good to rename
> it as gen6_rps_get_freq_caps.

I've made this change in v4. Thanks.

[Intel-gfx] [PATCH] drm/i915/rps: Centralize computation of freq caps

[Ashutosh Dixit]

Freq caps (i.e. RP0, RP1 and RPn frequencies) are read from HW. However the
formats (bit positions, widths, registers and units) of these vary for
different generations with even more variations arriving in the future. In
order not to have to do identical computation for these caps in multiple
places, here we centralize the computation of these caps. This makes the
code cleaner and also more extensible for the future.

v2: Clarify that caps are in "hw units" in comments (Lucas De Marchi)
v3: Minor checkpatch fix
v4: s/intel_rps_get_freq_caps/gen6_rps_get_freq_caps/ (Badal Nilawar)

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  24 +
 drivers/gpu/drm/i915/gt/intel_rps.c   | 101 ++
 drivers/gpu/drm/i915/gt/intel_rps.h   |   2 +-
 drivers/gpu/drm/i915/gt/intel_rps_types.h |  10 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  14 +--
 5 files changed, 79 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 31dbb2b96738..280a27cb9bdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -342,17 +342,16 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt, 
struct drm_printer *p)
} else if (GRAPHICS_VER(i915) >= 6) {
u32 rp_state_limits;
u32 gt_perf_status;
-   u32 rp_state_cap;
+   struct intel_rps_freq_caps caps;
u32 rpmodectl, rpinclimit, rpdeclimit;
u32 rpstat, cagf, reqf;
u32 rpcurupei, rpcurup, rpprevup;
u32 rpcurdownei, rpcurdown, rpprevdown;
u32 rpupei, rpupt, rpdownei, rpdownt;
u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
-   int max_freq;
 
rp_state_limits = intel_uncore_read(uncore, 
GEN6_RP_STATE_LIMITS);
-   rp_state_cap = intel_rps_read_state_cap(rps);
+   gen6_rps_get_freq_caps(rps, );
if (IS_GEN9_LP(i915))
gt_perf_status = intel_uncore_read(uncore, 
BXT_GT_PERF_STATUS);
else
@@ -474,25 +473,12 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt, 
struct drm_printer *p)
drm_printf(p, "RP DOWN THRESHOLD: %d (%lldns)\n",
   rpdownt, intel_gt_pm_interval_to_ns(gt, rpdownt));
 
-   max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 0 :
-   rp_state_cap >> 16) & 0xff;
-   max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
drm_printf(p, "Lowest (RPN) frequency: %dMHz\n",
-  intel_gpu_freq(rps, max_freq));
-
-   max_freq = (rp_state_cap & 0xff00) >> 8;
-   max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
+  intel_gpu_freq(rps, caps.min_freq));
drm_printf(p, "Nominal (RP1) frequency: %dMHz\n",
-  intel_gpu_freq(rps, max_freq));
-
-   max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 16 :
-   rp_state_cap >> 0) & 0xff;
-   max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
+  intel_gpu_freq(rps, caps.rp1_freq));
drm_printf(p, "Max non-overclocked (RP0) frequency: %dMHz\n",
-  intel_gpu_freq(rps, max_freq));
+  intel_gpu_freq(rps, caps.rp0_freq));
drm_printf(p, "Max overclocked frequency: %dMHz\n",
   intel_gpu_freq(rps, rps->max_freq));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 6c9fdf7906c5..f21f6e454998 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1070,23 +1070,59 @@ int intel_rps_set(struct intel_rps *rps, u8 val)
return 0;
 }
 
-static void gen6_rps_init(struct intel_rps *rps)
+static u32 intel_rps_read_state_cap(struct intel_rps *rps)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
-   u32 rp_state_cap = intel_rps_read_state_cap(rps);
+   struct intel_uncore *uncore = rps_to_uncore(rps);
 
-   /* All of these values are in units of 50MHz */
+   if (IS_XEHPSDV(i915))
+   return intel_uncore_read(uncore, XEHPSDV_RP_STATE_CAP);
+   else if (IS_GEN9_LP(i915))
+   return intel_uncore_read(uncore, BXT_RP_STATE_CAP);
+   else
+   return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
+}
+
+/* "Caps" frequencies should be converted to MHz using intel_gpu_freq() */
+void gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps 
*caps)
+{
+   struct 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dg2: Load DMC

[Tolakanahalli Pradeep, Madhumitha]

On Wed, 2022-03-23 at 12:01 -0700, Anusha Srivatsa wrote:
> Add Support to load dmc v2.06
> 
> Cc: Madhumitha Tolakanahalli Pradeep
> 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index a719c0f379ba..462111a15304 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -47,6 +47,10 @@
>  
>  #define DISPLAY_VER12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
>  
> +#define DG2_DMC_PATH   DMC_PATH(dg1, 2, 06)
  
   ^^ dg2

> +#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 6)
> +MODULE_FIRMWARE(DG2_DMC_PATH);
> +
>  #define ADLP_DMC_PATH  DMC_PATH(adlp, 2, 16)
>  #define ADLP_DMC_VERSION_REQUIRED  DMC_VERSION(2, 16)
>  MODULE_FIRMWARE(ADLP_DMC_PATH);
> @@ -681,7 +685,11 @@ void intel_dmc_ucode_init(struct drm_i915_private
> *dev_priv)
>  */
> intel_dmc_runtime_pm_get(dev_priv);
>  
> -   if (IS_ALDERLAKE_P(dev_priv)) {
> +   if (IS_DG2(dev_priv)) {
> +   dmc->fw_path = DG2_DMC_PATH;
> +   dmc->required_version = DG2_DMC_VERSION_REQUIRED;
> +   dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> +   } else if (IS_ALDERLAKE_P(dev_priv)) {
> dmc->fw_path = ADLP_DMC_PATH;
> dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
> dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;

Teeny error in DMC_PATH, the rest of the patch looks good.

- Madhumitha

Re: [Intel-gfx] [PATCH] drm/i915/display: Extend DP HDR support to hsw+

[Ville Syrjälä]

On Wed, Mar 23, 2022 at 09:04:36PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 24, 2022 at 12:15:22AM +0530, Uma Shankar wrote:
> > HSW+ platforms are able to send out HDR Metadata SDP DIP
> > packet as GMP. Hence, extending the support for HDR on DP
> > encoders for the same.
> > 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5389
> > Cc: Ville Syrjälä 
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 9e19165fd175..e10d2c151abf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4939,7 +4939,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
> > struct drm_connector *connect
> > intel_attach_dp_colorspace_property(connector);
> > }
> >  
> > -   if (IS_GEMINILAKE(dev_priv) || DISPLAY_VER(dev_priv) >= 11)
> > +   if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8)
> 
> CHV does not have this at all, and HSW/BDW don't have it on transcoder EDP.

Actually vlv/chv might have it since the vlv video DIP was supposedly
ripped from ibx. So potentially we could just enable this for all ilk+.
But that would require actual testing, so hsw+ seems like good enough
for now.

> 
> Also if we're going to attach this unconditionally then we should stop
> attaching it again in the LSPCON init path. Or we should skip this one
> when LSPCON is present.
> 
> > drm_object_attach_property(>base,
> >
> > connector->dev->mode_config.hdr_output_metadata_property,
> >0);
> > -- 
> > 2.25.1
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: More fixed_mode refactoring

[Patchwork]

== Series Details ==

Series: drm/i915: More fixed_mode refactoring
URL   : https://patchwork.freedesktop.org/series/101707/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22661


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 40)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(10): fi-kbl-soraka shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan 
fi-ctg-p8600 fi-hsw-4770 fi-pnv-d510 shard-rkl fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][5] ([fdo#109271]) +54 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050:   [PASS][6] -> [DMESG-FAIL][7] ([i915#2927] / 
[i915#3428])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#5341])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-bsw-n3050:   NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#1436] / 
[i915#3428] / [i915#4312])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][12] ([i915#4391]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

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

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][16] ([i915#3576]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [DMESG-WARN][18] ([i915#295] / [i915#5341]) -> 
[PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22661/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][20] ([i915#295]) -> [PASS][21] +10 

Re: [Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: More fixed_mode refactoring

[Ville Syrjälä]

On Wed, Mar 23, 2022 at 06:57:29PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: More fixed_mode refactoring
> URL   : https://patchwork.freedesktop.org/series/101707/
> State : warning
> 
> == Summary ==
> 
> $ make htmldocs 2>&1 > /dev/null | grep i915
> ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' 
> not found
> ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
> not found
> 

Where the heck is that crap coming from? There are no
references to intel_drrs_{enable,disable} anywhere.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915/display: Extend DP HDR support to hsw+

[Ville Syrjälä]

On Thu, Mar 24, 2022 at 12:15:22AM +0530, Uma Shankar wrote:
> HSW+ platforms are able to send out HDR Metadata SDP DIP
> packet as GMP. Hence, extending the support for HDR on DP
> encoders for the same.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5389
> Cc: Ville Syrjälä 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 9e19165fd175..e10d2c151abf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4939,7 +4939,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
> struct drm_connector *connect
>   intel_attach_dp_colorspace_property(connector);
>   }
>  
> - if (IS_GEMINILAKE(dev_priv) || DISPLAY_VER(dev_priv) >= 11)
> + if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8)

CHV does not have this at all, and HSW/BDW don't have it on transcoder EDP.

Also if we're going to attach this unconditionally then we should stop
attaching it again in the LSPCON init path. Or we should skip this one
when LSPCON is present.

>   drm_object_attach_property(>base,
>  
> connector->dev->mode_config.hdr_output_metadata_property,
>  0);
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH 2/2] drm/i915/dg2: DC states for DG2

[Anusha Srivatsa]

DG2 has same DC states as DG1 - upto DC5.

Bspec: 49193

Cc: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 3dc859032bac..349cc4bcea8a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4782,7 +4782,7 @@ static u32 get_allowed_dc_mask(const struct 
drm_i915_private *dev_priv,
if (!HAS_DISPLAY(dev_priv))
return 0;
 
-   if (IS_DG1(dev_priv))
+   if (IS_DG1(dev_priv) || IS_DG2(dev_priv))
max_dc = 3;
else if (DISPLAY_VER(dev_priv) >= 12)
max_dc = 4;
-- 
2.25.1

[Intel-gfx] [PATCH 1/2] drm/i915/dg2: Load DMC

[Anusha Srivatsa]

Add Support to load dmc v2.06

Cc: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index a719c0f379ba..462111a15304 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -47,6 +47,10 @@
 
 #define DISPLAY_VER12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
 
+#define DG2_DMC_PATH   DMC_PATH(dg1, 2, 06)
+#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 6)
+MODULE_FIRMWARE(DG2_DMC_PATH);
+
 #define ADLP_DMC_PATH  DMC_PATH(adlp, 2, 16)
 #define ADLP_DMC_VERSION_REQUIRED  DMC_VERSION(2, 16)
 MODULE_FIRMWARE(ADLP_DMC_PATH);
@@ -681,7 +685,11 @@ void intel_dmc_ucode_init(struct drm_i915_private 
*dev_priv)
 */
intel_dmc_runtime_pm_get(dev_priv);
 
-   if (IS_ALDERLAKE_P(dev_priv)) {
+   if (IS_DG2(dev_priv)) {
+   dmc->fw_path = DG2_DMC_PATH;
+   dmc->required_version = DG2_DMC_VERSION_REQUIRED;
+   dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
+   } else if (IS_ALDERLAKE_P(dev_priv)) {
dmc->fw_path = ADLP_DMC_PATH;
dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: More fixed_mode refactoring

[Patchwork]

== Series Details ==

Series: drm/i915: More fixed_mode refactoring
URL   : https://patchwork.freedesktop.org/series/101707/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915/dg2: Add relocation exception" (rev2)

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/dg2: Add relocation exception" (rev2)
URL   : https://patchwork.freedesktop.org/series/101669/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22660


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22660 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22660, 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_22660/index.html

Participating hosts (45 -> 42)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(8): fi-kbl-soraka shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan 
fi-ctg-p8600 shard-rkl fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  
 Suppressed 

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

  * igt@gem_busy@busy@all:
- {bat-dg2-8}:NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/bat-dg2-8/igt@gem_busy@b...@all.html

  * igt@gem_exec_gttfill@basic:
- {bat-dg2-9}:NOTRUN -> [SKIP][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/bat-dg2-9/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-dg2-9}:NOTRUN -> [FAIL][5] +7 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271]) +54 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [PASS][11] -> [INCOMPLETE][12] ([i915#4418])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#5341])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22660/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

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

[Intel-gfx] [PATCH] drm/i915/display: Extend DP HDR support to hsw+

[Uma Shankar]

HSW+ platforms are able to send out HDR Metadata SDP DIP
packet as GMP. Hence, extending the support for HDR on DP
encoders for the same.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5389
Cc: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9e19165fd175..e10d2c151abf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4939,7 +4939,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
intel_attach_dp_colorspace_property(connector);
}
 
-   if (IS_GEMINILAKE(dev_priv) || DISPLAY_VER(dev_priv) >= 11)
+   if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8)
drm_object_attach_property(>base,
   
connector->dev->mode_config.hdr_output_metadata_property,
   0);
-- 
2.25.1

[Intel-gfx] [PATCH 9/9] drm/i915: Change SDVO fixed mode handling

[Ville Syrjala]

From: Ville Syrjälä 

SDVO is the only connector type currently returning the VBT
fixed mode directly from .get_modes(), everyone else just
adds it to the fixed_modes list and then returns that from
.get_modes(). Adjust SDVO to follow the common behaviour.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_sdvo.c | 29 ---
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index 62e2e8b4358c..c9c3f71818d9 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2291,27 +2291,12 @@ static int intel_sdvo_get_lvds_modes(struct 
drm_connector *connector)
 {
struct intel_sdvo *intel_sdvo = 
intel_attached_sdvo(to_intel_connector(connector));
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   struct drm_display_mode *newmode;
int num_modes = 0;
 
drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
 
-   /*
-* Fetch modes from VBT. For SDVO prefer the VBT mode since some
-* SDVO->LVDS transcoders can't cope with the EDID mode.
-*/
-   newmode = 
intel_panel_vbt_sdvo_fixed_mode(to_intel_connector(connector));
-   if (newmode) {
-   drm_mode_probed_add(connector, newmode);
-   num_modes++;
-   }
-
-   /*
-* Attempt to get the mode list from DDC.
-* Assume that the preferred modes are
-* arranged in priority order.
-*/
+   num_modes += intel_panel_get_modes(to_intel_connector(connector));
num_modes += intel_ddc_get_modes(connector, _sdvo->ddc);
 
return num_modes;
@@ -2915,9 +2900,15 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int 
device)
if (!intel_sdvo_create_enhance_property(intel_sdvo, 
intel_sdvo_connector))
goto err;
 
-   intel_sdvo_get_lvds_modes(connector);
-
-   fixed_mode = intel_panel_edid_fixed_mode(intel_connector);
+   /*
+* Fetch modes from VBT. For SDVO prefer the VBT mode since some
+* SDVO->LVDS transcoders can't cope with the EDID mode.
+*/
+   fixed_mode = intel_panel_vbt_sdvo_fixed_mode(intel_connector);
+   if (!fixed_mode) {
+   intel_ddc_get_modes(connector, _sdvo->ddc);
+   fixed_mode = intel_panel_edid_fixed_mode(intel_connector);
+   }
 
intel_panel_init(intel_connector, fixed_mode, NULL);
 
-- 
2.34.1

[Intel-gfx] [PATCH 5/9] drm/i915: Rename intel_panel_vbt_fixed_mode()

[Ville Syrjala]

From: Ville Syrjälä 

Rename intel_panel_vbt_fixed_mode() to
intel_panel_vbt_lfp_fixed_mode() to be more descriptive.
We'll have another VBT fixed mode function soon and we
don't want to confuse the two.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
 drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 drivers/gpu/drm/i915/display/intel_panel.h | 2 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index b4fda29b04b5..44f4c65522b9 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -2050,7 +2050,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
intel_connector_attach_encoder(intel_connector, encoder);
 
mutex_lock(>mode_config.mutex);
-   fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
+   fixed_mode = intel_panel_vbt_lfp_fixed_mode(intel_connector);
mutex_unlock(>mode_config.mutex);
 
if (!fixed_mode) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d62123b9d0d3..e882a04a4cb1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5055,7 +5055,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
/* fallback to VBT if available for eDP */
if (!fixed_mode)
-   fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
+   fixed_mode = intel_panel_vbt_lfp_fixed_mode(intel_connector);
mutex_unlock(>mode_config.mutex);
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c
index d068e0607153..c3f017c3740c 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -974,7 +974,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
goto out;
 
/* Failed to get EDID, what about VBT? */
-   fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
+   fixed_mode = intel_panel_vbt_lfp_fixed_mode(intel_connector);
if (fixed_mode)
goto out;
 
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 2ba51222d156..bd606d0b1c24 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -246,7 +246,7 @@ intel_panel_edid_fixed_mode(struct intel_connector 
*connector)
 }
 
 struct drm_display_mode *
-intel_panel_vbt_fixed_mode(struct intel_connector *connector)
+intel_panel_vbt_lfp_fixed_mode(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct drm_display_info *info = >base.display_info;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.h 
b/drivers/gpu/drm/i915/display/intel_panel.h
index 579200270825..9704ac81fe3e 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.h
+++ b/drivers/gpu/drm/i915/display/intel_panel.h
@@ -47,6 +47,6 @@ intel_panel_edid_downclock_mode(struct intel_connector 
*connector,
 struct drm_display_mode *
 intel_panel_edid_fixed_mode(struct intel_connector *connector);
 struct drm_display_mode *
-intel_panel_vbt_fixed_mode(struct intel_connector *connector);
+intel_panel_vbt_lfp_fixed_mode(struct intel_connector *connector);
 
 #endif /* __INTEL_PANEL_H__ */
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index da0af425ed94..dc43cb8ecb86 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1980,7 +1980,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
intel_connector_attach_encoder(intel_connector, intel_encoder);
 
mutex_lock(>mode_config.mutex);
-   fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
+   fixed_mode = intel_panel_vbt_lfp_fixed_mode(intel_connector);
mutex_unlock(>mode_config.mutex);
 
if (!fixed_mode) {
-- 
2.34.1

[Intel-gfx] [PATCH 1/9] drm/i915: Pass intel_connector to intel_panel_{init, fini}()

[Ville Syrjala]

From: Ville Syrjälä 

All the other intel_panel functions take struct intel_connector,
so might as well make init()/fini() take one as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c |  2 +-
 drivers/gpu/drm/i915/display/intel_connector.c |  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c|  2 +-
 drivers/gpu/drm/i915/display/intel_dvo.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_panel.h |  5 ++---
 drivers/gpu/drm/i915/display/intel_sdvo.c  |  2 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c |  2 +-
 9 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 00cae5d26637..c7a6c2cce297 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -2057,7 +2057,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
 
-   intel_panel_init(_connector->panel, fixed_mode, NULL);
+   intel_panel_init(intel_connector, fixed_mode, NULL);
intel_backlight_setup(intel_connector, INVALID_PIPE);
 
if (dev_priv->vbt.dsi.config->dual_link)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
b/drivers/gpu/drm/i915/display/intel_connector.c
index a5f5dd55b0cb..1dcc268927a2 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -102,7 +102,7 @@ void intel_connector_destroy(struct drm_connector 
*connector)
if (!IS_ERR_OR_NULL(intel_connector->edid))
kfree(intel_connector->edid);
 
-   intel_panel_fini(_connector->panel);
+   intel_panel_fini(intel_connector);
 
drm_connector_cleanup(connector);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9e19165fd175..3bf44f7909e5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5060,7 +5060,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
pipe_name(pipe));
}
 
-   intel_panel_init(_connector->panel, fixed_mode, downclock_mode);
+   intel_panel_init(intel_connector, fixed_mode, downclock_mode);
if (!(dev_priv->quirks & QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK))
intel_connector->panel.backlight.power = 
intel_pps_backlight_power;
intel_backlight_setup(intel_connector, pipe);
diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c 
b/drivers/gpu/drm/i915/display/intel_dvo.c
index d4670889d26c..d4dc16a9c0dd 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo.c
+++ b/drivers/gpu/drm/i915/display/intel_dvo.c
@@ -549,7 +549,7 @@ void intel_dvo_init(struct drm_i915_private *dev_priv)
 * headers, likely), so for now, just get the current
 * mode being output through DVO.
 */
-   intel_panel_init(_connector->panel,
+   intel_panel_init(intel_connector,
 
intel_dvo_get_current_mode(intel_encoder),
 NULL);
intel_dvo->panel_wants_dither = true;
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c
index 5449d69fbae5..cd685dbf324b 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -996,7 +996,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
 out:
mutex_unlock(>mode_config.mutex);
 
-   intel_panel_init(_connector->panel, fixed_mode, downclock_mode);
+   intel_panel_init(intel_connector, fixed_mode, downclock_mode);
intel_backlight_setup(intel_connector, INVALID_PIPE);
 
lvds_encoder->is_dual_link = compute_is_dual_link_lvds(lvds_encoder, 
fixed_mode);
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index f428d0457c17..8c9e26539cc5 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -599,10 +599,12 @@ intel_panel_mode_valid(struct intel_connector *connector,
return MODE_OK;
 }
 
-int intel_panel_init(struct intel_panel *panel,
+int intel_panel_init(struct intel_connector *connector,
 struct drm_display_mode *fixed_mode,
 struct drm_display_mode *downclock_mode)
 {
+   struct intel_panel *panel = >panel;
+
intel_backlight_init_funcs(panel);
 
if (fixed_mode)
@@ -613,16 +615,15 @@ int intel_panel_init(struct intel_panel *panel,
return 0;
 }
 
-void intel_panel_fini(struct intel_panel *panel)
+void intel_panel_fini(struct intel_connector *connector)
 {
-   struct intel_connector 

[Intel-gfx] [PATCH 8/9] drm/i915: Use intel_panel_edid_fixed_mode() for sdvo

[Ville Syrjala]

From: Ville Syrjälä 

Despite the name intel_panel_edid_fixed_mode() doesn't actually
look in the EDID. All it does is dig out the preferred mode from
the connector's probed_modes list. That is also what the SDVO
LVDS code is doing by hand. Let's just call
intel_panel_edid_fixed_mode().

The slight difference in behaviour is that the SDVO code currently
bails if it can't find the preferred mode, whereas
intel_panel_edid_fixed_mode() will fall back to just returning
the first mode from the probed_modes list. Can't imagine why
such an LVDS panel would even exist, and also why would you have
a panel and be expected to not use it? So I'm going to assume
this is a total non-issue.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_sdvo.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index 27b3d3a79989..62e2e8b4358c 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2886,7 +2886,7 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int 
device)
struct drm_connector *connector;
struct intel_connector *intel_connector;
struct intel_sdvo_connector *intel_sdvo_connector;
-   struct drm_display_mode *mode;
+   struct drm_display_mode *fixed_mode;
 
DRM_DEBUG_KMS("initialising LVDS device %d\n", device);
 
@@ -2917,16 +2917,9 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int 
device)
 
intel_sdvo_get_lvds_modes(connector);
 
-   list_for_each_entry(mode, >probed_modes, head) {
-   if (mode->type & DRM_MODE_TYPE_PREFERRED) {
-   struct drm_display_mode *fixed_mode =
-   drm_mode_duplicate(connector->dev, mode);
+   fixed_mode = intel_panel_edid_fixed_mode(intel_connector);
 
-   intel_panel_init(intel_connector,
-fixed_mode, NULL);
-   break;
-   }
-   }
+   intel_panel_init(intel_connector, fixed_mode, NULL);
 
if (!intel_panel_preferred_fixed_mode(intel_connector))
goto err;
-- 
2.34.1

[Intel-gfx] [PATCH 7/9] drm/i915: Extract intel_panel_encoder_fixed_mode()

[Ville Syrjala]

From: Ville Syrjälä 

Apart from the EDID and VBT based mechanism we also sometimes
use the encoder's current mode as the panel fixed mode. We
currently have the same code for that duplicated in two places.
Let's unify.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dvo.c   | 30 +-
 drivers/gpu/drm/i915/display/intel_lvds.c  |  7 +
 drivers/gpu/drm/i915/display/intel_panel.c | 20 +++
 drivers/gpu/drm/i915/display/intel_panel.h |  4 +++
 4 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c 
b/drivers/gpu/drm/i915/display/intel_dvo.c
index 90e026cef6ee..8c98897d8313 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo.c
+++ b/drivers/gpu/drm/i915/display/intel_dvo.c
@@ -378,27 +378,6 @@ static const struct drm_encoder_funcs intel_dvo_enc_funcs 
= {
.destroy = intel_dvo_enc_destroy,
 };
 
-/*
- * Attempts to get a fixed panel timing for LVDS (currently only the i830).
- *
- * Other chips with DVO LVDS will need to extend this to deal with the LVDS
- * chip being on DVOB/C and having multiple pipes.
- */
-static struct drm_display_mode *
-intel_dvo_get_current_mode(struct intel_encoder *encoder)
-{
-   struct drm_display_mode *mode;
-
-   mode = intel_encoder_current_mode(encoder);
-   if (mode) {
-   DRM_DEBUG_KMS("using current (BIOS) mode: " DRM_MODE_FMT "\n",
- DRM_MODE_ARG(mode));
-   mode->type |= DRM_MODE_TYPE_PREFERRED;
-   }
-
-   return mode;
-}
-
 static enum port intel_dvo_port(i915_reg_t dvo_reg)
 {
if (i915_mmio_reg_equal(dvo_reg, DVOA))
@@ -541,6 +520,8 @@ void intel_dvo_init(struct drm_i915_private *dev_priv)
 
intel_connector_attach_encoder(intel_connector, intel_encoder);
if (dvo->type == INTEL_DVO_CHIP_LVDS) {
+   struct drm_display_mode *fixed_mode;
+
/*
 * For our LVDS chipsets, we should hopefully be able
 * to dig the fixed panel mode out of the BIOS data.
@@ -549,9 +530,10 @@ void intel_dvo_init(struct drm_i915_private *dev_priv)
 * headers, likely), so for now, just get the current
 * mode being output through DVO.
 */
-   intel_panel_init(intel_connector,
-
intel_dvo_get_current_mode(intel_encoder),
-NULL);
+   fixed_mode = 
intel_panel_encoder_fixed_mode(intel_connector,
+   
intel_encoder);
+
+   intel_panel_init(intel_connector, fixed_mode, NULL);
intel_dvo->panel_wants_dither = true;
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c
index c3f017c3740c..5b2367bc3cd2 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -983,12 +983,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
 * on.  If so, assume that whatever is currently programmed is the
 * correct mode.
 */
-   fixed_mode = intel_encoder_current_mode(intel_encoder);
-   if (fixed_mode) {
-   drm_dbg_kms(_priv->drm, "using current (BIOS) mode: " 
DRM_MODE_FMT "\n",
-   DRM_MODE_ARG(fixed_mode));
-   fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
-   }
+   fixed_mode = intel_panel_encoder_fixed_mode(intel_connector, 
intel_encoder);
 
/* If we still don't have a mode after all that, give up. */
if (!fixed_mode)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7f59db8b9ede..882e424973d4 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -292,6 +292,26 @@ intel_panel_vbt_sdvo_fixed_mode(struct intel_connector 
*connector)
return fixed_mode;
 }
 
+struct drm_display_mode *
+intel_panel_encoder_fixed_mode(struct intel_connector *connector,
+  struct intel_encoder *encoder)
+{
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+   struct drm_display_mode *fixed_mode;
+
+   fixed_mode = intel_encoder_current_mode(encoder);
+   if (!fixed_mode)
+   return NULL;
+
+   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] using current (BIOS) mode: " 
DRM_MODE_FMT "\n",
+   connector->base.base.id, connector->base.name,
+   DRM_MODE_ARG(fixed_mode));
+
+   fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+   return fixed_mode;
+}
+
 /* adjusted_mode has been preset to be the panel's fixed mode */
 static int pch_panel_fitting(struct intel_crtc_state *crtc_state,

[Intel-gfx] [PATCH 6/9] drm/i915: Extract intel_panel_vbt_sdvo_fixed_mode()

[Ville Syrjala]

From: Ville Syrjälä 

We have a function for duplicating the VBT LFP mode. Add the same
for the VBT SDVO mode.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 20 
 drivers/gpu/drm/i915/display/intel_panel.h |  2 ++
 drivers/gpu/drm/i915/display/intel_sdvo.c  | 14 --
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index bd606d0b1c24..7f59db8b9ede 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -272,6 +272,26 @@ intel_panel_vbt_lfp_fixed_mode(struct intel_connector 
*connector)
return fixed_mode;
 }
 
+struct drm_display_mode *
+intel_panel_vbt_sdvo_fixed_mode(struct intel_connector *connector)
+{
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+   struct drm_display_mode *fixed_mode;
+
+   if (!i915->vbt.sdvo_lvds_vbt_mode)
+   return NULL;
+
+   fixed_mode = drm_mode_duplicate(>drm,
+   i915->vbt.sdvo_lvds_vbt_mode);
+   if (!fixed_mode)
+   return NULL;
+
+   /* Guarantee the mode is preferred */
+   fixed_mode->type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER;
+
+   return fixed_mode;
+}
+
 /* adjusted_mode has been preset to be the panel's fixed mode */
 static int pch_panel_fitting(struct intel_crtc_state *crtc_state,
 const struct drm_connector_state *conn_state)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.h 
b/drivers/gpu/drm/i915/display/intel_panel.h
index 9704ac81fe3e..7e32c903a1e6 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.h
+++ b/drivers/gpu/drm/i915/display/intel_panel.h
@@ -48,5 +48,7 @@ struct drm_display_mode *
 intel_panel_edid_fixed_mode(struct intel_connector *connector);
 struct drm_display_mode *
 intel_panel_vbt_lfp_fixed_mode(struct intel_connector *connector);
+struct drm_display_mode *
+intel_panel_vbt_sdvo_fixed_mode(struct intel_connector *connector);
 
 #endif /* __INTEL_PANEL_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index a2061b132107..27b3d3a79989 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2301,16 +2301,10 @@ static int intel_sdvo_get_lvds_modes(struct 
drm_connector *connector)
 * Fetch modes from VBT. For SDVO prefer the VBT mode since some
 * SDVO->LVDS transcoders can't cope with the EDID mode.
 */
-   if (dev_priv->vbt.sdvo_lvds_vbt_mode != NULL) {
-   newmode = drm_mode_duplicate(connector->dev,
-dev_priv->vbt.sdvo_lvds_vbt_mode);
-   if (newmode != NULL) {
-   /* Guarantee the mode is preferred */
-   newmode->type = (DRM_MODE_TYPE_PREFERRED |
-DRM_MODE_TYPE_DRIVER);
-   drm_mode_probed_add(connector, newmode);
-   num_modes++;
-   }
+   newmode = 
intel_panel_vbt_sdvo_fixed_mode(to_intel_connector(connector));
+   if (newmode) {
+   drm_mode_probed_add(connector, newmode);
+   num_modes++;
}
 
/*
-- 
2.34.1

[Intel-gfx] [PATCH 4/9] drm/i915: Use intel_panel_preferred_fixed_mode() more

[Ville Syrjala]

From: Ville Syrjälä 

Use intel_panel_preferred_fixed_mode() for all the orientation
quirk setup and compute_is_dual_link_lvds()). All of these
happen after intel_panel_init() so the panel fixed_mode list
is already in place.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  7 ---
 drivers/gpu/drm/i915/display/intel_dp.c   |  7 ---
 drivers/gpu/drm/i915/display/intel_lvds.c | 11 ++-
 drivers/gpu/drm/i915/display/vlv_dsi.c|  7 ---
 4 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index c7a6c2cce297..b4fda29b04b5 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1965,9 +1965,10 @@ static void icl_dphy_param_init(struct intel_dsi 
*intel_dsi)
intel_dsi_log_params(intel_dsi);
 }
 
-static void icl_dsi_add_properties(struct intel_connector *connector,
-  const struct drm_display_mode *fixed_mode)
+static void icl_dsi_add_properties(struct intel_connector *connector)
 {
+   const struct drm_display_mode *fixed_mode =
+   intel_panel_preferred_fixed_mode(connector);
u32 allowed_scalers;
 
allowed_scalers = BIT(DRM_MODE_SCALE_ASPECT) |
@@ -2085,7 +2086,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
 
icl_dphy_param_init(intel_dsi);
 
-   icl_dsi_add_properties(intel_connector, fixed_mode);
+   icl_dsi_add_properties(intel_connector);
return;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bf13dbafbee..d62123b9d0d3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4962,11 +4962,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
 }
 
 static void
-intel_edp_add_properties(struct intel_dp *intel_dp,
-const struct drm_display_mode *fixed_mode)
+intel_edp_add_properties(struct intel_dp *intel_dp)
 {
struct intel_connector *connector = intel_dp->attached_connector;
struct drm_i915_private *i915 = to_i915(connector->base.dev);
+   const struct drm_display_mode *fixed_mode =
+   intel_panel_preferred_fixed_mode(connector);
 
if (!fixed_mode)
return;
@@ -5081,7 +5082,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
intel_connector->panel.backlight.power = 
intel_pps_backlight_power;
intel_backlight_setup(intel_connector, pipe);
 
-   intel_edp_add_properties(intel_dp, fixed_mode);
+   intel_edp_add_properties(intel_dp);
 
return true;
 
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c
index b57e76b4ef04..d068e0607153 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -778,12 +778,13 @@ bool intel_is_dual_link_lvds(struct drm_i915_private 
*dev_priv)
return encoder && to_lvds_encoder(>base)->is_dual_link;
 }
 
-static bool compute_is_dual_link_lvds(struct intel_lvds_encoder *lvds_encoder,
- const struct drm_display_mode *fixed_mode)
+static bool compute_is_dual_link_lvds(struct intel_lvds_encoder *lvds_encoder)
 {
-   struct drm_device *dev = lvds_encoder->base.base.dev;
+   struct drm_i915_private *dev_priv = 
to_i915(lvds_encoder->base.base.dev);
+   struct intel_connector *connector = lvds_encoder->attached_connector;
+   const struct drm_display_mode *fixed_mode =
+   intel_panel_preferred_fixed_mode(connector);
unsigned int val;
-   struct drm_i915_private *dev_priv = to_i915(dev);
 
/* use the module option value if specified */
if (dev_priv->params.lvds_channel_mode > 0)
@@ -999,7 +1000,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
intel_panel_init(intel_connector, fixed_mode, downclock_mode);
intel_backlight_setup(intel_connector, INVALID_PIPE);
 
-   lvds_encoder->is_dual_link = compute_is_dual_link_lvds(lvds_encoder, 
fixed_mode);
+   lvds_encoder->is_dual_link = compute_is_dual_link_lvds(lvds_encoder);
drm_dbg_kms(_priv->drm, "detected %s-link lvds configuration\n",
lvds_encoder->is_dual_link ? "dual" : "single");
 
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 32f5b115c2c2..da0af425ed94 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1657,10 +1657,11 @@ static const struct drm_connector_funcs 
intel_dsi_connector_funcs = {
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
 };
 
-static void vlv_dsi_add_properties(struct intel_connector *connector,
-  const struct drm_display_mode 

[Intel-gfx] [PATCH 3/9] drm/i915: Extract intel_edp_add_properties()

[Ville Syrjala]

From: Ville Syrjälä 

Pull the drm_connector_set_panel_orientation_with_quirk()
into intel_edp_add_properties() to match how the DSI encoders
do it. Less clutter in intel_edp_init_connector() overall.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f54088db9862..4bf13dbafbee 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4961,6 +4961,22 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
drm_connector_attach_vrr_capable_property(connector);
 }
 
+static void
+intel_edp_add_properties(struct intel_dp *intel_dp,
+const struct drm_display_mode *fixed_mode)
+{
+   struct intel_connector *connector = intel_dp->attached_connector;
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+
+   if (!fixed_mode)
+   return;
+
+   drm_connector_set_panel_orientation_with_quirk(>base,
+  i915->vbt.orientation,
+  fixed_mode->hdisplay,
+  fixed_mode->vdisplay);
+}
+
 static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 struct intel_connector *intel_connector)
 {
@@ -5065,11 +5081,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
intel_connector->panel.backlight.power = 
intel_pps_backlight_power;
intel_backlight_setup(intel_connector, pipe);
 
-   if (fixed_mode) {
-   drm_connector_set_panel_orientation_with_quirk(connector,
-   dev_priv->vbt.orientation,
-   fixed_mode->hdisplay, fixed_mode->vdisplay);
-   }
+   intel_edp_add_properties(intel_dp, fixed_mode);
 
return true;
 
-- 
2.34.1

[Intel-gfx] [PATCH 2/9] drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG()

[Ville Syrjala]

From: Ville Syrjälä 

Replace all drm_mode_debug_printmodeline() calls with
DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more
terse in places where we previously had a newline in the precedeing
drm_dbg_kms(), and avoids anything else sneaking in between the two
printk()s in all cases.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c| 12 +-
 drivers/gpu/drm/i915/display/intel_display.c | 12 +-
 drivers/gpu/drm/i915/display/intel_dp.c  |  6 ++---
 drivers/gpu/drm/i915/display/intel_dvo.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_lvds.c|  4 ++--
 drivers/gpu/drm/i915/display/intel_panel.c   | 24 ++--
 drivers/gpu/drm/i915/display/intel_tv.c  | 12 +-
 7 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index c7afe19dd44a..3f3e8ccd9026 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -306,8 +306,8 @@ parse_lfp_panel_dtd(struct drm_i915_private *i915,
i915->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
 
drm_dbg_kms(>drm,
-   "Found panel mode in BIOS VBT legacy lfp table:\n");
-   drm_mode_debug_printmodeline(panel_fixed_mode);
+   "Found panel mode in BIOS VBT legacy lfp table: " 
DRM_MODE_FMT "\n",
+   DRM_MODE_ARG(panel_fixed_mode));
 
fp_timing = get_lvds_fp_timing(bdb, lvds_lfp_data,
   lvds_lfp_data_ptrs,
@@ -397,8 +397,8 @@ parse_generic_dtd(struct drm_i915_private *i915,
panel_fixed_mode->flags |= DRM_MODE_FLAG_NVSYNC;
 
drm_dbg_kms(>drm,
-   "Found panel mode in BIOS VBT generic dtd table:\n");
-   drm_mode_debug_printmodeline(panel_fixed_mode);
+   "Found panel mode in BIOS VBT generic dtd table: " 
DRM_MODE_FMT "\n",
+   DRM_MODE_ARG(panel_fixed_mode));
 
i915->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
 }
@@ -551,8 +551,8 @@ parse_sdvo_panel_data(struct drm_i915_private *i915,
i915->vbt.sdvo_lvds_vbt_mode = panel_fixed_mode;
 
drm_dbg_kms(>drm,
-   "Found SDVO panel mode in BIOS VBT tables:\n");
-   drm_mode_debug_printmodeline(panel_fixed_mode);
+   "Found SDVO panel mode in BIOS VBT tables: " DRM_MODE_FMT 
"\n",
+   DRM_MODE_ARG(panel_fixed_mode));
 }
 
 static int intel_bios_ssc_frequency(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index dc6e21e4ef0b..ff50b4bc2b3d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5417,13 +5417,13 @@ static void intel_dump_pipe_config(const struct 
intel_crtc_state *pipe_config,
intel_vrr_vmin_vblank_start(pipe_config),
intel_vrr_vmax_vblank_start(pipe_config));
 
-   drm_dbg_kms(_priv->drm, "requested mode:\n");
-   drm_mode_debug_printmodeline(_config->hw.mode);
-   drm_dbg_kms(_priv->drm, "adjusted mode:\n");
-   drm_mode_debug_printmodeline(_config->hw.adjusted_mode);
+   drm_dbg_kms(_priv->drm, "requested mode: " DRM_MODE_FMT "\n",
+   DRM_MODE_ARG(_config->hw.mode));
+   drm_dbg_kms(_priv->drm, "adjusted mode: " DRM_MODE_FMT "\n",
+   DRM_MODE_ARG(_config->hw.adjusted_mode));
intel_dump_crtc_timings(dev_priv, _config->hw.adjusted_mode);
-   drm_dbg_kms(_priv->drm, "pipe mode:\n");
-   drm_mode_debug_printmodeline(_config->hw.pipe_mode);
+   drm_dbg_kms(_priv->drm, "pipe mode: " DRM_MODE_FMT "\n",
+   DRM_MODE_ARG(_config->hw.pipe_mode));
intel_dump_crtc_timings(dev_priv, _config->hw.pipe_mode);
drm_dbg_kms(_priv->drm,
"port clock: %d, pipe src: " DRM_RECT_FMT ", pixel rate 
%d\n",
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3bf44f7909e5..f54088db9862 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2579,9 +2579,9 @@ static void intel_edp_mso_mode_fixup(struct 
intel_connector *connector,
drm_mode_set_name(mode);
 
drm_dbg_kms(>drm,
-   "[CONNECTOR:%d:%s] using generated MSO mode: ",
-   connector->base.base.id, connector->base.name);
-   drm_mode_debug_printmodeline(mode);
+   "[CONNECTOR:%d:%s] using generated MSO mode: " DRM_MODE_FMT 
"\n",
+   connector->base.base.id, connector->base.name,
+   DRM_MODE_ARG(mode));
 }
 
 static void intel_edp_mso_init(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c 
b/drivers/gpu/drm/i915/display/intel_dvo.c
index d4dc16a9c0dd..90e026cef6ee 100644
--- 

[Intel-gfx] [PATCH 0/9] drm/i915: More fixed_mode refactoring

[Ville Syrjala]

From: Ville Syrjälä 

Continue refactoring the panel fixed_mode stuff. The main
thing here is unifying SDVO with the rest of the world.

Ville Syrjälä (9):
  drm/i915: Pass intel_connector to intel_panel_{init,fini}()
  drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG()
  drm/i915: Extract intel_edp_add_properties()
  drm/i915: Use intel_panel_preferred_fixed_mode() more
  drm/i915: Rename intel_panel_vbt_fixed_mode()
  drm/i915: Extract intel_panel_vbt_sdvo_fixed_mode()
  drm/i915: Extract intel_panel_encoder_fixed_mode()
  drm/i915: Use intel_panel_edid_fixed_mode() for sdvo
  drm/i915: Change SDVO fixed mode handling

 drivers/gpu/drm/i915/display/icl_dsi.c| 11 +--
 drivers/gpu/drm/i915/display/intel_bios.c | 12 +--
 .../gpu/drm/i915/display/intel_connector.c|  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 12 +--
 drivers/gpu/drm/i915/display/intel_dp.c   | 33 +---
 drivers/gpu/drm/i915/display/intel_dvo.c  | 30 ++--
 drivers/gpu/drm/i915/display/intel_lvds.c | 22 +++---
 drivers/gpu/drm/i915/display/intel_panel.c| 77 ++-
 drivers/gpu/drm/i915/display/intel_panel.h| 13 +++-
 drivers/gpu/drm/i915/display/intel_sdvo.c | 46 +++
 drivers/gpu/drm/i915/display/intel_tv.c   | 12 +--
 drivers/gpu/drm/i915/display/vlv_dsi.c| 11 +--
 12 files changed, 149 insertions(+), 132 deletions(-)

-- 
2.34.1

[Intel-gfx] [CI] PR for DG2 DMC v2.06

[Tolakanahalli Pradeep, Madhumitha]

The following changes since commit
681281e49fb6778831370e5d94e6e1d97f0752d6:

  amdgpu: update PSP 13.0.8 firmware (2022-03-18 07:35:54 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.06

for you to fetch changes up to
ecc28070ea5edd4733b78550326c1d56858181af:

  i915: Add DMC v2.06 for DG2 (2022-03-23 11:15:12 -0700)


Madhumitha Tolakanahalli Pradeep (1):
  i915: Add DMC v2.06 for DG2

 WHENCE   |   3 +++
 i915/dg2_dmc_ver2_06.bin | Bin 0 -> 22416 bytes
 2 files changed, 3 insertions(+)
 create mode 100644 i915/dg2_dmc_ver2_06.bin

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Revert "drm/i915/dg2: Add relocation exception" (rev2)

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/dg2: Add relocation exception" (rev2)
URL   : https://patchwork.freedesktop.org/series/101669/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] [PATCH] [topic/core-for-CI] Revert "drm/i915/dg2: Add relocation exception"

[Zbigniew Kempczyński]

This reverts commit 904ebf2ba89edaeba5c7c10540e43dba63541dc6.

Failures on dg2 tests were caused by invalid alignment when local memory
was in use. Changes which adopt alignment according to gen were already
merged in IGT so lets revert relocation temporary enabler for dg2. Keeping
it is a little bit problematic for IGT because on premerge we would see
results with kernel which supports relocation. To see no-relocation
results we need to send disabler (like this revert), point IGT with
"Test-with" tag what is cumbersome and time consuming so lets do this
permanently. If we will see some failures they need to be fixed instead
of keeping relocation enabler.

Signed-off-by: Zbigniew Kempczyński 
Cc: Lucas De Marchi 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 42a49fd2f2ab..8b0b4aeb6716 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -501,7 +501,7 @@ static bool platform_has_relocs_enabled(const struct 
i915_execbuffer *eb)
 */
if (GRAPHICS_VER(eb->i915) < 12 || IS_TIGERLAKE(eb->i915) ||
IS_ROCKETLAKE(eb->i915) || IS_ALDERLAKE_S(eb->i915) ||
-   IS_ALDERLAKE_P(eb->i915) || IS_DG2(eb->i915))
+   IS_ALDERLAKE_P(eb->i915))
return true;
 
return false;
-- 
2.32.0

Re: [Intel-gfx] [RFC 06/19] drm/edid: clean up cea_db_is_*() functions

[Jani Nikula]

On Wed, 23 Mar 2022, Ville Syrjälä  wrote:
> On Tue, Mar 22, 2022 at 11:40:35PM +0200, Jani Nikula wrote:
>> Abstract helpers for matching vendor data blocks and extended tags, and
>> use them to simplify all the cea_db_is_*() functions.
>> 
>> Take void pointer as parameter to allow transitional use for both u8 *
>> and struct cea_db *.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_edid.c | 113 -
>>  1 file changed, 37 insertions(+), 76 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index c12c3cbab274..a0a5a7271658 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4196,12 +4196,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
>> const u8 *db, u8 len,
>>  return modes;
>>  }
>>  
>> -static int
>> -cea_db_extended_tag(const u8 *db)
>> -{
>> -return db[1];
>> -}
>> -
>>  static int
>>  cea_revision(const u8 *cea)
>>  {
>> @@ -4313,6 +4307,22 @@ static const void *cea_db_data(const struct cea_db 
>> *db)
>>  return db->data;
>>  }
>>  
>> +static bool cea_db_is_extended_tag(const struct cea_db *db, int tag)
>> +{
>> +return (cea_db_tag(db) == CEA_DB_EXTENDED_TAG &&
>> +cea_db_payload_len(db) >= 1 &&
>> +db->data[0] == tag);
>> +}
>
> nit: not a huge fan of the redundant parens in all of these

I guess that's something I've picked up from Python, makes the
subsequent lines align nicely. Otherwise it's less pretty.

>
>> +
>> +static bool cea_db_is_vendor(const struct cea_db *db, int vendor_oui)
>
> I'd probably make the tag/oui unsigned.

Only chose int because the oui() function returns an int; maybe that
should eventually be turned into unsigned int.

>
> Reviewed-by: Ville Syrjälä 
>
>> +{
>> +const u8 *data = cea_db_data(db);
>> +
>> +return (cea_db_tag(db) == CEA_DB_VENDOR &&
>> +cea_db_payload_len(db) >= 3 &&
>> +oui(data[2], data[1], data[0]) == vendor_oui);
>> +}
>> +
>>  static void cea_db_iter_edid_begin(const struct edid *edid, struct 
>> cea_db_iter *iter)
>>  {
>>  memset(iter, 0, sizeof(*iter));
>> @@ -4443,79 +4453,44 @@ static void cea_db_iter_end(struct cea_db_iter *iter)
>>  memset(iter, 0, sizeof(*iter));
>>  }
>>  
>> -static bool cea_db_is_hdmi_vsdb(const u8 *db)
>> +static bool cea_db_is_hdmi_vsdb(const void *db)
>>  {
>> -if (cea_db_tag(db) != CEA_DB_VENDOR)
>> -return false;
>> -
>> -if (cea_db_payload_len(db) < 5)
>> -return false;
>> -
>> -return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
>> +return (cea_db_is_vendor(db, HDMI_IEEE_OUI) &&
>> +cea_db_payload_len(db) >= 5);
>>  }
>>  
>> -static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
>> +static bool cea_db_is_hdmi_forum_vsdb(const void *db)
>>  {
>> -if (cea_db_tag(db) != CEA_DB_VENDOR)
>> -return false;
>> -
>> -if (cea_db_payload_len(db) < 7)
>> -return false;
>> -
>> -return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
>> +return (cea_db_is_vendor(db, HDMI_FORUM_IEEE_OUI) &&
>> +cea_db_payload_len(db) >= 7);
>>  }
>>  
>> -static bool cea_db_is_microsoft_vsdb(const u8 *db)
>> +static bool cea_db_is_microsoft_vsdb(const void *db)
>>  {
>> -if (cea_db_tag(db) != CEA_DB_VENDOR)
>> -return false;
>> -
>> -if (cea_db_payload_len(db) != 21)
>> -return false;
>> -
>> -return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
>> +return (cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
>> +cea_db_payload_len(db) == 21);
>>  }
>>  
>> -static bool cea_db_is_vcdb(const u8 *db)
>> +static bool cea_db_is_vcdb(const void *db)
>>  {
>> -if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
>> -return false;
>> -
>> -if (cea_db_payload_len(db) != 2)
>> -return false;
>> -
>> -if (cea_db_extended_tag(db) != CEA_EXT_DB_VIDEO_CAP)
>> -return false;
>> -
>> -return true;
>> +return (cea_db_is_extended_tag(db, CEA_EXT_DB_VIDEO_CAP) &&
>> +cea_db_payload_len(db) == 2);
>>  }
>>  
>> -static bool cea_db_is_y420cmdb(const u8 *db)
>> +static bool cea_db_is_y420cmdb(const void *db)
>>  {
>> -if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
>> -return false;
>> -
>> -if (!cea_db_payload_len(db))
>> -return false;
>> -
>> -if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_CAP_MAP)
>> -return false;
>> -
>> -return true;
>> +return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_CAP_MAP);
>>  }
>>  
>> -static bool cea_db_is_y420vdb(const u8 *db)
>> +static bool cea_db_is_y420vdb(const void *db)
>>  {
>> -if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
>> -return false;
>> -
>> -if (!cea_db_payload_len(db))
>> -return false;
>> -
>> -if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_DATA)
>> -return false;
>> +return 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

[Patchwork]

== Series Details ==

Series: drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
URL   : https://patchwork.freedesktop.org/series/101699/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22659


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22659 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22659, 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_22659/index.html

Participating hosts (45 -> 44)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(6): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 shard-rkl 
fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][7] ([fdo#109271]) +54 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#5341])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][11] ([i915#4312])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-rkl-guc/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][12] ([i915#4391]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][16] ([i915#3921]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22659/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][18] ([i915#5338]) -> [PASS][19]
   [18]: 

Re: [Intel-gfx] [RFC 00/19] drm/edid: overhaul CEA data block iteration

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:29PM +0200, Jani Nikula wrote:
> Add iterators for EDID blocks and CEA data blocks, to iterate through
> all data blocks across all CEA extensions and CTA blocks in DisplayID
> data blocks. Fix all code assuming only one CEA extension. Fix code
> assuming CTA blocks contain everything that CEA extensions do. Sprinkle
> a bunch of cleanups on top.
> 
> This is completely UNTESTED, didn't even smoke test it. It builds. ;)

Despite that it's now
Reviewed-by: Ville Syrjälä 

Left a few minor comments here and there.

> 
> This superseeds parts of [1] and [2].
> 
> BR,
> Jani.
> 
> [1] https://patchwork.freedesktop.org/series/101241/
> [2] 
> https://patchwork.freedesktop.org/patch/msgid/20220321044330.27723-1-cooper.ch...@intel.com
> 
> 
> Cc: Shawn C Lee 
> Cc: Cooper Chiou 
> Cc: william.ts...@intel.com
> Cc: ankit.k.nauti...@intel.com
> Cc: ville.syrj...@linux.intel.com
> Cc: Drew Davenport 
> 
> Jani Nikula (19):
>   drm/edid: add drm_edid_extension_block_count() and drm_edid_size()
>   drm: use drm_edid_extension_block_count() and drm_edid_size()
>   drm/edid: clean up CEA data block tag definitions
>   drm/edid: add iterator for EDID base and extension blocks
>   drm/edid: add iterator for CEA data blocks
>   drm/edid: clean up cea_db_is_*() functions
>   drm/edid: convert add_cea_modes() to use cea db iter
>   drm/edid: convert drm_edid_to_speaker_allocation() to use cea db iter
>   drm/edid: convert drm_edid_to_sad() to use cea db iter
>   drm/edid: convert drm_detect_hdmi_monitor() to use cea db iter
>   drm/edid: convert drm_detect_monitor_audio() to use cea db iter
>   drm/edid: convert drm_parse_cea_ext() to use cea db iter
>   drm/edid: convert drm_edid_to_eld() to use cea db iter
>   drm/edid: sunset the old unused cea data block iterators
>   drm/edid: restore some type safety to cea_db_*() functions
>   drm/edid: detect basic audio only on CEA extension
>   drm/edid: detect color formats and CEA revision only on CEA extension
>   drm/edid: skip CEA extension scan in drm_edid_to_eld() just for CEA
> rev
>   drm/edid: sunset drm_find_cea_extension()
> 
>  drivers/gpu/drm/drm_connector.c |   2 +-
>  drivers/gpu/drm/drm_debugfs.c   |   3 +-
>  drivers/gpu/drm/drm_edid.c  | 781 ++--
>  include/drm/drm_edid.h  |   2 +
>  4 files changed, 455 insertions(+), 333 deletions(-)
> 
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [RFC 19/19] drm/edid: sunset drm_find_cea_extension()

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:48PM +0200, Jani Nikula wrote:
> Convert drm_find_cea_extension() to a predicate function to check if the
> EDID has a CEA extension or a DisplayID CTA data block. This is mainly
> to avoid adding new users that only find the first CEA extension.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index dfaa21f00941..84314b65b75b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3422,30 +3422,29 @@ const u8 *drm_find_edid_extension(const struct edid 
> *edid,
>   return edid_ext;
>  }
>  
> -static const u8 *drm_find_cea_extension(const struct edid *edid)
> +/* Return true if the EDID has a CEA extension or a DisplayID CTA data block 
> */
> +static bool drm_edid_has_cea_extension(const struct edid *edid)
>  {
>   const struct displayid_block *block;
>   struct displayid_iter iter;
> - const u8 *cea;
>   int ext_index = 0;
> + bool found = false;
>  
>   /* Look for a top level CEA extension block */
> - /* FIXME: make callers iterate through multiple CEA ext blocks? */
> - cea = drm_find_edid_extension(edid, CEA_EXT, _index);
> - if (cea)
> - return cea;
> + if (drm_find_edid_extension(edid, CEA_EXT, _index))
> + return true;
>  
>   /* CEA blocks can also be found embedded in a DisplayID block */
>   displayid_iter_edid_begin(edid, );
>   displayid_iter_for_each(block, ) {
>   if (block->tag == DATA_BLOCK_CTA) {
> - cea = (const u8 *)block;
> + found = true;
>   break;
>   }
>   }
>   displayid_iter_end();
>  
> - return cea;
> + return found;
>  }
>  
>  static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 
> vic)
> @@ -3715,7 +3714,7 @@ add_alternate_cea_modes(struct drm_connector 
> *connector, struct edid *edid)
>   int modes = 0;
>  
>   /* Don't add CEA modes if the CEA extension block is missing */
> - if (!drm_find_cea_extension(edid))
> + if (!drm_edid_has_cea_extension(edid))

I'm thinking we could just do
if (modes)
modes += add_alternate_cea_modes(...);
at the end of add_cea_modes().

Or perhaps
if (found)
modes += add_alternate_cea_modes(...);
if we think that adding the alternate modes would be apporpriate
even when add_cea_modes() didn't add anything. Not sure.

Yes, that would still introduce a sligth change in behaviour
in case we have a CEA ext block/DisplayID CTA block without
any of the video/hdmi/y420vdb blocks, but that edge case
doesn't feel like a deal-breaker to me.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [RFC 09/19] drm/edid: convert drm_edid_to_sad() to use cea db iter

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:38PM +0200, Jani Nikula wrote:
> Use the cea db iterator for short audio descriptors. We'll still stop at
> the first audio data block, but not at the first CEA extension if that
> doesn't have the info.

This stuff should probably be converted over to the drm_edid_to_eld()
approach which looks up all the SADs from the whole EDID. But that's
something for amdgpu/radeon folks to think about since they're the only
user.

> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 34 +-
>  1 file changed, 9 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 992b3578a73f..e341790521d6 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4854,40 +4854,21 @@ static void drm_edid_to_eld(struct drm_connector 
> *connector, struct edid *edid)
>   */
>  int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads)
>  {
> + const struct cea_db *db;
> + struct cea_db_iter iter;
>   int count = 0;
> - int i, start, end, dbl;
> - const u8 *cea;
> -
> - cea = drm_find_cea_extension(edid);
> - if (!cea) {
> - DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> - return 0;
> - }
> -
> - if (cea_revision(cea) < 3) {
> - DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> - return 0;
> - }
> -
> - if (cea_db_offsets(cea, , )) {
> - DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
> - return -EPROTO;
> - }
> -
> - for_each_cea_db(cea, i, start, end) {
> - const u8 *db = [i];
>  
> + cea_db_iter_edid_begin(edid, );
> + cea_db_iter_for_each(db, ) {
>   if (cea_db_tag(db) == CEA_DB_AUDIO) {
>   int j;
>  
> - dbl = cea_db_payload_len(db);
> -
> - count = dbl / 3; /* SAD is 3B */
> + count = cea_db_payload_len(db) / 3; /* SAD is 3B */
>   *sads = kcalloc(count, sizeof(**sads), GFP_KERNEL);
>   if (!*sads)
>   return -ENOMEM;
>   for (j = 0; j < count; j++) {
> - const u8 *sad = [1 + j * 3];
> + const u8 *sad = >data[j * 3];
>  
>   (*sads)[j].format = (sad[0] & 0x78) >> 3;
>   (*sads)[j].channels = sad[0] & 0x7;
> @@ -4897,6 +4878,9 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
> **sads)
>   break;
>   }
>   }
> + cea_db_iter_end();
> +
> + DRM_DEBUG_KMS("Found %d Short Audio Descriptors\n", count);
>  
>   return count;
>  }
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [RFC 05/19] drm/edid: add iterator for CEA data blocks

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:34PM +0200, Jani Nikula wrote:
> Add an iterator for CEA Data Blocks across CEA extensions and CTA
> DisplayID Data Blocks.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 198 ++---
>  1 file changed, 186 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 31d132fcd0ca..c12c3cbab274 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4196,24 +4196,12 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
> const u8 *db, u8 len,
>   return modes;
>  }
>  
> -static int
> -cea_db_payload_len(const u8 *db)
> -{
> - return db[0] & 0x1f;
> -}
> -
>  static int
>  cea_db_extended_tag(const u8 *db)
>  {
>   return db[1];
>  }
>  
> -static int
> -cea_db_tag(const u8 *db)
> -{
> - return db[0] >> 5;
> -}
> -
>  static int
>  cea_revision(const u8 *cea)
>  {
> @@ -4269,6 +4257,192 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
>   return 0;
>  }
>  
> +/*
> + * CEA Data Block iterator.
> + *
> + * Iterate through all CEA Data Blocks in both EDID CEA extensions and CTA 
> Data
> + * Blocks in DisplayID extension blocks.
> + *
> + * struct cea_db *db:
> + * struct cea_db_iter iter;
> + *
> + * cea_db_iter_edid_begin(edid, );
> + * cea_db_iter_for_each(db, ) {
> + * // do stuff with db
> + * }
> + * cea_db_iter_end();
> + */
> +struct cea_db_iter {
> + struct drm_edid_iter edid_iter;
> + struct displayid_iter displayid_iter;
> +
> + /* Current Data Block Collection. */
> + const u8 *collection;
> +
> + /* Current Data Block index in current collection. */
> + int index;
> +
> + /* End index in current collection. */
> + int end;
> +};
> +
> +/* CEA-861-F section 7.5 CEA Extension Version 3 and Table 43 */
> +struct cea_db {
> + u8 tag_length;
> + u8 data[];
> +} __packed;
> +
> +static int cea_db_tag(const void *_db)
> +{
> + /* FIXME: Transition to passing struct cea_db * everywhere. */
> + const struct cea_db *db = _db;
> +
> + return db->tag_length >> 5;
> +}
> +
> +static int cea_db_payload_len(const void *_db)
> +{
> + /* FIXME: Transition to passing struct cea_db * everywhere. */
> + const struct cea_db *db = _db;
> +
> + return db->tag_length & 0x1f;
> +}
> +
> +static const void *cea_db_data(const struct cea_db *db)
> +{
> + return db->data;
> +}
> +
> +static void cea_db_iter_edid_begin(const struct edid *edid, struct 
> cea_db_iter *iter)
> +{
> + memset(iter, 0, sizeof(*iter));
> +
> + drm_edid_iter_begin(edid, >edid_iter);
> + displayid_iter_edid_begin(edid, >displayid_iter);
> +}
> +
> +static const struct cea_db *
> +__cea_db_iter_current_block(const struct cea_db_iter *iter)
> +{
> + const struct cea_db *db;
> +
> + if (!iter->collection)
> + return NULL;
> +
> + db = (const struct cea_db *)>collection[iter->index];
> +
> + if (iter->index + sizeof(*db) <= iter->end &&
> + iter->index + sizeof(*db) + cea_db_payload_len(db) <= iter->end)
> + return db;
> +
> + return NULL;
> +}
> +
> +/*
> + * References:
> + * - VESA E-EDID v1.4
> + * - CEA-861-F section 7.5 CEA Extension Version 3
> + */
> +static const void *__cea_db_iter_edid_next(struct cea_db_iter *iter)
> +{
> + const u8 *ext;
> +
> + drm_edid_iter_for_each(ext, >edid_iter) {
> + /* Only support CEA extension revision 3+ */
> + if (ext[0] != CEA_EXT || cea_revision(ext) < 3)
> + continue;
> +
> + iter->index = 4;
> + iter->end = ext[2];
> + if (iter->end == 0)
> + iter->end = 127;
> + if (iter->end < 4 || iter->end > 127)
> + continue;
> +
> + return ext;
> + }
> +
> + return NULL;
> +}
> +
> +/*
> + * References:
> + * - DisplayID v1.3 Appendix C: CEA Data Block within a DisplayID Data Block
> + * - DisplayID v2.0 section 4.10 CTA DisplayID Data Block
> + *
> + * Note that the above do not specify any connection between DisplayID Data
> + * Block revision and CEA Extension versions.
> + */
> +static const void *__cea_db_iter_displayid_next(struct cea_db_iter *iter)
> +{
> + const struct displayid_block *block;
> +
> + displayid_iter_for_each(block, >displayid_iter) {
> + if (block->tag != DATA_BLOCK_CTA)
> + continue;
> +
> + iter->index = sizeof(*block);
> + iter->end = iter->index + block->num_bytes;

I'd like to keep the comment from cea_db_offsets() reminding
us why we  can trust this thing.

Overall looks pretty nice to my eyes.
Reviewed-by: Ville Syrjälä 

> +
> + return block;
> + }
> +
> + return NULL;
> +}
> +
> +static const struct cea_db *__cea_db_iter_next(struct cea_db_iter *iter)
> +{
> + const struct cea_db *db;
> +
> + if (iter->collection) {

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

[Patchwork]

== Series Details ==

Series: drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
URL   : https://patchwork.freedesktop.org/series/101699/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

[Patchwork]

== Series Details ==

Series: drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
URL   : https://patchwork.freedesktop.org/series/101699/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fce9e0a464ec drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
-:23: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Colin Ian King ' != 'Signed-off-by: 
Colin Ian King '

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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for dyndbg add exclusive class support (rev2)

[Patchwork]

== Series Details ==

Series: dyndbg add exclusive class support (rev2)
URL   : https://patchwork.freedesktop.org/series/101265/
State : failure

== Summary ==

Applying: dyndbg: fix static_branch manipulation
Applying: dyndbg: add class_id field and query support
error: sha1 information is lacking or useless (lib/dynamic_debug.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 dyndbg: add class_id field and query support
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/edid: fix CEA extension byte #3 parsing

[Patchwork]

== Series Details ==

Series: drm/edid: fix CEA extension byte #3 parsing
URL   : https://patchwork.freedesktop.org/series/101680/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22657_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_create@madvise@smem:
- {shard-rkl}:[INCOMPLETE][1] ([i915#5385]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-rkl-5/igt@gem_exec_create@madv...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-rkl-5/igt@gem_exec_create@madv...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#5327])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-iclb6/igt@gem_...@block-copy-compressed.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#3070])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb8/igt@gem_...@in-flight-contexts-immediate.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-iclb2/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][6] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-iclb3/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][7] ([fdo#109271]) +75 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-apl:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-iclb6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb3/igt@gem_huc_c...@huc-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#4613])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/shard-tglb5/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl:  NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613])
   [22]: 

Re: [Intel-gfx] [External] Re: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

[Souza, Jose]

Hi Mark

See comment below.

On Tue, 2022-03-22 at 10:23 -0400, Mark Pearson wrote:
> Thanks Stanislav,
> 
> On 3/22/22 10:18, Lisovskiy, Stanislav wrote:
> > On Tue, Mar 22, 2022 at 09:55:35AM -0400, Mark Pearson wrote:
> > > Hi,
> > > 
> > > On 3/21/22 06:49, Stanislav Lisovskiy wrote:
> > > > We are currently getting FIFO underruns, in particular
> > > > when PSR2 is enabled. There seem to be no existing workaround
> > > > or patches, which can fix that issue(were expecting some recent
> > > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > > which unfortunately didn't).
> > > > Current idea is that it looks like for some reason the
> > > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > theoretically correct.
> > > > So bump it up a bit by 15%(minimum experimental amount required
> > > > to get it working), if PSR2 is enabled.
> > > > For PSR1 there is no need in this hack, so we limit it only
> > > > to PSR2 and Alderlake.
> > > > 
> > > > v2: - Added comment(Jose Souza)
> > > > - Fixed 15% calculation(Jose Souza)
> > > > 
> > > > Signed-off-by: Stanislav Lisovskiy 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index fda8b701..92d57869983a 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > > intel_crtc_state *crtc_state)
> > > > dev_priv->max_cdclk_freq));
> > > > }
> > > >  
> > > > +
> > > > +   /*
> > > > +* HACK.  We are getting FIFO underruns, in particular
> > > > +* when PSR2 is enabled. There seem to be no existing workaround
> > > > +* or patches as of now.
> > > > +* Current idea is that it looks like for some reason the
> > > > +* DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > +* theoretically correct.
> > > > +* So bump it up a bit by 15%(minimum experimental amount 
> > > > required
> > > > +* to get it working), if PSR2 is enabled.
> > > > +* For PSR1 there is no need in this hack, so we limit it only
> > > > +* to PSR2 and Alderlake.
> > > > +*/
> > > > +   if (IS_ALDERLAKE_P(dev_priv)) {
> > > > +   struct intel_encoder *encoder;
> > > > +
> > > > +   for_each_intel_encoder_with_psr(_priv->drm, 
> > > > encoder) {
> > > > +   struct intel_dp *intel_dp = 
> > > > enc_to_intel_dp(encoder);
> > > > +
> > > > +   if (intel_dp->psr.psr2_enabled) {
> > > > +   min_cdclk = DIV_ROUND_UP(min_cdclk * 
> > > > 115, 100);
> > > > +   break;
> > > > +   }
> > > > +   }
> > > > +   }
> > > > +
> > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > drm_dbg_kms(_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d 
> > > > kHz)\n",
> > > 
> > > Not sure if this will get thru as I'm not subscribed to this list but I
> > > tested the patch below on my X1 Yoga 7 (Intel ADL-P with Step C0
> > > silicon) and it didn't fix some screen tearing issues I'm seeing there
> > > that are PSR2 related
> > > 
> > > I also tried increasing the timeout to *300 to see if that made any
> > > difference and it didn't.
> > > 
> > > Let me know if there's anything else I can try out - I have a couple of
> > > ADL-P machines I can test against and both are seeing screen tearing
> > 
> > Are you getting this screen tearing because of the FIFO underruns?
> > Those should be visible in dmesg. This patch can fix only part of underrun
> > issues caused by PSR2. 
> > If your screen tearing caused by PSR2, but there are no underruns that 
> > patch won't help for sure.
> > 
> Ah - OK, no FIFO underruns that I've noticed in the logs but I was
> hoping the two were connected. I'll keep an eye out for those in the
> meantime.
> 
> I guess I'll just wave a flag and say I'm seeing PSR2 related tearing
> issues. If I disable  PSR2 selective fetch it goes away
> (i915.enable_psr2_sel_fetch=0) - but as that's a different issue to this
> patch thread I don't want to drag the conversation too far sideways.

Do you have a bug for your issue? But before you file it please search in our 
bug tracker if there is another similar issue.

With your description so far it looks like you are affected by this 
https://gitlab.freedesktop.org/drm/intel/-/issues/5077 .
It was already fixed in drm-tip but it will take a while to land on Linus 
master and the on distros kernel.

> 
> Thanks!
> Mark

Re: [Intel-gfx] [RFC 06/19] drm/edid: clean up cea_db_is_*() functions

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:35PM +0200, Jani Nikula wrote:
> Abstract helpers for matching vendor data blocks and extended tags, and
> use them to simplify all the cea_db_is_*() functions.
> 
> Take void pointer as parameter to allow transitional use for both u8 *
> and struct cea_db *.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 113 -
>  1 file changed, 37 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c12c3cbab274..a0a5a7271658 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4196,12 +4196,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
> const u8 *db, u8 len,
>   return modes;
>  }
>  
> -static int
> -cea_db_extended_tag(const u8 *db)
> -{
> - return db[1];
> -}
> -
>  static int
>  cea_revision(const u8 *cea)
>  {
> @@ -4313,6 +4307,22 @@ static const void *cea_db_data(const struct cea_db *db)
>   return db->data;
>  }
>  
> +static bool cea_db_is_extended_tag(const struct cea_db *db, int tag)
> +{
> + return (cea_db_tag(db) == CEA_DB_EXTENDED_TAG &&
> + cea_db_payload_len(db) >= 1 &&
> + db->data[0] == tag);
> +}

nit: not a huge fan of the redundant parens in all of these

> +
> +static bool cea_db_is_vendor(const struct cea_db *db, int vendor_oui)

I'd probably make the tag/oui unsigned.

Reviewed-by: Ville Syrjälä 

> +{
> + const u8 *data = cea_db_data(db);
> +
> + return (cea_db_tag(db) == CEA_DB_VENDOR &&
> + cea_db_payload_len(db) >= 3 &&
> + oui(data[2], data[1], data[0]) == vendor_oui);
> +}
> +
>  static void cea_db_iter_edid_begin(const struct edid *edid, struct 
> cea_db_iter *iter)
>  {
>   memset(iter, 0, sizeof(*iter));
> @@ -4443,79 +4453,44 @@ static void cea_db_iter_end(struct cea_db_iter *iter)
>   memset(iter, 0, sizeof(*iter));
>  }
>  
> -static bool cea_db_is_hdmi_vsdb(const u8 *db)
> +static bool cea_db_is_hdmi_vsdb(const void *db)
>  {
> - if (cea_db_tag(db) != CEA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) < 5)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
> + return (cea_db_is_vendor(db, HDMI_IEEE_OUI) &&
> + cea_db_payload_len(db) >= 5);
>  }
>  
> -static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
> +static bool cea_db_is_hdmi_forum_vsdb(const void *db)
>  {
> - if (cea_db_tag(db) != CEA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) < 7)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
> + return (cea_db_is_vendor(db, HDMI_FORUM_IEEE_OUI) &&
> + cea_db_payload_len(db) >= 7);
>  }
>  
> -static bool cea_db_is_microsoft_vsdb(const u8 *db)
> +static bool cea_db_is_microsoft_vsdb(const void *db)
>  {
> - if (cea_db_tag(db) != CEA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) != 21)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
> + return (cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
> + cea_db_payload_len(db) == 21);
>  }
>  
> -static bool cea_db_is_vcdb(const u8 *db)
> +static bool cea_db_is_vcdb(const void *db)
>  {
> - if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (cea_db_payload_len(db) != 2)
> - return false;
> -
> - if (cea_db_extended_tag(db) != CEA_EXT_DB_VIDEO_CAP)
> - return false;
> -
> - return true;
> + return (cea_db_is_extended_tag(db, CEA_EXT_DB_VIDEO_CAP) &&
> + cea_db_payload_len(db) == 2);
>  }
>  
> -static bool cea_db_is_y420cmdb(const u8 *db)
> +static bool cea_db_is_y420cmdb(const void *db)
>  {
> - if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (!cea_db_payload_len(db))
> - return false;
> -
> - if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_CAP_MAP)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_CAP_MAP);
>  }
>  
> -static bool cea_db_is_y420vdb(const u8 *db)
> +static bool cea_db_is_y420vdb(const void *db)
>  {
> - if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (!cea_db_payload_len(db))
> - return false;
> -
> - if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_DATA)
> - return false;
> + return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_DATA);
> +}
>  
> - return true;
> +static bool cea_db_is_hdmi_hdr_metadata_block(const void *db)
> +{
> + return (cea_db_is_extended_tag(db, CEA_EXT_DB_HDR_STATIC_METADATA) &&
> + cea_db_payload_len(db) >= 3);
>  }
>  
>  #define for_each_cea_db(cea, i, start, end) \
> @@ -4651,20 +4626,6 @@ static void 

Re: [Intel-gfx] [PATCH 2/5] dyndbg: add class_id field and query support

[Jason Baron]

On 3/10/22 23:47, Jim Cromie wrote:
> DRM defines/uses 10 enum drm_debug_category's to create exclusive
> classes of debug messages.  To support this directly in dynamic-debug,
> add the following:
> 
> - struct _ddebug.class_id:4 - 4 bits is enough
> - define _DPRINTK_SITE_UNCLASSED 15 - see below
> 
> and the query support:
> - struct _ddebug_query.class_id
> - ddebug_parse_query  - looks for "class" keyword, then calls..
> - parse_class - accepts uint: 0-15, sets query.class_id and marker
> - vpr_info_dq - displays new field
> - ddebug_proc_show- append column with "cls:%d" if !UNCLASSED
> 
> With the patch, one can enable current/unclassed callsites by:
> 
>   #> echo drm class 15 +p > /proc/dynamic_debug/control
> 

To me, this is hard to read, what the heck is '15'? I have to go look it
up in the control file and it's not descriptive. I think that using
classes/categories makes sense but I'm wondering if it can be a bit more
user friendly? Perhaps, we can pass an array of strings that is indexed
by the class id to each pr_debug() site that wants to use class. So
something like:

enum levels {
LOW,
MEDIUM,
HIGH
};

static const char * const level_to_strings[] = {
[LOW] = "low",
[MEDIUM] = "medium",
[HIGH] = "high",
};

And then you'd have a wrapper macros in your driver:

#define module_foo_pr_debug_class(level, fmt, args...)
pr_debug_class(level, level_to_strings, fmt, args);

Such that call sites look like:

module_foo_pr_debug_class(LOW, fmt, args...);

Such that you're not always passing the strings array around. Now, this
does mean another pointer for struct _ddebug and most wouldn't have it.
Maybe we could just add another linker section for these so as to save
space.

> parse_class() accepts 0 .. _DPRINTK_SITE_UNCLASSED, which allows the
>> control interface to explicitly manipulate unclassed callsites.
> 
> After parsing keywords, ddebug_parse_query() sets .class_id=15, iff it
> wasnt explicitly set.  This allows future classed/categorized
> callsites to be untouched by legacy (class unaware) queries.
> 
> DEFINE_DYNAMIC_DEBUG_METADATA gets _CLS(cls,) suffix and arg, and
> initializes the new .class_id=cls field.  The old name gets the default.
> 
> Then, these _CLS(cls,...) modifications are repeated up through the
> stack of *dynamic_func_call* macros that use the METADATA initializer,
> so as to actually supply the category into it.
> 
> NOTES:
> 
> _DPRINTK_SITE_UNCLASSED: this symbol is used to initialize all
> existing/unclassed pr-debug callsites.  Normally, the default would be
> zero, but DRM_UT_CORE "uses" that value, in the sense that 0 is
> exposed as a bit position in drm.debug.  Using 15 allows identity
> mapping from category to class, avoiding fiddly offsets.
> 
> Default .class_id = 15 means that ``echo +p > control`` no longer
> toggles ALL the callsites, only the unclassed ones.  This was only
> useful for static-branch toggle load testing anyway.
> 

I think that # echo +p > control should continue to work as is, why
should the introduction of classes change that ?

> RFC:
> 
> The new _CLS macro flavor gets a warning from DRM/dri-devel's CI,
> but not from checkpatch (on this subject).
> 
> a8f6c71f283e dyndbg: add class_id field and query support
> -:141: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible 
> side-effects?
> +#define __dynamic_func_call_cls(id, cls, fmt, func, ...) do {\
> + DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\
> + if (DYNAMIC_DEBUG_BRANCH(id))   \
> + func(, ##__VA_ARGS__);   \
>  } while (0)
> 
> I couldn't fix it with a ``typeof(id) _id = id`` construct.  I haven't
> seen the warning myself, on the _CLS extended macro, nor the original.
> 
> CC: Rasmus Villemoes 
> Signed-off-by: Jim Cromie 
> ---
>  .../admin-guide/dynamic-debug-howto.rst   |  7 +++
>  include/linux/dynamic_debug.h | 54 ++-
>  lib/dynamic_debug.c   | 48 ++---
>  3 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst 
> b/Documentation/admin-guide/dynamic-debug-howto.rst
> index a89cfa083155..8ef8d7dcd140 100644
> --- a/Documentation/admin-guide/dynamic-debug-howto.rst
> +++ b/Documentation/admin-guide/dynamic-debug-howto.rst
> @@ -35,6 +35,7 @@ Dynamic debug has even more useful features:
> - line number (including ranges of line numbers)
> - module name
> - format string
> +   - class number:0-15
>  
>   * Provides a debugfs control file: ``/dynamic_debug/control``
> which can be read to display the complete list of known debug
> @@ -143,6 +144,7 @@ against.  Possible keywords are:::
>'module' string |
>'format' string |
>'line' line-range
> +  'class' integer:[0-15]
>  
>line-range ::= lineno 

Re: [Intel-gfx] [PATCH 00/22] drm: Review of mode copies

[Dmitry Baryshkov]

On 22/03/2022 01:37, Ville Syrjälä wrote:

On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:

On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
 wrote:


On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:

   drm: Add drm_mode_init()
   drm/bridge: Use drm_mode_copy()
   drm/imx: Use drm_mode_duplicate()
   drm/panel: Use drm_mode_duplicate()
   drm/vc4: Use drm_mode_copy()

These have been pushed to drm-misc-next.


   drm/amdgpu: Remove pointless on stack mode copies
   drm/amdgpu: Use drm_mode_init() for on-stack modes
   drm/amdgpu: Use drm_mode_copy()

amdgpu ones are reviewed, but I'll leave them for the
AMD folks to push to whichever tree they prefer.


I pulled patches 2, 4, 5 into my tree.


Thanks.


For 3, I'm happy to have it
land via drm-misc with the rest of the mode_init changes if you'd
prefer.


Either way works for me. I don't yet have reviews yet for
the other drivers, so I'll proably hold off for a bit more
at least. And the i915 patch I'll be merging via drm-intel.


   drm/radeon: Use drm_mode_copy()
   drm/gma500: Use drm_mode_copy()
   drm/tilcdc: Use drm_mode_copy()
   drm/i915: Use drm_mode_copy()


Those are now all in.

Which leaves us with these stragglers:

   drm/hisilicon: Use drm_mode_init() for on-stack modes



   drm/msm: Nuke weird on stack mode copy
   drm/msm: Use drm_mode_init() for on-stack modes
   drm/msm: Use drm_mode_copy()


These three patches went beneath my radar for some reason.

I have just sent a replacement for the first patch ([1]). Other two 
patches can be pulled in msm/msm-next (or msm/msm-fixes) during the next 
development cycle if that works for you.


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


   drm/mtk: Use drm_mode_init() for on-stack modes
   drm/rockchip: Use drm_mode_copy()
   drm/sti: Use drm_mode_copy()
   drm: Use drm_mode_init() for on-stack modes
   drm: Use drm_mode_copy()





--
With best wishes
Dmitry

Re: [Intel-gfx] [PATCH 1/5] dyndbg: fix static_branch manipulation

[Jason Baron]

On 3/10/22 23:47, Jim Cromie wrote:
> In 
> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/__;!!GjvTz_vk!HGKKoni4RVdEBgv_V0zPSNSX428bpf02zkCy2WbeQkBdVtp1QJqGX-lJYlRDGg$
>  
> 
> Vincent's patch commented on, and worked around, a bug toggling
> static_branch's, when a 2nd PRINTK-ish flag was added.  The bug
> results in a premature static_branch_disable when the 1st of 2 flags
> was disabled.
> 
> The cited commit computed newflags, but then in the JUMP_LABEL block,
> failed to use that result, instead using just one of the terms in it.
> Using newflags instead made the code work properly.
> 
> This is Vincents test-case, reduced.  It needs the 2nd flag to work
> properly, but it's explanatory here.
> 
> pt_test() {
> echo 5 > /sys/module/dynamic_debug/verbose
> 
> site="module tcp" # just one callsite
> echo " $site =_ " > /proc/dynamic_debug/control # clear it
> 
> # A B ~A ~B
> for flg in +T +p "-T #broke here" -p; do
>   echo " $site $flg " > /proc/dynamic_debug/control
> done;
> 
> # A B ~B ~A
> for flg in +T +p "-p #broke here" -T; do
>   echo " $site $flg " > /proc/dynamic_debug/control
> done
> }
> pt_test
> 
> Fixes: 84da83a6ffc0 dyndbg: combine flags & mask into a struct, simplify with 
> it
> CC: vincent.whitchu...@axis.com
> Signed-off-by: Jim Cromie 
> 
> --
> .drop @stable, no exposed bug.
> ---
>  lib/dynamic_debug.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index dd7f56af9aed..a56c1286ffa4 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -211,10 +211,11 @@ static int ddebug_change(const struct ddebug_query 
> *query,
>   continue;
>  #ifdef CONFIG_JUMP_LABEL
>   if (dp->flags & _DPRINTK_FLAGS_PRINT) {
> - if (!(modifiers->flags & _DPRINTK_FLAGS_PRINT))
> + if (!(newflags & _DPRINTK_FLAGS_PRINT))
>   
> static_branch_disable(>key.dd_key_true);
> - } else if (modifiers->flags & _DPRINTK_FLAGS_PRINT)
> + } else if (newflags & _DPRINTK_FLAGS_PRINT) {
>   static_branch_enable(>key.dd_key_true);
> + }
>  #endif
>   dp->flags = newflags;
>   v4pr_info("changed %s:%d [%s]%s =%s\n",



Hi Jim,

If iiuc this is currently a bug but could be if we add a second 'print' bit
such as for printing to the tracing logs. That said I agree that using 
'newflags'
here makes the code more straightforward/readable. So this one is fine with
me.

Acked-by: Jason Baron 

Thanks,

-Jason

Re: [Intel-gfx] [PATCH 18/22] drm/i915: Use drm_mode_init() for on-stack modes

[Julia Lawall]

On Mon, 21 Mar 2022, Ville Syrjälä wrote:

> On Wed, Mar 16, 2022 at 10:00:06AM +0200, Jani Nikula wrote:
> > On Fri, 18 Feb 2022, Ville Syrjala  wrote:
> > > From: Ville Syrjälä 
> > >
> > > Initialize on-stack modes with drm_mode_init() to guarantee
> > > no stack garbage in the list head, or that we aren't copying
> > > over another mode's list head.
> > >
> > > Based on the following cocci script, with manual fixups:
> > > @decl@
> > > identifier M;
> > > expression E;
> > > @@
> > > - struct drm_display_mode M = E;
> > > + struct drm_display_mode M;
> > >
> > > @@
> > > identifier decl.M;
> > > expression decl.E;
> > > statement S, S1;
> > > @@
> > > struct drm_display_mode M;
> > > ... when != S
> > > + drm_mode_init(, );
> > > +
> > > S1
> > >
> > > @@
> > > expression decl.E;
> > > @@
> > > - &*E
> > > + E
> > >
> > > Signed-off-by: Ville Syrjälä 
> >
> > I wonder if that cocci could be added to scripts/coccinelle or something
> > to detect anyone adding new ones?
>
> Maybe.
>
> Julia & co, would you be open to having drm subsystem specific
> coccinelle scripts? If so where should we put the?
> scripts/coccinelle/drm perhaps?

That would be fine.  It is possible to make a script only apply to a
specific directory, but I think that that is not necessary in this case,
since you mention types that are only relevant to drm code.

julia

[Intel-gfx] [PATCH] drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

[Colin Ian King]

There is a spelling mistake in a gvt_vgpu_err error message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 520a7e1942f3..a01e3a893e24 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -914,7 +914,7 @@ static int update_fdi_rx_iir_status(struct intel_vgpu *vgpu,
else if (FDI_RX_IMR_TO_PIPE(offset) != INVALID_INDEX)
index = FDI_RX_IMR_TO_PIPE(offset);
else {
-   gvt_vgpu_err("Unsupport registers %x\n", offset);
+   gvt_vgpu_err("Unsupported registers %x\n", offset);
return -EINVAL;
}
 
-- 
2.35.1

Re: [Intel-gfx] [PATCH v2] drm: add a check to verify the size alignment

[Christian König]

Am 23.03.22 um 08:34 schrieb Arunpravin Paneer Selvam:

Add a simple check to reject any size not aligned to the
min_page_size.

handle instances when size is not aligned with the min_page_size.
Unigine Heaven has allocation requests for example required pages
are 257 and alignment request is 256. To allocate the left over 1
page, continues the iteration to find the order value which is 0
and when it compares with min_order = 8, triggers the BUG_ON(order
< min_order). To avoid this problem, we added a simple check to
return -EINVAL if size is not aligned to the min_page_size.

v2: Added more details to the commit description

Signed-off-by: Arunpravin Paneer Selvam 
Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..b503c88786b0 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -661,6 +661,9 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (range_overflows(start, size, mm->size))
return -EINVAL;
  
+	if (WARN_ON(!IS_ALIGNED(size, min_page_size)))

+   return -EINVAL;
+


I'm not that happy with the handling here.

See a minimum page size larger than the requested size is perfectly 
valid, it just means that the remaining pages needs to be trimmed.


In other words when the request is to allocate 1 page with an alignment 
of 256 we just need to give the remaining 255 pages back to the allocator.


Regards,
Christian.


/* Actual range allocation */
if (start + size == end)
return __drm_buddy_alloc_range(mm, start, size, blocks);

base-commit: 056d47eaf6ea753fa2e21da31f9cbd8b721bbb7b

Re: [Intel-gfx] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

[Mark Pearson]

Hi,

On 3/21/22 06:49, Stanislav Lisovskiy wrote:
> We are currently getting FIFO underruns, in particular
> when PSR2 is enabled. There seem to be no existing workaround
> or patches, which can fix that issue(were expecting some recent
> selective fetch update and DBuf bw/SAGV fixes to help,
> which unfortunately didn't).
> Current idea is that it looks like for some reason the
> DBuf prefill time isn't enough once we exit PSR2, despite its
> theoretically correct.
> So bump it up a bit by 15%(minimum experimental amount required
> to get it working), if PSR2 is enabled.
> For PSR1 there is no need in this hack, so we limit it only
> to PSR2 and Alderlake.
> 
> v2: - Added comment(Jose Souza)
> - Fixed 15% calculation(Jose Souza)
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index fda8b701..92d57869983a 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct 
> intel_crtc_state *crtc_state)
>   dev_priv->max_cdclk_freq));
>   }
>  
> +
> + /*
> +  * HACK.  We are getting FIFO underruns, in particular
> +  * when PSR2 is enabled. There seem to be no existing workaround
> +  * or patches as of now.
> +  * Current idea is that it looks like for some reason the
> +  * DBuf prefill time isn't enough once we exit PSR2, despite its
> +  * theoretically correct.
> +  * So bump it up a bit by 15%(minimum experimental amount required
> +  * to get it working), if PSR2 is enabled.
> +  * For PSR1 there is no need in this hack, so we limit it only
> +  * to PSR2 and Alderlake.
> +  */
> + if (IS_ALDERLAKE_P(dev_priv)) {
> + struct intel_encoder *encoder;
> +
> + for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (intel_dp->psr.psr2_enabled) {
> + min_cdclk = DIV_ROUND_UP(min_cdclk * 115, 100);
> + break;
> + }
> + }
> + }
> +
>   if (min_cdclk > dev_priv->max_cdclk_freq) {
>   drm_dbg_kms(_priv->drm,
>   "required cdclk (%d kHz) exceeds max (%d kHz)\n",

Not sure if this will get thru as I'm not subscribed to this list but I
tested the patch below on my X1 Yoga 7 (Intel ADL-P with Step C0
silicon) and it didn't fix some screen tearing issues I'm seeing there
that are PSR2 related

I also tried increasing the timeout to *300 to see if that made any
difference and it didn't.

Let me know if there's anything else I can try out - I have a couple of
ADL-P machines I can test against and both are seeing screen tearing

Thanks
Mark

Re: [Intel-gfx] [PATCH 11/22] drm/msm: Use drm_mode_init() for on-stack modes

[Dmitry Baryshkov]

On 18/02/2022 13:03, Ville Syrjala wrote:

From: Ville Syrjälä 

Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(, );
+
S1

@@
expression decl.E;
@@
- &*E
+ E

Cc: Rob Clark 
Cc: Sean Paul 
Cc: Abhinav Kumar 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 


Reviewed-by: Dmitry Baryshkov 


---


--
With best wishes
Dmitry

Re: [Intel-gfx] [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu

[Christian König]

Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:

[SNIP]
@@ -415,48 +409,86 @@ static int amdgpu_vram_mgr_new(struct 
ttm_resource_manager *man,
goto error_fini;
}
  
-	mode = DRM_MM_INSERT_BEST;

+   INIT_LIST_HEAD(>blocks);
+
if (place->flags & TTM_PL_FLAG_TOPDOWN)
-   mode = DRM_MM_INSERT_HIGH;
+   node->flags |= DRM_BUDDY_TOPDOWN_ALLOCATION;
  
-	pages_left = node->base.num_pages;

+   if (place->fpfn || lpfn != man->size >> PAGE_SHIFT)
+   /* Allocate blocks in desired range */
+   node->flags |= DRM_BUDDY_RANGE_ALLOCATION;
  
-	/* Limit maximum size to 2GB due to SG table limitations */

-   pages = min(pages_left, 2UL << (30 - PAGE_SHIFT));
+   BUG_ON(!node->base.num_pages);


Please drop this BUG_ON(). This is not something which prevents further 
data corruption, so the BUG_ON() is not justified.



+   pages_left = node->base.num_pages;
  
  	i = 0;

-   spin_lock(>lock);
while (pages_left) {
-   uint32_t alignment = tbo->page_alignment;
+   if (tbo->page_alignment)
+   min_page_size = tbo->page_alignment << PAGE_SHIFT;
+   else
+   min_page_size = mgr->default_page_size;


The handling here looks extremely awkward to me.

min_page_size should be determined outside of the loop, based on 
default_page_size, alignment and contiguous flag.


Then why do you drop the lock and grab it again inside the loop? And 
what is "i" actually good for?



+
+   /* Limit maximum size to 2GB due to SG table limitations */
+   pages = min(pages_left, 2UL << (30 - PAGE_SHIFT));
  
  		if (pages >= pages_per_node)

-   alignment = pages_per_node;
-
-   r = drm_mm_insert_node_in_range(mm, >mm_nodes[i], pages,
-   alignment, 0, place->fpfn,
-   lpfn, mode);
-   if (unlikely(r)) {
-   if (pages > pages_per_node) {
-   if (is_power_of_2(pages))
-   pages = pages / 2;
-   else
-   pages = rounddown_pow_of_two(pages);
-   continue;
-   }
-   goto error_free;
+   min_page_size = pages_per_node << PAGE_SHIFT;
+
+   if (!is_contiguous && !IS_ALIGNED(pages, min_page_size >> 
PAGE_SHIFT))
+   is_contiguous = 1;
+
+   if (is_contiguous) {
+   pages = roundup_pow_of_two(pages);
+   min_page_size = pages << PAGE_SHIFT;
+
+   if (pages > lpfn)
+   lpfn = pages;
}
  
-		vis_usage += amdgpu_vram_mgr_vis_size(adev, >mm_nodes[i]);

-   amdgpu_vram_mgr_virt_start(>base, >mm_nodes[i]);
-   pages_left -= pages;
+   BUG_ON(min_page_size < mm->chunk_size);
+
+   mutex_lock(>lock);
+   r = drm_buddy_alloc_blocks(mm, (u64)place->fpfn << PAGE_SHIFT,
+  (u64)lpfn << PAGE_SHIFT,
+  (u64)pages << PAGE_SHIFT,
+  min_page_size,
+  >blocks,
+  node->flags);
+   mutex_unlock(>lock);
+   if (unlikely(r))
+   goto error_free_blocks;
+
++i;
  
  		if (pages > pages_left)

-   pages = pages_left;
+   pages_left = 0;
+   else
+   pages_left -= pages;
}
-   spin_unlock(>lock);
  
-	if (i == 1)

+   /* Free unused pages for contiguous allocation */
+   if (is_contiguous) {


Well that looks really odd, why is trimming not part of 
drm_buddy_alloc_blocks() ?



+   u64 actual_size = (u64)node->base.num_pages << PAGE_SHIFT;
+
+   mutex_lock(>lock);
+   drm_buddy_block_trim(mm,
+actual_size,
+>blocks);


Why is the drm_buddy_block_trim() function given all the blocks and not 
just the last one?


Regards,
Christian.


+   mutex_unlock(>lock);
+   }
+
+   list_for_each_entry(block, >blocks, link)
+   vis_usage += amdgpu_vram_mgr_vis_size(adev, block);
+
+   block = amdgpu_vram_mgr_first_block(>blocks);
+   if (!block) {
+   r = -EINVAL;
+   goto error_fini;
+   }
+
+   node->base.start = amdgpu_node_start(block) >> PAGE_SHIFT;
+
+   if (i == 1 && is_contiguous)
node->base.placement |= TTM_PL_FLAG_CONTIGUOUS;
  
  	if 

Re: [Intel-gfx] [PATCH 2/5] dyndbg: add class_id field and query support

[Jason Baron]

On 3/11/22 20:06, jim.cro...@gmail.com wrote:
> On Fri, Mar 11, 2022 at 12:06 PM Jason Baron  wrote:
>>
>>
>>
>> On 3/10/22 23:47, Jim Cromie wrote:
>>> DRM defines/uses 10 enum drm_debug_category's to create exclusive
>>> classes of debug messages.  To support this directly in dynamic-debug,
>>> add the following:
>>>
>>> - struct _ddebug.class_id:4 - 4 bits is enough
>>> - define _DPRINTK_SITE_UNCLASSED 15 - see below
>>>
>>> and the query support:
>>> - struct _ddebug_query.class_id
>>> - ddebug_parse_query  - looks for "class" keyword, then calls..
>>> - parse_class - accepts uint: 0-15, sets query.class_id and marker
>>> - vpr_info_dq - displays new field
>>> - ddebug_proc_show- append column with "cls:%d" if !UNCLASSED
>>>
>>> With the patch, one can enable current/unclassed callsites by:
>>>
>>>   #> echo drm class 15 +p > /proc/dynamic_debug/control
>>>
>>
>> To me, this is hard to read, what the heck is '15'? I have to go look it
>> up in the control file and it's not descriptive. I think that using
>> classes/categories makes sense but I'm wondering if it can be a bit more
>> user friendly? Perhaps, we can pass an array of strings that is indexed
>> by the class id to each pr_debug() site that wants to use class. So
>> something like:
>>
> 
> Im not at all averse to nice names, but as something added on.
> 
> 1st, the interface to make friendlier is DRM's
> 
> echo 0x04 > /sys/module/drm/parameters/debug   # which category ?
> 
> parm:   debug:Enable debug output, where each bit enables a
> debug category.
> Bit 0 (0x01)  will enable CORE messages (drm core code)
> Bit 1 (0x02)  will enable DRIVER messages (drm controller code)
> Bit 2 (0x04)  will enable KMS messages (modesetting code)
> 
> echo DRM_UT_DRIVER,DRM_UT_KMS > /sys/module/drm/parameters/debug   #
> now its pretty clear
> 
> If that works, its cuz DEFINE_DYNAMIC_DEBUG_CLASSBITS()
> plucks class symbols out of its __VA_ARGS__, and #stringifes them.
> So that macro could then build the 1-per-module static constant string array
> and (only) the callbacks would be able to use it.
> 
> from there, it shouldnt be hard to ref that from the module's ddebug_table,
> so parse_query could validate class args against the module given (or
> fail if none given)
> 
> Speaking strictly, theres a gap:
>echo module * class DRM_UT_KMS +p > control
> is nonsense for * other than drm + drivers,
> but its fair/safe to just disallow wildcards on modname for this purpose.
> 
> it does however imply that module foo must exist for FOO_CAT_1 to be usable.
> thats not currently the case:
> bash-5.1# echo module foo +p > /proc/dynamic_debug/control
> [   15.403749] dyndbg: read 14 bytes from userspace
> [   15.405413] dyndbg: query 0: "module foo +p" mod:*
> [   15.406486] dyndbg: split into words: "module" "foo" "+p"
> [   15.407070] dyndbg: op='+'
> [   15.407388] dyndbg: flags=0x1
> [   15.407809] dyndbg: *flagsp=0x1 *maskp=0x
> [   15.408300] dyndbg: parsed: func="" file="" module="foo" format=""
> lineno=0-0 class=15
> [   15.409151] dyndbg: no matches for query
> [   15.409591] dyndbg: no-match: func="" file="" module="foo"
> format="" lineno=0-0 class=15
> [   15.410524] dyndbg: processed 1 queries, with 0 matches, 0 errs
> bash-5.1#
> 
> ISTM we can keep that "0 errs" response for that case, but still reject this:
> 
>echo module foo class FOO_NOT_HERE +p > /proc/dynamic_debug/control
> 
> 

Ok, yeah so I guess I'm thinking about the 'class' more as global namespace,
so that for example, it could span modules, or be specific to certain modules.
I'm also thinking of it as a 'string' which is maybe hierarchical, so that it's
clear what sub-system, or sub-sub-system it belongs to. So for DRM for example,
it could be a string like "DRM:CORE". The index num I think is still helpful for
implementation so we don't have to store a pointer size, but I don't think it's
really exposed (except perhaps in module params b/c drm is doing that already?).


>> enum levels {
>> LOW,
>> MEDIUM,
>> HIGH
>> };
> 
> I want to steer clear of "level" anything,
> since 2>1 implies non independence of the categories
> 
> 

Agreed, that was a bad example on my part.

I've put together a rough patch on top of your series, to make my thinking
hopefully clear. I also think that the module param callback thing could be
implemented in this 'global' space with the 0-14 low numbers, by adding
some sort of offset into the table. IE you would add the low number +
the offset to get the 'string' to add to the ddebug query. I commented it
out in my patch below b/c I didn't implement that part.

Thoughts?


diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 664bb83778d2..b0bc1b536d54 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -8,6 +8,14 @@

 #include 

+enum ddebug_categories {
+FOO_BAR = 0,
+DRM_A = 1,
+DRM_B = 2,
+DRM_C = 

[Intel-gfx] [PATCH 22/23] drm/i915: drop bo->moving dependency

[Christian König]

That should now be handled by the common dma_resv framework.

Signed-off-by: Christian König 
Cc: intel-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 29 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object.h   |  5 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 15 +-
 drivers/gpu/drm/i915/i915_vma.c  |  9 +-
 4 files changed, 19 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index d87b508b59b1..fd240435ffef 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -742,18 +742,19 @@ static const struct drm_gem_object_funcs 
i915_gem_object_funcs = {
 /**
  * i915_gem_object_get_moving_fence - Get the object's moving fence if any
  * @obj: The object whose moving fence to get.
+ * @fence: The resulting fence
  *
  * A non-signaled moving fence means that there is an async operation
  * pending on the object that needs to be waited on before setting up
  * any GPU- or CPU PTEs to the object's pages.
  *
- * Return: A refcounted pointer to the object's moving fence if any,
- * NULL otherwise.
+ * Return: Negative error code or 0 for success.
  */
-struct dma_fence *
-i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj)
+int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj,
+struct dma_fence **fence)
 {
-   return dma_fence_get(i915_gem_to_ttm(obj)->moving);
+   return dma_resv_get_singleton(obj->base.resv, DMA_RESV_USAGE_KERNEL,
+ fence);
 }
 
 /**
@@ -771,23 +772,9 @@ i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj)
 int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr)
 {
-   struct dma_fence *fence = i915_gem_to_ttm(obj)->moving;
-   int ret;
-
assert_object_held(obj);
-   if (!fence)
-   return 0;
-
-   ret = dma_fence_wait(fence, intr);
-   if (ret)
-   return ret;
-
-   if (fence->error)
-   return fence->error;
-
-   i915_gem_to_ttm(obj)->moving = NULL;
-   dma_fence_put(fence);
-   return 0;
+   return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+intr, MAX_SCHEDULE_TIMEOUT);
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index f66d46882ea7..be57af8bfb31 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -521,9 +521,8 @@ i915_gem_object_finish_access(struct drm_i915_gem_object 
*obj)
i915_gem_object_unpin_pages(obj);
 }
 
-struct dma_fence *
-i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj);
-
+int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj,
+struct dma_fence **fence);
 int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index e4a232e22f9d..4d5d0cd64f23 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -452,19 +452,6 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
 }
 
-static int
-prev_deps(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
- struct i915_deps *deps)
-{
-   int ret;
-
-   ret = i915_deps_add_dependency(deps, bo->moving, ctx);
-   if (!ret)
-   ret = i915_deps_add_resv(deps, bo->base.resv, ctx);
-
-   return ret;
-}
-
 /**
  * i915_ttm_move - The TTM move callback used by i915.
  * @bo: The buffer object.
@@ -519,7 +506,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
struct i915_deps deps;
 
i915_deps_init(, GFP_KERNEL | __GFP_NORETRY | 
__GFP_NOWARN);
-   ret = prev_deps(bo, ctx, );
+   ret = i915_deps_add_resv(, bo->base.resv, ctx);
if (ret) {
i915_refct_sgt_put(dst_rsgt);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 52fd6705a518..8737159f4706 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1247,10 +1247,17 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
if (err)
return err;
 
+   if (vma->obj) {
+   err = i915_gem_object_get_moving_fence(vma->obj, );
+   if (err)
+   return err;
+   } else {
+   moving = NULL;
+   }
+
if (flags & PIN_GLOBAL)
wakeref = 

Re: [Intel-gfx] [External] Re: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

[Mark Pearson]

Thanks Stanislav,

On 3/22/22 10:18, Lisovskiy, Stanislav wrote:
> On Tue, Mar 22, 2022 at 09:55:35AM -0400, Mark Pearson wrote:
>> Hi,
>>
>> On 3/21/22 06:49, Stanislav Lisovskiy wrote:
>>> We are currently getting FIFO underruns, in particular
>>> when PSR2 is enabled. There seem to be no existing workaround
>>> or patches, which can fix that issue(were expecting some recent
>>> selective fetch update and DBuf bw/SAGV fixes to help,
>>> which unfortunately didn't).
>>> Current idea is that it looks like for some reason the
>>> DBuf prefill time isn't enough once we exit PSR2, despite its
>>> theoretically correct.
>>> So bump it up a bit by 15%(minimum experimental amount required
>>> to get it working), if PSR2 is enabled.
>>> For PSR1 there is no need in this hack, so we limit it only
>>> to PSR2 and Alderlake.
>>>
>>> v2: - Added comment(Jose Souza)
>>> - Fixed 15% calculation(Jose Souza)
>>>
>>> Signed-off-by: Stanislav Lisovskiy 
>>> ---
>>>  drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
>>>  1 file changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> index fda8b701..92d57869983a 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>>> @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct 
>>> intel_crtc_state *crtc_state)
>>> dev_priv->max_cdclk_freq));
>>> }
>>>  
>>> +
>>> +   /*
>>> +* HACK.  We are getting FIFO underruns, in particular
>>> +* when PSR2 is enabled. There seem to be no existing workaround
>>> +* or patches as of now.
>>> +* Current idea is that it looks like for some reason the
>>> +* DBuf prefill time isn't enough once we exit PSR2, despite its
>>> +* theoretically correct.
>>> +* So bump it up a bit by 15%(minimum experimental amount required
>>> +* to get it working), if PSR2 is enabled.
>>> +* For PSR1 there is no need in this hack, so we limit it only
>>> +* to PSR2 and Alderlake.
>>> +*/
>>> +   if (IS_ALDERLAKE_P(dev_priv)) {
>>> +   struct intel_encoder *encoder;
>>> +
>>> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
>>> +   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>>> +
>>> +   if (intel_dp->psr.psr2_enabled) {
>>> +   min_cdclk = DIV_ROUND_UP(min_cdclk * 115, 100);
>>> +   break;
>>> +   }
>>> +   }
>>> +   }
>>> +
>>> if (min_cdclk > dev_priv->max_cdclk_freq) {
>>> drm_dbg_kms(_priv->drm,
>>> "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>>
>> Not sure if this will get thru as I'm not subscribed to this list but I
>> tested the patch below on my X1 Yoga 7 (Intel ADL-P with Step C0
>> silicon) and it didn't fix some screen tearing issues I'm seeing there
>> that are PSR2 related
>>
>> I also tried increasing the timeout to *300 to see if that made any
>> difference and it didn't.
>>
>> Let me know if there's anything else I can try out - I have a couple of
>> ADL-P machines I can test against and both are seeing screen tearing
> 
> Are you getting this screen tearing because of the FIFO underruns?
> Those should be visible in dmesg. This patch can fix only part of underrun
> issues caused by PSR2. 
> If your screen tearing caused by PSR2, but there are no underruns that 
> patch won't help for sure.
> 
Ah - OK, no FIFO underruns that I've noticed in the logs but I was
hoping the two were connected. I'll keep an eye out for those in the
meantime.

I guess I'll just wave a flag and say I'm seeing PSR2 related tearing
issues. If I disable  PSR2 selective fetch it goes away
(i915.enable_psr2_sel_fetch=0) - but as that's a different issue to this
patch thread I don't want to drag the conversation too far sideways.

Thanks!
Mark

Re: [Intel-gfx] [PATCH 12/22] drm/msm: Use drm_mode_copy()

[Dmitry Baryshkov]

On 18/02/2022 13:03, Ville Syrjala wrote:

From: Ville Syrjälä 

struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.

Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.

Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.

@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}

@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, )
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)

@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(, )
|
- memcpy(, E, S)
+ drm_mode_copy(, E)
)

@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode

Cc: Rob Clark 
Cc: Sean Paul 
Cc: Abhinav Kumar 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 


Reviewed-by: Dmitry Baryshkov 


---



--
With best wishes
Dmitry

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/display: Remove MBUS joining invalid TODOs

[Caz Yokoyama]

On Tue, Mar 22, 2022 at 2:45 PM José Roberto de Souza 
wrote:

> skl_compute_ddb() will for a modeset in all pipes when MBUS joining
> changes between states, so all pipes will be disabled, have all
> MBUS related registers updated and then each pipe enabled.
>
I am not clear what you want to say here. Could you rephrase above 3 lines?


> So no vblank syncronization is necessary and here droping those TODOs.
>

  dropping
-caz


>
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index cf290bb704221..9ccf0f062862c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6066,7 +6066,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
> return ret;
>
> if (old_dbuf_state->joined_mbus !=
> new_dbuf_state->joined_mbus) {
> -   /* TODO: Implement vblank synchronized MBUS
> joining changes */
> ret = intel_modeset_all_pipes(state);
> if (ret)
> return ret;
> @@ -8195,10 +8194,6 @@ static void update_mbus_pre_enable(struct
> intel_atomic_state *state)
> if (!HAS_MBUS_JOINING(dev_priv))
> return;
>
> -   /*
> -* TODO: Implement vblank synchronized MBUS joining changes.
> -* Must be properly coordinated with dbuf reprogramming.
> -*/
> if (dbuf_state->joined_mbus) {
> mbus_ctl = MBUS_HASHING_MODE_1x4 | MBUS_JOIN |
> MBUS_JOIN_PIPE_SELECT_NONE;
> --
> 2.35.1
>
>

-- 
-caz, caz at caztech dot com, 503-six one zero - five six nine nine(m)

Re: [Intel-gfx] [PATCH v2] drm: Fix a infinite loop condition when order becomes 0

[Christian König]

Am 16.03.22 um 12:31 schrieb Matthew Auld:

On 16/03/2022 06:34, Arunpravin Paneer Selvam wrote:

handle a situation in the condition order-- == min_order,
when order = 0 and min_order = 0, leading to order = -1,
it now won't exit the loop. To avoid this problem,
added a order check in the same condition, (i.e)
when order is 0, we return -ENOSPC

v2: use full name in email program and in Signed-off tag

Signed-off-by: Arunpravin Paneer Selvam 


---
  drivers/gpu/drm/drm_buddy.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
  if (!IS_ERR(block))
  break;
  -    if (order-- == min_order) {
+    if (!order || order-- == min_order) {


It shouldn't be possible to enter an infinite loop here, without first 
tripping up the BUG_ON(order < min_order) further up, and for that, as 
we discussed here[1], it sounded like the conclusion was to rather add 
a simple check somewhere in drm_buddy_alloc_blocks() to reject any 
size not aligned to the min_page_size?


Sounds good to me as well.

And just to make it clear: I don't review the functionality here, that's 
up to you guys.


Just giving my Ack on things like style and pushing the end result 
upstream as necessary.


So let me know when you have settled on a solution.

Regards,
Christian.



[1] https://patchwork.freedesktop.org/patch/477414/?series=101108=1


  err = -ENOSPC;
  goto err_free;
  }

base-commit: 3bd60c0259406c5ca3ce5cdc958fb910ad4b8175

Re: [Intel-gfx] [PATCH 10/22] drm/msm: Nuke weird on stack mode copy

[Dmitry Baryshkov]

On 18/02/2022 13:03, Ville Syrjala wrote:

From: Ville Syrjälä 

This on stack middle man mode looks entirely pointless.
Just duplicate the original mode directly.

Cc: Rob Clark 
Cc: Sean Paul 
Cc: Abhinav Kumar 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 


I took a glance at the surrounding piece of code.
The dp_connector_get_modes() calls dp_display_get_modes() in attempt to 
fill the dp_mode argument. However the dp_display_get_modes() function 
just calls dp_panel_get_modes(), which does not touch dp_mode argument 
since the commit ab205927592b ("drm/msm/dp: remove mode hard-coding in 
case of DP CTS") dating September 2020. I think we can drop this piece 
of code completely.



---
  drivers/gpu/drm/msm/dp/dp_drm.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index d4d360d19eba..09188d02aa1e 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -56,7 +56,7 @@ static int dp_connector_get_modes(struct drm_connector 
*connector)
int rc = 0;
struct msm_dp *dp;
struct dp_display_mode *dp_mode = NULL;
-   struct drm_display_mode *m, drm_mode;
+   struct drm_display_mode *m;
  
  	if (!connector)

return 0;
@@ -82,13 +82,11 @@ static int dp_connector_get_modes(struct drm_connector 
*connector)
return rc;
}
if (dp_mode->drm_mode.clock) { /* valid DP mode */
-   memset(_mode, 0x0, sizeof(drm_mode));
-   drm_mode_copy(_mode, _mode->drm_mode);
-   m = drm_mode_duplicate(connector->dev, _mode);
+   m = drm_mode_duplicate(connector->dev, 
_mode->drm_mode);
if (!m) {
DRM_ERROR("failed to add mode %ux%u\n",
-  drm_mode.hdisplay,
-  drm_mode.vdisplay);
+ dp_mode->drm_mode.hdisplay,
+ dp_mode->drm_mode.vdisplay);
kfree(dp_mode);
return 0;
}



--
With best wishes
Dmitry

Re: [Intel-gfx] [RFC 03/19] drm/edid: clean up CEA data block tag definitions

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:32PM +0200, Jani Nikula wrote:
> Add prefixed names, group, sort, add references.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 59 +-
>  1 file changed, 32 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b96906774433..6c188539493e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3329,15 +3329,20 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>   return closure.modes;
>  }
>  
> -#define AUDIO_BLOCK  0x01
> -#define VIDEO_BLOCK 0x02
> -#define VENDOR_BLOCK0x03
> -#define SPEAKER_BLOCK0x04
> -#define HDR_STATIC_METADATA_BLOCK0x6
> -#define USE_EXTENDED_TAG 0x07
> -#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> -#define EXT_VIDEO_DATA_BLOCK_420 0x0E
> -#define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> +/* CEA-861-F Table 44 CEA Data Block Tag Codes */

Table 55 in CTA-861-G, if we want to use a more recent reference.
Though IIRC someone did say CTA-861-H might already be out as well.

> +#define CEA_DB_AUDIO 1
> +#define CEA_DB_VIDEO 2
> +#define CEA_DB_VENDOR3
> +#define CEA_DB_SPEAKER   4
> +#define CEA_DB_EXTENDED_TAG  7
> +
> +/* CEA-861-F Table 46 CEA Data Block Tag Codes */

Table 57 in CTA-861-G.

Reviewed-by: Ville Syrjälä 

> +#define CEA_EXT_DB_VIDEO_CAP 0
> +#define CEA_EXT_DB_VENDOR1
> +#define CEA_EXT_DB_HDR_STATIC_METADATA   6 /* CEA-861.3 2005 */
> +#define CEA_EXT_DB_420_VIDEO_DATA14
> +#define CEA_EXT_DB_420_VIDEO_CAP_MAP 15
> +
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -4220,7 +4225,7 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
>  
>  static bool cea_db_is_hdmi_vsdb(const u8 *db)
>  {
> - if (cea_db_tag(db) != VENDOR_BLOCK)
> + if (cea_db_tag(db) != CEA_DB_VENDOR)
>   return false;
>  
>   if (cea_db_payload_len(db) < 5)
> @@ -4231,7 +4236,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
>  
>  static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
>  {
> - if (cea_db_tag(db) != VENDOR_BLOCK)
> + if (cea_db_tag(db) != CEA_DB_VENDOR)
>   return false;
>  
>   if (cea_db_payload_len(db) < 7)
> @@ -4242,7 +4247,7 @@ static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
>  
>  static bool cea_db_is_microsoft_vsdb(const u8 *db)
>  {
> - if (cea_db_tag(db) != VENDOR_BLOCK)
> + if (cea_db_tag(db) != CEA_DB_VENDOR)
>   return false;
>  
>   if (cea_db_payload_len(db) != 21)
> @@ -4253,13 +4258,13 @@ static bool cea_db_is_microsoft_vsdb(const u8 *db)
>  
>  static bool cea_db_is_vcdb(const u8 *db)
>  {
> - if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
>   return false;
>  
>   if (cea_db_payload_len(db) != 2)
>   return false;
>  
> - if (cea_db_extended_tag(db) != EXT_VIDEO_CAPABILITY_BLOCK)
> + if (cea_db_extended_tag(db) != CEA_EXT_DB_VIDEO_CAP)
>   return false;
>  
>   return true;
> @@ -4267,13 +4272,13 @@ static bool cea_db_is_vcdb(const u8 *db)
>  
>  static bool cea_db_is_y420cmdb(const u8 *db)
>  {
> - if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
>   return false;
>  
>   if (!cea_db_payload_len(db))
>   return false;
>  
> - if (cea_db_extended_tag(db) != EXT_VIDEO_CAP_BLOCK_Y420CMDB)
> + if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_CAP_MAP)
>   return false;
>  
>   return true;
> @@ -4281,13 +4286,13 @@ static bool cea_db_is_y420cmdb(const u8 *db)
>  
>  static bool cea_db_is_y420vdb(const u8 *db)
>  {
> - if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
>   return false;
>  
>   if (!cea_db_payload_len(db))
>   return false;
>  
> - if (cea_db_extended_tag(db) != EXT_VIDEO_DATA_BLOCK_420)
> + if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_DATA)
>   return false;
>  
>   return true;
> @@ -4354,7 +4359,7 @@ add_cea_modes(struct drm_connector *connector, struct 
> edid *edid)
>   db = [i];
>   dbl = cea_db_payload_len(db);
>  
> - if (cea_db_tag(db) == VIDEO_BLOCK) {
> + if (cea_db_tag(db) == CEA_DB_VIDEO) {
>   video = db + 1;
>   video_len = dbl;
>   modes += do_cea_modes(connector, video, dbl);
> @@ -4428,10 +4433,10 @@ static void fixup_detailed_cea_mode_clock(struct 
> drm_display_mode *mode)
>  
>  static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
>  {
> - if (cea_db_tag(db) != USE_EXTENDED_TAG)

Re: [Intel-gfx] [RFC 02/19] drm: use drm_edid_extension_block_count() and drm_edid_size()

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:31PM +0200, Jani Nikula wrote:
> Use the block count and size helpers in all drm core code.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_connector.c |  2 +-
>  drivers/gpu/drm/drm_debugfs.c   |  3 +--
>  drivers/gpu/drm/drm_edid.c  | 14 +++---
>  3 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 76a8c707c34b..cfed43e61380 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2138,7 +2138,7 @@ int drm_connector_update_edid_property(struct 
> drm_connector *connector,
>   return 0;
>  
>   if (edid)
> - size = EDID_LENGTH * (1 + edid->extensions);
> + size = drm_edid_size(edid);
>  
>   /* Set the display info, using edid if available, otherwise
>* resetting the values to defaults. This duplicates the work
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 7f1b82dbaebb..a832ef6b33fe 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -362,8 +362,7 @@ static ssize_t edid_write(struct file *file, const char 
> __user *ubuf,
>   if (len == 5 && !strncmp(buf, "reset", 5)) {
>   connector->override_edid = false;
>   ret = drm_connector_update_edid_property(connector, NULL);
> - } else if (len < EDID_LENGTH ||
> -EDID_LENGTH * (1 + edid->extensions) > len)
> + } else if (len < EDID_LENGTH || drm_edid_size(edid) > len)
>   ret = -EINVAL;
>   else {
>   connector->override_edid = false;
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index f4b49693e666..b96906774433 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1643,8 +1643,8 @@ bool drm_edid_are_equal(const struct edid *edid1, const 
> struct edid *edid2)
>   return false;
>  
>   if (edid1) {
> - edid1_len = EDID_LENGTH * (1 + edid1->extensions);
> - edid2_len = EDID_LENGTH * (1 + edid2->extensions);
> + edid1_len = drm_edid_size(edid1);
> + edid2_len = drm_edid_size(edid2);
>  
>   if (edid1_len != edid2_len)
>   return false;
> @@ -1770,7 +1770,7 @@ bool drm_edid_is_valid(struct edid *edid)
>   if (!edid)
>   return false;
>  
> - for (i = 0; i <= edid->extensions; i++)
> + for (i = 0; i <= drm_edid_extension_block_count(edid); i++)
>   if (!drm_edid_block_valid(raw + i * EDID_LENGTH, i, true, NULL))

Maybe we should also have drm_edid_block_count(), drm_edid_block_data(),
drm_edid_extension_block_data() etc.?

Reviewed-by: Ville Syrjälä 

>   return false;
>  
> @@ -2224,7 +2224,7 @@ EXPORT_SYMBOL(drm_edid_size);
>   */
>  struct edid *drm_edid_duplicate(const struct edid *edid)
>  {
> - return kmemdup(edid, (edid->extensions + 1) * EDID_LENGTH, GFP_KERNEL);
> + return kmemdup(edid, drm_edid_size(edid), GFP_KERNEL);
>  }
>  EXPORT_SYMBOL(drm_edid_duplicate);
>  
> @@ -3353,17 +3353,17 @@ const u8 *drm_find_edid_extension(const struct edid 
> *edid,
>   int i;
>  
>   /* No EDID or EDID extensions */
> - if (edid == NULL || edid->extensions == 0)
> + if (edid == NULL || drm_edid_extension_block_count(edid) == 0)
>   return NULL;
>  
>   /* Find CEA extension */
> - for (i = *ext_index; i < edid->extensions; i++) {
> + for (i = *ext_index; i < drm_edid_extension_block_count(edid); i++) {
>   edid_ext = (const u8 *)edid + EDID_LENGTH * (i + 1);
>   if (edid_ext[0] == ext_id)
>   break;
>   }
>  
> - if (i >= edid->extensions)
> + if (i >= drm_edid_extension_block_count(edid))
>   return NULL;
>  
>   *ext_index = i + 1;
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

[Daniel Stone]

On Wed, 23 Mar 2022 at 15:14, Alex Deucher  wrote:
> On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone  wrote:
> > That's not what anyone's saying here ...
> >
> > No-one's demanding AMD publish RTL, or internal design docs, or
> > hardware specs, or URLs to JIRA tickets no-one can access.
> >
> > This is a large and invasive commit with pretty big ramifications;
> > containing exactly two lines of commit message, one of which just
> > duplicates the subject.
> >
> > It cannot be the case that it's completely impossible to provide any
> > justification, background, or details, about this commit being made.
> > Unless, of course, it's to fix a non-public security issue, that is
> > reasonable justification for eliding some of the details. But then
> > again, 'huge change which is very deliberately opaque' is a really
> > good way to draw a lot of attention to the commit, and it would be
> > better to provide more detail about the change to help it slip under
> > the radar.
> >
> > If dri-devel@ isn't allowed to inquire about patches which are posted,
> > then CCing the list is just a façade; might as well just do it all
> > internally and periodically dump out pull requests.
>
> I think we are in agreement. I think the withheld information
> Christian was referring to was on another thread with Christian and
> Paul discussing a workaround for a hardware bug:
> https://www.spinics.net/lists/amd-gfx/msg75908.html

Right, that definitely seems like some crossed wires. I don't see
anything wrong with that commit at all: the commit message and a
comment notes that there is a hardware issue preventing Raven from
being able to do TMZ+GTT, and the code does the very straightforward
and obvious thing to ensure that on VCN 1.0, any TMZ buffer must be
VRAM-placed.

This one, on the other hand, is much less clear ...

Cheers,
Daniel

Re: [Intel-gfx] [RFC 01/19] drm/edid: add drm_edid_extension_block_count() and drm_edid_size()

[Ville Syrjälä]

On Tue, Mar 22, 2022 at 11:40:30PM +0200, Jani Nikula wrote:
> Add abstractions for getting the number of EDID extension blocks and the
> total EDID size in bytes.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 18 ++
>  include/drm/drm_edid.h |  2 ++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 561f53831e29..f4b49693e666 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2198,6 +2198,24 @@ struct edid *drm_get_edid_switcheroo(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_get_edid_switcheroo);
>  
> +/**
> + * drm_edid_extension_block_count - get the number of EDID extension blocks
> + */
> +u8 drm_edid_extension_block_count(const struct edid *edid)

It's just a number, so could be 'int' IMO.

Reviewed-by: Ville Syrjälä 

> +{
> + return edid->extensions;
> +}
> +EXPORT_SYMBOL(drm_edid_extension_block_count);
> +
> +/**
> + * drm_edid_size - get the EDID size in bytes
> + */
> +size_t drm_edid_size(const struct edid *edid)
> +{
> + return (drm_edid_extension_block_count(edid) + 1) * EDID_LENGTH;
> +}
> +EXPORT_SYMBOL(drm_edid_size);
> +
>  /**
>   * drm_edid_duplicate - duplicate an EDID and the extensions
>   * @edid: EDID to duplicate
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 144c495b99c4..7a19daa00c0c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -564,6 +564,8 @@ struct edid *drm_get_edid(struct drm_connector *connector,
>  u32 drm_edid_get_panel_id(struct i2c_adapter *adapter);
>  struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
>struct i2c_adapter *adapter);
> +u8 drm_edid_extension_block_count(const struct edid *edid);
> +size_t drm_edid_size(const struct edid *edid);
>  struct edid *drm_edid_duplicate(const struct edid *edid);
>  int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
>  int drm_add_override_edid_modes(struct drm_connector *connector);
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/edid: fix CEA extension byte #3 parsing

[Jani Nikula]

On Wed, 23 Mar 2022, Ville Syrjälä  wrote:
> On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
>> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
>> Block does not. Don't interpret bogus data for color formats.
>
> I think what we might want eventually is a cleaner split between
> the CTA data blocks vs. the rest of the EDID CTA ext block. Only
> the former is relevant for DisplayID.

Well, I just abstracted it all away in the CEA data block iteration
series [1].

It'll be possible to add a different iteration initializer depending on
what you want to iterate and where.

BR,
Jani.


>
> But for a bugfix we want to keep it simple.
>
> Reviewed-by: Ville Syrjälä 
>
>> 
>> For most displays it's probably an unlikely scenario you'd have a CTA
>> DisplayID Data Block without a CEA extension, but they do exist.
>> 
>> Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
>> Cc:  # v4.15
>> Cc: Shawn C Lee 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>> 
>> ---
>> 
>> commit e28ad544f462 was merged in v5.3, but it has Cc: stable for v4.15.
>> 
>> This is also fixed in my CEA data block iteration series [1], but we'll
>> want the simple fix for stable first.
>> 
>> Hum, CTA is formerly CEA, I and the code seem to use both, should we use
>> only one or the other?
>
> And before CEA it was called EIA (IIRC). Dunno if we also use that name
> somewhere.
>
> If someone cares enough I guess we could rename everything to "cta".
>
>> 
>> [1] https://patchwork.freedesktop.org/series/101659/
>> ---
>>  drivers/gpu/drm/drm_edid.c | 12 
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 561f53831e29..ccf7031a6797 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -5187,10 +5187,14 @@ static void drm_parse_cea_ext(struct drm_connector 
>> *connector,
>>  
>>  /* The existence of a CEA block should imply RGB support */
>>  info->color_formats = DRM_COLOR_FORMAT_RGB444;
>> -if (edid_ext[3] & EDID_CEA_YCRCB444)
>> -info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> -if (edid_ext[3] & EDID_CEA_YCRCB422)
>> -info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> +
>> +/* CTA DisplayID Data Block does not have byte #3 */
>> +if (edid_ext[0] == CEA_EXT) {
>> +if (edid_ext[3] & EDID_CEA_YCRCB444)
>> +info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> +if (edid_ext[3] & EDID_CEA_YCRCB422)
>> +info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> +}
>>  
>>  if (cea_db_offsets(edid_ext, , ))
>>  return;
>> -- 
>> 2.30.2

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

[Alex Deucher]

On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone  wrote:
>
> Hi Alex,
>
> On Wed, 23 Mar 2022 at 14:42, Alex Deucher  wrote:
> > On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone  wrote:
> > > On Wed, 23 Mar 2022 at 08:19, Christian König  
> > > wrote:
> > > > Well the key point is it's not about you to judge that.
> > > >
> > > > If you want to complain about the commit message then come to me with
> > > > that and don't request information which isn't supposed to be publicly
> > > > available.
> > > >
> > > > So to make it clear: The information is intentionally hold back and not
> > > > made public.
> > >
> > > In that case, the code isn't suitable to be merged into upstream
> > > trees; it can be resubmitted when it can be explained.
> >
> > So you are saying we need to publish the problematic RTL to be able to
> > fix a HW bug in the kernel?  That seems a little unreasonable.  Also,
> > links to internal documents or bug trackers don't provide much value
> > to the community since they can't access them.  In general, adding
> > internal documents to commit messages is frowned on.
>
> That's not what anyone's saying here ...
>
> No-one's demanding AMD publish RTL, or internal design docs, or
> hardware specs, or URLs to JIRA tickets no-one can access.
>
> This is a large and invasive commit with pretty big ramifications;
> containing exactly two lines of commit message, one of which just
> duplicates the subject.
>
> It cannot be the case that it's completely impossible to provide any
> justification, background, or details, about this commit being made.
> Unless, of course, it's to fix a non-public security issue, that is
> reasonable justification for eliding some of the details. But then
> again, 'huge change which is very deliberately opaque' is a really
> good way to draw a lot of attention to the commit, and it would be
> better to provide more detail about the change to help it slip under
> the radar.
>
> If dri-devel@ isn't allowed to inquire about patches which are posted,
> then CCing the list is just a façade; might as well just do it all
> internally and periodically dump out pull requests.

I think we are in agreement. I think the withheld information
Christian was referring to was on another thread with Christian and
Paul discussing a workaround for a hardware bug:
https://www.spinics.net/lists/amd-gfx/msg75908.html

Alex


Alex

Re: [Intel-gfx] [PATCH 00/22] drm: Review of mode copies

[Ville Syrjälä]

On Wed, Mar 23, 2022 at 01:39:44PM +0300, Dmitry Baryshkov wrote:
> On 22/03/2022 01:37, Ville Syrjälä wrote:
> > On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
> >> On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
> >>  wrote:
> >>>
> >>> On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
> drm: Add drm_mode_init()
> drm/bridge: Use drm_mode_copy()
> drm/imx: Use drm_mode_duplicate()
> drm/panel: Use drm_mode_duplicate()
> drm/vc4: Use drm_mode_copy()
> >>> These have been pushed to drm-misc-next.
> >>>
> drm/amdgpu: Remove pointless on stack mode copies
> drm/amdgpu: Use drm_mode_init() for on-stack modes
> drm/amdgpu: Use drm_mode_copy()
> >>> amdgpu ones are reviewed, but I'll leave them for the
> >>> AMD folks to push to whichever tree they prefer.
> >>
> >> I pulled patches 2, 4, 5 into my tree.
> > 
> > Thanks.
> > 
> >> For 3, I'm happy to have it
> >> land via drm-misc with the rest of the mode_init changes if you'd
> >> prefer.
> > 
> > Either way works for me. I don't yet have reviews yet for
> > the other drivers, so I'll proably hold off for a bit more
> > at least. And the i915 patch I'll be merging via drm-intel.
> > 
> drm/radeon: Use drm_mode_copy()
> drm/gma500: Use drm_mode_copy()
> drm/tilcdc: Use drm_mode_copy()
> drm/i915: Use drm_mode_copy()
> > 
> > Those are now all in.
> > 
> > Which leaves us with these stragglers:
> drm/hisilicon: Use drm_mode_init() for on-stack modes
> 
> drm/msm: Nuke weird on stack mode copy
> drm/msm: Use drm_mode_init() for on-stack modes
> drm/msm: Use drm_mode_copy()
> 
> These three patches went beneath my radar for some reason.
> 
> I have just sent a replacement for the first patch ([1]). Other two 
> patches can be pulled in msm/msm-next (or msm/msm-fixes) during the next 
> development cycle if that works for you.

That'll do fine for me. Thanks.

> 
> [1] https://patchwork.freedesktop.org/series/101682/
> 
> drm/mtk: Use drm_mode_init() for on-stack modes
> drm/rockchip: Use drm_mode_copy()
> drm/sti: Use drm_mode_copy()
> drm: Use drm_mode_init() for on-stack modes
> drm: Use drm_mode_copy()
> > 
> 
> 
> -- 
> With best wishes
> Dmitry

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

[Juha-Pekka Heikkila]

On 22.3.2022 17.53, Matthew Auld wrote:

On Tue, 22 Mar 2022 at 12:06, Juha-Pekka Heikkila
 wrote:


On 22.3.2022 12.45, Matthew Auld wrote:

On Mon, 21 Mar 2022 at 18:36, Juha-Pekka Heikkila
 wrote:


On 21.3.2022 14.29, Matthew Auld wrote:

On Fri, 18 Mar 2022 at 09:22, Juha-Pekka Heikkila
 wrote:


On 17.3.2022 13.55, Matthew Auld wrote:

On Wed, 16 Mar 2022 at 22:23, Juha-Pekka Heikkila
 wrote:


Add fallback smem allocation for dpt if stolen memory
allocation failed.

Signed-off-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index fb0e7e79e0cd..c8b66433d4db 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -10,6 +10,7 @@
 #include "intel_display_types.h"
 #include "intel_dpt.h"
 #include "intel_fb.h"
+#include "gem/i915_gem_internal.h"


Nit: these should be kept sorted



 struct i915_dpt {
struct i915_address_space vm;
@@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
void __iomem *iomem;
struct i915_gem_ww_ctx ww;
int err;
+   u64 pin_flags = 0;
+
+   if (i915_gem_object_is_stolen(dpt->obj))
+   pin_flags |= PIN_MAPPABLE; /* for i915_vma_pin_iomap(stolen) */

wakeref = intel_runtime_pm_get(>runtime_pm);
atomic_inc(>gpu_error.pending_fb_pin);
@@ -138,7 +143,7 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
continue;

vma = i915_gem_object_ggtt_pin_ww(dpt->obj, , NULL, 0, 
4096,
- HAS_LMEM(i915) ? 0 : 
PIN_MAPPABLE);
+ pin_flags);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
continue;
@@ -248,10 +253,15 @@ intel_dpt_create(struct intel_framebuffer *fb)

size = round_up(size * sizeof(gen8_pte_t), I915_GTT_PAGE_SIZE);

-   if (HAS_LMEM(i915))
-   dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
-   else
+   dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(dpt_obj) && i915_ggtt_has_aperture(to_gt(i915)->ggtt))
dpt_obj = i915_gem_object_create_stolen(i915, size);
+   if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
+   drm_dbg_kms(>drm, "fb: [FB:%d] Allocating dpt from 
smem\n",
+   fb->base.base.id);
+
+   dpt_obj = i915_gem_object_create_internal(i915, size);


Looks like we are missing some prerequisite patch to be able to
directly map such memory in vma_pin_iomap?


For these functions I'm more like a consumer, I was following
suggestions from Chris on this. Is there something extra that should be
considered in this regard when use it like this?


AFAICT this will trigger the WARN_ON() in vma_pin_iomap() if we
fallback to create_internal(), since the object is now not lmem and is
also not map_and_fenceable(i.e PIN_MAPPABLE).


This shouldn't affect case when dpt allocation from lmem failed, it is
expected to go to "return ERR_CAST(dpt_obj);" below these comments. On
situation when allocating lmem and stolen failed on next "if" I added
!HAS_LMEM(i915) to handle situation with lmem. Though, when I was
originally trying this patch without limiting lmem case I remember with
dg2 I got black screen but I don't remember seeing WARN_ON() in logs.



The other issue is that we need some way of CPU mapping this type of
object, like with calling i915_gem_object_pin_map() inside
vma_pin_iomap(). It looks like there is an internal patch that tries
to handle both issues, so I guess we need to also bring that patch
upstream as a prerequisite to this?


I have above in intel_dpt_pin(..) that "pin_flags |= PIN_MAPPABLE" when
handling stolen memory. I suspect patch you are referring to is this
same patch I wrote, here just adjusted for upstreaming. This patch was
earlier tried by Lucas and Manasi to be working with adlp and apparently
cases with virtual machine this make it possible to have tiled
framebuffers. Without this patch those special cases will get -e2big
when creating tiled fb and no stolen memory available.


When the GGTT pin eventually ends up returning some vma that is not
within the ggtt->mappable_end, then we will start hitting the above
issues, starting with the WARN_ON. If you use PIN_HIGH here for the
non-stolen case, it should highlight the issue more reliably I think.



You mean once there's no space left in stolen there would be WARN_ON()?
This is case which was earlier tested by Lucas and Manasi on adlp to be
working correctly, this was on top of drm-tip. Also on internal testing
you can see 

Re: [Intel-gfx] [PATCH] drm/edid: fix CEA extension byte #3 parsing

[Ville Syrjälä]

On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
> Block does not. Don't interpret bogus data for color formats.

I think what we might want eventually is a cleaner split between
the CTA data blocks vs. the rest of the EDID CTA ext block. Only
the former is relevant for DisplayID.

But for a bugfix we want to keep it simple.

Reviewed-by: Ville Syrjälä 

> 
> For most displays it's probably an unlikely scenario you'd have a CTA
> DisplayID Data Block without a CEA extension, but they do exist.
> 
> Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
> Cc:  # v4.15
> Cc: Shawn C Lee 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> commit e28ad544f462 was merged in v5.3, but it has Cc: stable for v4.15.
> 
> This is also fixed in my CEA data block iteration series [1], but we'll
> want the simple fix for stable first.
> 
> Hum, CTA is formerly CEA, I and the code seem to use both, should we use
> only one or the other?

And before CEA it was called EIA (IIRC). Dunno if we also use that name
somewhere.

If someone cares enough I guess we could rename everything to "cta".

> 
> [1] https://patchwork.freedesktop.org/series/101659/
> ---
>  drivers/gpu/drm/drm_edid.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 561f53831e29..ccf7031a6797 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5187,10 +5187,14 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>  
>   /* The existence of a CEA block should imply RGB support */
>   info->color_formats = DRM_COLOR_FORMAT_RGB444;
> - if (edid_ext[3] & EDID_CEA_YCRCB444)
> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
> - if (edid_ext[3] & EDID_CEA_YCRCB422)
> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
> +
> + /* CTA DisplayID Data Block does not have byte #3 */
> + if (edid_ext[0] == CEA_EXT) {
> + if (edid_ext[3] & EDID_CEA_YCRCB444)
> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
> + if (edid_ext[3] & EDID_CEA_YCRCB422)
> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
> + }
>  
>   if (cea_db_offsets(edid_ext, , ))
>   return;
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

[Daniel Stone]

Hi Alex,

On Wed, 23 Mar 2022 at 14:42, Alex Deucher  wrote:
> On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone  wrote:
> > On Wed, 23 Mar 2022 at 08:19, Christian König  
> > wrote:
> > > Well the key point is it's not about you to judge that.
> > >
> > > If you want to complain about the commit message then come to me with
> > > that and don't request information which isn't supposed to be publicly
> > > available.
> > >
> > > So to make it clear: The information is intentionally hold back and not
> > > made public.
> >
> > In that case, the code isn't suitable to be merged into upstream
> > trees; it can be resubmitted when it can be explained.
>
> So you are saying we need to publish the problematic RTL to be able to
> fix a HW bug in the kernel?  That seems a little unreasonable.  Also,
> links to internal documents or bug trackers don't provide much value
> to the community since they can't access them.  In general, adding
> internal documents to commit messages is frowned on.

That's not what anyone's saying here ...

No-one's demanding AMD publish RTL, or internal design docs, or
hardware specs, or URLs to JIRA tickets no-one can access.

This is a large and invasive commit with pretty big ramifications;
containing exactly two lines of commit message, one of which just
duplicates the subject.

It cannot be the case that it's completely impossible to provide any
justification, background, or details, about this commit being made.
Unless, of course, it's to fix a non-public security issue, that is
reasonable justification for eliding some of the details. But then
again, 'huge change which is very deliberately opaque' is a really
good way to draw a lot of attention to the commit, and it would be
better to provide more detail about the change to help it slip under
the radar.

If dri-devel@ isn't allowed to inquire about patches which are posted,
then CCing the list is just a façade; might as well just do it all
internally and periodically dump out pull requests.

Cheers,
Daniel

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Decouple engine->sanitize callback on removing the status page

[Patchwork]

== Series Details ==

Series: drm/i915: Decouple engine->sanitize callback on removing the status page
URL   : https://patchwork.freedesktop.org/series/101679/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22656_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@many-contexts:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([i915#5163])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_ctx_persiste...@many-contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb6/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb8/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_capture@pi@vcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][4] ([i915#4547])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-skl2/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-glk1/igt@gem_exec_fair@basic-p...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-tglb2/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-skl1/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-apl4/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-skl9/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][15] ([i915#4270])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-tglb6/igt@gem_...@fail-invalid-protected-context.html

  * igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#4270]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb3/igt@gem_...@verify-pxp-stale-buf-optout-execution.html

  * igt@gem_render_copy@y-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb3/igt@gem_render_c...@y-tiled-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109290])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb1/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-iclb: NOTRUN -> [DMESG-WARN][19] ([i915#4991])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-iclb8/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][20] ([i915#2724])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22656/shard-snb2/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen9_exec_parse@allowed-single:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#2856]) +2 similar issues
   [21]: 

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

[Alex Deucher]

On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone  wrote:
>
> On Wed, 23 Mar 2022 at 08:19, Christian König  
> wrote:
> > Am 23.03.22 um 09:10 schrieb Paul Menzel:
> > > Sorry, I disagree. The motivation needs to be part of the commit
> > > message. For example see recent discussion on the LWN article
> > > *Donenfeld: Random number generator enhancements for Linux 5.17 and
> > > 5.18* [1].
> > >
> > > How much the commit message should be extended, I do not know, but the
> > > current state is insufficient (too terse).
> >
> > Well the key point is it's not about you to judge that.
> >
> > If you want to complain about the commit message then come to me with
> > that and don't request information which isn't supposed to be publicly
> > available.
> >
> > So to make it clear: The information is intentionally hold back and not
> > made public.
>
> In that case, the code isn't suitable to be merged into upstream
> trees; it can be resubmitted when it can be explained.

So you are saying we need to publish the problematic RTL to be able to
fix a HW bug in the kernel?  That seems a little unreasonable.  Also,
links to internal documents or bug trackers don't provide much value
to the community since they can't access them.  In general, adding
internal documents to commit messages is frowned on.

Alex

Re: [Intel-gfx] [v8 3/5] drm/edid: read HF-EEODB ext block

[Ville Syrjälä]

On Wed, Mar 23, 2022 at 12:11:50PM +0200, Jani Nikula wrote:
> On Thu, 17 Mar 2022, Lee Shawn C  wrote:
> > According to HDMI 2.1 spec.
> >
> > "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> > is utilized by Sink Devices to provide an alternate method to
> > indicate an EDID Extension Block count larger than 1, while
> > avoiding the need to present a VESA Block Map in the first
> > E-EDID Extension Block."
> >
> > It is a mandatory for HDMI 2.1 protocol compliance as well.
> > This patch help to know how many HF_EEODB blocks report by sink
> > and read allo HF_EEODB blocks back.
> 
> It still just boggles my mind that they've implemented something like
> this. They cite avoiding the EDID Block Map as the rationale... but it's
> been optional since E-EDID structure v1.4, published in 2006. 15+ years
> ago.
> 
> Can anyone tell me a sane reason for this? What does it provide that
> E-EDID 1.4 does not? Do they want to use E-EDID v1.3 with this? Why?

Looks to be pretty much the same approach as the DPCD extended
receiver cap mess we already have to deal with.

So I presume this is a hack to avoid breaking some garbage source
devices that explode when they see too many extension blocks,
or something along those lines.

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✗ Fi.CI.IGT: failure for Remove check for ComboPHY I/O voltage for DP source rate (rev5)

[Patchwork]

== Series Details ==

Series: Remove check for ComboPHY I/O voltage for DP source rate (rev5)
URL   : https://patchwork.freedesktop.org/series/96293/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11398_full -> Patchwork_22655_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22655_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22655_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 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-kbl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-kbl1/igt@gem_exec_whis...@basic-fds-forked-all.html

  * igt@gem_exec_whisper@basic-fds-priority-all:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-skl1/igt@gem_exec_whis...@basic-fds-priority-all.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-skl6/igt@gem_exec_whis...@basic-fds-priority-all.html

  * igt@perf@enable-disable:
- shard-skl:  [PASS][4] -> [FAIL][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-skl2/igt@p...@enable-disable.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-skl10/igt@p...@enable-disable.html

  
 Suppressed 

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

  * igt@gem_workarounds@suspend-resume-context:
- {shard-rkl}:[PASS][6] -> [INCOMPLETE][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-rkl-1/igt@gem_workarou...@suspend-resume-context.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-rkl-5/igt@gem_workarou...@suspend-resume-context.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-iclb5/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][10] -> [INCOMPLETE][11] ([i915#4547])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-skl2/igt@gem_exec_capture@p...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-skl9/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2846])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271]) +45 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-tglb: NOTRUN -> [SKIP][19] ([i915#4613])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-tglb1/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22655/shard-apl7/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> 

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

[Daniel Stone]

On Wed, 23 Mar 2022 at 08:19, Christian König  wrote:
> Am 23.03.22 um 09:10 schrieb Paul Menzel:
> > Sorry, I disagree. The motivation needs to be part of the commit
> > message. For example see recent discussion on the LWN article
> > *Donenfeld: Random number generator enhancements for Linux 5.17 and
> > 5.18* [1].
> >
> > How much the commit message should be extended, I do not know, but the
> > current state is insufficient (too terse).
>
> Well the key point is it's not about you to judge that.
>
> If you want to complain about the commit message then come to me with
> that and don't request information which isn't supposed to be publicly
> available.
>
> So to make it clear: The information is intentionally hold back and not
> made public.

In that case, the code isn't suitable to be merged into upstream
trees; it can be resubmitted when it can be explained.

Cheers,
Daniel

Re: [Intel-gfx] [PATCH] drm/edid: filter DisplayID v2.0 CTA block in audio detection

[Lee, Shawn C]

On Wednesday, March 23, 2022 6:40 PM, Jani  wrote :
>On Wed, 23 Mar 2022, "Lee, Shawn C"  wrote:
>> On Wednesday, March 23, 2022 6:04 PM, Nikula, Jani  
>> wrote :
>>>On Mon, 21 Mar 2022, Cooper Chiou  wrote:
 In DisplayID v2.0 CTS data block 0x81 case, there is no any audio 
 information definition, but drm_detect_monitor_audio didn't filter 
 it so that it caused eDP dummy audio card be detected improperly.

 We observed this issue on some AUO/BOE eDP panel with DID v2.0 CTA 
 block, and fix issue by adding filter for edid_ext[0]=DATA_BLOCK_CTA 
 case.
>>>
>>>Out of curiosity, what does the CTA DisplayID Data Block have for Data Block 
>>>revision?
>>>
>>>I haven't found any mention anywhere that it should have any correspondence 
>>>to the CEA *extension* revision number, which is supposed to be 1..3, and 
>>>really only 3 for about a decade now.
>>>
>>>Both the DisplayID v1.3 and v2.0 specs only mention revision 0.
>>>
>>>BR,
>>>Jani.
>>>
>>
>> We don't get many issues in EDID with DisplayID structure. In this case, the 
>> revision number is "0" as well.
>> As you mentioned, DisplayID v1.3 and v2.0 spec define the block revision 
>> value is always 0. Do you think it would cause any problem?
>
>A lot of places in the EDID parser expect CEA revision >= 3. This isn't true 
>for DisplayID data blocks, so we end up skipping a bunch of stuff if there's 
>no CEA extension and only a DisplayID block.
>
>I'm fixing this in my series.
>

Thanks for the information! Just like you said, block revision ID is always 
zero in DisplayID block.
Do you think we have to make sure revision ID is "0" instead of the other value?

Best regards,
Shawn

>
>BR,
>Jani.
>
>>
>> Best regards,
>> Shawn
>>

 Cc: Jani Nikula 
 Cc: Shawn C Lee 

 Signed-off-by: Cooper Chiou 
 ---
  drivers/gpu/drm/drm_edid.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c 
 index f5f5de362ff2..6c9ae4b130bd 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -4845,7 +4845,7 @@ bool drm_detect_monitor_audio(struct edid *edid)
  int start_offset, end_offset;

  edid_ext = drm_find_cea_extension(edid);
 -if (!edid_ext)
 +if (!edid_ext || (edid_ext[0] == DATA_BLOCK_CTA))
  goto end;

  has_audio = ((edid_ext[3] & EDID_BASIC_AUDIO) != 0);
>>>
>>>--
>>>Jani Nikula, Intel Open Source Graphics Center
>>>
>
>--
>Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v13 00/13] Add GuC Error Capture Support

[Tvrtko Ursulin]

Hi,

On 21/03/2022 16:45, Alan Previn wrote:

This series:
   1. Enables support of GuC to report error-state-capture
  using a list of MMIO registers the driver registers
  and GuC will dump, log and notify right before a GuC
  triggered engine-reset event.
   2. Updates the ADS blob creation to register said lists
  of global, engine class and engine instance registers
  with GuC.
   3. Defines tables of register lists that are global or
  engine class or engine instance in scope.
   4. Updates usage and buffer-state data for the regions
  of the shared GuC log-buffer to accomdate both
  the existing relay logging of general debug logs
  along with the new error state capture usage.
   5. Using a pool of preallocated memory, provide ability
  to extract and format the GuC reported register-capture
  data into chunks consistent with existing i915 error-
  state collection flows and structures.
   6. Connects the i915_gpu_coredump reporting function
  to the GuC error capture module to print all GuC
  error state capture dumps that is reported.


Story is finished with this series and we have everything on feature 
parity? Intel_error_decode handles it fine?


Would you have an example error capture at hand, I am curious how it looks?

Regards,

Tvrtko



This is the 13th rev of this series where the first 3 revs
are RFC

Prior receipts of rvb's:
   - Patch #2, #3, #4, #5, #10, #11, #12, #13 have received
 R-v-b's from Umesh Nerlige Ramappa 
   - Patch #1, #6, #7, #8, #9 has received an R-v-b from Matthew Brost
 . NOTE: some of these came in on the
 trybot series. https://patchwork.freedesktop.org/series/100831/

Changes from prior revs:
   v13:- Fixing register list definition styling as per Jani's request.
   v12:- Re-sending it because previous revs only got to intel-gfx,
 and only cover letter was in dri-devel. Also rebased again.
   v11:- Rebase again on latest drm-tip to fix merge error.
   v10:- Rebase on latest drm-tip again. Fix a number of checkpatch
 warnings and an error Reported-by: kernel test robot .
   v9: - Rebase on latest drm-tip to solve CI merge-build error.
   v8: - Fix a bug found by CI in rev7: Create a cached ADS
 capture list for null-header like the other lists.
   - Fixed a bug on the ggtt offset calculation in the
 ADS population loop. Thanks to Matt Brost.
   - Change the storage uses for initial allocation and
 caching of the ADS register lists so we only store
 a regular pointer instead of file handle.
   - Multiple improvements on code styling, variable names,
 comments and code reduction from Umesh suggestions
 across multiple patches.

   v7: - Rebased on lastest drm_tip that has the ADS now using
 shmem based ads_blob_write utilities. Stress test
 was performed with this patch included to fix a
 legacy bug:
 https://patchwork.freedesktop.org/series/100768/

   v6: - In patch #1, ADS reg-list population, we now alloc
 regular memory to create the lists and cache them for
 simpler and faster use by GuC ADS module at init,
 suspend-resume and reset cycles. This was in response
 to review comments from Lucas De Marchi that also
 wanted to ensure the GuC ADS module owns the final
 copying into the ADS phyical memory.
   - Thanks to Jani Nikula for pointing out that patch #2
 and #3 should ensure static tables as constant and
 dynamic lists should be allocated and cached but
 attached to the GT level for the case of multiple
 cards with different fusings for steered registers.
 These are addressed now along with multiple code
 style fixups (thanks to review comment from Umesh)
 and splitting the steered register list generation
 as a seperate patch.
   - The extraction functionality, Patch #10 and #11 (was
 patch #7), has fixed all of Umesh's review comments
 related to the code styling. Additionally, it was
 discovered during stress tests that the extraction
 function could be called by the ct processing thread
 at the same time as the start of a GT reset event.
 Thus, a redesign was done whereby the linked list of
 processed capture-output-nodes are allocated up
 front and reused throughout the driver's life to
 ensure no memory locks are taken during extraction.
   - For patch #6 (now 7, 8 and 9), updates to
 intel_guc_log was split into smaller chunks and the
 log_state structure was returned back to inside of
 the intel_guc_log struct as opposed to the
 intel_guc struct in prior rev. This is in response
 to review comments by Matt Brost.
   - #Patch 13 (previously #10) is mostly identical but
 addresses all of the code styling comments reviews
 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: fix CEA extension byte #3 parsing

[Patchwork]

== Series Details ==

Series: drm/edid: fix CEA extension byte #3 parsing
URL   : https://patchwork.freedesktop.org/series/101680/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11398 -> Patchwork_22657


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 42)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-kbl-8809g bat-rpls-1 bat-jsl-1 
  Missing(8): shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan fi-ctg-p8600 
fi-pnv-d510 shard-rkl fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][4] ([fdo#109271]) +54 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-kbl-8809g/igt@i915_pm_...@basic-rte.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_11398/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#5341])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@gt_timelines:
- {bat-rpls-2}:   [DMESG-WARN][11] ([i915#4391]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/bat-rpls-2/igt@i915_selftest@live@gt_timelines.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][13] ([i915#5338]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][15] ([i915#3576]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [DMESG-WARN][17] ([i915#295] / [i915#5341]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][19] ([i915#295]) -> [PASS][20] +10 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11398/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22657/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  
  {name}: This element is suppressed. This means 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/edid: fix CEA extension byte #3 parsing

[Patchwork]

== Series Details ==

Series: drm/edid: fix CEA extension byte #3 parsing
URL   : https://patchwork.freedesktop.org/series/101680/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not 
found
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' 
not found

[Intel-gfx] ✓ Fi.CI.IGT: success for Improve on resume time with VT-d enabled

[Patchwork]

== Series Details ==

Series: Improve on resume time with VT-d enabled
URL   : https://patchwork.freedesktop.org/series/101676/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11397_full -> Patchwork_22654_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_balancer@full-pulse:
- {shard-rkl}:[PASS][1] -> [DMESG-WARN][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-rkl-1/igt@gem_exec_balan...@full-pulse.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-rkl-5/igt@gem_exec_balan...@full-pulse.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][3] ([i915#4991])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-skl4/igt@gem_cre...@create-massive.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-apl2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-glk4/igt@gem_exec_fair@basic-p...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-glk3/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-iclb7/igt@gem_exec_fair@basic-p...@vecs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-iclb8/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-skl2/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-tglb: NOTRUN -> [SKIP][13] ([i915#3323])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-tglb8/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@unsync-unmap-after-close:
- shard-tglb: NOTRUN -> [SKIP][14] ([i915#3297])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-tglb8/igt@gem_userptr_bl...@unsync-unmap-after-close.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-glk:  [PASS][15] -> [SKIP][16] ([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-glk7/igt@i915_susp...@fence-restore-tiled2untiled.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-glk9/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#5286])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-tglb7/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180.html

  * igt@kms_big_fb@linear-64bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111614])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-tglb7/igt@kms_big...@linear-64bpp-rotate-90.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-glk:  [PASS][19] -> [DMESG-WARN][20] ([i915#118])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-glk1/igt@kms_big...@x-tiled-32bpp-rotate-180.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22654/shard-glk6/igt@kms_big...@x-tiled-32bpp-rotate-180.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][21] ([i915#3743]) +1 similar issue
   [21]: