✓ Fi.CI.BAT: success for drm/i915/display: update pll values in sync with Bspec for MTL (rev2)
== Series Details ==
Series: drm/i915/display: update pll values in sync with Bspec for MTL (rev2)
URL : https://patchwork.freedesktop.org/series/129878/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14268 -> Patchwork_129878v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/index.html
Participating hosts (38 -> 35)
--
Missing(3): bat-arls-2 fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_129878v2 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-cfl-8109u: [FAIL][1] ([i915#8293]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/fi-cfl-8109u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/fi-cfl-8109u/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-cfl-8109u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#4613]) +3 other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@verify-random:
- fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#3282])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@gem_tiled_pread_basic.html
* igt@i915_pm_rps@basic-api:
- bat-adlm-1: NOTRUN -> [SKIP][7] ([i915#6621])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@i915_pm_...@basic-api.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- bat-adlm-1: NOTRUN -> [SKIP][8] ([i915#9875] / [i915#9900]) +16
other tests skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_flip@basic-plain-flip:
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#3637]) +3 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@kms_f...@basic-plain-flip.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-adlm-1: NOTRUN -> [SKIP][10] ([fdo#109285])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- bat-adlm-1: NOTRUN -> [SKIP][11] ([i915#1849] / [i915#4342])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#9197])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc.html
* igt@kms_pm_backlight@basic-brightness:
- fi-cfl-8109u: NOTRUN -> [SKIP][13] ([fdo#109271]) +7 other tests
skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html
- bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#5354])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@kms_pm_backli...@basic-brightness.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#3555])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-flip:
- bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#3708] / [i915#9900])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@prime_v...@basic-fence-flip.html
* igt@prime_vgem@basic-write:
- bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#3708]) +2 other tests skip
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@prime_v...@basic-write.html
Possible fixes
* igt@gem_exec_parallel@engines@fds:
- bat-adlm-1: [INCOMPLETE][18] ([i915#10264]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/bat-adlm-1/igt@gem_exec_parallel@engi...@fds.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/bat-adlm-1/igt@gem_exec_parallel@engi...@fds.html
{name}: This element is suppressed. This means it is ignored
RE: [PATCH] drm/i915/display: update pll values in sync with Bspec for MTL
> -Original Message-
> From: Intel-gfx On Behalf Of Ravi
> Kumar Vodapalli
> Sent: Wednesday, February 14, 2024 9:07 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Vivekanandan, Balasubramani
> ;
> De Marchi, Lucas ; Taylor, Clinton A
> ; Kalvala, Haridhar
> ; Sripada, Radhakrishna
> ; Atwood, Matthew S
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH] drm/i915/display: update pll values in sync with Bspec for
> MTL
>
> DP/eDP and HDMI C20 PHY PLL values were updated for MTL platform
>
Looks valid update to the pll tables.
Reviewed-by: Mika Kahola
> Signed-off-by: Ravi Kumar Vodapalli
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 32 ++--
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 288a00e083c8..64e0f820a789 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -848,10 +848,10 @@ static const struct intel_c20pll_state mtl_c20_dp_hbr3
> = { static const struct intel_c20pll_state
> mtl_c20_dp_uhbr10 = {
> .clock = 100, /* 10 Gbps */
> .tx = { 0xbe21, /* tx cfg0 */
> - 0x4800, /* tx cfg1 */
> + 0xe800, /* tx cfg1 */
> 0x, /* tx cfg2 */
> },
> - .cmn = {0x0500, /* cmn cfg0*/
> + .cmn = {0x0700, /* cmn cfg0*/
> 0x0005, /* cmn cfg1 */
> 0x, /* cmn cfg2 */
> 0x, /* cmn cfg3 */
> @@ -1641,7 +1641,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_594
> = { static const struct intel_c20pll_state
> mtl_c20_hdmi_300 = {
> .clock = 300,
> .tx = { 0xbe98, /* tx cfg0 */
> - 0x9800, /* tx cfg1 */
> + 0x8800, /* tx cfg1 */
> 0x, /* tx cfg2 */
> },
> .cmn = { 0x0500, /* cmn cfg0*/
> @@ -1649,8 +1649,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_300
> = {
> 0x, /* cmn cfg2 */
> 0x, /* cmn cfg3 */
> },
> - .mpllb = { 0x209c, /* mpllb cfg0 */
> -0x7d10, /* mpllb cfg1 */
> + .mpllb = { 0x309c, /* mpllb cfg0 */
> +0x2110, /* mpllb cfg1 */
> 0xca06, /* mpllb cfg2 */
> 0xbe40, /* mpllb cfg3 */
> 0x, /* mpllb cfg4 */
> @@ -1666,7 +1666,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_300
> = { static const struct intel_c20pll_state
> mtl_c20_hdmi_600 = {
> .clock = 600,
> .tx = { 0xbe98, /* tx cfg0 */
> - 0x9800, /* tx cfg1 */
> + 0x8800, /* tx cfg1 */
> 0x, /* tx cfg2 */
> },
> .cmn = { 0x0500, /* cmn cfg0*/
> @@ -1674,8 +1674,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_600
> = {
> 0x, /* cmn cfg2 */
> 0x, /* cmn cfg3 */
> },
> - .mpllb = { 0x009c, /* mpllb cfg0 */
> -0x7d08, /* mpllb cfg1 */
> + .mpllb = { 0x109c, /* mpllb cfg0 */
> +0x2108, /* mpllb cfg1 */
> 0xca06, /* mpllb cfg2 */
> 0xbe40, /* mpllb cfg3 */
> 0x, /* mpllb cfg4 */
> @@ -1691,7 +1691,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_600
> = { static const struct intel_c20pll_state
> mtl_c20_hdmi_800 = {
> .clock = 800,
> .tx = { 0xbe98, /* tx cfg0 */
> - 0x9800, /* tx cfg1 */
> + 0x8800, /* tx cfg1 */
> 0x, /* tx cfg2 */
> },
> .cmn = { 0x0500, /* cmn cfg0*/
> @@ -1699,8 +1699,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_800
> = {
> 0x, /* cmn cfg2 */
> 0x, /* cmn cfg3 */
> },
> - .mpllb = { 0x00d0, /* mpllb cfg0 */
> -0x7d08, /* mpllb cfg1 */
> + .mpllb = { 0x10d0, /* mpllb cfg0 */
> +0x2108, /* mpllb cfg1 */
> 0x4a06, /* mpllb cfg2 */
> 0xbe40, /* mpllb cfg3 */
> 0x, /* mpllb cfg4 */
> @@ -1716,7 +1716,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_800
> = { static const struct intel_c20pll_state
> mtl_c20_hdmi_1000 = {
> .clock = 1000,
> .tx = { 0xbe98, /* tx cfg0 */
> - 0x9800, /* tx cfg1 */
> + 0x8800, /* tx cfg1 */
> 0x, /* tx cfg2 */
> },
> .cmn = { 0x0500, /* cmn cfg0*/
> @@ -1725,7 +1725,7 @@ static const struct intel_c20pll_state
> mtl_c20_hdmi_1000 = {
> 0x, /* cmn cfg3 */
> },
> .mpllb = { 0x1104, /* mpllb cfg0 */
> -0x7d08, /* mpllb cfg1 */
> +
✓ Fi.CI.IGT: success for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details == Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling code URL : https://patchwork.freedesktop.org/series/129874/ State : success == Summary == CI Bug Log - changes from CI_DRM_14268_full -> Patchwork_129874v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 8) -- No changes in participating hosts New tests - New tests have been introduced between CI_DRM_14268_full and Patchwork_129874v1_full: ### New IGT tests (1) ### * igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_contiguous: - Statuses : 7 pass(s) - Exec time: [0.0, 0.00] s Known issues Here are the changes found in Patchwork_129874v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-rkl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24]) -> ([PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [FAIL][30], [FAIL][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48]) ([i915#8293]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-6/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-6/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-5/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-5/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-5/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-5/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-4/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-4/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-3/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-2/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-2/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-1/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-7/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-7/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-7/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-6/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-6/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-5/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-5/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-5/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-4/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-4/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-4/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/shard-rkl-4/boot.html [40]:
RE: [PATCH 09/28] drm: Add Color ops capability property
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:35 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 09/28] drm: Add Color ops capability property
>
> On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> > Add capability property which a colorop can expose it's hardware's
> > abilities. It's a blob property that can be filled with respective
> > data structures depending on the colorop. The user space is expected
> > to read this property and program the colorop accordingly.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > include/drm/drm_colorop.h | 13 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9f6a3a1c8020..95f1df73209c 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> > *val = state->curve_1d_type;
> > } else if (property == colorop->data_property) {
> > *val = (state->data) ? state->data->base.id : 0;
> > + } else if (property == colorop->hw_caps_property) {
> > + *val = state->hw_caps ?
> > + state->hw_caps->base.id : 0;
> > } else {
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index 5b8c36538491..f417e109c40a 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -59,6 +59,12 @@ struct drm_colorop_state {
> > */
> > enum drm_colorop_curve_1d_type curve_1d_type;
> >
> > + /**
> > +* @hw_caps:
> > +*
> > +*/
> > + struct drm_property_blob *hw_caps;
> > +
>
> Is this supposed to be generic for any colorop or specifically for
> DRM_COLOROP_1D_LUT?
We have intentionally kept it generic so that it can be used for any kind
of hardware color block (1D LUT, 3D LUT etc.). Differentiation can be done
by using the Color op type.
Regards,
Uma Shankar
> > /**
> > * @data:
> > *
> > @@ -167,6 +173,13 @@ struct drm_colorop {
> > */
> > struct drm_property *bypass_property;
> >
> > + /**
> > +* @hwlut_caps_property:
> > +*
> > +* Property to expose hardware lut capbilities.
> > +*/
> > + struct drm_property *hw_caps_property;
> > +
> > /**
> > * @curve_1d_type:
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 08/28] drm: Add Color lut range attributes
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:34 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 08/28] drm: Add Color lut range attributes
>
> On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> > This defines a new structure to define color lut ranges, along with
> > related macro definitions and enums. This will help describe segmented
> > lut ranges/PWL LUTs in the hardware.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > include/uapi/drm/drm_mode.h | 58
> > +
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index af67f32e0087..376498715d0e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> > DRM_MODE_PAGE_FLIP_ASYNC | \
> > DRM_MODE_PAGE_FLIP_TARGET)
> >
>
> All of this uses DRM_MODE_LUT namespace but it seems specifically for the drm
> colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the naming.
Yeah Sebastian, we will update this and get it aligned.
Thanks for pointing out.
Regards,
Uma Shankar
> > +/**
> > + * DRM_MODE_LUT_INTERPOLATE
> > + *
> > + * linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(0)
> > +
> > +/**
> > + * DRM_MODE_LUT_REUSE_LAST
> > + *
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> > +
> > +/**
> > + * DRM_MODE_LUT_NON_DECREASING
> > + *
> > + * the curve must be non-decreasing
> > + */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> > +
> > +/**
> > + * DRM_MODE_LUT_REFLECT_NEGATIVE
> > + *
> > + * the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> > +
> > +/**
> > + * DRM_MODE_LUT_SINGLE_CHANNEL
> > + *
> > + * the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> > +
> > +/**
> > + * struct drm_color_lut_range
> > + *
> > + * structure to advertise capability of a color hardware
> > + * block that accepts LUT values. It can represent LUTs with
> > + * varied number of entries and distributions
> > + * (Multi segmented, Logarithmic etc).
> > + */
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > /*
> > * Request a page flip on the specified crtc.
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, February 13, 2024 4:32 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com; > m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com; > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es; > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com; > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com; > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net; > mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com; > s...@poorly.run; Borah, Chaitanya Kumar > Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms > > On Tue, 13 Feb 2024 12:18:07 +0530 > Uma Shankar wrote: > > > This series intends to add support for Plane Color Management for > > Intel platforms. This is based on the design which has been agreed > > upon by the community. Series implementing the design for generic DRM > > core has been sent out by Harry Wentland and is under review > > below: > > https://patchwork.freedesktop.org/series/123446/ > > > > The base work of above series is squashed under 1 patch and support > > for Intel platform is added on top of it. > > Any reviews on the original core design is expected to be done in > > Harry's series to avoid any forking of the discussion. > > > > We have added some changes/fixes to the Harry's core DRM changes, > > being put up as separate patches on top of squashed patch. These are > > expected to get included in the main series from Harry once agreed upon. > > > > Changes added on core design: > > 1. Below patches implement some fixes on original series > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > > > 2. Implemented a HW capability property to expose segmented luts. > > drm: Add Color lut range attributes > > drm: Add Color ops capability property > > drm: Define helper to create color ops capability property > > drm: Define helper for adding capability property for 1D LUT > > > > This helps in generically defining the hardware lut capabilities, lut > > distribution, precision, segmented or PWL LUTS. > > > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > > drm: Add Enhanced LUT precision structure > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > > > On top of this base work for DRM core plane color pipeline design, > > implementation is done for Intel hardware platforms. Below patches > > include the same: > > > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > > drm/i915/color: Add and attach COLORPIPELINE plane property > > drm/i915/color: Add framework to set colorop > > drm/i915/color: Add callbacks to set plane CTM > > drm/i915/color: Add framework to program PRE/POST CSC LUT > > FIXME: force disable legacy plane color properties for TGL and beyond > > drm/i915/color: Enable Plane Color Pipelines > > drm/i915: Define segmented Lut and add capabilities to colorop > > drm/i915/color: Add plane CTM callback for TGL and beyond > > drm/i915: Add register definitions for Plane Degamma > > drm/i915: Add register definitions for Plane Post CSC > > drm/i915/color: Program Pre-CSC registers > > drm/i915/xelpd: Program Plane Post CSC Registers > > > > Bhanu from Intel will be sending out the igt changes to help test the > > color pipeline implementation based on the current igt changes sent > > out by Harry. > > https://patchwork.freedesktop.org/series/123448/ > > > > Planned Next Steps: > > 1. Work with Harry and community and get DRM core changes for color > > pipeline merged. > > 2. Implement pipe color management (post blending) based on the > > current color pipeline design. > > 3. Work with compositor maintainers to get color processing > > implemented using display hardware, thereby avoid any GL or GPU shaders. > > > > Thanks to all the community maintainers and contributors who have > > helped to get this support in upstream Linux. Looking forward to > > collaborate, work together and get this merged. > > > > ... > > > Chaitanya Kumar Borah (16): > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > >
RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Tuesday, February 13, 2024 3:07 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
>
> On Tue, 13 Feb 2024 12:18:24 +0530
> Uma Shankar wrote:
>
> > This defines the lut segments and create the color pipeline
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 109
> > +
> > 1 file changed, 109 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index e223edbe4c13..223cd1ff7291 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> ilk_color_funcs = {
> > .get_config = ilk_get_config,
> > };
> >
> > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
>
> Hi Uma,
>
> is it a good idea to have these flags per-segment?
>
> I would find it very strange, unusable really, if REFLECT_NEGATIVE applied on
> some but not all segments, for example. Is such flexibility really necessary
> in the
> hardware description?
Hi Pekka,
Idea to have these flags is to just have some option in case there are some
differences
across segments. Most cases this should not be the case, just helps to future
proof
the implementation.
Based on how the community feels on the usability of it, we can take a call on
the flags
and the expected interpretation for the same. We are open for suggestions on
the same.
>
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
>
> The same question about input_bpc and output_bpc.
Same for these as well, userspace can just ignore these if no usage. However,
for some clients
it may help in Lut computations.
The original idea for the structure came from Ville (missed to mention that in
cover letter, will get that
updated in next version).
@ville.syrj...@linux.intel.com Please share your inputs on the usability of
these attributes.
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
>
> What if there is a gap or overlap between the previous segment .end and the
> next
> segment .start? Is it forbidden? Will the kernel common code verify that
> drivers
> don't make mistakes? Or IGT?
This is just to help give some reference to userspace. As of now, driver
trusts the values
coming from userspace if it sends wrong values its on him and driver can't help
much.
However, we surely can have some sanity check like non decreasing luts etc. to
driver.
Ideally LUT values should not overlap, but we can indicate this explicitly with
flag to
hint the userspace (for overlap or otherwise) and also get a check in driver
for the same.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 1 << 24, .end = 3 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 4 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > +
[PATCH] drm/i915/display: update pll values in sync with Bspec for MTL
DP/eDP and HDMI C20 PHY PLL values were updated for MTL platform
Signed-off-by: Ravi Kumar Vodapalli
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 32 ++--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 288a00e083c8..64e0f820a789 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -848,10 +848,10 @@ static const struct intel_c20pll_state mtl_c20_dp_hbr3 = {
static const struct intel_c20pll_state mtl_c20_dp_uhbr10 = {
.clock = 100, /* 10 Gbps */
.tx = { 0xbe21, /* tx cfg0 */
- 0x4800, /* tx cfg1 */
+ 0xe800, /* tx cfg1 */
0x, /* tx cfg2 */
},
- .cmn = {0x0500, /* cmn cfg0*/
+ .cmn = {0x0700, /* cmn cfg0*/
0x0005, /* cmn cfg1 */
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
@@ -1641,7 +1641,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_594 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_300 = {
.clock = 300,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1649,8 +1649,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_300 =
{
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
},
- .mpllb = { 0x209c, /* mpllb cfg0 */
- 0x7d10, /* mpllb cfg1 */
+ .mpllb = { 0x309c, /* mpllb cfg0 */
+ 0x2110, /* mpllb cfg1 */
0xca06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1666,7 +1666,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_300 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_600 = {
.clock = 600,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1674,8 +1674,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_600 =
{
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
},
- .mpllb = { 0x009c, /* mpllb cfg0 */
- 0x7d08, /* mpllb cfg1 */
+ .mpllb = { 0x109c, /* mpllb cfg0 */
+ 0x2108, /* mpllb cfg1 */
0xca06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1691,7 +1691,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_600 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_800 = {
.clock = 800,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1699,8 +1699,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_800 =
{
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
},
- .mpllb = { 0x00d0, /* mpllb cfg0 */
- 0x7d08, /* mpllb cfg1 */
+ .mpllb = { 0x10d0, /* mpllb cfg0 */
+ 0x2108, /* mpllb cfg1 */
0x4a06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1716,7 +1716,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_800 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_1000 = {
.clock = 1000,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1725,7 +1725,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_1000
= {
0x, /* cmn cfg3 */
},
.mpllb = { 0x1104, /* mpllb cfg0 */
- 0x7d08, /* mpllb cfg1 */
+ 0x2108, /* mpllb cfg1 */
0x0a06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1741,7 +1741,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_1000
= {
static const struct intel_c20pll_state mtl_c20_hdmi_1200 = {
.clock = 1200,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1749,8
[PATCH] drm/i915/display: update pll values in sync with Bspec for MTL
DP/eDP and HDMI C20 PHY PLL values were updated for MTL platform
Signed-off-by: Ravi Kumar Vodapalli
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 32 ++--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 288a00e083c8..64e0f820a789 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -848,10 +848,10 @@ static const struct intel_c20pll_state mtl_c20_dp_hbr3 = {
static const struct intel_c20pll_state mtl_c20_dp_uhbr10 = {
.clock = 100, /* 10 Gbps */
.tx = { 0xbe21, /* tx cfg0 */
- 0x4800, /* tx cfg1 */
+ 0xe800, /* tx cfg1 */
0x, /* tx cfg2 */
},
- .cmn = {0x0500, /* cmn cfg0*/
+ .cmn = {0x0700, /* cmn cfg0*/
0x0005, /* cmn cfg1 */
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
@@ -1641,7 +1641,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_594 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_300 = {
.clock = 300,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1649,8 +1649,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_300 =
{
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
},
- .mpllb = { 0x209c, /* mpllb cfg0 */
- 0x7d10, /* mpllb cfg1 */
+ .mpllb = { 0x309c, /* mpllb cfg0 */
+ 0x2110, /* mpllb cfg1 */
0xca06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1666,7 +1666,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_300 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_600 = {
.clock = 600,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1674,8 +1674,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_600 =
{
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
},
- .mpllb = { 0x009c, /* mpllb cfg0 */
- 0x7d08, /* mpllb cfg1 */
+ .mpllb = { 0x109c, /* mpllb cfg0 */
+ 0x2108, /* mpllb cfg1 */
0xca06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1691,7 +1691,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_600 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_800 = {
.clock = 800,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1699,8 +1699,8 @@ static const struct intel_c20pll_state mtl_c20_hdmi_800 =
{
0x, /* cmn cfg2 */
0x, /* cmn cfg3 */
},
- .mpllb = { 0x00d0, /* mpllb cfg0 */
- 0x7d08, /* mpllb cfg1 */
+ .mpllb = { 0x10d0, /* mpllb cfg0 */
+ 0x2108, /* mpllb cfg1 */
0x4a06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1716,7 +1716,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_800 =
{
static const struct intel_c20pll_state mtl_c20_hdmi_1000 = {
.clock = 1000,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1725,7 +1725,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_1000
= {
0x, /* cmn cfg3 */
},
.mpllb = { 0x1104, /* mpllb cfg0 */
- 0x7d08, /* mpllb cfg1 */
+ 0x2108, /* mpllb cfg1 */
0x0a06, /* mpllb cfg2 */
0xbe40, /* mpllb cfg3 */
0x, /* mpllb cfg4 */
@@ -1741,7 +1741,7 @@ static const struct intel_c20pll_state mtl_c20_hdmi_1000
= {
static const struct intel_c20pll_state mtl_c20_hdmi_1200 = {
.clock = 1200,
.tx = { 0xbe98, /* tx cfg0 */
- 0x9800, /* tx cfg1 */
+ 0x8800, /* tx cfg1 */
0x, /* tx cfg2 */
},
.cmn = { 0x0500, /* cmn cfg0*/
@@ -1749,8
RE: [PATCH 05/28] drm: Add support for 3x3 CTM
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, February 13, 2024 2:45 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run; Borah, Chaitanya Kumar
> Subject: Re: [PATCH 05/28] drm: Add support for 3x3 CTM
>
> On Tue, 13 Feb 2024 12:18:12 +0530
> Uma Shankar wrote:
>
> > From: Chaitanya Kumar Borah
> >
> > Add support for 3x3 Color Transformation Matrices in Color Pipeline.
> >
> > Signed-off-by: Chaitanya Kumar Borah
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_colorop.c | 2 +-
> > include/uapi/drm/drm_mode.h | 1 +
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index e7bf1fb054af..c54b0d6c133e 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> > case DRM_COLOROP_CTM_3X4:
> > size = sizeof(struct drm_color_ctm_3x4);
> > break;
> > + case DRM_COLOROP_CTM_3X3:
> > + size = sizeof(struct drm_color_ctm);
> > + break;
> > default:
> > /* should never get here */
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c index 462ffec42cdf..6bae6dc8e54b
> > 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> >0);
> >
> > /* data */
> > - if (type == DRM_COLOROP_CTM_3X4) {
> > + if (type == DRM_COLOROP_CTM_3X4 || type ==
> DRM_COLOROP_CTM_3X3) {
> > prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLOB,
> >"DATA", 0);
> > if (!prop)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index f16318f1785f..68696253867e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -868,6 +868,7 @@ struct drm_color_lut {
> >
> > enum drm_colorop_type {
> > DRM_COLOROP_1D_CURVE,
> > + DRM_COLOROP_CTM_3X3,
> > DRM_COLOROP_CTM_3X4,
> > };
> >
>
> Hi,
>
> where are the docs for DRM_COLOROP_CTM_3X3?
Hi Pekka,
Sorry, we missed this in the current version. Will update the same in next
revision.
Regards,
Uma Shankar
>
> Thanks,
> pq
✓ Fi.CI.BAT: success for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details ==
Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling
code
URL : https://patchwork.freedesktop.org/series/129874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14268 -> Patchwork_129874v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/index.html
Participating hosts (38 -> 35)
--
Missing(3): fi-glk-j4005 fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_129874v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-cfl-8109u: [FAIL][1] ([i915#8293]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/fi-cfl-8109u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/fi-cfl-8109u/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-cfl-8109u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-cfl-8109u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/bat-adlm-1/igt@gem_tiled_pread_basic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#9875] / [i915#9900]) +9
other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_flip@basic-plain-flip:
- bat-adlm-1: NOTRUN -> [SKIP][7] ([i915#3637]) +3 other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/bat-adlm-1/igt@kms_f...@basic-plain-flip.html
* igt@kms_pm_backlight@basic-brightness:
- fi-cfl-8109u: NOTRUN -> [SKIP][8] ([fdo#109271]) +7 other tests skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html
Possible fixes
* igt@gem_exec_parallel@engines@fds:
- bat-adlm-1: [INCOMPLETE][9] ([i915#10264]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/bat-adlm-1/igt@gem_exec_parallel@engi...@fds.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/bat-adlm-1/igt@gem_exec_parallel@engi...@fds.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10264]: https://gitlab.freedesktop.org/drm/intel/issues/10264
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#9875]: https://gitlab.freedesktop.org/drm/intel/issues/9875
[i915#9900]: https://gitlab.freedesktop.org/drm/intel/issues/9900
Build changes
-
* Linux: CI_DRM_14268 -> Patchwork_129874v1
CI-20190529: 20190529
CI_DRM_14268: e3e6421a490e14b441f0ace4fe3cf45f70aa5c11 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7711: 7711
Patchwork_129874v1: e3e6421a490e14b441f0ace4fe3cf45f70aa5c11 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
653e5e15b14c drm/tests/drm_buddy: add alloc_contiguous test
5c680a14da9f drm/buddy: Fix alloc_range() error handling code
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129874v1/index.html
✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details == Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling code URL : https://patchwork.freedesktop.org/series/129874/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details == Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling code URL : https://patchwork.freedesktop.org/series/129874/ State : warning == Summary == Error: dim checkpatch failed d076bd46f511 drm/buddy: Fix alloc_range() error handling code 5dd5f8bea578 drm/tests/drm_buddy: add alloc_contiguous test -:11: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use 'Link:' or 'Closes:' instead #11: References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097 -:102: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #102: FILE: drivers/gpu/drm/tests/drm_buddy_test.c:89: + KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size, + 2 * ps, ps, , -:108: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #108: FILE: drivers/gpu/drm/tests/drm_buddy_test.c:95: + KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size, + 3 * ps, ps, , total: 0 errors, 1 warnings, 2 checks, 107 lines checked
RE: [RFC 4/4] drm/i915/display/dp: On LT failure retry LT
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, February 13, 2024 11:45 PM
> To: Murthy, Arun R ; intel-gfx@lists.freedesktop.org
> Cc: Deak, Imre ; Syrjala, Ville
> ;
> Shankar, Uma ; Murthy, Arun R
>
> Subject: Re: [RFC 4/4] drm/i915/display/dp: On LT failure retry LT
>
> On Tue, 06 Feb 2024, Arun R Murthy wrote:
> > On link training failure retry link training with a lesser link
> > rate/lane count as specified in the DP spec.
> >
> > Signed-off-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index ed7620e7f763..29d785a4b904 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -2502,6 +2502,7 @@ static void mtl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> > crtc_state->port_clock,
> > crtc_state->lane_count);
> >
> > +retry:
> > /*
> > * We only configure what the register value will be here. Actual
> > * enabling happens during link training farther down.
> > @@ -2586,7 +2587,14 @@ static void mtl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> > * Pattern, wait for 5 idle patterns (DP_TP_STATUS Min_Idles_Sent)
> > * (timeout after 800 us)
> > */
> > - intel_dp_start_link_train(intel_dp, crtc_state);
> > + if (!intel_dp_start_link_train(intel_dp, crtc_state)) {
> > + /* Link Training failed, retain */
> > + intel_dp->link_trained = false;
> > + intel_dp_stop_link_train(intel_dp, crtc_state);
> > + encoder->post_disable(state, encoder,
> > + crtc_state, conn_state);
> > + goto retry;
> > + }
>
> As said, the retry needs to go via userspace.
If within the supported mode range then also do we need to send uevent to user
and should it come via userspace?
The fallback mandates in DP2.1 spec does this fallback in a loop.
The present fallback structure
Struct dp_fallback {
U32 link rate;
U8 lane_count;
U32 resolution;
}
In the same fallback code, the present mode will be verified to see if its less
than or equal to the resolution in dp_fallback. If so proceed within the
fallback loop else set the max link_rate/lane count values and sent uevent.
Thanks and Regards,
Arun R Murthy
>
> BR,
> Jani.
>
>
> >
> > /* 6.n Set DP_TP_CTL link training to Normal */
> > if (!is_trans_port_sync_mode(crtc_state))
>
> --
> Jani Nikula, Intel
RE: [PATCH 4/5] drm/xe/hdcp: Enable HDCP for XE
> > interaction of HDCP as a client with the GSC CS interface.
> >
> > --v2
> > -add kfree at appropriate place [Daniele] -remove useless define
> > [Daniele] -move host session logic to xe_gsc_submit.c [Daniele] -call
> > xe_gsc_check_and_update_pending directly in an if condition [Daniele]
> > -use xe_device instead of drm_i915_private [Daniele]
> >
> > --v3
> > -use xe prefix for newly exposed function [Daniele] -remove client
> > specific defines from intel_gsc_mtl_header [Daniele] -add missing
> > kfree() [Daniele] -have NULL check for hdcp_message in finish function
> > [Daniele] -dont have too many variable declarations in the same line
> > [Daniele]
> >
> > Signed-off-by: Suraj Kandpal
> > ---
> > drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 180
> ++-
> > drivers/gpu/drm/xe/xe_gsc_submit.c | 15 ++
> > drivers/gpu/drm/xe/xe_gsc_submit.h | 1 +
> > 3 files changed, 193 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > index 425db3532ce5..aa8c13916bb6 100644
> > --- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > +++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > @@ -4,12 +4,27 @@
> >*/
> >
> > #include
> > +#include
> >
> > +#include "abi/gsc_command_header_abi.h"
> > #include "intel_hdcp_gsc.h"
> > #include "xe_device_types.h"
> > #include "xe_gt.h"
> > #include "xe_gsc_proxy.h"
> > #include "xe_pm.h"
> > +#include "xe_bo.h"
> > +#include "xe_map.h"
> > +#include "xe_gsc_submit.h"
> > +
> > +#define HECI_MEADDRESS_HDCP 18
> > +
> > +struct intel_hdcp_gsc_message {
> > + struct xe_bo *hdcp_bo;
> > + u64 hdcp_cmd_in;
> > + u64 hdcp_cmd_out;
> > +};
> > +
> > +#define HDCP_GSC_HEADER_SIZE sizeof(struct intel_gsc_mtl_header)
> >
> > bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
> > {
> > @@ -40,19 +55,178 @@ bool intel_hdcp_gsc_check_status(struct xe_device
> *xe)
> > return ret;
> > }
> >
> > +/*This function helps allocate memory for the command that we will
> > +send to gsc cs */ static int intel_hdcp_gsc_initialize_message(struct
> xe_device *xe,
> > +struct intel_hdcp_gsc_message
> *hdcp_message) {
> > + struct xe_bo *bo = NULL;
> > + u64 cmd_in, cmd_out;
> > + int ret = 0;
> > +
> > + /* allocate object of two page for HDCP command memory and store
> it */
> > + xe_device_mem_access_get(xe);
> > + bo = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe), NULL,
> PAGE_SIZE * 2,
> > + ttm_bo_type_kernel,
> > + XE_BO_CREATE_SYSTEM_BIT |
> > + XE_BO_CREATE_GGTT_BIT);
> > +
> > + if (IS_ERR(bo)) {
> > + drm_err(>drm, "Failed to allocate bo for HDCP streaming
> command!\n");
> > + ret = PTR_ERR(bo);
> > + goto out;
> > + }
> > +
> > + cmd_in = xe_bo_ggtt_addr(bo);
> > + cmd_out = cmd_in + PAGE_SIZE;
> > + xe_map_memset(xe, >vmap, 0, 0, bo->size);
> > +
> > + hdcp_message->hdcp_bo = bo;
> > + hdcp_message->hdcp_cmd_in = cmd_in;
> > + hdcp_message->hdcp_cmd_out = cmd_out;
> > +out:
> > + xe_device_mem_access_put(xe);
> > + return ret;
> > +}
> > +
> > +static int intel_hdcp_gsc_hdcp2_init(struct xe_device *xe) {
> > + struct intel_hdcp_gsc_message *hdcp_message;
> > + int ret;
> > +
> > + hdcp_message = kzalloc(sizeof(*hdcp_message), GFP_KERNEL);
> > +
> > + if (!hdcp_message)
> > + return -ENOMEM;
> > +
> > + /*
> > +* NOTE: No need to lock the comp mutex here as it is already
> > +* going to be taken before this function called
> > +*/
> > + ret = intel_hdcp_gsc_initialize_message(xe, hdcp_message);
> > + xe->display.hdcp.hdcp_message = hdcp_message;
> > +
> > + if (ret) {
> > + drm_err(>drm, "Could not initialize hdcp_message\n");
> > + kfree(hdcp_message);
>
> Here you're leaving xe->display.hdcp.hdcp_message pointing to a memory
> location that we no longer own. is that safe for the _fini function?
>
Would it be better to not have a kfree here if initialization fails it gets
taken care of
In finish function anyways that would be safer I presume.
> LGTM apart from this (assuming it is going to be squashed with the next
> patch for merge).
Yes this will be squashed with the next patch when I send the new revision
Regards,
Suraj Kandpal
>
> Daniele
>
> > + }
> > +
> > + return ret;
> > +}
> > +
> > int intel_hdcp_gsc_init(struct xe_device *xe)
> > {
> > - drm_dbg_kms(>drm, "HDCP support not yet implemented\n");
> > - return -ENODEV;
> > + struct i915_hdcp_arbiter *data;
> > + int ret;
> > +
> > + data = kzalloc(sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + mutex_lock(>display.hdcp.hdcp_mutex);
> > + xe->display.hdcp.arbiter = data;
> > + xe->display.hdcp.arbiter->hdcp_dev = xe->drm.dev;
> > +
RE: [PATCH 2/5] drm/xe/hdcp: Use xe_device struct
>
> On 2/9/2024 2:14 AM, Suraj Kandpal wrote:
> > Use xe_device struct instead of drm_i915_private so as to not cause
> > confusion and comply with Xe standards even though xe_device gets
> > translated to drm_i915_private.
>
> AFAIU xe_device does not get translated to drm_i915_private, it's really an
> xe_device struct under the hood.
> The change itself looks ok to me, but I'll leave the final r-b to someone on
> the
> display side to confirm this is the correct approach.
>
Thanks Daniele for having a look maybe Jani or Ankit can help with the final rb
Regards,
Suraj Kandpal
> Daniele
>
> >
> > Signed-off-by: Suraj Kandpal
> > ---
> > drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > index 0f11a39333e2..5d1d0054b578 100644
> > --- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > +++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
> > @@ -3,30 +3,31 @@
> >* Copyright 2023, Intel Corporation.
> >*/
> >
> > -#include "i915_drv.h"
> > +#include
> > #include "intel_hdcp_gsc.h"
> > +#include "xe_device_types.h"
> >
> > -bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
> > +bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
> > {
> > return true;
> > }
> >
> > -bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
> > +bool intel_hdcp_gsc_check_status(struct xe_device *xe)
> > {
> > return false;
> > }
> >
> > -int intel_hdcp_gsc_init(struct drm_i915_private *i915)
> > +int intel_hdcp_gsc_init(struct xe_device *xe)
> > {
> > - drm_info(>drm, "HDCP support not yet implemented\n");
> > + drm_dbg_kms(>drm, "HDCP support not yet implemented\n");
> > return -ENODEV;
> > }
> >
> > -void intel_hdcp_gsc_fini(struct drm_i915_private *i915)
> > +void intel_hdcp_gsc_fini(struct xe_device *xe)
> > {
> > }
> >
> > -ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8
> > *msg_in,
> > +ssize_t intel_hdcp_gsc_msg_send(struct xe_device *xe, u8 *msg_in,
> > size_t msg_in_len, u8 *msg_out,
> > size_t msg_out_len)
> > {
[PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
From: Matthew Auld
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Reviewed-by: Arunpravin Paneer Selvam
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..4215d8b5fcf0 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
[PATCH 1/2] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
base-commit: 2c80a2b715df75881359d07dbaacff8ad411f40e
--
2.25.1
RE: [RFC 3/4] drm/i915/dp: use link rate and lane count in intel_dp struct
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, February 13, 2024 11:43 PM
> To: Murthy, Arun R ; intel-gfx@lists.freedesktop.org
> Cc: Deak, Imre ; Syrjala, Ville
> ;
> Shankar, Uma ; Murthy, Arun R
>
> Subject: Re: [RFC 3/4] drm/i915/dp: use link rate and lane count in intel_dp
> struct
>
> On Tue, 06 Feb 2024, Arun R Murthy wrote:
> > The link rate and lane count are now part of the intel_crtc_state
> > structure. These two parameters are nothing to do with the crtc and
> > are more confined to DP.
>
> As said offline, the parameters were specifically added to crtc state for both
> atomic and the state checker.
>
I am a bit lost as to from where we need this in atomic and state checker for
link rate and lane count as none of these parameters are coming from user nor
does it change in modeset. On driver init the link rate and lane count value is
fetched from the table and thereafter its constant, but used in many places for
configuration/calculation purpose for which the same in intel_dp struct would
do.
On link training failure, the link rate and lane count tends to change and new
value is initialized in intel_dp struct.
Thanks and Regards,
Arun R Murthy
> No go.
>
>
> BR,
> Jani.
>
> >
> > TODO: Need to still seperate out the use of link rate and port clock
> > which is in intel_dp and intel_crtc_state structure.
> >
> > Signed-off-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 16 ++--
> > drivers/gpu/drm/i915/display/intel_ddi.c | 21 ++---
> > .../drm/i915/display/intel_ddi_buf_trans.c| 7 +-
> > drivers/gpu/drm/i915/display/intel_dp.c | 8 +-
> > drivers/gpu/drm/i915/display/intel_dp.h | 2 +-
> > .../drm/i915/display/intel_dp_link_training.c | 81
> > ++- .../drm/i915/display/intel_dp_link_training.h | 2 +-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 ---
> > 8 files changed, 92 insertions(+), 74 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index 288a00e083c8..cde8f26ba26b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -414,6 +414,7 @@ void intel_cx0_phy_set_signal_levels(struct
> > intel_encoder *encoder, {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > const struct intel_ddi_buf_trans *trans;
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > enum phy phy = intel_port_to_phy(i915, encoder->port);
> > u8 owned_lane_mask;
> > intel_wakeref_t wakeref;
> > @@ -446,7 +447,7 @@ void intel_cx0_phy_set_signal_levels(struct
> intel_encoder *encoder,
> > MB_WRITE_COMMITTED);
> > }
> >
> > - for (ln = 0; ln < crtc_state->lane_count; ln++) {
> > + for (ln = 0; ln < intel_dp->lane_count; ln++) {
> > int level = intel_ddi_level(encoder, crtc_state, ln);
> > int lane = ln / 2;
> > int tx = ln % 2;
> > @@ -2327,10 +2328,11 @@ static void intel_c20_pll_program(struct
> drm_i915_private *i915,
> > const struct intel_crtc_state *crtc_state,
> > struct intel_encoder *encoder)
> > {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > const struct intel_c20pll_state *pll_state = _state-
> >cx0pll_state.c20;
> > bool dp = false;
> > - int lane = crtc_state->lane_count > 2 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> > - u32 clock = crtc_state->port_clock;
> > + int lane = intel_dp->lane_count > 2 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> > + u32 clock = intel_dp->link_rate;
> > bool cntx;
> > int i;
> >
> > @@ -2455,6 +2457,7 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
> > const struct intel_crtc_state
> *crtc_state,
> > bool lane_reversal)
> > {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > u32 val = 0;
> >
> > @@ -2475,7 +2478,7 @@ static void intel_program_port_clock_ctl(struct
> > intel_encoder *encoder,
> >
> > /* TODO: HDMI FRL */
> > /* DP2.0 10G and 20G rates enable MPLLA*/
> > - if (crtc_state->port_clock == 100 || crtc_state->port_clock ==
> 200)
> > + if (intel_dp->link_rate == 100 || intel_dp->link_rate ==
> > +200)
> > val |= crtc_state->cx0pll_state.ssc_enabled ?
> XELPDP_SSC_ENABLE_PLLA : 0;
> > else
> > val |= crtc_state->cx0pll_state.ssc_enabled ?
> > XELPDP_SSC_ENABLE_PLLB : 0; @@ -2705,6 +2708,7 @@ static void
> intel_cx0pll_enable(struct intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state) {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> >
RE: [RFC 1/4] drm/i915/display/dp: Add DP fallback on LT
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, February 13, 2024 11:41 PM
> To: Murthy, Arun R ; intel-gfx@lists.freedesktop.org
> Cc: Deak, Imre ; Syrjala, Ville
> ;
> Shankar, Uma ; Murthy, Arun R
>
> Subject: Re: [RFC 1/4] drm/i915/display/dp: Add DP fallback on LT
>
> On Tue, 06 Feb 2024, Arun R Murthy wrote:
> > Fallback mandates on DP link training failure. This patch just covers
> > the DP2.0 fallback sequence.
> >
> > TODO: Need to implement the DP1.4 fallback.
> >
> > Signed-off-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 92
> > ++---
> > 1 file changed, 82 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 10ec231acd98..82d354a6b0cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -104,6 +104,50 @@ static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
> > */
> > static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> >
> > +/* DL Link Rates */
> > +#define UHBR20 200
> > +#define UHBR13P5 135
> > +#define UHBR10 100
> > +#define HBR3 81
> > +#define HBR2 54
> > +#define HBR27
> > +#define RBR162000
> > +
> > +/* DP Lane Count */
> > +#define LANE_COUNT_4 4
> > +#define LANE_COUNT_2 2
> > +#define LANE_COUNT_1 1
> > +
> > +/* DP2.0 fallback values */
> > +struct dp_fallback {
> > + u32 link_rate;
> > + u8 lane_count;
> > +};
> > +
> > +struct dp_fallback dp2dot0_fallback[] = {
> > + {UHBR20, LANE_COUNT_4},
> > + {UHBR13P5, LANE_COUNT_4},
> > + {UHBR20, LANE_COUNT_2},
> > + {UHBR10, LANE_COUNT_4},
> > + {UHBR13P5, LANE_COUNT_2},
> > + {HBR3, LANE_COUNT_4},
> > + {UHBR20, LANE_COUNT_1},
> > + {UHBR10, LANE_COUNT_2},
> > + {HBR2, LANE_COUNT_4},
> > + {UHBR13P5, LANE_COUNT_1},
> > + {HBR3, LANE_COUNT_2},
> > + {UHBR10, LANE_COUNT_1},
> > + {HBR2, LANE_COUNT_2},
> > + {HBR, LANE_COUNT_4},
> > + {HBR3, LANE_COUNT_1},
> > + {RBR, LANE_COUNT_4},
> > + {HBR2, LANE_COUNT_1},
> > + {HBR, LANE_COUNT_2},
> > + {RBR, LANE_COUNT_2},
> > + {HBR, LANE_COUNT_1},
> > + {RBR, LANE_COUNT_1},
> > +};
> > +
> > /**
> > * intel_dp_is_edp - is the given port attached to an eDP panel (either
> > CPU or
> PCH)
> > * @intel_dp: DP struct
> > @@ -299,6 +343,19 @@ static int intel_dp_common_len_rate_limit(const
> struct intel_dp *intel_dp,
> >intel_dp->num_common_rates, max_rate);
> }
> >
> > +static bool intel_dp_link_rate_supported(struct intel_dp *intel_dp,
> > +u32 link_rate) {
> > + u8 i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(intel_dp->common_rates); i++) {
> > + if (intel_dp->common_rates[i] == link_rate)
> > + return true;
> > + else
> > + continue;
> > + }
> > + return false;
> > +}
> > +
> > static int intel_dp_common_rate(struct intel_dp *intel_dp, int index)
> > {
> > if (drm_WARN_ON(_to_i915(intel_dp)->drm,
> > @@ -671,15 +728,6 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > int index;
> >
> > - /*
> > -* TODO: Enable fallback on MST links once MST link compute can
> handle
> > -* the fallback params.
> > -*/
> > - if (intel_dp->is_mst) {
> > - drm_err(>drm, "Link Training Unsuccessful\n");
> > - return -1;
> > - }
> > -
>
> By removing this, the claim is both 8b/10b and 128b/132b DP MST link training
> fallbacks work...
Yes! This series focuses on the fallback mandates mentioned in DP2.1 spec and
doesn't fallback from MST to SST or vicecersa.
Hence if it is MST the fallback will be within MST and if its SST the fallback
will be within SST.
>
> > if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> > drm_dbg_kms(>drm,
> > "Retrying Link training for eDP with max
> parameters\n"); @@
> > -687,6 +735,31 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> > return 0;
> > }
> >
> > + /* DP fallback values */
> > + if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] &
> > +DP_CAP_ANSI_128B132B) {
>
> ...but this only addresses 128b/132b, and the 8b/10b MST drops to the existing
> SST fallback path.
Yes! As said above this fallback is based on fallback mandates mentioned in
DP2.1 spec in Table 3.31 and Figure 3-52 which focuses on reducing the link
rate/lance count and nothing to with MST/SST
>
> And with the current code, DP_CAP_ANSI_128B132B does not decide whether
> we use DP MST or not. So this will also cover 8b/10b fallback for displays
> that
> support 128b/132b but have DP_MSTM_CAP == 0.
Yes, the series doent depend on MST and SST and doest fallback from MST
Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
Hi Uma,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240213]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
linus/master v6.8-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20240214/202402141056.lzcslaot-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240214/202402141056.lzcslaot-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402141056.lzcslaot-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/tests/drm_fixp_test.c:11:59: warning: overflow in
>> expression; result is 9223372036854775807 with type 'long long'
>> [-Winteger-overflow]
11 | KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) -
1));
| ^
1 warning generated.
--
>> drivers/gpu/drm/vkms/vkms_composer.c:95:5: warning: no previous prototype
>> for function 'lerp_u16' [-Wmissing-prototypes]
95 | u16 lerp_u16(u16 a, u16 b, s64 t)
| ^
drivers/gpu/drm/vkms/vkms_composer.c:95:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
95 | u16 lerp_u16(u16 a, u16 b, s64 t)
| ^
| static
>> drivers/gpu/drm/vkms/vkms_composer.c:105:5: warning: no previous prototype
>> for function 'get_lut_index' [-Wmissing-prototypes]
105 | s64 get_lut_index(const struct vkms_color_lut *lut, u16
channel_value)
| ^
drivers/gpu/drm/vkms/vkms_composer.c:105:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
105 | s64 get_lut_index(const struct vkms_color_lut *lut, u16
channel_value)
| ^
| static
>> drivers/gpu/drm/vkms/vkms_composer.c:167:6: warning: no previous prototype
>> for function 'apply_3x4_matrix' [-Wmissing-prototypes]
167 | void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct
drm_color_ctm_3x4 *matrix)
| ^
drivers/gpu/drm/vkms/vkms_composer.c:167:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
167 | void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct
drm_color_ctm_3x4 *matrix)
| ^
| static
3 warnings generated.
--
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:1: warning: 'const' type qualifier on
>> return type has no effect [-Wignored-qualifiers]
11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane,
struct drm_prop_enum_list *list)
| ^
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:11: warning: no previous prototype
>> for function 'vkms_initialize_tf_pipeline' [-Wmissing-prototypes]
11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane,
struct drm_prop_enum_list *list)
| ^
drivers/gpu/drm/vkms/vkms_colorop.c:11:7: note: declare 'static' if the
function is not intended to be used outside of this translation unit
11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane,
struct drm_prop_enum_list *list)
| ^
| static
>> drivers/gpu/drm/vkms/vkms_colorop.c:80:5: warning: no previous prototype for
>> function 'vkms_initialize_colorops' [-Wmissing-prototypes]
80 | int vkms_initialize_colorops(struct drm_plane *plane)
| ^
drivers/gpu/drm/vkms/vkms_colorop.c:80:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
80 | int vkms_initialize_colorops(struct drm_plane *plane)
| ^
| static
3 warnings generated.
vim +11 drivers/gpu/drm/tests/drm_fixp_test.c
8
9 static void drm_test_sm2fixp(struct kunit *test)
10 {
> 11 KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) - 1));
12
13 /* 1 */
14
✗ Fi.CI.BUILD: failure for drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
== Series Details == Series: drm/dp: move intel_dp_vsc_sdp_pack() to generic helper URL : https://patchwork.freedesktop.org/series/129866/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/129866/revisions/1/mbox/ not applied Applying: drm/dp: move intel_dp_vsc_sdp_pack() to generic helper Using index info to reconstruct a base tree... M drivers/gpu/drm/display/drm_dp_helper.c M drivers/gpu/drm/i915/display/intel_dp.c M include/drm/display/drm_dp_helper.h Falling back to patching base and 3-way merge... Auto-merging include/drm/display/drm_dp_helper.h Auto-merging drivers/gpu/drm/i915/display/intel_dp.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_dp.c Auto-merging drivers/gpu/drm/display/drm_dp_helper.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/dp: move intel_dp_vsc_sdp_pack() to generic helper 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". Build failed, no error log produced
[PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 73 +--
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..066cfbbf7a91 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2916,6 +2916,84 @@ void drm_dp_vsc_sdp_log(const char *level, struct device
*dev,
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ * table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+ sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+ sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+ sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+ sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+ if (vsc->revision == 0x6) {
+ sdp->db[0] = 1;
+ sdp->db[3] = 1;
+ }
+
+ /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+ if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+ goto out;
+
+ /* VSC SDP Payload for DB16 through DB18 */
+ /* Pixel Encoding and Colorimetry Formats */
+ sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+ sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+ switch (vsc->bpc) {
+ case 6:
+ /* 6bpc: 0x0 */
+ break;
+ case 8:
+ sdp->db[17] = 0x1; /* DB17[3:0] */
+ break;
+ case 10:
+ sdp->db[17] = 0x2;
+ break;
+ case 12:
+ sdp->db[17] = 0x3;
+ break;
+ case 16:
+ sdp->db[17] = 0x4;
+ break;
+ default:
+ WARN(1, "Missing case %d\n", vsc->bpc);
+ return -EINVAL;
+ }
+
+ /* Dynamic Range and Component Bit Depth */
+ if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
+ sdp->db[17] |= 0x80; /* DB17[7] */
+
+ /* Content Type */
+ sdp->db[18] = vsc->content_type & 0x7;
+
+out:
+ return length;
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f5ef95da5534..e94db51aeeb7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4110,73 +4110,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
- size_t length = sizeof(struct dp_sdp);
-
- if (size < length)
- return -ENOSPC;
-
- memset(sdp, 0, size);
-
- /*
-* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
-* VSC SDP Header Bytes
-*/
- sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
- sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
- sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
- sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
-
- if (vsc->revision == 0x6) {
- sdp->db[0] = 1;
- sdp->db[3] = 1;
- }
-
- /*
-* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
-* Format as per DP 1.4a spec and DP 2.0 respectively.
-*/
- if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
- goto out;
-
- /* VSC SDP Payload for DB16 through DB18 */
- /* Pixel Encoding and Colorimetry Formats */
- sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
- sdp->db[16] |=
Re: [PATCH 4/5] drm/xe/hdcp: Enable HDCP for XE
On 2/9/2024 2:14 AM, Suraj Kandpal wrote:
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
--v2
-add kfree at appropriate place [Daniele]
-remove useless define [Daniele]
-move host session logic to xe_gsc_submit.c [Daniele]
-call xe_gsc_check_and_update_pending directly in an if condition
[Daniele]
-use xe_device instead of drm_i915_private [Daniele]
--v3
-use xe prefix for newly exposed function [Daniele]
-remove client specific defines from intel_gsc_mtl_header [Daniele]
-add missing kfree() [Daniele]
-have NULL check for hdcp_message in finish function [Daniele]
-dont have too many variable declarations in the same line [Daniele]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 180 ++-
drivers/gpu/drm/xe/xe_gsc_submit.c | 15 ++
drivers/gpu/drm/xe/xe_gsc_submit.h | 1 +
3 files changed, 193 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 425db3532ce5..aa8c13916bb6 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -4,12 +4,27 @@
*/
#include
+#include
+#include "abi/gsc_command_header_abi.h"
#include "intel_hdcp_gsc.h"
#include "xe_device_types.h"
#include "xe_gt.h"
#include "xe_gsc_proxy.h"
#include "xe_pm.h"
+#include "xe_bo.h"
+#include "xe_map.h"
+#include "xe_gsc_submit.h"
+
+#define HECI_MEADDRESS_HDCP 18
+
+struct intel_hdcp_gsc_message {
+ struct xe_bo *hdcp_bo;
+ u64 hdcp_cmd_in;
+ u64 hdcp_cmd_out;
+};
+
+#define HDCP_GSC_HEADER_SIZE sizeof(struct intel_gsc_mtl_header)
bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
@@ -40,19 +55,178 @@ bool intel_hdcp_gsc_check_status(struct xe_device *xe)
return ret;
}
+/*This function helps allocate memory for the command that we will send to gsc cs */
+static int intel_hdcp_gsc_initialize_message(struct xe_device *xe,
+struct intel_hdcp_gsc_message
*hdcp_message)
+{
+ struct xe_bo *bo = NULL;
+ u64 cmd_in, cmd_out;
+ int ret = 0;
+
+ /* allocate object of two page for HDCP command memory and store it */
+ xe_device_mem_access_get(xe);
+ bo = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe), NULL,
PAGE_SIZE * 2,
+ ttm_bo_type_kernel,
+ XE_BO_CREATE_SYSTEM_BIT |
+ XE_BO_CREATE_GGTT_BIT);
+
+ if (IS_ERR(bo)) {
+ drm_err(>drm, "Failed to allocate bo for HDCP streaming
command!\n");
+ ret = PTR_ERR(bo);
+ goto out;
+ }
+
+ cmd_in = xe_bo_ggtt_addr(bo);
+ cmd_out = cmd_in + PAGE_SIZE;
+ xe_map_memset(xe, >vmap, 0, 0, bo->size);
+
+ hdcp_message->hdcp_bo = bo;
+ hdcp_message->hdcp_cmd_in = cmd_in;
+ hdcp_message->hdcp_cmd_out = cmd_out;
+out:
+ xe_device_mem_access_put(xe);
+ return ret;
+}
+
+static int intel_hdcp_gsc_hdcp2_init(struct xe_device *xe)
+{
+ struct intel_hdcp_gsc_message *hdcp_message;
+ int ret;
+
+ hdcp_message = kzalloc(sizeof(*hdcp_message), GFP_KERNEL);
+
+ if (!hdcp_message)
+ return -ENOMEM;
+
+ /*
+* NOTE: No need to lock the comp mutex here as it is already
+* going to be taken before this function called
+*/
+ ret = intel_hdcp_gsc_initialize_message(xe, hdcp_message);
+ xe->display.hdcp.hdcp_message = hdcp_message;
+
+ if (ret) {
+ drm_err(>drm, "Could not initialize hdcp_message\n");
+ kfree(hdcp_message);
Here you're leaving xe->display.hdcp.hdcp_message pointing to a memory
location that we no longer own. is that safe for the _fini function?
LGTM apart from this (assuming it is going to be squashed with the next
patch for merge).
Daniele
+ }
+
+ return ret;
+}
+
int intel_hdcp_gsc_init(struct xe_device *xe)
{
- drm_dbg_kms(>drm, "HDCP support not yet implemented\n");
- return -ENODEV;
+ struct i915_hdcp_arbiter *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ mutex_lock(>display.hdcp.hdcp_mutex);
+ xe->display.hdcp.arbiter = data;
+ xe->display.hdcp.arbiter->hdcp_dev = xe->drm.dev;
+ xe->display.hdcp.arbiter->ops = _hdcp_ops;
+ ret = intel_hdcp_gsc_hdcp2_init(xe);
+ if (ret)
+ kfree(data);
+
+ mutex_unlock(>display.hdcp.hdcp_mutex);
+
+ return ret;
}
void intel_hdcp_gsc_fini(struct xe_device *xe)
{
+ struct intel_hdcp_gsc_message *hdcp_message =
+ xe->display.hdcp.hdcp_message;
+
+ if (!hdcp_message)
+ return;
+
+
Re: [PATCH 3/5] drm/xe: Use gsc_proxy_init_done to check proxy status
On 2/9/2024 2:14 AM, Suraj Kandpal wrote:
Expose gsc_proxy_init_done so that we can check if gsc proxy has
been initialized or not.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 25 +++-
drivers/gpu/drm/xe/xe_gsc_proxy.c| 4 ++--
drivers/gpu/drm/xe/xe_gsc_proxy.h| 1 +
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 5d1d0054b578..425db3532ce5 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -4,8 +4,12 @@
*/
#include
+
#include "intel_hdcp_gsc.h"
#include "xe_device_types.h"
+#include "xe_gt.h"
+#include "xe_gsc_proxy.h"
+#include "xe_pm.h"
bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
@@ -14,7 +18,26 @@ bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
bool intel_hdcp_gsc_check_status(struct xe_device *xe)
{
- return false;
+ struct xe_tile *tile = xe_device_get_root_tile(xe);
+ struct xe_gt *gt = tile->media_gt;
+ bool ret = true;
+
Sorry for missing this in the previous rev, but I just remembered that
if the GSC FW is not enabled then the forcewake domain is not
initialized, which would lead to the forcewake_get throwing an error, so
we need a check here first:
if (!xe_uc_fw_is_enabled(>uc.gsc.fw))
return false;
With this change:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
+ xe_pm_runtime_get(xe);
+ ret = xe_force_wake_get(gt_to_fw(gt), XE_FW_GSC);
+ if (ret) {
+ drm_dbg_kms(>drm,
+ "failed to get forcewake to check proxy status\n");
+ ret = false;
+ goto out;
+ }
+
+ if (!xe_gsc_proxy_init_done(>uc.gsc))
+ ret = false;
+
+ xe_force_wake_put(gt_to_fw(gt), XE_FW_GSC);
+out:
+ xe_pm_runtime_put(xe);
+ return ret;
}
int intel_hdcp_gsc_init(struct xe_device *xe)
diff --git a/drivers/gpu/drm/xe/xe_gsc_proxy.c
b/drivers/gpu/drm/xe/xe_gsc_proxy.c
index 309ef80e3b95..1ced6b4d4946 100644
--- a/drivers/gpu/drm/xe/xe_gsc_proxy.c
+++ b/drivers/gpu/drm/xe/xe_gsc_proxy.c
@@ -66,7 +66,7 @@ static inline struct xe_device *kdev_to_xe(struct device
*kdev)
return dev_get_drvdata(kdev);
}
-static bool gsc_proxy_init_done(struct xe_gsc *gsc)
+bool xe_gsc_proxy_init_done(struct xe_gsc *gsc)
{
struct xe_gt *gt = gsc_to_gt(gsc);
u32 fwsts1 = xe_mmio_read32(gt, HECI_FWSTS1(MTL_GSC_HECI1_BASE));
@@ -528,7 +528,7 @@ int xe_gsc_proxy_start(struct xe_gsc *gsc)
if (err)
return err;
- if (!gsc_proxy_init_done(gsc)) {
+ if (!xe_gsc_proxy_init_done(gsc)) {
xe_gt_err(gsc_to_gt(gsc), "GSC FW reports proxy init not
completed\n");
return -EIO;
}
diff --git a/drivers/gpu/drm/xe/xe_gsc_proxy.h
b/drivers/gpu/drm/xe/xe_gsc_proxy.h
index 908f9441f093..c511ade6b863 100644
--- a/drivers/gpu/drm/xe/xe_gsc_proxy.h
+++ b/drivers/gpu/drm/xe/xe_gsc_proxy.h
@@ -11,6 +11,7 @@
struct xe_gsc;
int xe_gsc_proxy_init(struct xe_gsc *gsc);
+bool xe_gsc_proxy_init_done(struct xe_gsc *gsc);
void xe_gsc_proxy_remove(struct xe_gsc *gsc);
int xe_gsc_proxy_start(struct xe_gsc *gsc);
Re: [PATCH 2/5] drm/xe/hdcp: Use xe_device struct
On 2/9/2024 2:14 AM, Suraj Kandpal wrote:
Use xe_device struct instead of drm_i915_private so as to not
cause confusion and comply with Xe standards even though xe_device
gets translated to drm_i915_private.
AFAIU xe_device does not get translated to drm_i915_private, it's really
an xe_device struct under the hood.
The change itself looks ok to me, but I'll leave the final r-b to
someone on the display side to confirm this is the correct approach.
Daniele
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 0f11a39333e2..5d1d0054b578 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -3,30 +3,31 @@
* Copyright 2023, Intel Corporation.
*/
-#include "i915_drv.h"
+#include
#include "intel_hdcp_gsc.h"
+#include "xe_device_types.h"
-bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
+bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
return true;
}
-bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
+bool intel_hdcp_gsc_check_status(struct xe_device *xe)
{
return false;
}
-int intel_hdcp_gsc_init(struct drm_i915_private *i915)
+int intel_hdcp_gsc_init(struct xe_device *xe)
{
- drm_info(>drm, "HDCP support not yet implemented\n");
+ drm_dbg_kms(>drm, "HDCP support not yet implemented\n");
return -ENODEV;
}
-void intel_hdcp_gsc_fini(struct drm_i915_private *i915)
+void intel_hdcp_gsc_fini(struct xe_device *xe)
{
}
-ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8 *msg_in,
+ssize_t intel_hdcp_gsc_msg_send(struct xe_device *xe, u8 *msg_in,
size_t msg_in_len, u8 *msg_out,
size_t msg_out_len)
{
✓ Fi.CI.BAT: success for Fix crash due to open pmu events during unbind
== Series Details ==
Series: Fix crash due to open pmu events during unbind
URL : https://patchwork.freedesktop.org/series/129845/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14267 -> Patchwork_129845v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-glk-j4005 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_129845v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_psr@psr-sprite-plane-onoff}:
- {bat-arls-2}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/bat-arls-2/igt@kms_...@psr-sprite-plane-onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- {bat-arls-2}: [SKIP][2] ([i915#10208] / [i915#8809]) -> [ABORT][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14267/bat-arls-2/igt@kms_setm...@basic-clone-single-crtc.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/bat-arls-2/igt@kms_setm...@basic-clone-single-crtc.html
Known issues
Here are the changes found in Patchwork_129845v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-bsw-n3050: [PASS][4] -> [FAIL][5] ([i915#8293])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14267/fi-bsw-n3050/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/fi-bsw-n3050/boot.html
- fi-apl-guc: [PASS][6] -> [FAIL][7] ([i915#8293])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14267/fi-apl-guc/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/fi-apl-guc/boot.html
- fi-cfl-8109u: [PASS][8] -> [FAIL][9] ([i915#8293])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14267/fi-cfl-8109u/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/fi-cfl-8109u/boot.html
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- bat-mtlp-6: [DMESG-FAIL][10] -> [PASS][11] +20 other tests pass
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14267/bat-mtlp-6/igt@i915_selftest@live@gem_contexts.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/bat-mtlp-6/igt@i915_selftest@live@gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10208]: https://gitlab.freedesktop.org/drm/intel/issues/10208
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#8809]: https://gitlab.freedesktop.org/drm/intel/issues/8809
Build changes
-
* IGT: IGT_7711 -> IGTPW_10664
* Linux: CI_DRM_14267 -> Patchwork_129845v1
CI-20190529: 20190529
CI_DRM_14267: 43ab7b073fa4840f29521c57cab1f4eb161d4223 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_10664: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_10664/index.html
IGT_7711: 7711
Patchwork_129845v1: 43ab7b073fa4840f29521c57cab1f4eb161d4223 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
9b31829b0a65 i915/pmu: Cleanup pending events on unbind
4224b822ae0d i915/pmu: Add pmu_teardown helper
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129845v1/index.html
✗ Fi.CI.CHECKPATCH: warning for Fix crash due to open pmu events during unbind
== Series Details == Series: Fix crash due to open pmu events during unbind URL : https://patchwork.freedesktop.org/series/129845/ State : warning == Summary == Error: dim checkpatch failed 7b353b9e67ee i915/pmu: Add pmu_teardown helper 252db2a88e4a i915/pmu: Cleanup pending events on unbind -:33: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?) #33: Ref: https://lore.kernel.org/lkml/20240115170120.662220-1-tvrtko.ursu...@linux.intel.com/T/#me72abfa2771e6fc94b167ce47efdbf391cc313ab -:33: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'Ref:', use 'Link:' or 'Closes:' instead #33: Ref: https://lore.kernel.org/lkml/20240115170120.662220-1-tvrtko.ursu...@linux.intel.com/T/#me72abfa2771e6fc94b167ce47efdbf391cc313ab -:240: ERROR:TRAILING_WHITESPACE: trailing whitespace #240: FILE: drivers/gpu/drm/i915/i915_pmu.h:167: +^I * @work: worker to delay release of drm device reference $ total: 1 errors, 2 warnings, 0 checks, 166 lines checked
✗ Fi.CI.SPARSE: warning for Fix crash due to open pmu events during unbind
== Series Details == Series: Fix crash due to open pmu events during unbind URL : https://patchwork.freedesktop.org/series/129845/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
Hi Uma,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240213]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
linus/master v6.8-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-defconfig
(https://download.01.org/0day-ci/archive/20240214/202402140432.nufiowye-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240214/202402140432.nufiowye-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402140432.nufiowye-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_colorop.c:268: warning: Function parameter or struct
>> member 'type' not described in 'drm_get_colorop_curve_1d_type_name'
drivers/gpu/drm/drm_colorop.c:268: warning: Excess function parameter
'range' description in 'drm_get_colorop_curve_1d_type_name'
vim +268 drivers/gpu/drm/drm_colorop.c
259
260 /**
261 * drm_get_colorop_curve_1d_type_name - return a string for 1D curve
type
262 * @range: 1d curve type to compute name of
263 *
264 * In contrast to the other drm_get_*_name functions this one here
returns a
265 * const pointer and hence is threadsafe.
266 */
267 const char *drm_get_colorop_curve_1d_type_name(enum
drm_colorop_curve_1d_type type)
> 268 {
269 if (WARN_ON(type >= ARRAY_SIZE(colorop_curve_1d_type_name)))
270 return "unknown";
271
272 return colorop_curve_1d_type_name[type];
273 }
274
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
✓ Fi.CI.BAT: success for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details ==
Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling
code
URL : https://patchwork.freedesktop.org/series/129835/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14266 -> Patchwork_129835v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129835v1/index.html
Participating hosts (38 -> 35)
--
Missing(3): bat-jsl-1 fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_129835v1 that come from known issues:
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
Build changes
-
* Linux: CI_DRM_14266 -> Patchwork_129835v1
CI-20190529: 20190529
CI_DRM_14266: f16ab0ed5e0f1f8d26a88cab8854ed609283906e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7711: 7711
Patchwork_129835v1: f16ab0ed5e0f1f8d26a88cab8854ed609283906e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7176e61dff99 drm/tests/drm_buddy: add alloc_contiguous test
5f26c4e06ea9 drm/buddy: Fix alloc_range() error handling code
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129835v1/index.html
✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details == Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling code URL : https://patchwork.freedesktop.org/series/129835/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/buddy: Fix alloc_range() error handling code
== Series Details == Series: series starting with [1/2] drm/buddy: Fix alloc_range() error handling code URL : https://patchwork.freedesktop.org/series/129835/ State : warning == Summary == Error: dim checkpatch failed c8e823c34dcc drm/buddy: Fix alloc_range() error handling code dd0bc4e07514 drm/tests/drm_buddy: add alloc_contiguous test -:11: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use 'Link:' or 'Closes:' instead #11: References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097 total: 0 errors, 1 warnings, 0 checks, 107 lines checked
Re: [PATCH 2/2] i915/pmu: Cleanup pending events on unbind
On Tue, Feb 13, 2024 at 08:36:43PM +0200, Jani Nikula wrote:
On Tue, 13 Feb 2024, Umesh Nerlige Ramappa
wrote:
Once a user opens an fd for a perf event, if the driver undergoes a
function level reset (FLR), the resources are not cleaned up as
expected. For this discussion FLR is defined as a PCI unbind followed by
a bind. perf_pmu_unregister() would cleanup everything, but when the user
closes the perf fd, perf_release is executed and we encounter null
pointer dereferences and/or list corruption in that path which require a
reboot to recover.
The only approach that worked to resolve this was to close the file
associated with the event such that the relevant cleanup happens w.r.t.
the open file. To do so, use the event->owner task and find the file
relevant to the event and close it. This relies on the
file->private_data matching the event object.
Note:
- Closing the event file is a delayed work that gets queued to system_wq.
The close is seen to happen when kernel returns to user space following
the unbind.
- perf framework will access the pmu object after the last event has
been destroyed. The drm device is refcounted in the init and destroy
hooks, so this causes a use after free if we are releasing the drm
device reference after unbind has been called. To work around this, we
take an extra reference in the unbind path and release it using a
delayed work in the destroy patch. The delayed work is queued to
system_wq.
Ref:
https://lore.kernel.org/lkml/20240115170120.662220-1-tvrtko.ursu...@linux.intel.com/T/#me72abfa2771e6fc94b167ce47efdbf391cc313ab
Opens:
- Synchronization may be needed between i915_pmu_unregister and
i915_pmu_event_destroy to avoid any races.
- If unbind and bind happen from the same process the event fd is closed
after bind completes. This means that the cleanup would not happen
until bind completes. In this case, i915 loads fine, but pmu
registration fails with an error that the sysfs entries are already
present. There is no solution feasible here. Since this is not a fatal
error (reloading i915 works fine) and the usual case is to have bind and
unbind in separate processes, there is no intention to solve this.
Other solutions/aspects tried:
- Call perf_event_disable() followed by perf_event_release_kernel() in
the unbind path to clean up the events. This still causes issues when
user closes the fd since perf_event_release_kernel() is called again and
fails requiring reboot.
- Close all event fds in unbind and wait for the close to complete by
checking if list is empty. This wait does not work since the files
are actually closed when unbind returns to user space.
Testing:
- New IGT tests have been added for this and are run with KASAN and
kmemleak enabled.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_pmu.c | 96 -
drivers/gpu/drm/i915/i915_pmu.h | 15 ++
2 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4d2a289f848a..2f365c7f5db7 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -4,6 +4,8 @@
* Copyright © 2017-2018 Intel Corporation
*/
+#include
+#include
#include
#include "gt/intel_engine.h"
@@ -573,9 +575,21 @@ static void i915_pmu_event_destroy(struct perf_event
*event)
{
struct i915_pmu *pmu = event_to_pmu(event);
struct drm_i915_private *i915 = pmu_to_i915(pmu);
+ struct i915_event *e = event->pmu_private;
drm_WARN_ON(>drm, event->parent);
+ if (e) {
+ event->pmu_private = NULL;
+ list_del(>link);
+ kfree(e);
+ }
+
+ if (i915->pmu.closed && list_empty(>pmu.initialized_events)) {
+ pmu_teardown(>pmu);
+ mod_delayed_work(system_wq, >pmu.work, 50);
+ }
+
drm_dev_put(>drm);
}
@@ -684,6 +698,14 @@ static int i915_pmu_event_init(struct perf_event *event)
return ret;
if (!event->parent) {
+ struct i915_event *e = kzalloc(sizeof(*e), GFP_KERNEL);
+
+ if (!e)
+ return -ENOMEM;
+
+ e->event = event;
+ list_add(>link, >initialized_events);
+ event->pmu_private = e;
drm_dev_get(>drm);
event->destroy = i915_pmu_event_destroy;
}
@@ -1256,6 +1278,14 @@ void i915_pmu_exit(void)
cpuhp_remove_multi_state(cpuhp_slot);
}
+static void i915_pmu_release(struct work_struct *work)
+{
+ struct i915_pmu *pmu = container_of(work, typeof(*pmu), work.work);
+ struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
+
+ drm_dev_put(>drm);
+}
+
void i915_pmu_register(struct drm_i915_private *i915)
{
struct i915_pmu *pmu = >pmu;
@@ -1313,6 +1343,9 @@ void i915_pmu_register(struct drm_i915_private *i915)
pmu->base.read =
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On Fri, 2024-02-09 at 09:06 +, Tvrtko Ursulin wrote:
> On 08/02/2024 17:55, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> > > On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > > > On 08/02/2024 14:30, Souza, Jose wrote:
> > > > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin
> > > > > >
> > > > > > Add a new query to the GuC submission interface version.
> > > > > >
> > > > > > Mesa intends to use this information to check for old firmware
> > > > > > versions
> > > > > > with a known bug where using the render and compute command
> > > > > > streamers
> > > > > > simultaneously can cause GPU hangs due issues in firmware
> > > > > > scheduling.
> > > > > >
> > > > > > Based on patches from Vivaik and Joonas.
> > > > > >
> > > > > > Compile tested only.
> > > > > >
> > > > > > v2:
> > > > > >* Added branch version.
> > > > >
> > > > > Reviewed-by: José Roberto de Souza
> > > > > Tested-by: José Roberto de Souza
> > > > > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> > > >
> > > > Thanks, but please we also need to close down on the branch number
> > > > situation. I.e. be sure what is the failure mode in shipping Mesa with
> > > > the change as it stands in the MR linked. What platforms could start
> > > > failing and when, depending on GuC FW release eventualities.
> > >
> > > yes, I have asked John Harrison for a documentation link about the
> > > firmware versioning.
> >
> > Got the documentation link, MR updated.
> > Will ask for reviews in Mesa side.
>
> Is it then understood and accepted that should GuC ever update the
> branch number on any given platform, that platform, for all deployed
> Mesa's in the field, will automatically revert to no async queues and so
> cause a silent performance regression?
yes, understood and accepted.
The Mesa MR is now reviewed, thank you Sagar.
>
> Regards,
>
> Tvrtko
>
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Tvrtko
> > > >
> > > > > > Signed-off-by: Tvrtko Ursulin
> > > > > > Cc: Kenneth Graunke
> > > > > > Cc: Jose Souza
> > > > > > Cc: Sagar Ghuge
> > > > > > Cc: Paulo Zanoni
> > > > > > Cc: John Harrison
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Jani Nikula
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: Vivaik Balasubrawmanian
> > > > > > Cc: Joonas Lahtinen
> > > > > > ---
> > > > > >drivers/gpu/drm/i915/i915_query.c | 33
> > > > > > +++
> > > > > >include/uapi/drm/i915_drm.h | 12 +++
> > > > > >2 files changed, 45 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > > > index 00871ef99792..d4dba1240b40 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct
> > > > > > drm_i915_private *i915,
> > > > > > return hwconfig->size;
> > > > > >}
> > > > > >
> > > > > > +static int
> > > > > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > > > > +struct drm_i915_query_item *query)
> > > > > > +{
> > > > > > + struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > > > > +
> > > > > > u64_to_user_ptr(query->data_ptr);
> > > > > > + struct drm_i915_query_guc_submission_version ver;
> > > > > > + struct intel_guc *guc = _gt(i915)->uc.guc;
> > > > > > + const size_t size = sizeof(ver);
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > > > > + return -ENODEV;
> > > > > > +
> > > > > > + ret = copy_query_item(, size, size, query);
> > > > > > + if (ret != 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + if (ver.branch || ver.major || ver.minor || ver.patch)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + ver.branch = 0;
> > > > > > + ver.major = guc->submission_version.major;
> > > > > > + ver.minor = guc->submission_version.minor;
> > > > > > + ver.patch = guc->submission_version.patch;
> > > > > > +
> > > > > > + if (copy_to_user(query_ptr, , size))
> > > > > > + return -EFAULT;
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > >static int (* const i915_query_funcs[])(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > struct drm_i915_query_item
> > > > > > *query_item) = {
> > > > > > query_topology_info,
> > > > > > @@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > > query_memregion_info,
> > > > > > query_hwconfig_blob,
> > > > > > query_geometry_subslices,
> > > > > > + query_guc_submission_version,
> > > > > >
Re: [PATCH 2/2] i915/pmu: Cleanup pending events on unbind
On Tue, 13 Feb 2024, Umesh Nerlige Ramappa
wrote:
> Once a user opens an fd for a perf event, if the driver undergoes a
> function level reset (FLR), the resources are not cleaned up as
> expected. For this discussion FLR is defined as a PCI unbind followed by
> a bind. perf_pmu_unregister() would cleanup everything, but when the user
> closes the perf fd, perf_release is executed and we encounter null
> pointer dereferences and/or list corruption in that path which require a
> reboot to recover.
>
> The only approach that worked to resolve this was to close the file
> associated with the event such that the relevant cleanup happens w.r.t.
> the open file. To do so, use the event->owner task and find the file
> relevant to the event and close it. This relies on the
> file->private_data matching the event object.
>
> Note:
> - Closing the event file is a delayed work that gets queued to system_wq.
> The close is seen to happen when kernel returns to user space following
> the unbind.
>
> - perf framework will access the pmu object after the last event has
> been destroyed. The drm device is refcounted in the init and destroy
> hooks, so this causes a use after free if we are releasing the drm
> device reference after unbind has been called. To work around this, we
> take an extra reference in the unbind path and release it using a
> delayed work in the destroy patch. The delayed work is queued to
> system_wq.
>
> Ref:
> https://lore.kernel.org/lkml/20240115170120.662220-1-tvrtko.ursu...@linux.intel.com/T/#me72abfa2771e6fc94b167ce47efdbf391cc313ab
>
> Opens:
> - Synchronization may be needed between i915_pmu_unregister and
> i915_pmu_event_destroy to avoid any races.
>
> - If unbind and bind happen from the same process the event fd is closed
> after bind completes. This means that the cleanup would not happen
> until bind completes. In this case, i915 loads fine, but pmu
> registration fails with an error that the sysfs entries are already
> present. There is no solution feasible here. Since this is not a fatal
> error (reloading i915 works fine) and the usual case is to have bind and
> unbind in separate processes, there is no intention to solve this.
>
> Other solutions/aspects tried:
> - Call perf_event_disable() followed by perf_event_release_kernel() in
> the unbind path to clean up the events. This still causes issues when
> user closes the fd since perf_event_release_kernel() is called again and
> fails requiring reboot.
>
> - Close all event fds in unbind and wait for the close to complete by
> checking if list is empty. This wait does not work since the files
> are actually closed when unbind returns to user space.
>
> Testing:
> - New IGT tests have been added for this and are run with KASAN and
> kmemleak enabled.
>
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 96 -
> drivers/gpu/drm/i915/i915_pmu.h | 15 ++
> 2 files changed, 110 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 4d2a289f848a..2f365c7f5db7 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -4,6 +4,8 @@
> * Copyright © 2017-2018 Intel Corporation
> */
>
> +#include
> +#include
> #include
>
> #include "gt/intel_engine.h"
> @@ -573,9 +575,21 @@ static void i915_pmu_event_destroy(struct perf_event
> *event)
> {
> struct i915_pmu *pmu = event_to_pmu(event);
> struct drm_i915_private *i915 = pmu_to_i915(pmu);
> + struct i915_event *e = event->pmu_private;
>
> drm_WARN_ON(>drm, event->parent);
>
> + if (e) {
> + event->pmu_private = NULL;
> + list_del(>link);
> + kfree(e);
> + }
> +
> + if (i915->pmu.closed && list_empty(>pmu.initialized_events)) {
> + pmu_teardown(>pmu);
> + mod_delayed_work(system_wq, >pmu.work, 50);
> + }
> +
> drm_dev_put(>drm);
> }
>
> @@ -684,6 +698,14 @@ static int i915_pmu_event_init(struct perf_event *event)
> return ret;
>
> if (!event->parent) {
> + struct i915_event *e = kzalloc(sizeof(*e), GFP_KERNEL);
> +
> + if (!e)
> + return -ENOMEM;
> +
> + e->event = event;
> + list_add(>link, >initialized_events);
> + event->pmu_private = e;
> drm_dev_get(>drm);
> event->destroy = i915_pmu_event_destroy;
> }
> @@ -1256,6 +1278,14 @@ void i915_pmu_exit(void)
> cpuhp_remove_multi_state(cpuhp_slot);
> }
>
> +static void i915_pmu_release(struct work_struct *work)
> +{
> + struct i915_pmu *pmu = container_of(work, typeof(*pmu), work.work);
> + struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
> +
> + drm_dev_put(>drm);
> +}
> +
> void i915_pmu_register(struct drm_i915_private *i915)
> {
> struct i915_pmu *pmu = >pmu;
>
Re: [RFC 4/4] drm/i915/display/dp: On LT failure retry LT
On Tue, 06 Feb 2024, Arun R Murthy wrote:
> On link training failure retry link training with a lesser link
> rate/lane count as specified in the DP spec.
>
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ed7620e7f763..29d785a4b904 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2502,6 +2502,7 @@ static void mtl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>crtc_state->port_clock,
>crtc_state->lane_count);
>
> +retry:
> /*
>* We only configure what the register value will be here. Actual
>* enabling happens during link training farther down.
> @@ -2586,7 +2587,14 @@ static void mtl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>* Pattern, wait for 5 idle patterns (DP_TP_STATUS Min_Idles_Sent)
>* (timeout after 800 us)
>*/
> - intel_dp_start_link_train(intel_dp, crtc_state);
> + if (!intel_dp_start_link_train(intel_dp, crtc_state)) {
> + /* Link Training failed, retain */
> + intel_dp->link_trained = false;
> + intel_dp_stop_link_train(intel_dp, crtc_state);
> + encoder->post_disable(state, encoder,
> +crtc_state, conn_state);
> + goto retry;
> + }
As said, the retry needs to go via userspace.
BR,
Jani.
>
> /* 6.n Set DP_TP_CTL link training to Normal */
> if (!is_trans_port_sync_mode(crtc_state))
--
Jani Nikula, Intel
Re: [RFC 3/4] drm/i915/dp: use link rate and lane count in intel_dp struct
On Tue, 06 Feb 2024, Arun R Murthy wrote:
> The link rate and lane count are now part of the intel_crtc_state
> structure. These two parameters are nothing to do with the crtc and are
> more confined to DP.
As said offline, the parameters were specifically added to crtc state
for both atomic and the state checker.
No go.
BR,
Jani.
>
> TODO: Need to still seperate out the use of link rate and port clock
> which is in intel_dp and intel_crtc_state structure.
>
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 16 ++--
> drivers/gpu/drm/i915/display/intel_ddi.c | 21 ++---
> .../drm/i915/display/intel_ddi_buf_trans.c| 7 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 8 +-
> drivers/gpu/drm/i915/display/intel_dp.h | 2 +-
> .../drm/i915/display/intel_dp_link_training.c | 81 ++-
> .../drm/i915/display/intel_dp_link_training.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 ---
> 8 files changed, 92 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 288a00e083c8..cde8f26ba26b 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -414,6 +414,7 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder
> *encoder,
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> const struct intel_ddi_buf_trans *trans;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> enum phy phy = intel_port_to_phy(i915, encoder->port);
> u8 owned_lane_mask;
> intel_wakeref_t wakeref;
> @@ -446,7 +447,7 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder
> *encoder,
> MB_WRITE_COMMITTED);
> }
>
> - for (ln = 0; ln < crtc_state->lane_count; ln++) {
> + for (ln = 0; ln < intel_dp->lane_count; ln++) {
> int level = intel_ddi_level(encoder, crtc_state, ln);
> int lane = ln / 2;
> int tx = ln % 2;
> @@ -2327,10 +2328,11 @@ static void intel_c20_pll_program(struct
> drm_i915_private *i915,
> const struct intel_crtc_state *crtc_state,
> struct intel_encoder *encoder)
> {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> const struct intel_c20pll_state *pll_state =
> _state->cx0pll_state.c20;
> bool dp = false;
> - int lane = crtc_state->lane_count > 2 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> - u32 clock = crtc_state->port_clock;
> + int lane = intel_dp->lane_count > 2 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> + u32 clock = intel_dp->link_rate;
> bool cntx;
> int i;
>
> @@ -2455,6 +2457,7 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
>const struct intel_crtc_state
> *crtc_state,
>bool lane_reversal)
> {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> u32 val = 0;
>
> @@ -2475,7 +2478,7 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
>
> /* TODO: HDMI FRL */
> /* DP2.0 10G and 20G rates enable MPLLA*/
> - if (crtc_state->port_clock == 100 || crtc_state->port_clock ==
> 200)
> + if (intel_dp->link_rate == 100 || intel_dp->link_rate == 200)
> val |= crtc_state->cx0pll_state.ssc_enabled ?
> XELPDP_SSC_ENABLE_PLLA : 0;
> else
> val |= crtc_state->cx0pll_state.ssc_enabled ?
> XELPDP_SSC_ENABLE_PLLB : 0;
> @@ -2705,6 +2708,7 @@ static void intel_cx0pll_enable(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> enum phy phy = intel_port_to_phy(i915, encoder->port);
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
> @@ -2744,7 +2748,7 @@ static void intel_cx0pll_enable(struct intel_encoder
> *encoder,
>* 6. Program the enabled and disabled owned PHY lane
>* transmitters over message bus
>*/
> - intel_cx0_program_phy_lane(i915, encoder, crtc_state->lane_count,
> lane_reversal);
> + intel_cx0_program_phy_lane(i915, encoder, intel_dp->lane_count,
> lane_reversal);
>
> /*
>* 7. Follow the Display Voltage Frequency Switching - Sequence
> @@ -2756,7 +2760,7 @@ static void intel_cx0pll_enable(struct intel_encoder
> *encoder,
>* clock frequency.
>*/
> intel_de_write(i915, DDI_CLK_VALFREQ(encoder->port),
> -
Re: [RFC 1/4] drm/i915/display/dp: Add DP fallback on LT
On Tue, 06 Feb 2024, Arun R Murthy wrote:
> Fallback mandates on DP link training failure. This patch just covers
> the DP2.0 fallback sequence.
>
> TODO: Need to implement the DP1.4 fallback.
>
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 92 ++---
> 1 file changed, 82 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 10ec231acd98..82d354a6b0cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -104,6 +104,50 @@ static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
> */
> static const u8 valid_dsc_slicecount[] = {1, 2, 4};
>
> +/* DL Link Rates */
> +#define UHBR20 200
> +#define UHBR13P5 135
> +#define UHBR10 100
> +#define HBR3 81
> +#define HBR2 54
> +#define HBR 27
> +#define RBR 162000
> +
> +/* DP Lane Count */
> +#define LANE_COUNT_4 4
> +#define LANE_COUNT_2 2
> +#define LANE_COUNT_1 1
> +
> +/* DP2.0 fallback values */
> +struct dp_fallback {
> + u32 link_rate;
> + u8 lane_count;
> +};
> +
> +struct dp_fallback dp2dot0_fallback[] = {
> + {UHBR20, LANE_COUNT_4},
> + {UHBR13P5, LANE_COUNT_4},
> + {UHBR20, LANE_COUNT_2},
> + {UHBR10, LANE_COUNT_4},
> + {UHBR13P5, LANE_COUNT_2},
> + {HBR3, LANE_COUNT_4},
> + {UHBR20, LANE_COUNT_1},
> + {UHBR10, LANE_COUNT_2},
> + {HBR2, LANE_COUNT_4},
> + {UHBR13P5, LANE_COUNT_1},
> + {HBR3, LANE_COUNT_2},
> + {UHBR10, LANE_COUNT_1},
> + {HBR2, LANE_COUNT_2},
> + {HBR, LANE_COUNT_4},
> + {HBR3, LANE_COUNT_1},
> + {RBR, LANE_COUNT_4},
> + {HBR2, LANE_COUNT_1},
> + {HBR, LANE_COUNT_2},
> + {RBR, LANE_COUNT_2},
> + {HBR, LANE_COUNT_1},
> + {RBR, LANE_COUNT_1},
> +};
> +
> /**
> * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU
> or PCH)
> * @intel_dp: DP struct
> @@ -299,6 +343,19 @@ static int intel_dp_common_len_rate_limit(const struct
> intel_dp *intel_dp,
> intel_dp->num_common_rates, max_rate);
> }
>
> +static bool intel_dp_link_rate_supported(struct intel_dp *intel_dp, u32
> link_rate)
> +{
> + u8 i;
> +
> + for (i = 0; i < ARRAY_SIZE(intel_dp->common_rates); i++) {
> + if (intel_dp->common_rates[i] == link_rate)
> + return true;
> + else
> + continue;
> + }
> + return false;
> +}
> +
> static int intel_dp_common_rate(struct intel_dp *intel_dp, int index)
> {
> if (drm_WARN_ON(_to_i915(intel_dp)->drm,
> @@ -671,15 +728,6 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> int index;
>
> - /*
> - * TODO: Enable fallback on MST links once MST link compute can handle
> - * the fallback params.
> - */
> - if (intel_dp->is_mst) {
> - drm_err(>drm, "Link Training Unsuccessful\n");
> - return -1;
> - }
> -
By removing this, the claim is both 8b/10b and 128b/132b DP MST link
training fallbacks work...
> if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> drm_dbg_kms(>drm,
> "Retrying Link training for eDP with max
> parameters\n");
> @@ -687,6 +735,31 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> return 0;
> }
>
> + /* DP fallback values */
> + if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B)
> {
...but this only addresses 128b/132b, and the 8b/10b MST drops to the
existing SST fallback path.
And with the current code, DP_CAP_ANSI_128B132B does not decide whether
we use DP MST or not. So this will also cover 8b/10b fallback for
displays that support 128b/132b but have DP_MSTM_CAP == 0.
> + for(index = 0; index < ARRAY_SIZE(dp2dot0_fallback); index++) {
> + if (link_rate == dp2dot0_fallback[index].link_rate &&
> + lane_count ==
> dp2dot0_fallback[index].lane_count) {
> + for(index += 1; index <
> ARRAY_SIZE(dp2dot0_fallback); index++) {
I honestly do not understand the double looping here, and how index is
managed.
> + if
> (intel_dp_link_rate_supported(intel_dp,
> +
> dp2dot0_fallback[index].link_rate)) {
> +
> intel_dp_set_link_params(intel_dp,
> +
> dp2dot0_fallback[index].link_rate,
> +
> dp2dot0_fallback[index].lane_count);
intel_dp_set_link_params() is supposed to be called
Re: [PATCH 0/2] Fix crash due to open pmu events during unbind
Resending to include patch 2/2. Please ignore this series. On Mon, Feb 12, 2024 at 10:46:48PM -0800, Umesh Nerlige Ramappa wrote: Once a user opens an fd for a perf event, if the driver undergoes a function level reset (FLR), the resources are not cleaned up as expected. For this discussion FLR is defined as a PCI unbind followed by a bind. perf_pmu_unregister() would cleanup everything, but when the user closes the perf fd much later, perf_release() is called and we encounter null pointer dereferences and/or list corruption in that path which require a reboot to recover. The only approach that worked to resolve this was to close the file associated with the event such that the relevant cleanup happens w.r.t. the open file. To do so, use the event->owner task and find the file relevant to the event and close it. This relies on the file->private_data matching the event object. Test-with: 20240213062948.32735-1-umesh.nerlige.rama...@intel.com Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (2): i915/pmu: Add pmu_teardown helper INTEL_DII: i915/pmu: Cleanup pending events on unbind drivers/gpu/drm/i915/i915_pmu.c | 192 drivers/gpu/drm/i915/i915_pmu.h | 15 +++ 2 files changed, 161 insertions(+), 46 deletions(-) -- 2.34.1
[PATCH 0/2] Fix crash due to open pmu events during unbind
Once a user opens an fd for a perf event, if the driver undergoes a function level reset (FLR), the resources are not cleaned up as expected. For this discussion FLR is defined as a PCI unbind followed by a bind. perf_pmu_unregister() would cleanup everything, but when the user closes the perf fd much later, perf_release() is called and we encounter null pointer dereferences and/or list corruption in that path which require a reboot to recover. The only approach that worked to resolve this was to close the file associated with the event such that the relevant cleanup happens w.r.t. the open file. To do so, use the event->owner task and find the file relevant to the event and close it. This relies on the file->private_data matching the event object. Test-with: 20240213062948.32735-1-umesh.nerlige.rama...@intel.com Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (2): i915/pmu: Add pmu_teardown helper i915/pmu: Cleanup pending events on unbind drivers/gpu/drm/i915/i915_pmu.c | 192 drivers/gpu/drm/i915/i915_pmu.h | 15 +++ 2 files changed, 161 insertions(+), 46 deletions(-) -- 2.34.1
[PATCH 1/2] i915/pmu: Add pmu_teardown helper
Move pmu teardown to a helper and place it above the destroy hook so
that teardown can also happen inside destroy when events are closed
after i915 pmu is unregistered.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_pmu.c | 106 +---
1 file changed, 56 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 21eb0c5b320d..4d2a289f848a 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -514,6 +514,61 @@ static enum hrtimer_restart i915_sample(struct hrtimer
*hrtimer)
return HRTIMER_RESTART;
}
+static enum cpuhp_state cpuhp_slot = CPUHP_INVALID;
+
+static int i915_pmu_register_cpuhp_state(struct i915_pmu *pmu)
+{
+ if (cpuhp_slot == CPUHP_INVALID)
+ return -EINVAL;
+
+ return cpuhp_state_add_instance(cpuhp_slot, >cpuhp.node);
+}
+
+static void i915_pmu_unregister_cpuhp_state(struct i915_pmu *pmu)
+{
+ cpuhp_state_remove_instance(cpuhp_slot, >cpuhp.node);
+}
+
+static void free_event_attributes(struct i915_pmu *pmu)
+{
+ struct attribute **attr_iter = pmu->events_attr_group.attrs;
+
+ for (; *attr_iter; attr_iter++)
+ kfree((*attr_iter)->name);
+
+ kfree(pmu->events_attr_group.attrs);
+ kfree(pmu->i915_attr);
+ kfree(pmu->pmu_attr);
+
+ pmu->events_attr_group.attrs = NULL;
+ pmu->i915_attr = NULL;
+ pmu->pmu_attr = NULL;
+}
+
+static bool is_igp(struct drm_i915_private *i915)
+{
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+
+ /* IGP is :00:02.0 */
+ return pci_domain_nr(pdev->bus) == 0 &&
+ pdev->bus->number == 0 &&
+ PCI_SLOT(pdev->devfn) == 2 &&
+ PCI_FUNC(pdev->devfn) == 0;
+}
+
+static void pmu_teardown(struct i915_pmu *pmu)
+{
+ struct drm_i915_private *i915 = pmu_to_i915(pmu);
+
+ i915_pmu_unregister_cpuhp_state(pmu);
+ perf_pmu_unregister(>base);
+ pmu->base.event_init = NULL;
+ kfree(pmu->base.attr_groups);
+ if (!is_igp(i915))
+ kfree(pmu->name);
+ free_event_attributes(pmu);
+}
+
static void i915_pmu_event_destroy(struct perf_event *event)
{
struct i915_pmu *pmu = event_to_pmu(event);
@@ -1133,22 +1188,6 @@ err:;
return NULL;
}
-static void free_event_attributes(struct i915_pmu *pmu)
-{
- struct attribute **attr_iter = pmu->events_attr_group.attrs;
-
- for (; *attr_iter; attr_iter++)
- kfree((*attr_iter)->name);
-
- kfree(pmu->events_attr_group.attrs);
- kfree(pmu->i915_attr);
- kfree(pmu->pmu_attr);
-
- pmu->events_attr_group.attrs = NULL;
- pmu->i915_attr = NULL;
- pmu->pmu_attr = NULL;
-}
-
static int i915_pmu_cpu_online(unsigned int cpu, struct hlist_node *node)
{
struct i915_pmu *pmu = hlist_entry_safe(node, typeof(*pmu), cpuhp.node);
@@ -1194,8 +1233,6 @@ static int i915_pmu_cpu_offline(unsigned int cpu, struct
hlist_node *node)
return 0;
}
-static enum cpuhp_state cpuhp_slot = CPUHP_INVALID;
-
int i915_pmu_init(void)
{
int ret;
@@ -1219,30 +1256,6 @@ void i915_pmu_exit(void)
cpuhp_remove_multi_state(cpuhp_slot);
}
-static int i915_pmu_register_cpuhp_state(struct i915_pmu *pmu)
-{
- if (cpuhp_slot == CPUHP_INVALID)
- return -EINVAL;
-
- return cpuhp_state_add_instance(cpuhp_slot, >cpuhp.node);
-}
-
-static void i915_pmu_unregister_cpuhp_state(struct i915_pmu *pmu)
-{
- cpuhp_state_remove_instance(cpuhp_slot, >cpuhp.node);
-}
-
-static bool is_igp(struct drm_i915_private *i915)
-{
- struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
-
- /* IGP is :00:02.0 */
- return pci_domain_nr(pdev->bus) == 0 &&
- pdev->bus->number == 0 &&
- PCI_SLOT(pdev->devfn) == 2 &&
- PCI_FUNC(pdev->devfn) == 0;
-}
-
void i915_pmu_register(struct drm_i915_private *i915)
{
struct i915_pmu *pmu = >pmu;
@@ -1341,12 +1354,5 @@ void i915_pmu_unregister(struct drm_i915_private *i915)
hrtimer_cancel(>timer);
- i915_pmu_unregister_cpuhp_state(pmu);
-
- perf_pmu_unregister(>base);
- pmu->base.event_init = NULL;
- kfree(pmu->base.attr_groups);
- if (!is_igp(i915))
- kfree(pmu->name);
- free_event_attributes(pmu);
+ pmu_teardown(pmu);
}
--
2.34.1
[PATCH 2/2] i915/pmu: Cleanup pending events on unbind
Once a user opens an fd for a perf event, if the driver undergoes a
function level reset (FLR), the resources are not cleaned up as
expected. For this discussion FLR is defined as a PCI unbind followed by
a bind. perf_pmu_unregister() would cleanup everything, but when the user
closes the perf fd, perf_release is executed and we encounter null
pointer dereferences and/or list corruption in that path which require a
reboot to recover.
The only approach that worked to resolve this was to close the file
associated with the event such that the relevant cleanup happens w.r.t.
the open file. To do so, use the event->owner task and find the file
relevant to the event and close it. This relies on the
file->private_data matching the event object.
Note:
- Closing the event file is a delayed work that gets queued to system_wq.
The close is seen to happen when kernel returns to user space following
the unbind.
- perf framework will access the pmu object after the last event has
been destroyed. The drm device is refcounted in the init and destroy
hooks, so this causes a use after free if we are releasing the drm
device reference after unbind has been called. To work around this, we
take an extra reference in the unbind path and release it using a
delayed work in the destroy patch. The delayed work is queued to
system_wq.
Ref:
https://lore.kernel.org/lkml/20240115170120.662220-1-tvrtko.ursu...@linux.intel.com/T/#me72abfa2771e6fc94b167ce47efdbf391cc313ab
Opens:
- Synchronization may be needed between i915_pmu_unregister and
i915_pmu_event_destroy to avoid any races.
- If unbind and bind happen from the same process the event fd is closed
after bind completes. This means that the cleanup would not happen
until bind completes. In this case, i915 loads fine, but pmu
registration fails with an error that the sysfs entries are already
present. There is no solution feasible here. Since this is not a fatal
error (reloading i915 works fine) and the usual case is to have bind and
unbind in separate processes, there is no intention to solve this.
Other solutions/aspects tried:
- Call perf_event_disable() followed by perf_event_release_kernel() in
the unbind path to clean up the events. This still causes issues when
user closes the fd since perf_event_release_kernel() is called again and
fails requiring reboot.
- Close all event fds in unbind and wait for the close to complete by
checking if list is empty. This wait does not work since the files
are actually closed when unbind returns to user space.
Testing:
- New IGT tests have been added for this and are run with KASAN and
kmemleak enabled.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_pmu.c | 96 -
drivers/gpu/drm/i915/i915_pmu.h | 15 ++
2 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4d2a289f848a..2f365c7f5db7 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -4,6 +4,8 @@
* Copyright © 2017-2018 Intel Corporation
*/
+#include
+#include
#include
#include "gt/intel_engine.h"
@@ -573,9 +575,21 @@ static void i915_pmu_event_destroy(struct perf_event
*event)
{
struct i915_pmu *pmu = event_to_pmu(event);
struct drm_i915_private *i915 = pmu_to_i915(pmu);
+ struct i915_event *e = event->pmu_private;
drm_WARN_ON(>drm, event->parent);
+ if (e) {
+ event->pmu_private = NULL;
+ list_del(>link);
+ kfree(e);
+ }
+
+ if (i915->pmu.closed && list_empty(>pmu.initialized_events)) {
+ pmu_teardown(>pmu);
+ mod_delayed_work(system_wq, >pmu.work, 50);
+ }
+
drm_dev_put(>drm);
}
@@ -684,6 +698,14 @@ static int i915_pmu_event_init(struct perf_event *event)
return ret;
if (!event->parent) {
+ struct i915_event *e = kzalloc(sizeof(*e), GFP_KERNEL);
+
+ if (!e)
+ return -ENOMEM;
+
+ e->event = event;
+ list_add(>link, >initialized_events);
+ event->pmu_private = e;
drm_dev_get(>drm);
event->destroy = i915_pmu_event_destroy;
}
@@ -1256,6 +1278,14 @@ void i915_pmu_exit(void)
cpuhp_remove_multi_state(cpuhp_slot);
}
+static void i915_pmu_release(struct work_struct *work)
+{
+ struct i915_pmu *pmu = container_of(work, typeof(*pmu), work.work);
+ struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
+
+ drm_dev_put(>drm);
+}
+
void i915_pmu_register(struct drm_i915_private *i915)
{
struct i915_pmu *pmu = >pmu;
@@ -1313,6 +1343,9 @@ void i915_pmu_register(struct drm_i915_private *i915)
pmu->base.read = i915_pmu_event_read;
pmu->base.event_idx = i915_pmu_event_event_idx;
+ INIT_LIST_HEAD(>initialized_events);
+
Re: [PATCH 1/2] drm/i915/fbc: Don't use a fence for a plane if FBC is not possible
On Tue, 2024-01-23 at 11:00 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > No point in wasting a fence on a plane if it can't do FBC anyway. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Vinod Govindapillai > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index a92e959c8ac7..96a31d73f869 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -533,7 +533,7 @@ bool intel_plane_uses_fence(const struct > intel_plane_state *plane_state) > struct drm_i915_private *dev_priv = to_i915(plane->base.dev); > > return DISPLAY_VER(dev_priv) < 4 || > - (plane->fbc && > + (plane->fbc && !plane_state->no_fbc_reason && > plane_state->view.gtt.type == I915_GTT_VIEW_NORMAL); > } >
Re: [PATCH 6/6] drm/i915: do not defer cleanup work
On Mon, Feb 05, 2024 at 03:40:53PM +0530, Chaitanya Kumar Borah wrote:
> After we move the cursor fb unpin to a vblank work, we encounter
> race conditions between the vblank work and the atomic clean up
> work leading to dump stacks[1]. Let's serialize the clean up
> to avoid theses races.
This needs to be properly root caused, not just duct taped over.
>
> [1]
>
>[ 278.748767] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
>[ 278.749115] RIP: 0010:intel_display_rps_mark_interactive+0x4/0x40 [i915]
>[ 278.749425] Code: 92 cb 20 e1 e9 49 ff ff ff 5b 48 89 ef 5d 41 5c e9 11
> 23 44 e1 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 <38>
> 96 a5 05 00 00 74 2a 55 48 89 f5 0f b6 f2 53 48 8b bf 40 37 00
>[ 278.749428] RSP: 0018:c929fdc8 EFLAGS: 00010246
>[ 278.749433] RAX: 0060 RBX: RCX:
>
>[ 278.749435] RDX: RSI: RDI:
> 888124d7
>[ 278.749438] RBP: 88810394c000 R08: R09:
> c929fc80
>[ 278.749441] R10: 00f6d950 R11: 00f6da18 R12:
> 888124d7
>[ 278.749443] R13: 88814c952000 R14: 8881000aac05 R15:
> 8881059baf10
>[ 278.749446] FS: () GS:88817bd8()
> knlGS:
>[ 278.749449] CS: 0010 DS: ES: CR0: 80050033
>[ 278.749452] CR2: 05a5 CR3: 000104078000 CR4:
> 00350ef0
>[ 278.749454] Call Trace:
>[ 278.749458]
>[ 278.749461] ? __die_body+0x1a/0x60
>[ 278.749469] ? page_fault_oops+0x156/0x450
>[ 278.749474] ? do_user_addr_fault+0x65/0x9e0
>[ 278.749479] ? exc_page_fault+0x68/0x1a0
>[ 278.749486] ? asm_exc_page_fault+0x26/0x30
>[ 278.749494] ? intel_display_rps_mark_interactive+0x4/0x40 [i915]
>[ 278.749802] intel_cleanup_plane_fb+0x6f/0xc0 [i915]
>[ 278.750114] drm_atomic_helper_cleanup_planes+0x42/0x60
>[ 278.750122] intel_atomic_cleanup_work+0x70/0xc0 [i915]
>[ 278.750433] ? process_scheduled_works+0x264/0x530
>[ 278.750438] process_scheduled_works+0x2db/0x530
>[ 278.750444] ? __pfx_worker_thread+0x10/0x10
>[ 278.750448] worker_thread+0x18c/0x350
>[ 278.750452] ? __pfx_worker_thread+0x10/0x10
>[ 278.750455] kthread+0xfe/0x130
>[ 278.750460] ? __pfx_kthread+0x10/0x10
>[ 278.750464] ret_from_fork+0x2c/0x50
>[ 278.750468] ? __pfx_kthread+0x10/0x10
>[ 278.750472] ret_from_fork_asm+0x1b/0x30
>
> Signed-off-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index bf684c4d1732..b0e89036508e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7006,10 +7006,8 @@ static void intel_atomic_commit_fence_wait(struct
> intel_atomic_state *intel_stat
> }
> }
>
> -static void intel_atomic_cleanup_work(struct work_struct *work)
> +static void intel_atomic_cleanup_work(struct intel_atomic_state *state)
> {
> - struct intel_atomic_state *state =
> - container_of(work, struct intel_atomic_state, base.commit_work);
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> struct intel_crtc_state *old_crtc_state;
> struct intel_crtc *crtc;
> @@ -7283,8 +7281,8 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>* schedule point (cond_resched()) here anyway to keep latencies
>* down.
>*/
> - INIT_WORK(>base.commit_work, intel_atomic_cleanup_work);
> - queue_work(system_highpri_wq, >base.commit_work);
> +
> + intel_atomic_cleanup_work(state);
> }
>
> static void intel_atomic_commit_work(struct work_struct *work)
> --
> 2.25.1
--
Ville Syrjälä
Intel
RE: [PATCH 4/5] drm/i915: Add PLL .compare_hw_state() vfunc
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, February 9, 2024 8:38 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 4/5] drm/i915: Add PLL .compare_hw_state() vfunc
>
> From: Ville Syrjälä
>
> Chunk up the humenguous dpll_hw_state comparison check into per-platform
> variants, implemented in the dpll_mgr. This is step
> one in allowing each platform (or perhaps even PLL) type to have a custom hw
> state structure instead of having to smash it all into
> one.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 78 ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 95
> +++ drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 +
> 3 files changed, 141 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1d381fa96c84..66ee6749fdae 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4907,6 +4907,36 @@ pipe_config_mismatch(bool fastset, const struct
> intel_crtc *crtc,
> va_end(args);
> }
>
> +static void
> +pipe_config_pll_mismatch(bool fastset,
> + const struct intel_crtc *crtc,
> + const char *name,
> + const struct intel_dpll_hw_state *a,
> + const struct intel_dpll_hw_state *b) {
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> +
> + if (fastset) {
> + if (!drm_debug_enabled(DRM_UT_KMS))
> + return;
> +
> + drm_dbg_kms(>drm,
> + "[CRTC:%d:%s] fastset requirement not met in %s\n",
> + crtc->base.base.id, crtc->base.name, name);
> + drm_dbg_kms(>drm, "expected:\n");
> + intel_dpll_dump_hw_state(i915, a);
> + drm_dbg_kms(>drm, "found:\n");
> + intel_dpll_dump_hw_state(i915, b);
> + } else {
> + drm_err(>drm, "[CRTC:%d:%s] mismatch in %s buffer\n",
> + crtc->base.base.id, crtc->base.name, name);
> + drm_err(>drm, "expected:\n");
> + intel_dpll_dump_hw_state(i915, a);
> + drm_err(>drm, "found:\n");
> + intel_dpll_dump_hw_state(i915, b);
> + }
> +}
> +
> static bool fastboot_enabled(struct drm_i915_private *dev_priv) {
> /* Enable fastboot by default on Skylake and newer */ @@ -5016,7
> +5046,17 @@ intel_pipe_config_compare(const
> struct intel_crtc_state *current_config,
> } \
> } while (0)
>
> -#define PIPE_CONF_CHECK_TIMINGS(name) do { \
> +#define PIPE_CONF_CHECK_PLL(name) do { \
> + if (!intel_dpll_compare_hw_state(dev_priv, _config->name, \
> + _config->name)) { \
> + pipe_config_pll_mismatch(fastset, crtc, __stringify(name), \
> + _config->name, \
> + _config->name); \
> + ret = false; \
> + } \
> +} while (0)
> +
> +#define PIPE_CONF_CHECK_TIMINGS(name) do { \
> PIPE_CONF_CHECK_I(name.crtc_hdisplay); \
> PIPE_CONF_CHECK_I(name.crtc_htotal); \
> PIPE_CONF_CHECK_I(name.crtc_hblank_start); \ @@ -5223,40 +5263,8 @@
> intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> PIPE_CONF_CHECK_P(shared_dpll);
>
> /* FIXME convert everything over the dpll_mgr */
> - if (dev_priv->display.dpll.mgr || HAS_GMCH(dev_priv)) {
> - PIPE_CONF_CHECK_X(dpll_hw_state.dpll);
> - PIPE_CONF_CHECK_X(dpll_hw_state.dpll_md);
> - PIPE_CONF_CHECK_X(dpll_hw_state.fp0);
> - PIPE_CONF_CHECK_X(dpll_hw_state.fp1);
> - PIPE_CONF_CHECK_X(dpll_hw_state.wrpll);
> - PIPE_CONF_CHECK_X(dpll_hw_state.spll);
> - PIPE_CONF_CHECK_X(dpll_hw_state.ctrl1);
> - PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr1);
> - PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr2);
> - PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr0);
> - PIPE_CONF_CHECK_X(dpll_hw_state.div0);
> - PIPE_CONF_CHECK_X(dpll_hw_state.ebb0);
> - PIPE_CONF_CHECK_X(dpll_hw_state.ebb4);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll0);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll1);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll2);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll3);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll6);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll8);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll9);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pll10);
> - PIPE_CONF_CHECK_X(dpll_hw_state.pcsdw12);
> - PIPE_CONF_CHECK_X(dpll_hw_state.mg_refclkin_ctl);
> -
Re: [PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
Am 13.02.24 um 15:28 schrieb Matthew Auld:
On 13/02/2024 13:52, Arunpravin Paneer Selvam wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
It looks like you changed the patch authorship here.
Going to fix this if I get tasked with pushing this to drm-misc-fixes.
But I still have hope that Arun will figure out how to do this himself.
Christian.
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64
chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+ * Idea is to fragment the address space by alternating block
+ * allocations between three different lists; one for left,
middle and
+ * right. We can then free a list to simulate fragmentation. In
+ * particular we want to exercise the
DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+ * including the try_harder path.
+ */
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+ * At this point we should have enough contiguous space for 2
blocks,
+ * however they are never buddies (since we freed middle and
right) so
+ * will require the try_harder logic to find them.
+ */
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0,
mm_size,
+ 2 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0,
mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
KUNIT_CASE(drm_test_buddy_alloc_optimistic),
KUNIT_CASE(drm_test_buddy_alloc_pessimistic),
KUNIT_CASE(drm_test_buddy_alloc_pathological),
+ KUNIT_CASE(drm_test_buddy_alloc_contiguous),
{}
};
Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
On Tue, Feb 13, 2024 at 05:21:26PM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Feb 13, 2024 at 05:11:37PM +0200, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: Rodrigo Vivi
> > > Sent: Tuesday, February 13, 2024 8:26 PM
> > > To: Shankar, Uma
> > > Cc: intel-gfx@lists.freedesktop.org; Lisovskiy, Stanislav
> > > ; ville.syrj...@linux.intel.com;
> > > jani.nik...@linux.intel.com
> > > Subject: Re: [PATCH] drm/i915: Add bigjoiner force enable option to
> > > debugfs
> > >
> > > On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> > > > From: Stanislav Lisovskiy
> > > >
> > > > For validation purposes, it might be useful to be able to force
> > > > Bigjoiner mode, even if current dotclock/resolution do not require
> > > > that.
> > > > Lets add such to option to debugfs.
> > > >
> > > > v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> > > > debugfs entry is created so lets just check manually
> > > > the DISPLAY_VER.
> > > >
> > > > v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> > > > - Remove redundant modeset lock(Jani Nikula)
> > > > - Use kstrtobool_from_user for boolean value(Jani Nikula)
> > > >
> > > > v4: - Apply the changes to proper function(Jani Nikula)
> > > >
> > > > v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> > > > (Ville Syrjälä)
> > > > - Added eDP connector check to intel_connector_debugfs_add
> > > > (Ville Syrjälä)
> > > > - Removed debug message in order to prevent dmesg flooding
> > > > (Ville Syrjälä)
> > > >
> > > > v6: - Assume now always that m->private is intel_connector
> > > > - Fixed other similar conflicts
> > > >
> > > > v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> > > > - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> > > > manually.(Ville Syrjälä)
> > > >
> > > > v8: - Pass intel_connector to debugfs_create_file, instead of
> > > > drm_connector.
> > > > (Jani Nikula)
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > >
> > > please remind to sign-off when sending someone else's patch.
> >
> > Oh yeah, sorry missed it. Was filling in for Stan while he was OOO.
> > @Lisovskiy, Stanislav Please address rest of the comments raised by Rodrigo.
>
> Sorry, had that pushed already in the morning, since it was Acked and I was
> asked
> to do it asap.
no worries. if you are confident that the _show function magically works I trust
your tests more then my eyes and greps.
>
> Stan
>
> >
> > Regards,
> > Uma Shankar
> >
> > > > ---
> > > > .../drm/i915/display/intel_display_debugfs.c | 47 +++
> > > > .../drm/i915/display/intel_display_types.h| 2 +
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> > > > 3 files changed, 52 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > index 6f2d13c8ccf7..a962b48bcf13 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > @@ -1391,6 +1391,20 @@ out: drm_modeset_unlock(
> > > >drm.mode_config.connection_mutex);
> > > > return ret;
> > > > }
> > > >
> > > > +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> > > > +{
> > > > + struct intel_connector *connector = m->private;
> > > > + struct drm_crtc *crtc;
> > > > +
> > > > + crtc = connector->base.state->crtc;
> > > > + if (connector->base.status != connector_status_connected ||
> > > > !crtc)
> > > > + return -ENODEV;
> > > > +
> > > > + seq_printf(m, "Bigjoiner enable: %d\n",
> > > > +connector->force_bigjoiner_enable);
> > >
> > > probably better with a yes_or_no string?
> > >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > static ssize_t i915_dsc_output_format_write(struct file *file,
> > > > const char __user *ubuf,
> > > > size_t len, loff_t *offp)
> > > > @@ -1412,6 +1426,30 @@ static ssize_t
> > > > i915_dsc_output_format_write(struct
> > > file *file,
> > > > return len;
> > > > }
> > > >
> > > > +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> > > > + const char __user *ubuf,
> > > > + size_t len, loff_t *offp)
> > > > +{
> > > > + struct seq_file *m = file->private_data;
> > > > + struct intel_connector *connector = m->private;
> > > > + struct drm_crtc *crtc;
> > > > + bool bigjoiner_en = 0;
> > > > + int ret;
> > > > +
> > > > + crtc = connector->base.state->crtc;
> > > > + if (connector->base.status != connector_status_connected ||
> > > > !crtc)
> > > > + return
Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
On Tue, Feb 13, 2024 at 05:11:37PM +0200, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Rodrigo Vivi
> > Sent: Tuesday, February 13, 2024 8:26 PM
> > To: Shankar, Uma
> > Cc: intel-gfx@lists.freedesktop.org; Lisovskiy, Stanislav
> > ; ville.syrj...@linux.intel.com;
> > jani.nik...@linux.intel.com
> > Subject: Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
> >
> > On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> > > From: Stanislav Lisovskiy
> > >
> > > For validation purposes, it might be useful to be able to force
> > > Bigjoiner mode, even if current dotclock/resolution do not require
> > > that.
> > > Lets add such to option to debugfs.
> > >
> > > v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> > > debugfs entry is created so lets just check manually
> > > the DISPLAY_VER.
> > >
> > > v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> > > - Remove redundant modeset lock(Jani Nikula)
> > > - Use kstrtobool_from_user for boolean value(Jani Nikula)
> > >
> > > v4: - Apply the changes to proper function(Jani Nikula)
> > >
> > > v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> > > (Ville Syrjälä)
> > > - Added eDP connector check to intel_connector_debugfs_add
> > > (Ville Syrjälä)
> > > - Removed debug message in order to prevent dmesg flooding
> > > (Ville Syrjälä)
> > >
> > > v6: - Assume now always that m->private is intel_connector
> > > - Fixed other similar conflicts
> > >
> > > v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> > > - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> > > manually.(Ville Syrjälä)
> > >
> > > v8: - Pass intel_connector to debugfs_create_file, instead of
> > > drm_connector.
> > > (Jani Nikula)
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> >
> > please remind to sign-off when sending someone else's patch.
>
> Oh yeah, sorry missed it. Was filling in for Stan while he was OOO.
> @Lisovskiy, Stanislav Please address rest of the comments raised by Rodrigo.
Sorry, had that pushed already in the morning, since it was Acked and I was
asked
to do it asap.
Stan
>
> Regards,
> Uma Shankar
>
> > > ---
> > > .../drm/i915/display/intel_display_debugfs.c | 47 +++
> > > .../drm/i915/display/intel_display_types.h| 2 +
> > > drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> > > 3 files changed, 52 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index 6f2d13c8ccf7..a962b48bcf13 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -1391,6 +1391,20 @@ out: drm_modeset_unlock(
> > >drm.mode_config.connection_mutex);
> > > return ret;
> > > }
> > >
> > > +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> > > +{
> > > + struct intel_connector *connector = m->private;
> > > + struct drm_crtc *crtc;
> > > +
> > > + crtc = connector->base.state->crtc;
> > > + if (connector->base.status != connector_status_connected || !crtc)
> > > + return -ENODEV;
> > > +
> > > + seq_printf(m, "Bigjoiner enable: %d\n",
> > > +connector->force_bigjoiner_enable);
> >
> > probably better with a yes_or_no string?
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static ssize_t i915_dsc_output_format_write(struct file *file,
> > > const char __user *ubuf,
> > > size_t len, loff_t *offp)
> > > @@ -1412,6 +1426,30 @@ static ssize_t i915_dsc_output_format_write(struct
> > file *file,
> > > return len;
> > > }
> > >
> > > +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> > > +const char __user *ubuf,
> > > +size_t len, loff_t *offp)
> > > +{
> > > + struct seq_file *m = file->private_data;
> > > + struct intel_connector *connector = m->private;
> > > + struct drm_crtc *crtc;
> > > + bool bigjoiner_en = 0;
> > > + int ret;
> > > +
> > > + crtc = connector->base.state->crtc;
> > > + if (connector->base.status != connector_status_connected || !crtc)
> > > + return -ENODEV;
> > > +
> > > + ret = kstrtobool_from_user(ubuf, len, _en);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + connector->force_bigjoiner_enable = bigjoiner_en;
> > > + *offp += len;
> > > +
> > > + return len;
> > > +}
> > > +
> > > static int i915_dsc_output_format_open(struct inode *inode,
> > > struct file *file)
> > > {
> > > @@ -1505,6 +1543,8 @@ static const struct file_operations
> > i915_dsc_fractional_bpp_fops = {
> > > .write = i915_dsc_fractional_bpp_write };
> > >
> > >
RE: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
> -Original Message-
> From: Rodrigo Vivi
> Sent: Tuesday, February 13, 2024 8:26 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Lisovskiy, Stanislav
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com
> Subject: Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
>
> On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> > From: Stanislav Lisovskiy
> >
> > For validation purposes, it might be useful to be able to force
> > Bigjoiner mode, even if current dotclock/resolution do not require
> > that.
> > Lets add such to option to debugfs.
> >
> > v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> > debugfs entry is created so lets just check manually
> > the DISPLAY_VER.
> >
> > v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> > - Remove redundant modeset lock(Jani Nikula)
> > - Use kstrtobool_from_user for boolean value(Jani Nikula)
> >
> > v4: - Apply the changes to proper function(Jani Nikula)
> >
> > v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> > (Ville Syrjälä)
> > - Added eDP connector check to intel_connector_debugfs_add
> > (Ville Syrjälä)
> > - Removed debug message in order to prevent dmesg flooding
> > (Ville Syrjälä)
> >
> > v6: - Assume now always that m->private is intel_connector
> > - Fixed other similar conflicts
> >
> > v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> > - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> > manually.(Ville Syrjälä)
> >
> > v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
> > (Jani Nikula)
> >
> > Signed-off-by: Stanislav Lisovskiy
>
> please remind to sign-off when sending someone else's patch.
Oh yeah, sorry missed it. Was filling in for Stan while he was OOO.
@Lisovskiy, Stanislav Please address rest of the comments raised by Rodrigo.
Regards,
Uma Shankar
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 47 +++
> > .../drm/i915/display/intel_display_types.h| 2 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> > 3 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 6f2d13c8ccf7..a962b48bcf13 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1391,6 +1391,20 @@ out: drm_modeset_unlock(
> >drm.mode_config.connection_mutex);
> > return ret;
> > }
> >
> > +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> > +{
> > + struct intel_connector *connector = m->private;
> > + struct drm_crtc *crtc;
> > +
> > + crtc = connector->base.state->crtc;
> > + if (connector->base.status != connector_status_connected || !crtc)
> > + return -ENODEV;
> > +
> > + seq_printf(m, "Bigjoiner enable: %d\n",
> > +connector->force_bigjoiner_enable);
>
> probably better with a yes_or_no string?
>
> > +
> > + return 0;
> > +}
> > +
> > static ssize_t i915_dsc_output_format_write(struct file *file,
> > const char __user *ubuf,
> > size_t len, loff_t *offp)
> > @@ -1412,6 +1426,30 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
> > return len;
> > }
> >
> > +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + struct seq_file *m = file->private_data;
> > + struct intel_connector *connector = m->private;
> > + struct drm_crtc *crtc;
> > + bool bigjoiner_en = 0;
> > + int ret;
> > +
> > + crtc = connector->base.state->crtc;
> > + if (connector->base.status != connector_status_connected || !crtc)
> > + return -ENODEV;
> > +
> > + ret = kstrtobool_from_user(ubuf, len, _en);
> > + if (ret < 0)
> > + return ret;
> > +
> > + connector->force_bigjoiner_enable = bigjoiner_en;
> > + *offp += len;
> > +
> > + return len;
> > +}
> > +
> > static int i915_dsc_output_format_open(struct inode *inode,
> >struct file *file)
> > {
> > @@ -1505,6 +1543,8 @@ static const struct file_operations
> i915_dsc_fractional_bpp_fops = {
> > .write = i915_dsc_fractional_bpp_write };
> >
> > +DEFINE_SHOW_STORE_ATTRIBUTE(i915_bigjoiner_enable);
>
> I don't believe this macro here is using the defined _show function, but
> maybe I'm
> not following that very well since this macro is not widely used.
>
> What about using DEFINE_SIMPLE_ATTRIBUTE instead?
>
> > +
> > /*
> > * Returns the Current CRTC's bpc.
> > * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> > @@ -1586,6 +1626,13 @@ void
RE: ✓ Fi.CI.IGT: success for drm/i915/selftests: Increasing the sleep time for live_rc6_manual (rev4)
Pushed to drm-intel-gt-next. Thanks, Anshuman. From: Intel-gfx On Behalf Of Patchwork Sent: Monday, February 12, 2024 1:09 PM To: Anirban, Sk Cc: intel-gfx@lists.freedesktop.org Subject: ✓ Fi.CI.IGT: success for drm/i915/selftests: Increasing the sleep time for live_rc6_manual (rev4) Patch Details Series: drm/i915/selftests: Increasing the sleep time for live_rc6_manual (rev4) URL: https://patchwork.freedesktop.org/series/129664/ State: success Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v4/index.html CI Bug Log - changes from CI_DRM_14248_full -> Patchwork_129664v4_full Summary SUCCESS No regressions found. Participating hosts (8 -> 8) No changes in participating hosts New tests New tests have been introduced between CI_DRM_14248_full and Patchwork_129664v4_full: New IGT tests (124) • igt@kms_cursor_edge_walk@128x128-left-edge: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@128x128-left-edge@pipe-a-hdmi-a-1: o Statuses : 4 pass(s) o Exec time: [1.74, 3.88] s • igt@kms_cursor_edge_walk@128x128-left-edge@pipe-a-hdmi-a-4: o Statuses : 1 pass(s) o Exec time: [3.39] s • igt@kms_cursor_edge_walk@128x128-left-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.40] s • igt@kms_cursor_edge_walk@128x128-left-edge@pipe-d-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [1.67] s • igt@kms_cursor_edge_walk@128x128-left-edge@pipe-d-hdmi-a-4: o Statuses : 1 pass(s) o Exec time: [3.20] s • igt@kms_cursor_edge_walk@128x128-right-edge: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@128x128-right-edge@pipe-a-hdmi-a-1: o Statuses : 3 pass(s) o Exec time: [1.74, 3.87] s • igt@kms_cursor_edge_walk@128x128-right-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.43] s • igt@kms_cursor_edge_walk@128x128-right-edge@pipe-d-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [1.65] s • igt@kms_cursor_edge_walk@128x128-top-bottom: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@128x128-top-bottom@pipe-a-hdmi-a-1: o Statuses : 3 pass(s) o Exec time: [1.74, 3.69] s • igt@kms_cursor_edge_walk@128x128-top-edge: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@128x128-top-edge@pipe-a-hdmi-a-1: o Statuses : 4 pass(s) o Exec time: [1.70, 3.92] s • igt@kms_cursor_edge_walk@128x128-top-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.40] s • igt@kms_cursor_edge_walk@256x256-left-edge@pipe-a-hdmi-a-1: o Statuses : 3 pass(s) o Exec time: [1.81, 4.09] s • igt@kms_cursor_edge_walk@256x256-left-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.40] s • igt@kms_cursor_edge_walk@256x256-left-edge@pipe-d-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [1.66] s • igt@kms_cursor_edge_walk@256x256-right-edge: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@256x256-right-edge@pipe-a-hdmi-a-1: o Statuses : 4 pass(s) o Exec time: [1.78, 3.98] s • igt@kms_cursor_edge_walk@256x256-right-edge@pipe-a-hdmi-a-4: o Statuses : 1 pass(s) o Exec time: [3.32] s • igt@kms_cursor_edge_walk@256x256-right-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.32] s • igt@kms_cursor_edge_walk@256x256-right-edge@pipe-d-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [1.66] s • igt@kms_cursor_edge_walk@256x256-right-edge@pipe-d-hdmi-a-4: o Statuses : 1 pass(s) o Exec time: [3.20] s • igt@kms_cursor_edge_walk@256x256-top-bottom: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@256x256-top-bottom@pipe-a-hdmi-a-1: o Statuses : 3 pass(s) o Exec time: [1.76, 3.72] s • igt@kms_cursor_edge_walk@256x256-top-bottom@pipe-b-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.32] s • igt@kms_cursor_edge_walk@256x256-top-bottom@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.39] s • igt@kms_cursor_edge_walk@256x256-top-bottom@pipe-d-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [1.69] s • igt@kms_cursor_edge_walk@256x256-top-edge@pipe-a-hdmi-a-1: o Statuses : 3 pass(s) o Exec time: [1.73, 3.96] s • igt@kms_cursor_edge_walk@256x256-top-edge@pipe-a-hdmi-a-4: o Statuses : 1 pass(s) o Exec time: [3.31] s • igt@kms_cursor_edge_walk@256x256-top-edge@pipe-a-vga-1: o Statuses : 1 pass(s) o Exec time: [3.38] s • igt@kms_cursor_edge_walk@256x256-top-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.49] s • igt@kms_cursor_edge_walk@256x256-top-edge@pipe-d-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [1.66] s • igt@kms_cursor_edge_walk@256x256-top-edge@pipe-d-hdmi-a-4: o Statuses : 1 pass(s) o Exec time: [3.20] s • igt@kms_cursor_edge_walk@64x64-left-edge: o Statuses : o Exec time: [None] s • igt@kms_cursor_edge_walk@64x64-left-edge@pipe-a-hdmi-a-1: o Statuses : 3 pass(s) o Exec time: [1.77, 3.99] s • igt@kms_cursor_edge_walk@64x64-left-edge@pipe-c-hdmi-a-1: o Statuses : 1 pass(s) o Exec time: [3.40] s • igt@kms_cursor_edge_walk@64x64-right-edge@pipe-a-edp-1: o Statuses : 1 pass(s) o Exec time: [3.59] s • igt@kms_cursor_edge_walk@64x64-right-edge@pipe-a-hdmi-a-1: o Statuses : 4 pass(s) o Exec time: [1.73, 3.90] s •
Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> From: Stanislav Lisovskiy
>
> For validation purposes, it might be useful to be able to
> force Bigjoiner mode, even if current dotclock/resolution
> do not require that.
> Lets add such to option to debugfs.
>
> v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> debugfs entry is created so lets just check manually
> the DISPLAY_VER.
>
> v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> - Remove redundant modeset lock(Jani Nikula)
> - Use kstrtobool_from_user for boolean value(Jani Nikula)
>
> v4: - Apply the changes to proper function(Jani Nikula)
>
> v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> (Ville Syrjälä)
> - Added eDP connector check to intel_connector_debugfs_add
> (Ville Syrjälä)
> - Removed debug message in order to prevent dmesg flooding
> (Ville Syrjälä)
>
> v6: - Assume now always that m->private is intel_connector
> - Fixed other similar conflicts
>
> v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> manually.(Ville Syrjälä)
>
> v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
> (Jani Nikula)
>
> Signed-off-by: Stanislav Lisovskiy
please remind to sign-off when sending someone else's patch.
> ---
> .../drm/i915/display/intel_display_debugfs.c | 47 +++
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 6f2d13c8ccf7..a962b48bcf13 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1391,6 +1391,20 @@ out:
> drm_modeset_unlock(>drm.mode_config.connection_mutex);
> return ret;
> }
>
> +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> +{
> + struct intel_connector *connector = m->private;
> + struct drm_crtc *crtc;
> +
> + crtc = connector->base.state->crtc;
> + if (connector->base.status != connector_status_connected || !crtc)
> + return -ENODEV;
> +
> + seq_printf(m, "Bigjoiner enable: %d\n",
> connector->force_bigjoiner_enable);
probably better with a yes_or_no string?
> +
> + return 0;
> +}
> +
> static ssize_t i915_dsc_output_format_write(struct file *file,
> const char __user *ubuf,
> size_t len, loff_t *offp)
> @@ -1412,6 +1426,30 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
> return len;
> }
>
> +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> +const char __user *ubuf,
> +size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct intel_connector *connector = m->private;
> + struct drm_crtc *crtc;
> + bool bigjoiner_en = 0;
> + int ret;
> +
> + crtc = connector->base.state->crtc;
> + if (connector->base.status != connector_status_connected || !crtc)
> + return -ENODEV;
> +
> + ret = kstrtobool_from_user(ubuf, len, _en);
> + if (ret < 0)
> + return ret;
> +
> + connector->force_bigjoiner_enable = bigjoiner_en;
> + *offp += len;
> +
> + return len;
> +}
> +
> static int i915_dsc_output_format_open(struct inode *inode,
> struct file *file)
> {
> @@ -1505,6 +1543,8 @@ static const struct file_operations
> i915_dsc_fractional_bpp_fops = {
> .write = i915_dsc_fractional_bpp_write
> };
>
> +DEFINE_SHOW_STORE_ATTRIBUTE(i915_bigjoiner_enable);
I don't believe this macro here is using the defined _show function,
but maybe I'm not following that very well since this macro is
not widely used.
What about using DEFINE_SIMPLE_ATTRIBUTE instead?
> +
> /*
> * Returns the Current CRTC's bpc.
> * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> @@ -1586,6 +1626,13 @@ void intel_connector_debugfs_add(struct
> intel_connector *connector)
> connector, _dsc_fractional_bpp_fops);
> }
>
> + if (DISPLAY_VER(i915) >= 11 &&
> + (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP)) {
I wish we had a simpler check, but I couldn't find. :/
> + debugfs_create_file("i915_bigjoiner_force_enable", 0644, root,
> + connector, _bigjoiner_enable_fops);
> + }
> +
> if (connector_type == DRM_MODE_CONNECTOR_DSI ||
> connector_type == DRM_MODE_CONNECTOR_eDP ||
>
✓ Fi.CI.BAT: success for drm/i915: Support replaying GPU hangs with captured context image
== Series Details ==
Series: drm/i915: Support replaying GPU hangs with captured context image
URL : https://patchwork.freedesktop.org/series/129832/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14262 -> Patchwork_129832v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/index.html
Participating hosts (36 -> 35)
--
Additional (2): fi-glk-j4005 bat-kbl-2
Missing(3): bat-mtlp-8 bat-arls-2 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129832v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-apl-guc: [PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-apl-guc/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/fi-apl-guc/boot.html
### IGT changes ###
Issues hit
* igt@fbdev@info:
- bat-kbl-2: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1849])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/bat-kbl-2/igt@fb...@info.html
* igt@gem_huc_copy@huc-copy:
- fi-glk-j4005: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-glk-j4005: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][6] ([fdo#109271]) +35 other tests
skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005: NOTRUN -> [SKIP][7] ([fdo#109271]) +6 other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
Build changes
-
* Linux: CI_DRM_14262 -> Patchwork_129832v1
CI-20190529: 20190529
CI_DRM_14262: 7c8e9135509f2e438e11a4af17387a204ab59884 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7710: d87a5d85a60fba1283821d5212c3aece64cb36ba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129832v1: 7c8e9135509f2e438e11a4af17387a204ab59884 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
92a04333d63d drm/i915: Support replaying GPU hangs with captured context image
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129832v1/index.html
Re: [PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
On 13/02/2024 13:52, Arunpravin Paneer Selvam wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
It looks like you changed the patch authorship here.
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start
✗ Fi.CI.SPARSE: warning for drm/i915: Support replaying GPU hangs with captured context image
== Series Details == Series: drm/i915: Support replaying GPU hangs with captured context image URL : https://patchwork.freedesktop.org/series/129832/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
✗ Fi.CI.CHECKPATCH: warning for drm/i915: Support replaying GPU hangs with captured context image
== Series Details == Series: drm/i915: Support replaying GPU hangs with captured context image URL : https://patchwork.freedesktop.org/series/129832/ State : warning == Summary == Error: dim checkpatch failed 53cbd1a9087f drm/i915: Support replaying GPU hangs with captured context image -:354: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #354: FILE: drivers/gpu/drm/i915/i915_params.c:139: +i915_param_named(enable_debug_only_api, bool, 0400, + "Enable support for unstable debug only userspace API. (default:false)"); -:370: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #370: FILE: drivers/gpu/drm/i915/i915_params.h:68: + param(bool, enable_debug_only_api, false, IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API) ? 0400 : 0) total: 0 errors, 1 warnings, 1 checks, 320 lines checked
✓ Fi.CI.BAT: success for drm/i915/mst: enable MST mode for 128b/132b single-stream sideband (rev3)
== Series Details ==
Series: drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
(rev3)
URL : https://patchwork.freedesktop.org/series/129468/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14262 -> Patchwork_129468v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129468v3/index.html
Participating hosts (36 -> 34)
--
Additional (1): bat-kbl-2
Missing(3): bat-mtlp-8 bat-adlm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129468v3 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-cfl-8109u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129468v3/fi-cfl-8109u/boot.html
### IGT changes ###
Issues hit
* igt@fbdev@info:
- bat-kbl-2: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1849])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129468v3/bat-kbl-2/igt@fb...@info.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][4] ([fdo#109271]) +35 other tests
skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129468v3/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-c-dp-2:
- fi-kbl-7567u: NOTRUN -> [SKIP][5] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129468v3/fi-kbl-7567u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-c-dp-2.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
Build changes
-
* Linux: CI_DRM_14262 -> Patchwork_129468v3
CI-20190529: 20190529
CI_DRM_14262: 7c8e9135509f2e438e11a4af17387a204ab59884 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7710: d87a5d85a60fba1283821d5212c3aece64cb36ba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129468v3: 7c8e9135509f2e438e11a4af17387a204ab59884 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
fda236a32c14 drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
8cc793f0909f drm/i915/mst: add intel_dp_mst_disconnect()
2deb677b699c drm/i915/mst: use the MST mode detected previously
875fa71b4572 drm/i915/mst: abstract choosing the MST mode to use
7d79663e064a drm/i915/mst: improve debug logging of DP MST mode detect
ccdb95e45a5f drm/mst: read sideband messaging cap
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129468v3/index.html
✗ Fi.CI.SPARSE: warning for drm/i915/mst: enable MST mode for 128b/132b single-stream sideband (rev3)
== Series Details == Series: drm/i915/mst: enable MST mode for 128b/132b single-stream sideband (rev3) URL : https://patchwork.freedesktop.org/series/129468/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
✗ Fi.CI.CHECKPATCH: warning for drm/i915/mst: enable MST mode for 128b/132b single-stream sideband (rev3)
== Series Details == Series: drm/i915/mst: enable MST mode for 128b/132b single-stream sideband (rev3) URL : https://patchwork.freedesktop.org/series/129468/ State : warning == Summary == Error: dim checkpatch failed ca1b6d4e0985 drm/mst: read sideband messaging cap -:127: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #127: FILE: include/drm/display/drm_dp_mst_helper.h:842: +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE]); total: 0 errors, 1 warnings, 0 checks, 90 lines checked f7c4da2226c7 drm/i915/mst: improve debug logging of DP MST mode detect c7fd713f2afd drm/i915/mst: abstract choosing the MST mode to use 910233abb983 drm/i915/mst: use the MST mode detected previously 872026c36cca drm/i915/mst: add intel_dp_mst_disconnect() eaaedce1a393 drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
[PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
KUNIT_CASE(drm_test_buddy_alloc_optimistic),
[PATCH 1/2] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
base-commit: 2c80a2b715df75881359d07dbaacff8ad411f40e
--
2.25.1
RE: [PATCH v2 1/6] drm/mst: read sideband messaging cap
On Tue, 13 Feb 2024, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, February 13, 2024 5:01 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: dri-de...@lists.freedesktop.org; intel...@lists.freedesktop.org; Nikula,
>> Jani
>> ; Murthy, Arun R ; Ville
>> Syrjälä
>> Subject: [PATCH v2 1/6] drm/mst: read sideband messaging cap
>>
>> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST with
>> sideband messaging", or "MST". Modify all call sites to take the new return
>> value into account.
>>
>> v2:
>> - Rename enumerators (Ville)
>>
>> Cc: Arun R Murthy
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
>> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
>> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
>> include/drm/display/drm_dp_mst_helper.h | 23 ++-
>> 4 files changed, 38 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> index 03d528209426..c193be3577f7 100644
>> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> @@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const
>> struct drm_dp_mst_topology_mgr *mgr,
>> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>>
>> /**
>> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
>> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
>> * @aux: The DP AUX channel to use
>> * @dpcd: A cached copy of the DPCD capabilities for this sink
>> *
>> - * Returns: %True if the sink supports MST, %false otherwise
>> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
>> */
>> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
>> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
>> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
>> + const u8
>> dpcd[DP_RECEIVER_CAP_SIZE])
>> {
>> u8 mstm_cap;
>>
>> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
>> - return false;
>> + return DRM_DP_SST;
>>
>> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
>> - return false;
>> + return DRM_DP_SST;
>> +
>> + if (mstm_cap & DP_MST_CAP)
>> + return DRM_DP_MST;
>> +
>> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
>> + return DRM_DP_SST_SIDEBAND_MSG;
> Bit[1] of MSTM_CAP indicates sideband messaging is supported or not
> and nothing to do with MST/SST. So would it make more sense to have it
> as DRM_DP_SIDEBAND_MSG?
Bit 1 is literally described as SINGLE_STREAM_SIDEBAND_MSG_SUPPORT in
the spec, "Supports Sideband MSG while not supporting multi-stream
transport".
Bit 1 is also only valid when bit 0 says, "Does not support MST mode".
BR,
Jani.
>
> Thanks and Regards,
> Arun R Murthy
>
>>
>> - return mstm_cap & DP_MST_CAP;
>> + return DRM_DP_SST;
>> }
>> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 5045c34a16be..a1c304f451bd 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>>
>> return i915->display.params.enable_dp_mst &&
>> intel_dp_mst_source_support(intel_dp) &&
>> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
>> DRM_DP_MST;
>> }
>>
>> static void
>> @@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
>> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> struct intel_encoder *encoder =
>> _to_dig_port(intel_dp)->base;
>> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp-
>> >dpcd);
>> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux,
>> +intel_dp->dpcd) == DRM_DP_MST;
>>
>> drm_dbg_kms(>drm,
>> "[ENCODER:%d:%s] MST support: port: %s, sink: %s,
>> modparam: %s\n", diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
>> b/drivers/gpu/drm/nouveau/nouveau_dp.c
>> index 7de7707ec6a8..fb06ee17d9e5 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
>> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
>> *nv_connector,
>> if (nouveau_mst) {
>> mstm = outp->dp.mstm;
>> if (mstm)
>> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
>> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd)
>> == DRM_DP_MST;
>> }
>>
>> if (nouveau_dp_has_sink_count(connector, outp)) { diff --git
>> a/include/drm/display/drm_dp_mst_helper.h
>>
✗ Fi.CI.BAT: failure for Bigjoiner refactoring (rev6)
== Series Details == Series: Bigjoiner refactoring (rev6) URL : https://patchwork.freedesktop.org/series/128311/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14262 -> Patchwork_128311v6 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_128311v6 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_128311v6, please notify your bug team (i915-ci-in...@lists.freedesktop.org) 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_128311v6/index.html Participating hosts (36 -> 34) -- Missing(2): bat-mtlp-8 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_128311v6: ### IGT changes ### Possible regressions * igt@i915_module_load@load: - bat-jsl-1: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-jsl-1/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-jsl-1/igt@i915_module_l...@load.html - bat-adlp-6: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-adlp-6/igt@i915_module_l...@load.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-adlp-6/igt@i915_module_l...@load.html - fi-rkl-11600: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-rkl-11600/igt@i915_module_l...@load.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/fi-rkl-11600/igt@i915_module_l...@load.html - fi-apl-guc: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-apl-guc/igt@i915_module_l...@load.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/fi-apl-guc/igt@i915_module_l...@load.html - bat-dg1-7: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-dg1-7/igt@i915_module_l...@load.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-dg1-7/igt@i915_module_l...@load.html - bat-jsl-3: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-jsl-3/igt@i915_module_l...@load.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-jsl-3/igt@i915_module_l...@load.html - bat-adlp-9: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-adlp-9/igt@i915_module_l...@load.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-adlp-9/igt@i915_module_l...@load.html - fi-skl-guc: [PASS][15] -> [ABORT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-skl-guc/igt@i915_module_l...@load.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/fi-skl-guc/igt@i915_module_l...@load.html - bat-dg2-11: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-dg2-11/igt@i915_module_l...@load.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-dg2-11/igt@i915_module_l...@load.html - fi-kbl-7567u: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-kbl-7567u/igt@i915_module_l...@load.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/fi-kbl-7567u/igt@i915_module_l...@load.html - bat-adln-1: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-adln-1/igt@i915_module_l...@load.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-adln-1/igt@i915_module_l...@load.html - fi-cfl-8700k: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-cfl-8700k/igt@i915_module_l...@load.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/fi-cfl-8700k/igt@i915_module_l...@load.html - bat-rplp-1: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/bat-rplp-1/igt@i915_module_l...@load.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/bat-rplp-1/igt@i915_module_l...@load.html - fi-tgl-1115g4: [PASS][27] -> [INCOMPLETE][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14262/fi-tgl-1115g4/igt@i915_module_l...@load.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v6/fi-tgl-1115g4/igt@i915_module_l...@load.html - fi-cfl-guc: [PASS][29] -> [INCOMPLETE][30] [29]:
✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev6)
== Series Details == Series: Bigjoiner refactoring (rev6) URL : https://patchwork.freedesktop.org/series/128311/ State : warning == Summary == Error: dim checkpatch failed 3f2182449074 drm/i915/bigjoiner: Refactor bigjoiner state readout 0f581e82534c Start separating pipe vs transcoder set logic for bigjoiner during modeset -:12: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?) #12: That way we can also remove a bunch of checks like intel_crtc_is_bigjoiner_slave. -:184: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #184: FILE: drivers/gpu/drm/i915/display/intel_display.c:1750: +* to change the workaround. */ -:310: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #310: FILE: drivers/gpu/drm/i915/display/intel_display.h:283: +#define for_each_intel_crtc_in_pipe_mask_reverse(dev, intel_crtc, pipe_mask) \ + list_for_each_entry_reverse(intel_crtc, \ + &(dev)->mode_config.crtc_list, \ + base.head) \ + for_each_if((pipe_mask) & BIT(intel_crtc->pipe)) -:310: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_crtc' - possible side-effects? #310: FILE: drivers/gpu/drm/i915/display/intel_display.h:283: +#define for_each_intel_crtc_in_pipe_mask_reverse(dev, intel_crtc, pipe_mask) \ + list_for_each_entry_reverse(intel_crtc, \ + &(dev)->mode_config.crtc_list, \ + base.head) \ + for_each_if((pipe_mask) & BIT(intel_crtc->pipe)) total: 1 errors, 2 warnings, 1 checks, 274 lines checked
[RFC] drm/i915: Support replaying GPU hangs with captured context image
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which prevent replicating all hangs, one step further is being
able to replay against a real GPU.
This is almost doable today with the missing part being able to upload the
captured context image into the driver state prior to executing the
uploaded hanging batch and all the buffers.
To enable this last part we add a new context parameter called
I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
configuration pattern of being able to select which context to apply
against, paired with the actual image and its size.
Since this is adding a new concept of debug only uapi, we hide it behind
a new kconfig option and also require activation with a module parameter.
Together with a warning banner printed at driver load, all those combined
should be sufficient to guard against inadvertently enabling the feature.
In terms of implementation the only trivial change is shadowing of the
default state from engine to context. We also allow the legacy context
set param to be used since that removes the need to record the per context
data in the proto context, while still allowing flexibility of specifying
context images for any context.
Mesa MR using the uapi can be seen at:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Carlos Santa
---
drivers/gpu/drm/i915/Kconfig.debug| 17 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 106 ++
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers/gpu/drm/i915/gt/intel_context.h | 22
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 8 +-
drivers/gpu/drm/i915/i915_params.c| 5 +
drivers/gpu/drm/i915/i915_params.h| 3 +-
include/uapi/drm/i915_drm.h | 27 +
10 files changed, 194 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 5b7162076850..32e9f70e91ed 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -16,6 +16,23 @@ config DRM_I915_WERROR
If in doubt, say "N".
+config DRM_I915_REPLAY_GPU_HANGS_API
+ bool "Enable GPU hang replay userspace API"
+ depends on DRM_I915
+ depends on EXPERT
+ default n
+ help
+ Choose this option if you want to enable special and unstable
+ userspace API used for replaying GPU hangs on a running system.
+
+ This API is intended to be used by userspace graphics stack developers
+ and provides no stability guarantees.
+
+ The API needs to be activated at boot time using the
+ enable_debug_only_api module parameter.
+
+ If in doubt, say "N".
+
config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..1cfd624bd978 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -78,6 +78,7 @@
#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "gt/shmem_utils.h"
#include "pxp/intel_pxp.h"
@@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
+ case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
default:
ret = -EINVAL;
break;
@@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx,
return 0;
}
+static int set_context_image(struct i915_gem_context *ctx,
+struct drm_i915_gem_context_param *args)
+{
+ struct i915_gem_context_param_context_image user;
+ struct intel_context *ce;
+ struct file *shmem_state;
+ unsigned long lookup;
+ void *state;
+ int ret = 0;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API))
+ return -EINVAL;
+
+ if (!ctx->i915->params.enable_debug_only_api)
+ return -EINVAL;
+
+ if (args->size < sizeof(user))
+ return -EINVAL;
+
+ if (copy_from_user(, u64_to_user_ptr(args->value), sizeof(user)))
+ return -EFAULT;
+
+ if (user.mbz)
+ return -EINVAL;
+
+ if (user.flags & ~(I915_CONTEXT_IMAGE_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if (user.flags & I915_CONTEXT_IMAGE_FLAG_ENGINE_INDEX)
+ lookup |= LOOKUP_USER_INDEX;
+
+ ce
RE: [PATCH 3/5] drm/i915: Reuse ibx_dump_hw_state() for gmch platforms
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Friday, February 9, 2024 8:38 PM > To: intel-gfx@lists.freedesktop.org > Subject: [PATCH 3/5] drm/i915: Reuse ibx_dump_hw_state() for gmch platforms > > From: Ville Syrjälä > > GMCH platform DPLLs are similar to the IBX+ PCH DPLLs so we can just use the > same state dump function for both. > Reviewed-by: Mika Kahola > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > index e7e0a4cf9f93..c6cc7465b92c 100644 > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > @@ -4458,13 +4458,7 @@ void intel_dpll_dump_hw_state(struct drm_i915_private > *i915, > /* fallback for platforms that don't use the shared dpll >* infrastructure >*/ > - drm_dbg_kms(>drm, > - "dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, " > - "fp0: 0x%x, fp1: 0x%x\n", > - hw_state->dpll, > - hw_state->dpll_md, > - hw_state->fp0, > - hw_state->fp1); > + ibx_dump_hw_state(i915, hw_state); > } > } > > -- > 2.43.0
RE: [PATCH v2 1/6] drm/mst: read sideband messaging cap
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, February 13, 2024 5:01 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; intel...@lists.freedesktop.org; Nikula,
> Jani
> ; Murthy, Arun R ; Ville
> Syrjälä
> Subject: [PATCH v2 1/6] drm/mst: read sideband messaging cap
>
> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST with
> sideband messaging", or "MST". Modify all call sites to take the new return
> value into account.
>
> v2:
> - Rename enumerators (Ville)
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 23 ++-
> 4 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 03d528209426..c193be3577f7 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const
> struct drm_dp_mst_topology_mgr *mgr,
> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>
> /**
> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
> * @aux: The DP AUX channel to use
> * @dpcd: A cached copy of the DPCD capabilities for this sink
> *
> - * Returns: %True if the sink supports MST, %false otherwise
> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
> */
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> {
> u8 mstm_cap;
>
> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> - return false;
> + return DRM_DP_SST;
>
> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
> - return false;
> + return DRM_DP_SST;
> +
> + if (mstm_cap & DP_MST_CAP)
> + return DRM_DP_MST;
> +
> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
> + return DRM_DP_SST_SIDEBAND_MSG;
Bit[1] of MSTM_CAP indicates sideband messaging is supported or not and nothing
to do with MST/SST. So would it make more sense to have it as
DRM_DP_SIDEBAND_MSG?
Thanks and Regards,
Arun R Murthy
>
> - return mstm_cap & DP_MST_CAP;
> + return DRM_DP_SST;
> }
> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5045c34a16be..a1c304f451bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->display.params.enable_dp_mst &&
> intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DRM_DP_MST;
> }
>
> static void
> @@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> _to_dig_port(intel_dp)->base;
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp-
> >dpcd);
> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux,
> +intel_dp->dpcd) == DRM_DP_MST;
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s,
> modparam: %s\n", diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7de7707ec6a8..fb06ee17d9e5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
> *nv_connector,
> if (nouveau_mst) {
> mstm = outp->dp.mstm;
> if (mstm)
> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd)
> == DRM_DP_MST;
> }
>
> if (nouveau_dp_has_sink_count(connector, outp)) { diff --git
> a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 9b19d8bd520a..3c9e128c444a 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -818,7 +818,28 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr
> *mgr);
>
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
Re: [PATCH 09/28] drm: Add Color ops capability property
On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> Add capability property which a colorop can expose it's
> hardware's abilities. It's a blob property that can be
> filled with respective data structures depending on the
> colorop. The user space is expected to read this property
> and program the colorop accordingly.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> include/drm/drm_colorop.h | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9f6a3a1c8020..95f1df73209c 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> *val = state->curve_1d_type;
> } else if (property == colorop->data_property) {
> *val = (state->data) ? state->data->base.id : 0;
> + } else if (property == colorop->hw_caps_property) {
> + *val = state->hw_caps ?
> + state->hw_caps->base.id : 0;
> } else {
> return -EINVAL;
> }
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index 5b8c36538491..f417e109c40a 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -59,6 +59,12 @@ struct drm_colorop_state {
>*/
> enum drm_colorop_curve_1d_type curve_1d_type;
>
> + /**
> + * @hw_caps:
> + *
> + */
> + struct drm_property_blob *hw_caps;
> +
Is this supposed to be generic for any colorop or specifically for
DRM_COLOROP_1D_LUT?
> /**
>* @data:
>*
> @@ -167,6 +173,13 @@ struct drm_colorop {
>*/
> struct drm_property *bypass_property;
>
> + /**
> + * @hwlut_caps_property:
> + *
> + * Property to expose hardware lut capbilities.
> + */
> + struct drm_property *hw_caps_property;
> +
> /**
>* @curve_1d_type:
>*
> --
> 2.42.0
>
Re: [PATCH 08/28] drm: Add Color lut range attributes
On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> This defines a new structure to define color lut ranges,
> along with related macro definitions and enums. This will help
> describe segmented lut ranges/PWL LUTs in the hardware.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> include/uapi/drm/drm_mode.h | 58 +
> 1 file changed, 58 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index af67f32e0087..376498715d0e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> DRM_MODE_PAGE_FLIP_ASYNC | \
> DRM_MODE_PAGE_FLIP_TARGET)
>
All of this uses DRM_MODE_LUT namespace but it seems specifically for
the drm colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the
naming.
> +/**
> + * DRM_MODE_LUT_INTERPOLATE
> + *
> + * linearly interpolate between the points
> + */
> +#define DRM_MODE_LUT_INTERPOLATE BIT(0)
> +
> +/**
> + * DRM_MODE_LUT_REUSE_LAST
> + *
> + * the last value of the previous range is the
> + * first value of the current range.
> + */
> +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> +
> +/**
> + * DRM_MODE_LUT_NON_DECREASING
> + *
> + * the curve must be non-decreasing
> + */
> +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> +
> +/**
> + * DRM_MODE_LUT_REFLECT_NEGATIVE
> + *
> + * the curve is reflected across origin for negative inputs
> + */
> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> +
> +/**
> + * DRM_MODE_LUT_SINGLE_CHANNEL
> + *
> + * the same curve (red) is used for blue and green channels as well
> + */
> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> +
> +/**
> + * struct drm_color_lut_range
> + *
> + * structure to advertise capability of a color hardware
> + * block that accepts LUT values. It can represent LUTs with
> + * varied number of entries and distributions
> + * (Multi segmented, Logarithmic etc).
> + */
> +
> +struct drm_color_lut_range {
> + /* DRM_MODE_LUT_* */
> + __u32 flags;
> + /* number of points on the curve */
> + __u16 count;
> + /* input/output bits per component */
> + __u8 input_bpc, output_bpc;
> + /* input start/end values */
> + __s32 start, end;
> + /* output min/max values */
> + __s32 min, max;
> +};
> +
> /*
> * Request a page flip on the specified crtc.
> *
> --
> 2.42.0
>
Re: ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915: Prevent HW access during init from SDVO TV get_modes hook
On Mon, Feb 12, 2024 at 09:54:59PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Prevent HW access during init > from SDVO TV get_modes hook > URL : https://patchwork.freedesktop.org/series/129788/ > State : failure Thanks for the review, pushed the patchset. The failure is unrelated see below. > > == Summary == > > CI Bug Log - changes from CI_DRM_14255_full -> Patchwork_129788v1_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_129788v1_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_129788v1_full, please notify your bug team > (i915-ci-in...@lists.freedesktop.org) to allow them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (8 -> 8) > -- > > No changes in participating hosts > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_129788v1_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_flip@modeset-vs-vblank-race@c-hdmi-a1: > - shard-tglu: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14255/shard-tglu-8/igt@kms_flip@modeset-vs-vblank-r...@c-hdmi-a1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129788v1/shard-tglu-3/igt@kms_flip@modeset-vs-vblank-r...@c-hdmi-a1.html The above is: <6>[ 357.328756] snd_hda_codec_hdmi hdaudioC0D2: HDMI: audio coding xtype 5 not expected <6>[ 357.328761] snd_hda_codec_hdmi hdaudioC0D2: HDMI: audio coding xtype 0 not expected <6>[ 357.328764] snd_hda_codec_hdmi hdaudioC0D2: HDMI: audio coding xtype 10 not expected <6>[ 357.328767] snd_hda_codec_hdmi hdaudioC0D2: HDMI: audio coding xtype 6 not expected <7>[ 357.328978] i915 :00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:308:HDMI-A-1] <7>[ 357.329296] i915 :00:02.0: [drm:intel_modeset_verify_crtc [i915]] [CRTC:167:pipe B] <7>[ 357.387649] i915 :00:02.0: [drm:i915_audio_component_get_power [i915]] restored AUD_FREQ_CNTRL to 0x810 couldn't find any ticket or precedence on TGL machines ignoring suspend tests. The only oddity is the audio info messages, which only happen on shard-tgl machines, but not sure if this is the root cause. The changes in this patch shouldn't have any effect on the above CI run which would result in an "Reject display access from task ..." message. > > > New tests > - > > New tests have been introduced between CI_DRM_14255_full and > Patchwork_129788v1_full: > > ### New IGT tests (4) ### > > * igt@kms_cursor_edge_walk@256x256-left-edge@pipe-a-vga-1: > - Statuses : 1 pass(s) > - Exec time: [3.38] s > > * igt@kms_cursor_edge_walk@64x64-left-edge@pipe-a-hdmi-a-4: > - Statuses : 1 pass(s) > - Exec time: [3.32] s > > * igt@kms_cursor_edge_walk@64x64-left-edge@pipe-d-hdmi-a-4: > - Statuses : 1 pass(s) > - Exec time: [3.20] s > > * igt@kms_cursor_edge_walk@64x64-top-bottom@pipe-a-vga-1: > - Statuses : 1 pass(s) > - Exec time: [3.37] s > > > > Known issues > > > Here are the changes found in Patchwork_129788v1_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@api_intel_bb@object-reloc-purge-cache: > - shard-dg2: NOTRUN -> [SKIP][3] ([i915#8411]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129788v1/shard-dg2-10/igt@api_intel...@object-reloc-purge-cache.html > > * igt@api_intel_bb@render-ccs: > - shard-dg2: NOTRUN -> [FAIL][4] ([i915#6122]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129788v1/shard-dg2-10/igt@api_intel...@render-ccs.html > > * igt@device_reset@cold-reset-bound: > - shard-rkl: NOTRUN -> [SKIP][5] ([i915#7701]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129788v1/shard-rkl-3/igt@device_re...@cold-reset-bound.html > > * igt@drm_fdinfo@idle@rcs0: > - shard-rkl: [PASS][6] -> [FAIL][7] ([i915#7742]) +1 other test > fail >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14255/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129788v1/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html > > * igt@drm_fdinfo@most-busy-check-all@bcs0: > - shard-dg2: NOTRUN -> [SKIP][8] ([i915#8414]) +11 other tests > skip >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129788v1/shard-dg2-5/igt@drm_fdinfo@most-busy-check-...@bcs0.html > > * igt@fbdev@pan: > - shard-snb: [PASS][9] -> [FAIL][10] ([i915#4435]) >[9]: >
[PATCH v2 6/6] drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
If the sink supports 128b/132b and single-stream sideband messaging, enable MST mode. With this, the topology manager will still write DP_MSTM_CTRL, which should be ignored by the sink. In the future, the topology manager should probably only set the sideband messaging related parts of the register. Cc: Arun R Murthy Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 7f97d5512a3e..689d5c8ba6b0 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4027,7 +4027,8 @@ intel_dp_mst_mode_choose(struct intel_dp *intel_dp, if (!intel_dp_mst_source_support(intel_dp)) return DRM_DP_SST; - if (sink_mst_mode == DRM_DP_SST_SIDEBAND_MSG) + if (sink_mst_mode == DRM_DP_SST_SIDEBAND_MSG && + !(intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B)) return DRM_DP_SST; return sink_mst_mode; -- 2.39.2
[PATCH v2 5/6] drm/i915/mst: add intel_dp_mst_disconnect()
Abstract the MST mode disconnect to a separate function.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 72e91322e310..7f97d5512a3e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4069,6 +4069,20 @@ intel_dp_mst_configure(struct intel_dp *intel_dp)
intel_dp->mst_detect = DRM_DP_SST;
}
+static void
+intel_dp_mst_disconnect(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ if (!intel_dp->is_mst)
+ return;
+
+ drm_dbg_kms(>drm, "MST device may have disappeared %d vs %d\n",
+ intel_dp->is_mst, intel_dp->mst_mgr.mst_state);
+ intel_dp->is_mst = false;
+ drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
+}
+
static bool
intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *esi)
{
@@ -5721,15 +5735,7 @@ intel_dp_detect(struct drm_connector *connector,
memset(intel_connector->dp.dsc_dpcd, 0,
sizeof(intel_connector->dp.dsc_dpcd));
intel_dp->psr.sink_panel_replay_support = false;
- if (intel_dp->is_mst) {
- drm_dbg_kms(_priv->drm,
- "MST device may have disappeared %d vs
%d\n",
- intel_dp->is_mst,
- intel_dp->mst_mgr.mst_state);
- intel_dp->is_mst = false;
- drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
- intel_dp->is_mst);
- }
+ intel_dp_mst_disconnect(intel_dp);
goto out;
}
--
2.39.2
[PATCH v2 4/6] drm/i915/mst: use the MST mode detected previously
Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
logic for choosing MST mode, and store the chosen mode in struct
intel_dp. Rename intel_dp_configure_mst() to intel_dp_mst_configure()
while at it.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 23 ---
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 01eb6e4e6049..4a8440a3a812 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1780,6 +1780,7 @@ struct intel_dp {
bool is_mst;
int active_mst_links;
+ enum drm_dp_mst_mode mst_detect;
/* connector directly attached - won't be use for modeset in mst world
*/
struct intel_connector *attached_connector;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 007cb2a04e38..72e91322e310 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4039,11 +4039,10 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
enum drm_dp_mst_mode sink_mst_mode;
- enum drm_dp_mst_mode mst_detect;
sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
- mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
+ intel_dp->mst_detect = intel_dp_mst_mode_choose(intel_dp,
sink_mst_mode);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s -> enable: %s\n",
@@ -4051,25 +4050,23 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
str_yes_no(intel_dp_mst_source_support(intel_dp)),
intel_dp_mst_mode_str(sink_mst_mode),
str_yes_no(i915->display.params.enable_dp_mst),
- intel_dp_mst_mode_str(mst_detect));
+ intel_dp_mst_mode_str(intel_dp->mst_detect));
- return mst_detect != DRM_DP_SST;
+ return intel_dp->mst_detect != DRM_DP_SST;
}
static void
-intel_dp_configure_mst(struct intel_dp *intel_dp)
+intel_dp_mst_configure(struct intel_dp *intel_dp)
{
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
== DRM_DP_MST;
-
if (!intel_dp_mst_source_support(intel_dp))
return;
- intel_dp->is_mst = sink_can_mst &&
- i915->display.params.enable_dp_mst;
+ intel_dp->is_mst = intel_dp->mst_detect != DRM_DP_SST;
+
+ drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst);
- drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
- intel_dp->is_mst);
+ /* Avoid stale info on the next detect cycle. */
+ intel_dp->mst_detect = DRM_DP_SST;
}
static bool
@@ -5739,7 +5736,7 @@ intel_dp_detect(struct drm_connector *connector,
intel_dp_detect_dsc_caps(intel_dp, intel_connector);
- intel_dp_configure_mst(intel_dp);
+ intel_dp_mst_configure(intel_dp);
/*
* TODO: Reset link params when switching to MST mode, until MST
--
2.39.2
[PATCH v2 3/6] drm/i915/mst: abstract choosing the MST mode to use
Clarify the conditions for choosing the MST mode to use by adding a new
function intel_dp_mst_mode_choose(). This also prepares for being able
to extend the MST modes to single-stream sideband messaging.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 944f566525dd..007cb2a04e38 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4015,6 +4015,24 @@ static const char *intel_dp_mst_mode_str(enum
drm_dp_mst_mode mst_mode)
return str_yes_no(mst_mode == DRM_DP_MST);
}
+static enum drm_dp_mst_mode
+intel_dp_mst_mode_choose(struct intel_dp *intel_dp,
+enum drm_dp_mst_mode sink_mst_mode)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ if (!i915->display.params.enable_dp_mst)
+ return DRM_DP_SST;
+
+ if (!intel_dp_mst_source_support(intel_dp))
+ return DRM_DP_SST;
+
+ if (sink_mst_mode == DRM_DP_SST_SIDEBAND_MSG)
+ return DRM_DP_SST;
+
+ return sink_mst_mode;
+}
+
static bool
intel_dp_mst_detect(struct intel_dp *intel_dp)
{
@@ -4025,12 +4043,7 @@ intel_dp_mst_detect(struct intel_dp *intel_dp)
sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
- if (i915->display.params.enable_dp_mst &&
- intel_dp_mst_source_support(intel_dp) &&
- sink_mst_mode == DRM_DP_MST)
- mst_detect = DRM_DP_MST;
- else
- mst_detect = DRM_DP_SST;
+ mst_detect = intel_dp_mst_mode_choose(intel_dp, sink_mst_mode);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s -> enable: %s\n",
--
2.39.2
[PATCH v2 2/6] drm/i915/mst: improve debug logging of DP MST mode detect
Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
detect debug logging there. Debug log the sink's MST capability,
including single-stream sideband messaging support, and the decision
whether to enable MST mode or not. Do this regardless of whether we're
actually enabling MST or not.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 45 +
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a1c304f451bd..944f566525dd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4007,31 +4007,48 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
intel_dp->downstream_ports) == 0;
}
+static const char *intel_dp_mst_mode_str(enum drm_dp_mst_mode mst_mode)
+{
+ if (mst_mode == DRM_DP_SST_SIDEBAND_MSG)
+ return "single-stream sideband messaging";
+ else
+ return str_yes_no(mst_mode == DRM_DP_MST);
+}
+
static bool
-intel_dp_can_mst(struct intel_dp *intel_dp)
+intel_dp_mst_detect(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ enum drm_dp_mst_mode sink_mst_mode;
+ enum drm_dp_mst_mode mst_detect;
+
+ sink_mst_mode = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
+
+ if (i915->display.params.enable_dp_mst &&
+ intel_dp_mst_source_support(intel_dp) &&
+ sink_mst_mode == DRM_DP_MST)
+ mst_detect = DRM_DP_MST;
+ else
+ mst_detect = DRM_DP_SST;
- return i915->display.params.enable_dp_mst &&
- intel_dp_mst_source_support(intel_dp) &&
- drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
DRM_DP_MST;
+ drm_dbg_kms(>drm,
+ "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s -> enable: %s\n",
+ encoder->base.base.id, encoder->base.name,
+ str_yes_no(intel_dp_mst_source_support(intel_dp)),
+ intel_dp_mst_mode_str(sink_mst_mode),
+ str_yes_no(i915->display.params.enable_dp_mst),
+ intel_dp_mst_mode_str(mst_detect));
+
+ return mst_detect != DRM_DP_SST;
}
static void
intel_dp_configure_mst(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- struct intel_encoder *encoder =
- _to_dig_port(intel_dp)->base;
bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
== DRM_DP_MST;
- drm_dbg_kms(>drm,
- "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s\n",
- encoder->base.base.id, encoder->base.name,
- str_yes_no(intel_dp_mst_source_support(intel_dp)),
- str_yes_no(sink_can_mst),
- str_yes_no(i915->display.params.enable_dp_mst));
-
if (!intel_dp_mst_source_support(intel_dp))
return;
@@ -5390,7 +5407,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
connector_status_connected : connector_status_disconnected;
}
- if (intel_dp_can_mst(intel_dp))
+ if (intel_dp_mst_detect(intel_dp))
return connector_status_connected;
/* If no HPD, poke DDC gently */
--
2.39.2
[PATCH v2 1/6] drm/mst: read sideband messaging cap
Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST
with sideband messaging", or "MST". Modify all call sites to take the
new return value into account.
v2:
- Rename enumerators (Ville)
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 23 ++-
4 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 03d528209426..c193be3577f7 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const struct
drm_dp_mst_topology_mgr *mgr,
EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
/**
- * drm_dp_read_mst_cap() - check whether or not a sink supports MST
+ * drm_dp_read_mst_cap() - Read the sink's MST mode capability
* @aux: The DP AUX channel to use
* @dpcd: A cached copy of the DPCD capabilities for this sink
*
- * Returns: %True if the sink supports MST, %false otherwise
+ * Returns: enum drm_dp_mst_mode to indicate MST mode capability
*/
-bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
-const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
+const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
u8 mstm_cap;
if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
- return false;
+ return DRM_DP_SST;
if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
- return false;
+ return DRM_DP_SST;
+
+ if (mstm_cap & DP_MST_CAP)
+ return DRM_DP_MST;
+
+ if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
+ return DRM_DP_SST_SIDEBAND_MSG;
- return mstm_cap & DP_MST_CAP;
+ return DRM_DP_SST;
}
EXPORT_SYMBOL(drm_dp_read_mst_cap);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5045c34a16be..a1c304f451bd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
return i915->display.params.enable_dp_mst &&
intel_dp_mst_source_support(intel_dp) &&
- drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
+ drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
DRM_DP_MST;
}
static void
@@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder =
_to_dig_port(intel_dp)->base;
- bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
+ bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd)
== DRM_DP_MST;
drm_dbg_kms(>drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s\n",
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 7de7707ec6a8..fb06ee17d9e5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
if (nouveau_mst) {
mstm = outp->dp.mstm;
if (mstm)
- mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
+ mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd) ==
DRM_DP_MST;
}
if (nouveau_dp_has_sink_count(connector, outp)) {
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 9b19d8bd520a..3c9e128c444a 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -818,7 +818,28 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
-bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
+/**
+ * enum drm_dp_mst_mode - sink's MST mode capability
+ */
+enum drm_dp_mst_mode {
+ /**
+* @DRM_DP_SST: The sink does not support MST nor single stream sideband
+* messaging.
+*/
+ DRM_DP_SST,
+ /**
+* @DRM_DP_MST: Sink supports MST, more than one stream and single
+* stream sideband messaging.
+*/
+ DRM_DP_MST,
+ /**
+* @DRM_DP_SST_SIDEBAND_MSG: Sink supports only one stream and single
+* stream sideband messaging.
+*/
+ DRM_DP_SST_SIDEBAND_MSG,
+};
+
+enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
[PATCH v2 0/6] drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
Sort of successor to [1], but revamped. BR, Jani. [1] https://patchwork.freedesktop.org/series/129468/ Jani Nikula (6): drm/mst: read sideband messaging cap drm/i915/mst: improve debug logging of DP MST mode detect drm/i915/mst: abstract choosing the MST mode to use drm/i915/mst: use the MST mode detected previously drm/i915/mst: add intel_dp_mst_disconnect() drm/i915/mst: enable MST mode for 128b/132b single-stream sideband drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 +++-- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 90 +-- drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +- include/drm/display/drm_dp_mst_helper.h | 23 - 5 files changed, 99 insertions(+), 37 deletions(-) -- 2.39.2
Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
On Tue, 13 Feb 2024 12:18:07 +0530 Uma Shankar wrote: > This series intends to add support for Plane Color Management for > Intel platforms. This is based on the design which has been agreed > upon by the community. Series implementing the design for generic > DRM core has been sent out by Harry Wentland and is under review > below: > https://patchwork.freedesktop.org/series/123446/ > > The base work of above series is squashed under 1 patch and support > for Intel platform is added on top of it. > Any reviews on the original core design is expected to be done in > Harry's series to avoid any forking of the discussion. > > We have added some changes/fixes to the Harry's core DRM changes, > being put up as separate patches on top of squashed patch. These are > expected to get included in the main series from Harry once agreed upon. > > Changes added on core design: > 1. Below patches implement some fixes on original series > drm: Add missing function declarations > drm: handle NULL next colorop in drm_colorop_set_next_property > drm: Fix error logging in set Color Pipeline > > 2. Implemented a HW capability property to expose segmented luts. > drm: Add Color lut range attributes > drm: Add Color ops capability property > drm: Define helper to create color ops capability property > drm: Define helper for adding capability property for 1D LUT > > This helps in generically defining the hardware lut capabilities, > lut distribution, precision, segmented or PWL LUTS. > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > drm: Add Enhanced LUT precision structure > drm: Add support for 3x3 CTM > drm: Add 1D LUT color op > > On top of this base work for DRM core plane color pipeline design, > implementation is done for Intel hardware platforms. Below patches > include the same: > > drm/i915: Add identifiers for intel color blocks > drm/i915: Add intel_color_op > drm/i915/color: Add helper to allocate intel colorop > drm/i915/color: Add helper to create intel colorop > drm/i915/color: Create a transfer function color pipeline > drm/i915/color: Add and attach COLORPIPELINE plane property > drm/i915/color: Add framework to set colorop > drm/i915/color: Add callbacks to set plane CTM > drm/i915/color: Add framework to program PRE/POST CSC LUT > FIXME: force disable legacy plane color properties for TGL and beyond > drm/i915/color: Enable Plane Color Pipelines > drm/i915: Define segmented Lut and add capabilities to colorop > drm/i915/color: Add plane CTM callback for TGL and beyond > drm/i915: Add register definitions for Plane Degamma > drm/i915: Add register definitions for Plane Post CSC > drm/i915/color: Program Pre-CSC registers > drm/i915/xelpd: Program Plane Post CSC Registers > > Bhanu from Intel will be sending out the igt changes to help test the > color pipeline implementation based on the current igt changes sent out > by Harry. > https://patchwork.freedesktop.org/series/123448/ > > Planned Next Steps: > 1. Work with Harry and community and get DRM core changes for color > pipeline merged. > 2. Implement pipe color management (post blending) based on the current > color pipeline design. > 3. Work with compositor maintainers to get color processing implemented > using display hardware, thereby avoid any GL or GPU shaders. > > Thanks to all the community maintainers and contributors who have helped > to get this support in upstream Linux. Looking forward to collaborate, > work together and get this merged. > ... > Chaitanya Kumar Borah (16): > drm: Add missing function declarations > drm: handle NULL next colorop in drm_colorop_set_next_property > drm: Fix error logging in set Color Pipeline > drm: Add support for 3x3 CTM > drm: Add 1D LUT color op > drm/i915: Add identifiers for intel color blocks > drm/i915: Add intel_color_op > drm/i915/color: Add helper to allocate intel colorop > drm/i915/color: Add helper to create intel colorop > drm/i915/color: Create a transfer function color pipeline > drm/i915/color: Add and attach COLORPIPELINE plane property > drm/i915/color: Add framework to set colorop > drm/i915/color: Add callbacks to set plane CTM > drm/i915/color: Add framework to program PRE/POST CSC LUT > FIXME: force disable legacy plane color properties for TGL and beyond > drm/i915/color: Enable Plane Color Pipelines > > Harry Wentland (1): > [NOT FOR REVIEW] drm: color pipeline base work > > Uma Shankar (11): > drm: Add Enhanced LUT precision structure > drm: Add Color lut range attributes > drm: Add Color ops capability property > drm: Define helper to create color ops capability property > drm: Define helper for adding capability property for 1D LUT > drm/i915: Define segmented Lut and add capabilities to colorop > drm/i915/color: Add plane CTM callback for TGL and beyond > drm/i915: Add register definitions for Plane Degamma > drm/i915: Add register definitions for Plane Post CSC > drm/i915/color: Program
[PATCH 3/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset
Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
slave crtcs should be handled by master hooks. Same for encoders.
That way we can also remove a bunch of checks like
intel_crtc_is_bigjoiner_slave.
v2: Get rid of master vs slave checks and separation in crtc enable/disable
hooks.
Use unified iteration cycle for all of those, while enabling/disabling
transcoder only for those pipes where its needed(Ville Syrjälä)
v3: Move all the intel_encoder_* calls under transcoder code path(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 183 ---
drivers/gpu/drm/i915/display/intel_display.h | 6 +
3 files changed, 121 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 922194b957be2..6c690aefec9d1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3340,8 +3340,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
{
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
- if (!intel_crtc_is_bigjoiner_slave(crtc_state))
- intel_ddi_enable_transcoder_func(encoder, crtc_state);
+ intel_ddi_enable_transcoder_func(encoder, crtc_state);
/* Enable/Disable DP2.0 SDP split config before transcoder */
intel_audio_sdp_split_update(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 616a890b2658f..8ef2f38b8ed96 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1631,31 +1631,12 @@ static void hsw_configure_cpu_transcoder(const struct
intel_crtc_state *crtc_sta
hsw_set_transconf(crtc_state);
}
-static void hsw_crtc_enable(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+static void hsw_crtc_enable_pre_transcoder(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
- enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
- bool psl_clkgate_wa;
-
- if (drm_WARN_ON(_priv->drm, crtc->active))
- return;
-
- intel_dmc_enable_pipe(dev_priv, crtc->pipe);
-
- if (!new_crtc_state->bigjoiner_pipes) {
- intel_encoders_pre_pll_enable(state, crtc);
-
- if (new_crtc_state->shared_dpll)
- intel_enable_shared_dpll(new_crtc_state);
-
- intel_encoders_pre_enable(state, crtc);
- } else {
- icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
- }
intel_dsc_enable(new_crtc_state);
@@ -1665,19 +1646,17 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
intel_set_pipe_src_size(new_crtc_state);
if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
bdw_set_pipe_misc(new_crtc_state);
+}
- if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
- !transcoder_is_dsi(cpu_transcoder))
- hsw_configure_cpu_transcoder(new_crtc_state);
+static void hsw_crtc_enable_post_transcoder(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
crtc->active = true;
- /* Display WA #1180: WaDisableScalarClockGating: glk */
- psl_clkgate_wa = DISPLAY_VER(dev_priv) == 10 &&
- new_crtc_state->pch_pfit.enabled;
- if (psl_clkgate_wa)
- glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
-
if (DISPLAY_VER(dev_priv) >= 9)
skl_pfit_enable(new_crtc_state);
else
@@ -1701,26 +1680,83 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
intel_initial_watermarks(state, crtc);
- if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
- intel_crtc_vblank_on(new_crtc_state);
+ intel_crtc_vblank_on(new_crtc_state);
+}
- intel_encoders_enable(state, crtc);
+static void hsw_crtc_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
+ struct
RE: [PATCH 2/5] drm/i915: Include the CRTC name in the ELD buffer mismatch
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, February 9, 2024 8:38 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 2/5] drm/i915: Include the CRTC name in the ELD buffer
> mismatch
>
> From: Ville Syrjälä
>
> Most crtc state mismatches include the CRTC id+name in the prints. Also
> include it in the ELD buffer mismatch prints.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f20728b7f67b..1d381fa96c84 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4851,10 +4851,12 @@ memcmp_diff_len(const u8 *a, const u8 *b, size_t len)
> }
>
> static void
> -pipe_config_buffer_mismatch(struct drm_i915_private *dev_priv,
> - bool fastset, const char *name,
> +pipe_config_buffer_mismatch(bool fastset, const struct intel_crtc *crtc,
> + const char *name,
> const u8 *a, const u8 *b, size_t len) {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +
> if (fastset) {
> if (!drm_debug_enabled(DRM_UT_KMS))
> return;
> @@ -4863,7 +4865,8 @@ pipe_config_buffer_mismatch(struct drm_i915_private
> *dev_priv,
> len = memcmp_diff_len(a, b, len);
>
> drm_dbg_kms(_priv->drm,
> - "fastset requirement not met in %s buffer\n", name);
> + "[CRTC:%d:%s] fastset requirement not met in %s
> buffer\n",
> + crtc->base.base.id, crtc->base.name, name);
> print_hex_dump(KERN_DEBUG, "expected: ", DUMP_PREFIX_NONE,
> 16, 0, a, len, false);
> print_hex_dump(KERN_DEBUG, "found: ", DUMP_PREFIX_NONE, @@
> -4872,7 +4875,8 @@
> pipe_config_buffer_mismatch(struct drm_i915_private *dev_priv,
> /* only dump up to the last difference */
> len = memcmp_diff_len(a, b, len);
>
> - drm_err(_priv->drm, "mismatch in %s buffer\n", name);
> + drm_err(_priv->drm, "[CRTC:%d:%s] mismatch in %s buffer\n",
> + crtc->base.base.id, crtc->base.name, name);
> print_hex_dump(KERN_ERR, "expected: ", DUMP_PREFIX_NONE,
> 16, 0, a, len, false);
> print_hex_dump(KERN_ERR, "found: ", DUMP_PREFIX_NONE, @@
> -5071,7 +5075,7 @@
> intel_pipe_config_compare(const struct intel_crtc_state *current_config,
> BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
> BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
> if (!intel_compare_buffer(current_config->name, pipe_config->name,
> (len))) { \
> - pipe_config_buffer_mismatch(dev_priv, fastset,
> __stringify(name), \
> + pipe_config_buffer_mismatch(fastset, crtc, __stringify(name), \
> current_config->name, \
> pipe_config->name, \
> (len)); \
> --
> 2.43.0
Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
On Tue, 13 Feb 2024 12:18:24 +0530
Uma Shankar wrote:
> This defines the lut segments and create the color pipeline
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 109 +
> 1 file changed, 109 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index e223edbe4c13..223cd1ff7291 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs ilk_color_funcs
> = {
> .get_config = ilk_get_config,
> };
>
> +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> + /* segment 1 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_NON_DECREASING),
Hi Uma,
is it a good idea to have these flags per-segment?
I would find it very strange, unusable really, if REFLECT_NEGATIVE
applied on some but not all segments, for example. Is such flexibility
really necessary in the hardware description?
> + .count = 128,
> + .input_bpc = 24, .output_bpc = 16,
The same question about input_bpc and output_bpc.
> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
What if there is a gap or overlap between the previous segment .end and
the next segment .start? Is it forbidden? Will the kernel common code
verify that drivers don't make mistakes? Or IGT?
Thanks,
pq
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 3 << 24, .end = 7 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + }
> +};
> +
> +/* FIXME input bpc? */
> +static const struct drm_color_lut_range xelpd_gamma_hdr[] = {
> + /*
> + * ToDo: Add Segment 1
> + * There is an optional fine segment added with 9 lut values
> + * Will be added later
> + */
> +
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 32,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
> + .min = 0, .max = 1 << 24,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (3 << 24),
> + },
> + /* Segment 5 */
> + {
> + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> +
Re: [PATCH 3/4] drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
On 2/12/2024 11:06 PM, Mitul Golani wrote:
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
- Correct code indent. [Jani]
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_dp.c | 95 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 12 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
include/drm/display/drm_dp_helper.h | 3 +
4 files changed, 112 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5045c34a16be..6e9180ce069a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -95,7 +95,6 @@
#define INTEL_DP_RESOLUTION_STANDARD (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
#define INTEL_DP_RESOLUTION_FAILSAFE (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
-
/* Constants for DP DSC configurations */
static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
@@ -4087,6 +4086,34 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
return false;
}
+static ssize_t intel_dp_as_sdp_pack(const struct drm_dp_as_sdp *as_sdp,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /* Prepare AS (Adaptive Sync) SDP Header */
+ sdp->sdp_header.HB0 = 0;
+ sdp->sdp_header.HB1 = as_sdp->sdp_type;
+ sdp->sdp_header.HB2 = 0x02;
+ sdp->sdp_header.HB3 = as_sdp->length;
+
+ /* Fill AS (Adaptive Sync) SDP Payload */
+ sdp->db[1] = 0x0;
+ sdp->db[1] = as_sdp->vtotal & 0xFF;
+ sdp->db[2] = (as_sdp->vtotal >> 8) & 0xF;
+ sdp->db[3] = 0x0;
+ sdp->db[4] = 0x0;
+ sdp->db[7] = 0x0;
+ sdp->db[8] = 0x0;
+
+ return length;
+}
+
static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
struct dp_sdp *sdp, size_t size)
{
@@ -4254,6 +4281,10 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
_state->infoframes.drm.drm,
,
sizeof(sdp));
break;
+ case DP_SDP_ADAPTIVE_SYNC:
+ len = intel_dp_as_sdp_pack(_state->infoframes.as_sdp, ,
+ sizeof(sdp));
+ break;
default:
MISSING_CASE(type);
return;
@@ -4274,7 +4305,8 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 dip_enable = VIDEO_DIP_ENABLE_AVI_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW |
-VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK;
+VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK |
+VIDEO_DIP_ENABLE_AS_HSW;
Perhaps set this only for ADLP+
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
@@ -4296,6 +4328,40 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static
+int intel_dp_as_sdp_unpack(struct drm_dp_as_sdp *as_sdp,
+ const void *buffer, size_t size)
+{
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ memset(as_sdp, 0, sizeof(*as_sdp));
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != DP_SDP_ADAPTIVE_SYNC)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB2 != 0x02)
+ return -EINVAL;
+
+ if ((sdp->sdp_header.HB3 & 0x3F) != 9)
+ return -EINVAL;
+
+ if ((sdp->db[0] & AS_SDP_OP_MODE) != 0x0)
+ return -EINVAL;
+
+ as_sdp->vtotal = ((u64)sdp->db[2] << 32) | (u64)sdp->db[1];
+ as_sdp->target_rr = 0;
+ as_sdp->duration_incr_ms = 0;
+ as_sdp->duration_decr_ms = 0;
+
+ return 0;
+}
+
static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp *vsc,
const void *buffer, size_t size)
{
@@ -4366,6 +4432,27 @@ static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp
*vsc,
return 0;
}
+static int
+intel_read_dp_metadata_infoframe_as_sdp(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state,
Re: [PATCH 05/28] drm: Add support for 3x3 CTM
On Tue, 13 Feb 2024 12:18:12 +0530
Uma Shankar wrote:
> From: Chaitanya Kumar Borah
>
> Add support for 3x3 Color Transformation Matrices in Color Pipeline.
>
> Signed-off-by: Chaitanya Kumar Borah
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> drivers/gpu/drm/drm_colorop.c | 2 +-
> include/uapi/drm/drm_mode.h | 1 +
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index e7bf1fb054af..c54b0d6c133e 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> case DRM_COLOROP_CTM_3X4:
> size = sizeof(struct drm_color_ctm_3x4);
> break;
> + case DRM_COLOROP_CTM_3X3:
> + size = sizeof(struct drm_color_ctm);
> + break;
> default:
> /* should never get here */
> return -EINVAL;
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 462ffec42cdf..6bae6dc8e54b 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> 0);
>
> /* data */
> - if (type == DRM_COLOROP_CTM_3X4) {
> + if (type == DRM_COLOROP_CTM_3X4 || type == DRM_COLOROP_CTM_3X3) {
> prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLOB,
> "DATA", 0);
> if (!prop)
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index f16318f1785f..68696253867e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -868,6 +868,7 @@ struct drm_color_lut {
>
> enum drm_colorop_type {
> DRM_COLOROP_1D_CURVE,
> + DRM_COLOROP_CTM_3X3,
> DRM_COLOROP_CTM_3X4,
> };
>
Hi,
where are the docs for DRM_COLOROP_CTM_3X3?
Thanks,
pq
pgpN84FhUCsw1.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
On Mon, 12 Feb 2024, Uma Shankar wrote:
> From: Stanislav Lisovskiy
>
> For validation purposes, it might be useful to be able to
> force Bigjoiner mode, even if current dotclock/resolution
> do not require that.
> Lets add such to option to debugfs.
>
> v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> debugfs entry is created so lets just check manually
> the DISPLAY_VER.
>
> v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> - Remove redundant modeset lock(Jani Nikula)
> - Use kstrtobool_from_user for boolean value(Jani Nikula)
>
> v4: - Apply the changes to proper function(Jani Nikula)
>
> v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> (Ville Syrjälä)
> - Added eDP connector check to intel_connector_debugfs_add
> (Ville Syrjälä)
> - Removed debug message in order to prevent dmesg flooding
> (Ville Syrjälä)
>
> v6: - Assume now always that m->private is intel_connector
> - Fixed other similar conflicts
>
> v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> manually.(Ville Syrjälä)
>
> v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
> (Jani Nikula)
>
> Signed-off-by: Stanislav Lisovskiy
Acked-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_debugfs.c | 47 +++
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 6f2d13c8ccf7..a962b48bcf13 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1391,6 +1391,20 @@ out:
> drm_modeset_unlock(>drm.mode_config.connection_mutex);
> return ret;
> }
>
> +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> +{
> + struct intel_connector *connector = m->private;
> + struct drm_crtc *crtc;
> +
> + crtc = connector->base.state->crtc;
> + if (connector->base.status != connector_status_connected || !crtc)
> + return -ENODEV;
> +
> + seq_printf(m, "Bigjoiner enable: %d\n",
> connector->force_bigjoiner_enable);
> +
> + return 0;
> +}
> +
> static ssize_t i915_dsc_output_format_write(struct file *file,
> const char __user *ubuf,
> size_t len, loff_t *offp)
> @@ -1412,6 +1426,30 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
> return len;
> }
>
> +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> +const char __user *ubuf,
> +size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct intel_connector *connector = m->private;
> + struct drm_crtc *crtc;
> + bool bigjoiner_en = 0;
> + int ret;
> +
> + crtc = connector->base.state->crtc;
> + if (connector->base.status != connector_status_connected || !crtc)
> + return -ENODEV;
> +
> + ret = kstrtobool_from_user(ubuf, len, _en);
> + if (ret < 0)
> + return ret;
> +
> + connector->force_bigjoiner_enable = bigjoiner_en;
> + *offp += len;
> +
> + return len;
> +}
> +
> static int i915_dsc_output_format_open(struct inode *inode,
> struct file *file)
> {
> @@ -1505,6 +1543,8 @@ static const struct file_operations
> i915_dsc_fractional_bpp_fops = {
> .write = i915_dsc_fractional_bpp_write
> };
>
> +DEFINE_SHOW_STORE_ATTRIBUTE(i915_bigjoiner_enable);
> +
> /*
> * Returns the Current CRTC's bpc.
> * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> @@ -1586,6 +1626,13 @@ void intel_connector_debugfs_add(struct
> intel_connector *connector)
> connector, _dsc_fractional_bpp_fops);
> }
>
> + if (DISPLAY_VER(i915) >= 11 &&
> + (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP)) {
> + debugfs_create_file("i915_bigjoiner_force_enable", 0644, root,
> + connector, _bigjoiner_enable_fops);
> + }
> +
> if (connector_type == DRM_MODE_CONNECTOR_DSI ||
> connector_type == DRM_MODE_CONNECTOR_eDP ||
> connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 01eb6e4e6049..0d4012097db1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -626,6 +626,8 @@
✗ Fi.CI.BAT: failure for Plane Color Pipeline support for Intel platforms
== Series Details == Series: Plane Color Pipeline support for Intel platforms URL : https://patchwork.freedesktop.org/series/129811/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14259 -> Patchwork_129811v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_129811v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_129811v1, please notify your bug team (i915-ci-in...@lists.freedesktop.org) 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_129811v1/index.html Participating hosts (37 -> 37) -- Additional (2): bat-kbl-2 fi-bsw-n3050 Missing(2): bat-atsm-1 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_129811v1: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - bat-adln-1: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-adln-1/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-adln-1/igt@debugfs_test@read_all_entries.html - bat-mtlp-8: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-mtlp-8/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-mtlp-8/igt@debugfs_test@read_all_entries.html - bat-dg2-8: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-dg2-8/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-dg2-8/igt@debugfs_test@read_all_entries.html - bat-adlm-1: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-adlm-1/igt@debugfs_test@read_all_entries.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-adlm-1/igt@debugfs_test@read_all_entries.html - fi-tgl-1115g4: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/fi-tgl-1115g4/igt@debugfs_test@read_all_entries.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/fi-tgl-1115g4/igt@debugfs_test@read_all_entries.html - bat-mtlp-6: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-mtlp-6/igt@debugfs_test@read_all_entries.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-mtlp-6/igt@debugfs_test@read_all_entries.html - bat-dg1-7: [PASS][13] -> [ABORT][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-dg1-7/igt@debugfs_test@read_all_entries.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-dg1-7/igt@debugfs_test@read_all_entries.html - bat-adlp-9: [PASS][15] -> [ABORT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-adlp-9/igt@debugfs_test@read_all_entries.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-adlp-9/igt@debugfs_test@read_all_entries.html - bat-adlp-6: [PASS][17] -> [ABORT][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-adlp-6/igt@debugfs_test@read_all_entries.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-adlp-6/igt@debugfs_test@read_all_entries.html - bat-rplp-1: [PASS][19] -> [ABORT][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-rplp-1/igt@debugfs_test@read_all_entries.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-rplp-1/igt@debugfs_test@read_all_entries.html - fi-rkl-11600: [PASS][21] -> [ABORT][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/fi-rkl-11600/igt@debugfs_test@read_all_entries.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/fi-rkl-11600/igt@debugfs_test@read_all_entries.html - bat-dg2-9: [PASS][23] -> [ABORT][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-dg2-9/igt@debugfs_test@read_all_entries.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-dg2-9/igt@debugfs_test@read_all_entries.html - bat-dg2-11: [PASS][25] -> [ABORT][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14259/bat-dg2-11/igt@debugfs_test@read_all_entries.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129811v1/bat-dg2-11/igt@debugfs_test@read_all_entries.html Suppressed The following results come from untrusted machines, tests, or statuses. They do not affect the overall result. *
✗ Fi.CI.SPARSE: warning for Plane Color Pipeline support for Intel platforms
== Series Details == Series: Plane Color Pipeline support for Intel platforms URL : https://patchwork.freedesktop.org/series/129811/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
✗ Fi.CI.CHECKPATCH: warning for Plane Color Pipeline support for Intel platforms
== Series Details ==
Series: Plane Color Pipeline support for Intel platforms
URL : https://patchwork.freedesktop.org/series/129811/
State : warning
== Summary ==
Error: dim checkpatch failed
8c131441495a drm: color pipeline base work
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:24: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#24:
new file mode 100644
-:29: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#29: FILE: Documentation/gpu/rfc/color_pipeline.rst:1:
+
-:450: CHECK:LINE_SPACING: Please don't use multiple blank lines
#450: FILE: drivers/gpu/drm/drm_atomic.c:594:
+
-:507: CHECK:LINE_SPACING: Please don't use multiple blank lines
#507: FILE: drivers/gpu/drm/drm_atomic.c:786:
+
-:510: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#510: FILE: drivers/gpu/drm/drm_atomic.c:789:
+static void drm_atomic_colorop_print_state(struct drm_printer *p,
+ const struct drm_colorop_state *state)
-:517: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#517: FILE: drivers/gpu/drm/drm_atomic.c:796:
+ drm_printf(p, "\tcurve_1d_type=%s\n",
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
-:528: WARNING:IF_0: Consider removing the code enclosed by this #if 0 and its
#endif
#528: FILE: drivers/gpu/drm/drm_atomic.c:821:
+#if 0
-:529: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#529: FILE: drivers/gpu/drm/drm_atomic.c:822:
+ drm_printf(p, "\tcolor-pipeline=%s\n",$
-:530: ERROR:CODE_INDENT: code indent should use tabs where possible
#530: FILE: drivers/gpu/drm/drm_atomic.c:823:
+ drm_get_color_pipeline_name(state->color_pipeline));$
-:530: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#530: FILE: drivers/gpu/drm/drm_atomic.c:823:
+ drm_get_color_pipeline_name(state->color_pipeline));$
-:532: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#532: FILE: drivers/gpu/drm/drm_atomic.c:825:
+ drm_printf(p, "\tcolor-pipeline=%d\n",$
-:533: ERROR:CODE_INDENT: code indent should use tabs where possible
#533: FILE: drivers/gpu/drm/drm_atomic.c:826:
+ state->color_pipeline ? state->color_pipeline->base.id : 0);$
-:533: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#533: FILE: drivers/gpu/drm/drm_atomic.c:826:
+ state->color_pipeline ? state->color_pipeline->base.id : 0);$
-:677: CHECK:LINE_SPACING: Please don't use multiple blank lines
#677: FILE: drivers/gpu/drm/drm_atomic_uapi.c:259:
+
-:708: CHECK:LINE_SPACING: Please don't use multiple blank lines
#708: FILE: drivers/gpu/drm/drm_atomic_uapi.c:290:
+
+
-:738: WARNING:LINE_SPACING: Missing a blank line after declarations
#738: FILE: drivers/gpu/drm/drm_atomic_uapi.c:593:
+ struct drm_colorop *colorop = NULL;
+ colorop = drm_colorop_find(dev, file_priv, val);
-:762: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#762: FILE: drivers/gpu/drm/drm_atomic_uapi.c:707:
+static int drm_atomic_color_set_data_property(struct drm_colorop *colorop,
+ struct drm_colorop_state *state,
-:769: CHECK:LINE_SPACING: Please don't use multiple blank lines
#769: FILE: drivers/gpu/drm/drm_atomic_uapi.c:714:
+
+
-:788: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#788: FILE: drivers/gpu/drm/drm_atomic_uapi.c:733:
+static int drm_atomic_colorop_set_property(struct drm_colorop *colorop,
+ struct drm_colorop_state *state, struct drm_file *file_priv,
-:811: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#811: FILE: drivers/gpu/drm/drm_atomic_uapi.c:756:
+drm_atomic_colorop_get_property(struct drm_colorop *colorop,
+ const struct drm_colorop_state *state,
-:814: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#814: FILE: drivers/gpu/drm/drm_atomic_uapi.c:759:
+ if (property == colorop->type_property) {
[...]
+ } else if (property == colorop->bypass_property) {
[...]
+ } else if (property == colorop->curve_1d_type_property) {
[...]
+ } else if (property == colorop->data_property) {
[...]
+ } else {
[...]
-:843: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#843: FILE: drivers/gpu/drm/drm_atomic_uapi.c:1043:
+ ret = drm_atomic_colorop_get_property(colorop,
+ colorop->state, property, val);
-:873: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#873: FILE: drivers/gpu/drm/drm_atomic_uapi.c:1246:
+ ret =
