✗ Fi.CI.BAT: failure for Panel Replay eDP support (rev10)
== Series Details ==
Series: Panel Replay eDP support (rev10)
URL : https://patchwork.freedesktop.org/series/133684/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14967 -> Patchwork_133684v10
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_133684v10 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_133684v10, 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_133684v10/index.html
Participating hosts (43 -> 42)
--
Additional (2): fi-tgl-1115g4 fi-kbl-8809g
Missing(3): bat-kbl-2 bat-arls-1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_133684v10:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@hang-read-crc@pipe-b-dp-1:
- bat-dg2-8: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-dg2-8/igt@kms_pipe_crc_basic@hang-read-...@pipe-b-dp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-dg2-8/igt@kms_pipe_crc_basic@hang-read-...@pipe-b-dp-1.html
Known issues
Here are the changes found in Patchwork_133684v10 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([i915#9318])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][4] ([i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][6] ([i915#4613]) +3 other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#4103]) +1 other test skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_dsc@dsc-basic:
- fi-kbl-8809g: NOTRUN -> [SKIP][9] +30 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-kbl-8809g/igt@kms_...@dsc-basic.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#3555] / [i915#3840])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4: NOTRUN -> [SKIP][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pm_backlight@basic-brightness:
- fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#9812])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_pm_backli...@basic-brightness.html
* igt@kms_psr@psr-primary-page-flip:
- fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([i915#9732]) +3 other tests skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_...@psr-primary-page-flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#3555])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {bat-mtlp-9}: [FAIL][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-mtlp-9/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-mtlp-9/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {bat-mtlp-9}: [DMESG-FAIL][17] ([i915#11009]) -> [PASS][18] +1
other test pass
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-mtlp-9/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-mtlp-9/igt@kms_b
Re: Fixes that failed to pick to v6.10-rc2
On Wed, 05 Jun 2024, "Hogander, Jouni" wrote:
> On Wed, 2024-06-05 at 13:06 +0300, Jani Nikula wrote:
>>
>> Jouni, Animesh, there are some PSR commits with Fixes: pointing at
>> commits in v6.9 or v6.10-rc1.
>>
>> This does not apply cleanly to -rc1:
>> d07a578703db ("drm/i915/display: Do not print "psr: enabled" for on
>> Panel Replay")
>>
>> This applies but does not build:
>> 45b5853114ad ("drm/i915/psr: Get Early Transport status in
>> intel_psr_pipe_get_config")
>>
>> This applies and builds but decided to punt because of the above:
>> cd43a85ec3c6 ("drm/i915/psr: Use enable boolean from intel_crtc_state
>> for Early Transport")
>>
>> If these are important fixes to be backported to v6.10, please
>> provide
>> the backports.
>
> First patch is just for shaping debugfs interface printout. I think
> that is ok to leave out.
>
> Early transport is disabled by default currently -> should be ok to
> leave out two last patches.
There have been more PSR patches in drm-intel-next with Fixes: pointing
at commits upstream. I've skipped them too. But it should be noted that
once drm-intel-next gets merged upstream for v6.11, the stable team will
inevitably start picking those commits up.
BR,
Jani.
>
> BR,
>
> Jouni Högander
>>
>> BR,
>> Jani.
>>
>>
>
--
Jani Nikula, Intel
Re: [PATCH v9 01/11] drm/i915/psr: Check panel ALPM capability for eDP Panel Replay
On Wed, 19 Jun 2024, Jouni Högander wrote:
> Our HW doesn't support Panel Replay without AUX_LESS ALPM on eDP. Check
> panel support for this and prevent eDP panel replay if it doesn't exits.
>
> Bspec: 68920
>
> v2: use intel_alpm_aux_less_wake_supported
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a9d9383e4ee5..20e6717a5215 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -571,6 +571,13 @@ static void _panel_replay_init_dpcd(struct intel_dp
> *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>
> + if (intel_dp_is_edp(intel_dp) &&
> + (!intel_alpm_aux_less_wake_supported(intel_dp))) {
Drive-by comment, excessive parens there.
> + drm_dbg_kms(&i915->drm,
> + "Panel doesn't support AUX-less ALPM, eDP Panel
> Replay not possible\n");
> + return;
> + }
> +
> intel_dp->psr.sink_panel_replay_support = true;
>
> if (intel_dp->pr_dpcd & DP_PANEL_REPLAY_SU_SUPPORT)
--
Jani Nikula, Intel
Re: [PATCH 2/9] drm/i915/display: Wa 16021440873 is writing wrong register
On Tue, 18 Jun 2024, Jouni Högander wrote:
> Wa 16021440873 is writing wrong register. Instead of PIPE_SRCSZ_ERLY_TPT
> write CURPOS_ERLY_TPT.
I know this is merged already... but the commit message fails to explain
the changes to psr2_pipe_srcsz_early_tpt_calc().
BR,
Jani.
>
> v2: use right offset as well
>
> Fixes: 29cdef8539c3 ("drm/i915/display: Implement Wa_16021440873")
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_cursor.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_psr.c| 12 +++-
> 2 files changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 7f7fc710350c..66436e526021 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -524,8 +524,8 @@ static void wa_16021440873(struct intel_plane *plane,
>
> intel_de_write_fw(dev_priv, SEL_FETCH_CUR_CTL(pipe), ctl);
>
> - intel_de_write(dev_priv, PIPE_SRCSZ_ERLY_TPT(pipe),
> -PIPESRC_HEIGHT(et_y_position));
> + intel_de_write(dev_priv, CURPOS_ERLY_TPT(dev_priv, pipe),
> +CURSOR_POS_Y(et_y_position));
> }
>
> static void i9xx_cursor_update_sel_fetch_arm(struct intel_plane *plane,
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 3f36b94020ff..2a33e35ceeff 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2164,19 +2164,14 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> crtc_state->psr2_man_track_ctl = val;
> }
>
> -static u32
> -psr2_pipe_srcsz_early_tpt_calc(struct intel_crtc_state *crtc_state,
> -bool full_update, bool cursor_in_su_area)
> +static u32 psr2_pipe_srcsz_early_tpt_calc(struct intel_crtc_state
> *crtc_state,
> + bool full_update)
> {
> int width, height;
>
> if (!crtc_state->enable_psr2_su_region_et || full_update)
> return 0;
>
> - if (!cursor_in_su_area)
> - return PIPESRC_WIDTH(0) |
> - PIPESRC_HEIGHT(drm_rect_height(&crtc_state->pipe_src));
> -
> width = drm_rect_width(&crtc_state->psr2_su_area);
> height = drm_rect_height(&crtc_state->psr2_su_area);
>
> @@ -2485,8 +2480,7 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
> skip_sel_fetch_set_loop:
> psr2_man_trk_ctl_calc(crtc_state, full_update);
> crtc_state->pipe_srcsz_early_tpt =
> - psr2_pipe_srcsz_early_tpt_calc(crtc_state, full_update,
> -cursor_in_su_area);
> + psr2_pipe_srcsz_early_tpt_calc(crtc_state, full_update);
> return 0;
> }
--
Jani Nikula, Intel
Re: [PATCH 1/9] drm: Add helpers for x16 fixed point values
On Fri, 14 Jun 2024, Imre Deak wrote:
> Add helpers to convert between x16 fixed point and integer/fraction
> values. Also add the format/argument macros required to printk x16
> fixed point variables.
>
> These are needed by later patches dumping the Display Stream Compression
> configuration in DRM core and in the i915 driver to replace the
> corresponding bpp_x16 helpers defined locally in the driver.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 5 +++--
> include/drm/drm_fixed.h | 23 +++
> 2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 79a615667aab1..806f9c9764995 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -4151,9 +4152,9 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> int symbol_cycles;
>
> if (lane_count == 0 || hactive == 0 || bpp_x16 == 0) {
> - DRM_DEBUG_KMS("Invalid BW overhead params: lane_count %d,
> hactive %d, bpp_x16 %d.%04d\n",
> + DRM_DEBUG_KMS("Invalid BW overhead params: lane_count %d,
> hactive %d, bpp_x16 " DRM_X16_FMT "\n",
> lane_count, hactive,
> - bpp_x16 >> 4, (bpp_x16 & 0xf) * 625);
> + DRM_X16_ARGS(bpp_x16));
> return 0;
> }
>
> diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
> index 81572d32db0c2..0fe2a7f50d54e 100644
> --- a/include/drm/drm_fixed.h
> +++ b/include/drm/drm_fixed.h
> @@ -214,4 +214,27 @@ static inline s64 drm_fixp_exp(s64 x)
> return sum;
> }
>
> +static inline int drm_x16_from_int(int val_int)
> +{
> + return val_int << 4;
> +}
> +
> +static inline int drm_x16_to_int(int val_x16)
> +{
> + return val_x16 >> 4;
> +}
> +
> +static inline int drm_x16_to_int_roundup(int val_x16)
> +{
> + return (val_x16 + 0xf) >> 4;
> +}
> +
> +static inline int drm_x16_to_frac(int val_x16)
> +{
> + return val_x16 & 0xf;
> +}
Sad trombone about the completely different naming scheme compared to
the rest of the file.
Not saying the existing naming is great, but neither is this. And
there's no way to unify except by renaming *both* afterwards.
We could devise a scheme now that could be used for the existing stuff
later, without renaming the new stuff.
*shrug*
BR,
Jani.
> +
> +#define DRM_X16_FMT "%d.%04d"
> +#define DRM_X16_ARGS(val_x16)drm_x16_to_int(val_x16),
> (drm_x16_to_frac(val_x16) * 625)
> +
> #endif
--
Jani Nikula, Intel
[PATCH v2 0/1] drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off and only asserted in display on. But during observation it found clk remains active in display OFF. As workaround, Display driver shall execute set-reset sequence at the end of the Initialize Sequence. Wa_14020225554 Mitul Golani (1): drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock drivers/gpu/drm/i915/display/intel_display_power.c | 8 1 file changed, 8 insertions(+) -- 2.45.2
[PATCH v2 1/1] drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off
and only asserted in display on. But during observation it found
clk remains active in display OFF. As workaround, Display driver
shall execute set-reset sequence at the end of the Initialize
Sequence.
Wa_14020225554
--v2:
- Update workaround number in commit message.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display_power.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index e288a1b21d7e..0d8875fa5ef2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1704,6 +1704,14 @@ static void icl_display_core_init(struct
drm_i915_private *dev_priv,
/* Wa_14011503030:xelpd */
if (DISPLAY_VER(dev_priv) == 13)
intel_de_write(dev_priv, XELPD_DISPLAY_ERR_FATAL_MASK, ~0);
+
+ /* Wa_14020225554 */
+ if (DISPLAY_VER(dev_priv) == 20) {
+ intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D,
+ PCH_GMBUSUNIT_CLOCK_GATE_DISABLE);
+ intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
+PCH_GMBUSUNIT_CLOCK_GATE_DISABLE, 0);
+ }
}
static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
--
2.45.2
Re: [PATCH v2 3/8] drm/i915: Don't check for atomic context on PREEMPT_RT
On 18/06/2024 13:54, Sebastian Andrzej Siewior wrote: On 2024-06-18 10:00:09 [+0100], Tvrtko Ursulin wrote: I did a re-test but am not 100% certain yet. CI looks frustratingly noisy at the moment. igt@debugfs_test@read_all_entries appears to be a fluke which is not new. But igt@gem_exec_parallel@engines@basic from the latest run seem new. So I queued another re-test. Okay. If you want me to repost the whole series or just parts of it, just say so. Looks like a green set of results, both BAT and full run. Patches 1&2 will need someone from the display side to bless though. Regards, Tvrtko
Re: [PATCH v2 4/8] drm/i915: Disable tracing points on PREEMPT_RT
On 13/06/2024 11:20, Sebastian Andrzej Siewior wrote: Luca Abeni reported this: | BUG: scheduling while atomic: kworker/u8:2/15203/0x0003 | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 | Call Trace: | rt_spin_lock+0x3f/0x50 | gen6_read32+0x45/0x1d0 [i915] | g4x_get_vblank_counter+0x36/0x40 [i915] | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915] The tracing events use trace_intel_pipe_update_start() among other events use functions acquire spinlock_t locks which are transformed into sleeping locks on PREEMPT_RT. A few trace points use intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also might acquire a sleeping locks on PREEMPT_RT. At the time the arguments are evaluated within trace point, preemption is disabled and so the locks must not be acquired on PREEMPT_RT. Based on this I don't see any other way than disable trace points on PREMPT_RT. Reported-by: Luca Abeni Cc: Steven Rostedt Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/display/intel_display_trace.h | 4 drivers/gpu/drm/i915/i915_trace.h | 4 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h b/drivers/gpu/drm/i915/display/intel_display_trace.h index 49a5e6d9dc0d7..b15c999d91e68 100644 --- a/drivers/gpu/drm/i915/display/intel_display_trace.h +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h @@ -9,6 +9,10 @@ #if !defined(__INTEL_DISPLAY_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ) #define __INTEL_DISPLAY_TRACE_H__ +#if defined(CONFIG_PREEMPT_RT) && !defined(NOTRACE) +#define NOTRACE +#endif + #include #include #include diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index ce1cbee1b39dd..247e7d9448d70 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -6,6 +6,10 @@ #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ) #define _I915_TRACE_H_ +#if defined(CONFIG_PREEMPT_RT) && !defined(NOTRACE) +#define NOTRACE +#endif + #include #include #include If tracing experts said this is the way then it is fine by me. Acked-by: Tvrtko Ursulin Regards, Tvrtko
Re: [PATCH v2 6/8] drm/i915: Drop the irqs_disabled() check
On 13/06/2024 11:20, Sebastian Andrzej Siewior wrote: The !irqs_disabled() check triggers on PREEMPT_RT even with i915_sched_engine::lock acquired. The reason is the lock is transformed into a sleeping lock on PREEMPT_RT and does not disable interrupts. There is no need to check for disabled interrupts. The lockdep annotation below already check if the lock has been acquired by the caller and will yell if the interrupts are not disabled. Remove the !irqs_disabled() check. Reported-by: Maarten Lankhorst Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/i915_request.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 519e096c607cd..466b5ee8ed6d2 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -608,7 +608,6 @@ bool __i915_request_submit(struct i915_request *request) RQ_TRACE(request, "\n"); - GEM_BUG_ON(!irqs_disabled()); lockdep_assert_held(&engine->sched_engine->lock); /* @@ -717,7 +716,6 @@ void __i915_request_unsubmit(struct i915_request *request) */ RQ_TRACE(request, "\n"); - GEM_BUG_ON(!irqs_disabled()); lockdep_assert_held(&engine->sched_engine->lock); /* Maarten can you r-b since it seems this one originated from your testing? Otherwise: Acked-by: Tvrtko Ursulin Regards, Tvrtko
Re: [PATCH v2 8/8] Revert "drm/i915: Depend on !PREEMPT_RT."
On 13/06/2024 11:20, Sebastian Andrzej Siewior wrote: Once the known issues are addressed, it should be safe to enable the driver. Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 5932024f8f954..a02162d6b710e 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -3,7 +3,6 @@ config DRM_I915 tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics" depends on DRM depends on X86 && PCI - depends on !PREEMPT_RT select INTEL_GTT if X86 select INTERVAL_TREE # we need shmfs for the swappable backing store, and in particular Cool! Acked-by: Tvrtko Ursulin Regards, Tvrtko
[PATCH v3] drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off
and only asserted in display on. But during observation it found
clk remains active in display OFF. As workaround, Display driver
shall execute set-reset sequence at the end of the Initialize
Sequence.
Wa_15013987218
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display_power.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index e288a1b21d7e..aef54c1a2ba9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1704,6 +1704,14 @@ static void icl_display_core_init(struct
drm_i915_private *dev_priv,
/* Wa_14011503030:xelpd */
if (DISPLAY_VER(dev_priv) == 13)
intel_de_write(dev_priv, XELPD_DISPLAY_ERR_FATAL_MASK, ~0);
+
+ /* Wa_15013987218 */
+ if (DISPLAY_VER(dev_priv) == 20) {
+ intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D,
+ PCH_GMBUSUNIT_CLOCK_GATE_DISABLE);
+ intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
+PCH_GMBUSUNIT_CLOCK_GATE_DISABLE, 0);
+ }
}
static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
--
2.45.2
Re: Linux 6.10-rc1
Hi! > > > Let's bring in the actual gpu people.. Dave/Jani/others - does any of > > > this sound familiar? Pavel says things have gotten much slower in > > > 6.10: "something was very wrong with the performance, likely to do > > > with graphics" > > > > Actually, maybe it's not graphics at all. Rafael just sent me a pull > > request that fixes a "turbo is disabled at boot, but magically enabled > > at runtime by firmware" issue. > > > > The 6.10-rc1 kernel would notice that turbo was disabled, and stopped > > noticing that it magically got re-enabled. > > > > Pavel, that was with a very different laptop, but who knows... That > > would match the "laptop is much slower" thing. > > > > So current -git might be worth checking. > > So... I went to (then) current -git and I don't want to replace my > machine any more. So the problem should not exist in current mainline. > > (I did not have good objective data, so I'm not 100% sure problem was > real in the first place. More like 90% sure.) Ok, so machine is ready to be thrown out of window, again. Trying to play 29C3 video should not make machine completely unusable ... as in keyboard looses keystrokes in terminal. https://media.ccc.de/v/29c3-5333-en-gsm_cell_phone_network_review_h264#t=340 dmesg is kind-of unhappy: [130729.891961] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci [130733.311644] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci [130736.534601] i915 :00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=617818 end=617819) time 159 us, min 1017, max 1023, scanline start 1012, end 1024 [130738.625131] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci [130745.451785] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci ... [131631.941091] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci [131634.817628] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci [131639.536918] usb 2-1.2.3: reset low-speed USB device number 13 using ehci-pci [131790.153952] i915 :00:02.0: [drm] GPU HANG: ecode 6:1:95bc, in Xorg [3043] [131790.154245] i915 :00:02.0: [drm] GT0: Resetting chip for stopped heartbeat on rcs0 [131790.255994] i915 :00:02.0: [drm] Xorg[3043] context reset due to GPU hang Wifi is a bit too active, even on fairly idle system: 430 root -51 0 0 0 0 S 0.3 0.0 8:48.74 irq/17-iwlwifi Ideas welcome, especially some way to see what graphics is doing. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. signature.asc Description: PGP signature
[PULL] drm-intel-fixes
Hi Dave & Sima - Surprisingly few fixes lately, here's one for joiner+MSO. drm-intel-fixes-2024-06-19: drm/i915 fixes for v6.10-rc5: - Fix conditions for joiner usage, it's not possible with eDP MSO BR, Jani. The following changes since commit 6ba59ff4227927d3a8530fc2973b80e94b54d58f: Linux 6.10-rc4 (2024-06-16 13:40:16 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-fixes-2024-06-19 for you to fetch changes up to 49cc17967be95d64606d5684416ee51eec35e84a: drm/i915/mso: using joiner is not possible with eDP MSO (2024-06-17 12:01:01 +0300) drm/i915 fixes for v6.10-rc5: - Fix conditions for joiner usage, it's not possible with eDP MSO Jani Nikula (1): drm/i915/mso: using joiner is not possible with eDP MSO drivers/gpu/drm/i915/display/intel_dp.c | 4 1 file changed, 4 insertions(+) -- Jani Nikula, Intel
Re: [PATCH] drm/i915/gt: Fix potential UAF by revoke of fence registers
Hi Janusz,
On Mon, Jun 03, 2024 at 09:54:45PM +0200, Janusz Krzysztofik wrote:
> CI has been sporadically reporting the following issue triggered by
> igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
>
> <6> [414.049203] i915: Running
> intel_hangcheck_live_selftests/igt_reset_evict_fence
> ...
> <6> [414.068804] i915 :00:02.0: [drm] GT0: GUC: submission enabled
> <6> [414.068812] i915 :00:02.0: [drm] GT0: GUC: SLPC enabled
> <3> [414.070354] Unable to pin Y-tiled fence; err:-4
> <3> [414.071282] i915_vma_revoke_fence:301
> GEM_BUG_ON(!i915_active_is_idle(&fence->active))
> ...
> <4>[ 609.603992] [ cut here ]
> <2>[ 609.603995] kernel BUG at
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
> <4>[ 609.604003] invalid opcode: [#1] PREEMPT SMP NOPTI
> <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W
> 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
> <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client
> Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723
> 01/20/2023
> <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
> <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
> ...
> <4>[ 609.604271] Call Trace:
> <4>[ 609.604273]
> ...
> <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]
> <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]
> <4>[ 609.604977] force_unbind+0x24/0xa0 [i915]
> <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]
> <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
> <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
> <4>[ 609.605440] process_scheduled_works+0x351/0x690
> ...
>
> In the past, there were similar failures reported by CI from other IGT
> tests, observed on other platforms.
>
> Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
> before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
> idleness of vma->active via fence_update(). That commit introduced
> vma->fence->active in order for the fence_update() to be able to wait
> selectively on that one instead of vma->active since only idleness of
> fence registers was needed. But then, another commit 0d86ee35097a
> ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
> fence_update() in i915_vma_revoke_fence() with only fence_write(), and
> also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
> No justification was provided on why we might then expect idleness of
> vma->fence->active without first waiting on it.
>
> The issue can be potentially caused by a race among revocation of fence
> registers on one side and sequential execution of signal callbacks invoked
> on completion of a request that was using them on the other, still
> processed in parallel to revocation of those fence registers. Fix it by
> waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
>
> Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021
> Signed-off-by: Janusz Krzysztofik
> Cc: sta...@vger.kernel.org # v5.8+
merged in drm-intel-gt-next.
Thanks,
Andi
Re: [PATCH v2 0/2] Sparse errors on the i915_gem_stolen
Hi,
On Tue, Jun 18, 2024 at 07:34:22PM +, Cavitt, Jonathan wrote:
> > Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
> > warning") produces two sparse warnings. The first one being a bit
> > more sever as it might cause a segmentation fault.
> >
> > The difference between v1 and v2 is that the patch should return
> > a NULL, which won't cause any issues.
> >
> > Andi
>
> Sure. Apply to all:
> Reviewed-by: Jonathan Cavitt
Thanks, if no other comments, I'm going to merge this soon,
Thanks,
Andi
✓ Fi.CI.BAT: success for drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
== Series Details ==
Series: drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
URL : https://patchwork.freedesktop.org/series/135056/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14969 -> Patchwork_135056v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/index.html
Participating hosts (40 -> 38)
--
Additional (1): fi-kbl-8809g
Missing(3): fi-glk-j4005 fi-snb-2520m fi-bsw-n3050
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_135056v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live:
- {bat-mtlp-9}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/bat-mtlp-9/igt@i915_selft...@live.html
Known issues
Here are the changes found in Patchwork_135056v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-8809g: NOTRUN -> [SKIP][3] ([i915#4613]) +3 other tests skip
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/fi-kbl-8809g/igt@gem_lmem_swapp...@basic.html
* igt@i915_module_load@load:
- bat-dg2-8: [PASS][4] -> [DMESG-WARN][5] ([i915#10014])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14969/bat-dg2-8/igt@i915_module_l...@load.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/bat-dg2-8/igt@i915_module_l...@load.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-8809g: NOTRUN -> [SKIP][6] +30 other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/fi-kbl-8809g/igt@kms_force_connector_ba...@force-load-detect.html
Possible fixes
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- {bat-mtlp-9}: [DMESG-WARN][7] ([i915#11009]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14969/bat-mtlp-9/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/bat-mtlp-9/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_frontbuffer_tracking@basic:
- bat-arls-2: [DMESG-WARN][9] ([i915#7507]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14969/bat-arls-2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/bat-arls-2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-6:
- {bat-mtlp-9}: [DMESG-FAIL][11] ([i915#11009]) -> [PASS][12] +2
other tests pass
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14969/bat-mtlp-9/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-6.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/bat-mtlp-9/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-6.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-b-dp-7:
- {bat-mtlp-9}: [FAIL][13] ([i915#10979]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14969/bat-mtlp-9/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-b-dp-7.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v1/bat-mtlp-9/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-b-dp-7.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10014]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10014
[i915#10580]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10580
[i915#10979]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10979
[i915#11009]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11009
[i915#11375]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11375
[i915#2190]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/2190
[i915#3637]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/3637
[i915#4613]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/4613
[i915#6121]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/6121
[i915#7507]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/7507
Build changes
-
* Linux: CI_DRM_14969 -> Patchwork_135056v1
CI-20190529: 20190529
CI_DRM_14969: 5ce321df94a7bbaad2cb8c98f9cb8115dfb566c7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7892: 7
RE: [RFC 0/5] Introduce drm sharpening property
> -Original Message- > From: Pekka Paalanen > Sent: Thursday, March 28, 2024 3:35 PM > To: Garg, Nemesa > Cc: Simon Ser ; intel-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; G M, Adarsh > Subject: Re: [RFC 0/5] Introduce drm sharpening property > > On Wed, 27 Mar 2024 13:29:16 +0200 > Pekka Paalanen wrote: > > > On Wed, 27 Mar 2024 07:11:48 + > > "Garg, Nemesa" wrote: > > > > > > -Original Message- > > > > From: Pekka Paalanen > > > > Sent: Wednesday, March 13, 2024 3:07 PM > > > > To: Garg, Nemesa > > > > Cc: Simon Ser ; > > > > intel-gfx@lists.freedesktop.org; dri- de...@lists.freedesktop.org; > > > > G M, Adarsh > > > > Subject: Re: [RFC 0/5] Introduce drm sharpening property > > > > > > > > On Tue, 12 Mar 2024 16:26:00 +0200 Pekka Paalanen > > > > wrote: > > > > > > > > > On Tue, 12 Mar 2024 08:30:34 + "Garg, Nemesa" > > > > > wrote: > > > > > > > > > > > This KMS property is not implementing any formula > > > > > > > > > > Sure it is. Maybe Intel just does not want to tell what the > > > > > algorithm is, or maybe it's even patented. > > > > > > > > > > > and the values > > > > > > that are being used are based on empirical analysis and > > > > > > certain experiments done on the hardware. These values are > > > > > > fixed and is not expected to change and this can change from > > > > > > vendor to vendor. The client can choose any sharpness value on > > > > > > the scale and on the basis of it the sharpness will be set. > > > > > > The sharpness effect can be changed from content to content > > > > > > and from display to display so user needs to adjust the > > > > > > optimum intensity value so as to get good experience on the screen. > > > > > > > > > > > > > > > > IOW, it's an opaque box operation, and there is no way to > > > > > reproduce its results without the specific Intel hardware. > > > > > Definitely no way to reproduce its results in free open source > > > > > software > alone. > > > > > > > > > > Such opaque box operations can only occur after KMS blending, at > > > > > the CRTC or later stage. They cannot appear before blending, not > > > > > in the new KMS color pipeline design at least. The reason is > > > > > that the modern way to use KMS planes is opportunistic composition > > > > > off- > loading. > > > > > Opportunistic means that userspace decides from time to time > > > > > whether it composes the final picture using KMS or some other > > > > > rendering method (usually GPU and shaders). Since userspace will > > > > > arbitrarily switch between KMS and render composition, both must > > > > > result in the exact same image, or end users will observe unwanted > > > > > flicker. > > > > > > > > > > Such opaque box operations are fine after blending, because there they > > > > > can be configured once and remain on forever. No switching, no > > > > > flicker. > > > > > > > > If you want to see how sharpness property would apply in Wayland > > > > design, it would be in step 5 "Adjust (settings UI)" of > > > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/co > > > > lor- management-model.md#compositor-color-management-model > > > > > > > > To relate that diagram to KMS color processing, you can identify step 3 > "Compose" > > > > as the KMS blending step. Everything before step 3 happens in KMS > > > > plane color processing, and steps 4-5 happen in KMS CRTC color > > > > processing. > > > > > > > > Sharpening would essentially be a "compositor color effect", it > > > > just happens to be implementable only by specific Intel hardware. > > > > > > > > If a color effect is dynamic or content-dependant, it will > > > > preclude colorimetric monitor calibration. > > > > > > > > > > > > Thanks, > > > > pq > > > > > > > > > > > > > Where does "sharpeness" operation occur in the Intel color > > > > > processing chain? Is it before or after blending? > > > > > > > > Thank you for detail explanation and link. > > > Sharpness operation occur post blending in CRTC ie on the final > > > composed output after blending . Yes Pekka you are right as per the > > > diagram it is done at step 5 "Adjust (settings UI)"). I will also > > > document this thing along with documentation change. > > > > > > > > What kind of transfer characteristics does it expect from the > > > > > image, and can those be realized with KMS CRTC properties if KMS is > > > > > configured such that the blending happens using some other > characteristics > > > > (e.g. > > > > > blending in optical space)? > > > > > > > > The filter values are not dependent/calculated on the inputs of > > > image but depending on the blending space and other inputs the > > > blended output gets changed and the sharpness is applied post > > > blending so according to the content user needs to adjust the > > > strength value to get the better visual effect. So tuning of > > > sharpness strength may be needed by user based on the input > > > contents and blending p
Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote: > On Tue, 11 Jun 2024, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > As we extend the use of DSB for critical pipe/plane register > > programming, it'll be nice to have an escape valve at hand, > > in case things go very poorly. To that end, add a i915.enable_dsb > > modparam by which we can force the driver to take the pure mmio > > path instead. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++ > > drivers/gpu/drm/i915/display/intel_display_params.h | 1 + > > drivers/gpu/drm/i915/display/intel_dsb.c| 3 +++ > > 3 files changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c > > b/drivers/gpu/drm/i915/display/intel_display_params.c > > index aebdb7b59dbf..449a31767791 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display_params.c > > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c > > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, 0400, > > intel_display_param_named_unsafe(enable_dpt, bool, 0400, > > "Enable display page table (DPT) (default: true)"); > > > > +intel_display_param_named_unsafe(enable_dsb, bool, 0600, > > + "Enable display state buffer (DSB) (default: true)"); > > Not much point in leaving the module param 0600, is there? It'll let you try both dsb and mmio paths at runtime without having to do a full reboot/reload. > > BR, > Jani. > > > + > > intel_display_param_named_unsafe(enable_sagv, bool, 0400, > > "Enable system agent voltage/frequency scaling (SAGV) (default: true)"); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h > > b/drivers/gpu/drm/i915/display/intel_display_params.h > > index 1208a62c16d2..48c29c55c939 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display_params.h > > +++ b/drivers/gpu/drm/i915/display/intel_display_params.h > > @@ -31,6 +31,7 @@ struct drm_i915_private; > > param(int, vbt_sdvo_panel_type, -1, 0400) \ > > param(int, enable_dc, -1, 0400) \ > > param(bool, enable_dpt, true, 0400) \ > > + param(bool, enable_dsb, true, 0600) \ > > param(bool, enable_sagv, true, 0600) \ > > param(int, disable_power_well, -1, 0400) \ > > param(bool, enable_ips, true, 0600) \ > > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c > > b/drivers/gpu/drm/i915/display/intel_dsb.c > > index bee48ac419ce..2ab3765f6c06 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dsb.c > > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c > > @@ -460,6 +460,9 @@ struct intel_dsb *intel_dsb_prepare(struct > > intel_atomic_state *state, > > if (!HAS_DSB(i915)) > > return NULL; > > > > + if (!i915->display.params.enable_dsb) > > + return NULL; > > + > > /* TODO: DSB is broken in Xe KMD, so disabling it until fixed */ > > if (!IS_ENABLED(I915)) > > return NULL; > > -- > Jani Nikula, Intel -- Ville Syrjälä Intel
[PATCH v3 2/9] drm: Export drm_plane_has_format()
From: Ville Syrjälä
Export drm_plane_has_format() so that drivers can use it.
v2: add kerneldoc
Reviewed-by: Jani Nikula
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_internal.h | 2 --
drivers/gpu/drm/drm_plane.c | 10 ++
include/drm/drm_plane.h | 2 ++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index cdd60f2a4052..1f73b8d6d750 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -272,8 +272,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* drm_plane.c */
int drm_plane_register_all(struct drm_device *dev);
void drm_plane_unregister_all(struct drm_device *dev);
-bool drm_plane_has_format(struct drm_plane *plane,
- u32 format, u64 modifier);
struct drm_mode_rect *
__drm_plane_get_damage_clips(const struct drm_plane_state *state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 268aa2299df5..a28b22fdd7a4 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -877,6 +877,15 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
return 0;
}
+/**
+ * drm_plane_has_format - Check whether the plane supports this format and
modifier combination
+ * @plane: drm plane
+ * @format: pixel format (DRM_FORMAT_*)
+ * @modifier: data layout modifier
+ *
+ * Returns:
+ * Whether the plane supports the specified format and modifier combination.
+ */
bool drm_plane_has_format(struct drm_plane *plane,
u32 format, u64 modifier)
{
@@ -906,6 +915,7 @@ bool drm_plane_has_format(struct drm_plane *plane,
return true;
}
+EXPORT_SYMBOL(drm_plane_has_format);
static int __setplane_check(struct drm_plane *plane,
struct drm_crtc *crtc,
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9507542121fa..dd718c62ac31 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -972,6 +972,8 @@ static inline struct drm_plane *drm_plane_find(struct
drm_device *dev,
#define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
+bool drm_plane_has_format(struct drm_plane *plane,
+ u32 format, u64 modifier);
bool drm_any_plane_has_format(struct drm_device *dev,
u32 format, u64 modifier);
--
2.44.2
Re: [PATCH v3 2/9] drm: Export drm_plane_has_format()
On Wed, 19 Jun 2024 at 12:31, Ville Syrjala wrote: > Export drm_plane_has_format() so that drivers can use it. Acked-by: Daniel Stone
Re: [PATCH v2 0/9] drm/i915: Polish plane surface alignment handling
On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > intel_surf_alignment() in particular has devolved into > a complete mess. Redesign the code so that we can handle > alignment restrictions in a nicer. Also adjust alignment > for TGL+ to actually match the hardware requirements. > > v2: Drop the per-plane vma stuff as it was borked > Don't temporarily remove the 2MiB DPT alignment for UV on TGL > > Ville Syrjälä (9): > drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format() > drm: Export drm_plane_has_format() Maarten/Maxime/Thomas, can I get an ack for merging these via drm-intel please? > drm/i915: Introduce the plane->min_alignment() vfunc > drm/i915: Introduce fb->min_alignment > drm/i915: Split cursor alignment to per-platform vfuncs > drm/i915: Split pre-skl platforms out from intel_surf_alignment() > drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c > drm/i915: Update plane alignment requirements for TGL+ > drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff > > drivers/gpu/drm/drm_atomic.c | 7 +- > drivers/gpu/drm/drm_crtc.c| 6 +- > drivers/gpu/drm/drm_crtc_internal.h | 2 - > drivers/gpu/drm/drm_plane.c | 23 ++- > drivers/gpu/drm/i915/display/i9xx_plane.c | 75 - > drivers/gpu/drm/i915/display/intel_cursor.c | 38 + > .../drm/i915/display/intel_display_types.h| 5 + > drivers/gpu/drm/i915/display/intel_fb.c | 151 -- > drivers/gpu/drm/i915/display/intel_fb.h | 3 - > drivers/gpu/drm/i915/display/intel_fb_pin.c | 39 +++-- > drivers/gpu/drm/i915/display/intel_fb_pin.h | 3 +- > drivers/gpu/drm/i915/display/intel_fbdev.c| 5 +- > drivers/gpu/drm/i915/display/intel_sprite.c | 26 +++ > .../drm/i915/display/skl_universal_plane.c| 85 +- > drivers/gpu/drm/xe/display/xe_fb_pin.c| 3 +- > drivers/gpu/drm/xe/display/xe_plane_initial.c | 4 +- Lucas, can you give me an ack for the merging the xe changes via drm-intel? > include/drm/drm_plane.h | 2 + > 17 files changed, 309 insertions(+), 168 deletions(-) > > -- > 2.44.2 -- Ville Syrjälä Intel
Re: [PATCH v6 0/8] drm: Support per-plane async flip configuration
On Fri, Jun 14, 2024 at 04:37:41PM -0300, André Almeida wrote: > Hi Dmitry, > > Em 14/06/2024 14:32, Dmitry Baryshkov escreveu: > > On Fri, Jun 14, 2024 at 12:35:27PM GMT, André Almeida wrote: > >> AMD hardware can do async flips with overlay planes, but currently there's > >> no > >> easy way to enable that in DRM. To solve that, this patchset creates a new > >> drm_plane field, bool async_flip, that allows drivers to choose which > >> plane can > >> or cannot do async flips. This is latter used on drm_atomic_set_property > >> when > >> users want to do async flips. > >> > >> Patch 1 allows async commits with IN_FENCE_ID in any driver. > >> > >> Patches 2 to 7 have no function change. As per current code, every driver > >> that > >> allows async page flips using the atomic API, allows doing it only in the > >> primary plane. Those patches then enable it for every driver. > >> > >> Patch 8 finally enables async flip on overlay planes for amdgpu. > >> > >> Changes from v5: > >> - Instead of enabling plane->async_flip in the common code, move it to > >> driver > >> code. > >> - Enable primary plane async flip on every driver > >> https://lore.kernel.org/dri-devel/20240612193713.167448-1-andrealm...@igalia.com/ > >> > >> André Almeida (8): > >>drm/atomic: Allow userspace to use explicit sync with atomic async > >> flips > >>drm: Support per-plane async flip configuration > >>drm/amdgpu: Enable async flips on the primary plane > >>drm: atmel-hlcdc: Enable async flips on the primary plane > >>drm/i915: Enable async flips on the primary plane > >>drm/nouveau: Enable async flips on the primary plane > >>drm/vc4: Enable async flips on the primary plane > >>drm/amdgpu: Make it possible to async flip overlay planes > >> > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 ++ > >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +++ > >> drivers/gpu/drm/drm_atomic_uapi.c | 8 +--- > >> drivers/gpu/drm/i915/display/i9xx_plane.c | 3 +++ > >> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 > >> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 > >> drivers/gpu/drm/vc4/vc4_plane.c | 4 +++- > > > > The main question is why only these drivers were updated. > > > > According to `git grep async_page_flip`, only those drivers supports > async page flip. The only corner case is radeon, that does supports > async but doesn't support planes. The primary plane will alwyas exist (drm_crtc_init() will create one for the old drivers that don't do it explicitly). So you should be able to convert radeon as well. And looks like some pre-dc amdgpu stuff is in a similar situation. That should presumably allow the old flag to be removed entirely? Hmm, I suppose drm_getcap() would need a bit of work to eg. go through all the planes to see if any of them support async flips. > > Do you know any other driver that should be updated to? > > >> include/drm/drm_plane.h | 5 + > >> 8 files changed, 29 insertions(+), 4 deletions(-) > >> > >> -- > >> 2.45.2 > >> > > -- Ville Syrjälä Intel
Re: [PATCH 1/9] drm: Add helpers for x16 fixed point values
On Wed, Jun 19, 2024 at 01:10:09PM +0300, Jani Nikula wrote:
> On Fri, 14 Jun 2024, Imre Deak wrote:
> > Add helpers to convert between x16 fixed point and integer/fraction
> > values. Also add the format/argument macros required to printk x16
> > fixed point variables.
> >
> > These are needed by later patches dumping the Display Stream Compression
> > configuration in DRM core and in the i915 driver to replace the
> > corresponding bpp_x16 helpers defined locally in the driver.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/display/drm_dp_helper.c | 5 +++--
> > include/drm/drm_fixed.h | 23 +++
> > 2 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > b/drivers/gpu/drm/display/drm_dp_helper.c
> > index 79a615667aab1..806f9c9764995 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -35,6 +35,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -4151,9 +4152,9 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> > int symbol_cycles;
> >
> > if (lane_count == 0 || hactive == 0 || bpp_x16 == 0) {
> > - DRM_DEBUG_KMS("Invalid BW overhead params: lane_count %d,
> > hactive %d, bpp_x16 %d.%04d\n",
> > + DRM_DEBUG_KMS("Invalid BW overhead params: lane_count %d,
> > hactive %d, bpp_x16 " DRM_X16_FMT "\n",
> > lane_count, hactive,
> > - bpp_x16 >> 4, (bpp_x16 & 0xf) * 625);
> > + DRM_X16_ARGS(bpp_x16));
> > return 0;
> > }
> >
> > diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
> > index 81572d32db0c2..0fe2a7f50d54e 100644
> > --- a/include/drm/drm_fixed.h
> > +++ b/include/drm/drm_fixed.h
> > @@ -214,4 +214,27 @@ static inline s64 drm_fixp_exp(s64 x)
> > return sum;
> > }
> >
> > +static inline int drm_x16_from_int(int val_int)
> > +{
> > + return val_int << 4;
> > +}
> > +
> > +static inline int drm_x16_to_int(int val_x16)
> > +{
> > + return val_x16 >> 4;
> > +}
> > +
> > +static inline int drm_x16_to_int_roundup(int val_x16)
> > +{
> > + return (val_x16 + 0xf) >> 4;
> > +}
> > +
> > +static inline int drm_x16_to_frac(int val_x16)
> > +{
> > + return val_x16 & 0xf;
> > +}
>
> Sad trombone about the completely different naming scheme compared to
> the rest of the file.
>
> Not saying the existing naming is great, but neither is this. And
> there's no way to unify except by renaming *both* afterwards.
>
> We could devise a scheme now that could be used for the existing stuff
> later, without renaming the new stuff.
Based on [1]'s short variant, we could have:
dfixed*(fixed20_12 v) -> drm_uq12*(drm_uq20_12_t v)
drm_fixp*(s64 v) -> drm_q32*(s64 v)
drm_x16*(int v)-> drm_q4*(int v)
Or instead of uq12/q32/q4 using ufp12/fp32/fp4.
[1] https://en.wikipedia.org/wiki/Q_(number_format)
> *shrug*
>
> BR,
> Jani.
>
>
>
> > +
> > +#define DRM_X16_FMT"%d.%04d"
> > +#define DRM_X16_ARGS(val_x16) drm_x16_to_int(val_x16),
> > (drm_x16_to_frac(val_x16) * 625)
> > +
> > #endif
>
> --
> Jani Nikula, Intel
Re: [PATCH 2/9] drm/i915/display: Wa 16021440873 is writing wrong register
On Wed, 2024-06-19 at 12:51 +0300, Jani Nikula wrote:
> On Tue, 18 Jun 2024, Jouni Högander wrote:
> > Wa 16021440873 is writing wrong register. Instead of
> > PIPE_SRCSZ_ERLY_TPT
> > write CURPOS_ERLY_TPT.
>
> I know this is merged already... but the commit message fails to
> explain
> the changes to psr2_pipe_srcsz_early_tpt_calc().
I was originally thinking I need to take wa_16021440873 into account
in psr2_pipe_srcsz_early_tpt as well because this is calculating value
for PIPE_SRCSZ_ERLY_TPT. As PIPE_SRCSZ_ERLY_TPT was wrong offset -> no
need to care about the wa in psr2_pipe_srcsz_early_tpt_calc
BR,
Jouni Högander
>
> BR,
> Jani.
>
>
> >
> > v2: use right offset as well
> >
> > Fixes: 29cdef8539c3 ("drm/i915/display: Implement Wa_16021440873")
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_cursor.c | 4 ++--
> > drivers/gpu/drm/i915/display/intel_psr.c | 12 +++-
> > 2 files changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index 7f7fc710350c..66436e526021 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -524,8 +524,8 @@ static void wa_16021440873(struct intel_plane
> > *plane,
> >
> > intel_de_write_fw(dev_priv, SEL_FETCH_CUR_CTL(pipe), ctl);
> >
> > - intel_de_write(dev_priv, PIPE_SRCSZ_ERLY_TPT(pipe),
> > - PIPESRC_HEIGHT(et_y_position));
> > + intel_de_write(dev_priv, CURPOS_ERLY_TPT(dev_priv, pipe),
> > + CURSOR_POS_Y(et_y_position));
> > }
> >
> > static void i9xx_cursor_update_sel_fetch_arm(struct intel_plane
> > *plane,
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 3f36b94020ff..2a33e35ceeff 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -2164,19 +2164,14 @@ static void psr2_man_trk_ctl_calc(struct
> > intel_crtc_state *crtc_state,
> > crtc_state->psr2_man_track_ctl = val;
> > }
> >
> > -static u32
> > -psr2_pipe_srcsz_early_tpt_calc(struct intel_crtc_state
> > *crtc_state,
> > - bool full_update, bool
> > cursor_in_su_area)
> > +static u32 psr2_pipe_srcsz_early_tpt_calc(struct intel_crtc_state
> > *crtc_state,
> > + bool full_update)
> > {
> > int width, height;
> >
> > if (!crtc_state->enable_psr2_su_region_et || full_update)
> > return 0;
> >
> > - if (!cursor_in_su_area)
> > - return PIPESRC_WIDTH(0) |
> > - PIPESRC_HEIGHT(drm_rect_height(&crtc_state-
> > >pipe_src));
> > -
> > width = drm_rect_width(&crtc_state->psr2_su_area);
> > height = drm_rect_height(&crtc_state->psr2_su_area);
> >
> > @@ -2485,8 +2480,7 @@ int intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> > skip_sel_fetch_set_loop:
> > psr2_man_trk_ctl_calc(crtc_state, full_update);
> > crtc_state->pipe_srcsz_early_tpt =
> > - psr2_pipe_srcsz_early_tpt_calc(crtc_state,
> > full_update,
> > - cursor_in_su_area);
> > + psr2_pipe_srcsz_early_tpt_calc(crtc_state,
> > full_update);
> > return 0;
> > }
>
Re: [PATCH v7] drm/i915/panelreplay: Panel replay workaround with VRR
On Tue, Jun 18, 2024 at 04:52:15PM +0530, Animesh Manna wrote:
> Panel Replay VSC SDP not getting sent when VRR is enabled
> and W1 and W2 are 0. So Program Set Context Latency in
> TRANS_SET_CONTEXT_LATENCY register to at least a value of 1.
>
> HSD: 14015406119
>
> v1: Initial version.
> v2: Update timings stored in adjusted_mode struct. [Ville]
> v3: Add WA in compute_config(). [Ville]
> v4:
> - Add DISPLAY_VER() check and improve code comment. [Rodrigo]
> - Introduce centralized intel_crtc_vblank_delay(). [Ville]
> v5: Move to crtc_compute_config(). [Ville]
> v6: Restrict DISPLAY_VER till 14. [Mitul]
> v7:
> - Corrected code-comment. [Mitul]
> - dev_priv local variable removed. [Jani]
>
> Reviewed-by: Mitul Golani
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 21
> drivers/gpu/drm/i915/display/intel_display.h | 1 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7bc4f3de691e..c3ff3a5c5fa3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2515,6 +2515,10 @@ static int intel_crtc_compute_config(struct
> intel_atomic_state *state,
> intel_atomic_get_new_crtc_state(state, crtc);
> int ret;
>
> + /* wa_14015401596: display versions 13, 14 */
> + if (IS_DISPLAY_VER(to_i915(crtc->base.dev), 13, 14))
> + intel_crtc_vblank_delay(crtc_state);
> +
> ret = intel_dpll_crtc_compute_clock(state, crtc);
> if (ret)
> return ret;
> @@ -3924,6 +3928,23 @@ bool intel_crtc_get_pipe_config(struct
> intel_crtc_state *crtc_state)
> return true;
> }
>
> +void intel_crtc_vblank_delay(struct intel_crtc_state *crtc_state)
> +{
> + struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> +
> + /*
> + * wa_14015401596 for display versions 13, 14.
> + * Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY register
> + * to at least a value of 1 when Panel Replay is enabled with VRR.
> + * Value for TRANS_SET_CONTEXT_LATENCY is calculated by substracting
> + * crtc_vdisplay from crtc_vblank_start, so incrementing
> crtc_vblank_start
> + * by 1 if both are equal.
> + */
> + if (crtc_state->vrr.enable && crtc_state->has_panel_replay &&
> + adjusted_mode->crtc_vblank_start == adjusted_mode->crtc_vdisplay)
> + adjusted_mode->crtc_vblank_start += 1;
> +}
This is probably too late actually. We already used the previous value
to calculate the VRR guardband/pipeline full values, which may or may
not now be incorrect. So NAK for now until someone actually checks how
it all works (I don't recall the details right now).
> +
> int intel_dotclock_calculate(int link_freq,
>const struct intel_link_m_n *m_n)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index b0cf6ca70952..f99a24e76608 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -428,6 +428,7 @@ bool intel_crtc_is_joiner_primary(const struct
> intel_crtc_state *crtc_state);
> u8 intel_crtc_joiner_secondary_pipes(const struct intel_crtc_state
> *crtc_state);
> struct intel_crtc *intel_primary_crtc(const struct intel_crtc_state
> *crtc_state);
> bool intel_crtc_get_pipe_config(struct intel_crtc_state *crtc_state);
> +void intel_crtc_vblank_delay(struct intel_crtc_state *crtc_state);
> bool intel_pipe_config_compare(const struct intel_crtc_state *current_config,
> const struct intel_crtc_state *pipe_config,
> bool fastset);
> --
> 2.29.0
--
Ville Syrjälä
Intel
Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
On Wed, 19 Jun 2024, Ville Syrjälä wrote: > On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote: >> On Tue, 11 Jun 2024, Ville Syrjala wrote: >> > From: Ville Syrjälä >> > >> > As we extend the use of DSB for critical pipe/plane register >> > programming, it'll be nice to have an escape valve at hand, >> > in case things go very poorly. To that end, add a i915.enable_dsb >> > modparam by which we can force the driver to take the pure mmio >> > path instead. >> > >> > Signed-off-by: Ville Syrjälä >> > --- >> > drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++ >> > drivers/gpu/drm/i915/display/intel_display_params.h | 1 + >> > drivers/gpu/drm/i915/display/intel_dsb.c| 3 +++ >> > 3 files changed, 7 insertions(+) >> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c >> > b/drivers/gpu/drm/i915/display/intel_display_params.c >> > index aebdb7b59dbf..449a31767791 100644 >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.c >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c >> > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, 0400, >> > intel_display_param_named_unsafe(enable_dpt, bool, 0400, >> >"Enable display page table (DPT) (default: true)"); >> > >> > +intel_display_param_named_unsafe(enable_dsb, bool, 0600, >> > + "Enable display state buffer (DSB) (default: true)"); >> >> Not much point in leaving the module param 0600, is there? > > It'll let you try both dsb and mmio paths at runtime without > having to do a full reboot/reload. I mean does any code actually look at the *module* parameter runtime? It's only the initial value for the device param? BR, Jani. > >> >> BR, >> Jani. >> >> > + >> > intel_display_param_named_unsafe(enable_sagv, bool, 0400, >> >"Enable system agent voltage/frequency scaling (SAGV) (default: true)"); >> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h >> > b/drivers/gpu/drm/i915/display/intel_display_params.h >> > index 1208a62c16d2..48c29c55c939 100644 >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.h >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.h >> > @@ -31,6 +31,7 @@ struct drm_i915_private; >> >param(int, vbt_sdvo_panel_type, -1, 0400) \ >> >param(int, enable_dc, -1, 0400) \ >> >param(bool, enable_dpt, true, 0400) \ >> > + param(bool, enable_dsb, true, 0600) \ >> >param(bool, enable_sagv, true, 0600) \ >> >param(int, disable_power_well, -1, 0400) \ >> >param(bool, enable_ips, true, 0600) \ >> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c >> > b/drivers/gpu/drm/i915/display/intel_dsb.c >> > index bee48ac419ce..2ab3765f6c06 100644 >> > --- a/drivers/gpu/drm/i915/display/intel_dsb.c >> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c >> > @@ -460,6 +460,9 @@ struct intel_dsb *intel_dsb_prepare(struct >> > intel_atomic_state *state, >> >if (!HAS_DSB(i915)) >> >return NULL; >> > >> > + if (!i915->display.params.enable_dsb) >> > + return NULL; >> > + >> >/* TODO: DSB is broken in Xe KMD, so disabling it until fixed */ >> >if (!IS_ENABLED(I915)) >> >return NULL; >> >> -- >> Jani Nikula, Intel -- Jani Nikula, Intel
Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
On Wed, Jun 19, 2024 at 04:11:08PM +0300, Jani Nikula wrote: > On Wed, 19 Jun 2024, Ville Syrjälä wrote: > > On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote: > >> On Tue, 11 Jun 2024, Ville Syrjala wrote: > >> > From: Ville Syrjälä > >> > > >> > As we extend the use of DSB for critical pipe/plane register > >> > programming, it'll be nice to have an escape valve at hand, > >> > in case things go very poorly. To that end, add a i915.enable_dsb > >> > modparam by which we can force the driver to take the pure mmio > >> > path instead. > >> > > >> > Signed-off-by: Ville Syrjälä > >> > --- > >> > drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++ > >> > drivers/gpu/drm/i915/display/intel_display_params.h | 1 + > >> > drivers/gpu/drm/i915/display/intel_dsb.c| 3 +++ > >> > 3 files changed, 7 insertions(+) > >> > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c > >> > b/drivers/gpu/drm/i915/display/intel_display_params.c > >> > index aebdb7b59dbf..449a31767791 100644 > >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.c > >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c > >> > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, 0400, > >> > intel_display_param_named_unsafe(enable_dpt, bool, 0400, > >> > "Enable display page table (DPT) (default: true)"); > >> > > >> > +intel_display_param_named_unsafe(enable_dsb, bool, 0600, > >> > +"Enable display state buffer (DSB) (default: true)"); > >> > >> Not much point in leaving the module param 0600, is there? > > > > It'll let you try both dsb and mmio paths at runtime without > > having to do a full reboot/reload. > > I mean does any code actually look at the *module* parameter runtime? > It's only the initial value for the device param? You can change it via the debugfs i915_params/* thing. -- Ville Syrjälä Intel
[PATCH 2/2] drm/i915: disable fbc due to Wa_16023588340
On BMG-G21 we need to disable fbc due to complications around the WA.
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/display/intel_display_wa.h | 8
drivers/gpu/drm/i915/display/intel_fbc.c| 6 ++
drivers/gpu/drm/xe/Makefile | 4 +++-
drivers/gpu/drm/xe/display/xe_display_wa.c | 16
4 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/xe/display/xe_display_wa.c
diff --git a/drivers/gpu/drm/i915/display/intel_display_wa.h
b/drivers/gpu/drm/i915/display/intel_display_wa.h
index 63201d09852c..be644ab6ae00 100644
--- a/drivers/gpu/drm/i915/display/intel_display_wa.h
+++ b/drivers/gpu/drm/i915/display/intel_display_wa.h
@@ -6,8 +6,16 @@
#ifndef __INTEL_DISPLAY_WA_H__
#define __INTEL_DISPLAY_WA_H__
+#include
+
struct drm_i915_private;
void intel_display_wa_apply(struct drm_i915_private *i915);
+#ifdef I915
+static inline bool intel_display_needs_wa_16023588340(struct drm_i915_private
*i915) { return false; }
+#else
+bool intel_display_needs_wa_16023588340(struct drm_i915_private *i915);
+#endif
+
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 67116c9f1464..8488f82143a4 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -56,6 +56,7 @@
#include "intel_display_device.h"
#include "intel_display_trace.h"
#include "intel_display_types.h"
+#include "intel_display_wa.h"
#include "intel_fbc.h"
#include "intel_fbc_regs.h"
#include "intel_frontbuffer.h"
@@ -1237,6 +1238,11 @@ static int intel_fbc_check_plane(struct
intel_atomic_state *state,
return 0;
}
+ if (intel_display_needs_wa_16023588340(i915)) {
+ plane_state->no_fbc_reason = "Wa_16023588340";
+ return 0;
+ }
+
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
if (i915_vtd_active(i915) && (IS_SKYLAKE(i915) || IS_BROXTON(i915))) {
plane_state->no_fbc_reason = "VT-d enabled";
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 0e16e5029081..f7521fd5db4c 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -34,7 +34,8 @@ uses_generated_oob := \
$(obj)/xe_ring_ops.o \
$(obj)/xe_vm.o \
$(obj)/xe_wa.o \
- $(obj)/xe_ttm_stolen_mgr.o
+ $(obj)/xe_ttm_stolen_mgr.o \
+ $(obj)/display/xe_display_wa.o \
$(uses_generated_oob): $(generated_oob)
@@ -192,6 +193,7 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
display/xe_display.o \
display/xe_display_misc.o \
display/xe_display_rps.o \
+ display/xe_display_wa.o \
display/xe_dsb_buffer.o \
display/xe_fb_pin.o \
display/xe_hdcp_gsc.o \
diff --git a/drivers/gpu/drm/xe/display/xe_display_wa.c
b/drivers/gpu/drm/xe/display/xe_display_wa.c
new file mode 100644
index ..68e3d1959ad6
--- /dev/null
+++ b/drivers/gpu/drm/xe/display/xe_display_wa.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2024 Intel Corporation
+ */
+
+#include "intel_display_wa.h"
+
+#include "xe_device.h"
+#include "xe_wa.h"
+
+#include
+
+bool intel_display_needs_wa_16023588340(struct drm_i915_private *i915)
+{
+ return XE_WA(xe_root_mmio_gt(i915), 16023588340);
+}
--
2.45.1
Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
On Wed, Jun 19, 2024 at 04:24:16PM +0300, Ville Syrjälä wrote: > On Wed, Jun 19, 2024 at 04:11:08PM +0300, Jani Nikula wrote: > > On Wed, 19 Jun 2024, Ville Syrjälä wrote: > > > On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote: > > >> On Tue, 11 Jun 2024, Ville Syrjala wrote: > > >> > From: Ville Syrjälä > > >> > > > >> > As we extend the use of DSB for critical pipe/plane register > > >> > programming, it'll be nice to have an escape valve at hand, > > >> > in case things go very poorly. To that end, add a i915.enable_dsb > > >> > modparam by which we can force the driver to take the pure mmio > > >> > path instead. > > >> > > > >> > Signed-off-by: Ville Syrjälä > > >> > --- > > >> > drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++ > > >> > drivers/gpu/drm/i915/display/intel_display_params.h | 1 + > > >> > drivers/gpu/drm/i915/display/intel_dsb.c| 3 +++ > > >> > 3 files changed, 7 insertions(+) > > >> > > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c > > >> > b/drivers/gpu/drm/i915/display/intel_display_params.c > > >> > index aebdb7b59dbf..449a31767791 100644 > > >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.c > > >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c > > >> > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, > > >> > 0400, > > >> > intel_display_param_named_unsafe(enable_dpt, bool, 0400, > > >> >"Enable display page table (DPT) (default: true)"); > > >> > > > >> > +intel_display_param_named_unsafe(enable_dsb, bool, 0600, > > >> > + "Enable display state buffer (DSB) (default: true)"); > > >> > > >> Not much point in leaving the module param 0600, is there? > > > > > > It'll let you try both dsb and mmio paths at runtime without > > > having to do a full reboot/reload. > > > > I mean does any code actually look at the *module* parameter runtime? > > It's only the initial value for the device param? > > You can change it via the debugfs i915_params/* thing. Apparently the modparam vs. debugfs permissions are specified in two different places. This is rather confusing. Is there no way to put them in the same place? Or can we just nuke the permission stuff from the modparam macro entirely so it won't end up confusing me again? Looks like there is exactly one (gem related) modparam that uses 0600, everything else seems to be 0400. -- Ville Syrjälä Intel
Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
On Wed, Jun 19, 2024 at 05:44:08PM +0300, Ville Syrjälä wrote: > On Wed, Jun 19, 2024 at 04:24:16PM +0300, Ville Syrjälä wrote: > > On Wed, Jun 19, 2024 at 04:11:08PM +0300, Jani Nikula wrote: > > > On Wed, 19 Jun 2024, Ville Syrjälä wrote: > > > > On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote: > > > >> On Tue, 11 Jun 2024, Ville Syrjala > > > >> wrote: > > > >> > From: Ville Syrjälä > > > >> > > > > >> > As we extend the use of DSB for critical pipe/plane register > > > >> > programming, it'll be nice to have an escape valve at hand, > > > >> > in case things go very poorly. To that end, add a i915.enable_dsb > > > >> > modparam by which we can force the driver to take the pure mmio > > > >> > path instead. > > > >> > > > > >> > Signed-off-by: Ville Syrjälä > > > >> > --- > > > >> > drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++ > > > >> > drivers/gpu/drm/i915/display/intel_display_params.h | 1 + > > > >> > drivers/gpu/drm/i915/display/intel_dsb.c| 3 +++ > > > >> > 3 files changed, 7 insertions(+) > > > >> > > > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c > > > >> > b/drivers/gpu/drm/i915/display/intel_display_params.c > > > >> > index aebdb7b59dbf..449a31767791 100644 > > > >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.c > > > >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c > > > >> > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, > > > >> > 0400, > > > >> > intel_display_param_named_unsafe(enable_dpt, bool, 0400, > > > >> > "Enable display page table (DPT) (default: true)"); > > > >> > > > > >> > +intel_display_param_named_unsafe(enable_dsb, bool, 0600, > > > >> > +"Enable display state buffer (DSB) (default: true)"); > > > >> > > > >> Not much point in leaving the module param 0600, is there? > > > > > > > > It'll let you try both dsb and mmio paths at runtime without > > > > having to do a full reboot/reload. > > > > > > I mean does any code actually look at the *module* parameter runtime? > > > It's only the initial value for the device param? > > > > You can change it via the debugfs i915_params/* thing. > > Apparently the modparam vs. debugfs permissions are specified in two > different places. This is rather confusing. > > Is there no way to put them in the same place? Or can we just nuke > the permission stuff from the modparam macro entirely so it won't > end up confusing me again? Looks like there is exactly one (gem related) > modparam that uses 0600, everything else seems to be 0400. And even that seems to use the per-device copy in the actual code. So looks to me like we can just rip out the macro argument and make it 0400 always. -- Ville Syrjälä Intel
✓ Fi.CI.BAT: success for drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock (rev2)
== Series Details ==
Series: drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock (rev2)
URL : https://patchwork.freedesktop.org/series/135056/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14970 -> Patchwork_135056v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/index.html
Participating hosts (42 -> 38)
--
Missing(4): bat-dg2-11 bat-arlh-2 fi-cfl-8109u fi-snb-2520m
Known issues
Here are the changes found in Patchwork_135056v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- bat-arls-2: [PASS][1] -> [DMESG-WARN][2] ([i915#7507])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14970/bat-arls-2/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/bat-arls-2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-arls-5: NOTRUN -> [SKIP][3] ([i915#11346] / [i915#11393])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/bat-arls-5/igt@kms_pipe_crc_ba...@nonblocking-crc.html
Possible fixes
* igt@kms_flip@basic-flip-vs-dpms@a-dp6:
- {bat-mtlp-9}: [DMESG-WARN][4] ([i915#11009]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14970/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html
* igt@kms_flip@basic-flip-vs-dpms@b-dp7:
- {bat-mtlp-9}: [FAIL][6] ([i915#6121]) -> [PASS][7] +6 other tests
pass
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14970/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@b-dp7.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@b-dp7.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10979]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10979
[i915#11009]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11009
[i915#11346]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11346
[i915#11393]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11393
[i915#11394]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11394
[i915#11395]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11395
[i915#6121]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/6121
[i915#7507]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/7507
Build changes
-
* Linux: CI_DRM_14970 -> Patchwork_135056v2
CI-20190529: 20190529
CI_DRM_14970: 207282b212f760b65686198827bbb9b429a1ab90 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7892: 7892
Patchwork_135056v2: 207282b212f760b65686198827bbb9b429a1ab90 @
git://anongit.freedesktop.org/gfx-ci/linux
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/index.html
Re: [PATCH v16 9/9] drm/i915: Compute CMRR and calculate vtotal
Hi Mitul,
On Mon, Jun 10, 2024 at 12:52:02PM +0530, Mitul Golani wrote:
...
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 4ad99a54aa83..05f67dc9d98d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -12,6 +12,9 @@
> #include "intel_vrr_regs.h"
> #include "intel_dp.h"
>
> +#define FIXED_POINT_PRECISION100
> +#define CMRR_PRECISION_TOLERANCE 10
> +
> bool intel_vrr_is_capable(struct intel_connector *connector)
> {
> const struct drm_display_info *info = &connector->base.display_info;
> @@ -107,6 +110,52 @@ int intel_vrr_vmax_vblank_start(const struct
> intel_crtc_state *crtc_state)
> return crtc_state->vrr.vmax - intel_vrr_vblank_exit_length(crtc_state);
> }
>
> +static bool
> +is_cmrr_frac_required(struct intel_crtc_state *crtc_state)
> +{
> + int calculated_refresh_k, actual_refresh_k, pixel_clock_per_line;
> + struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (!HAS_CMRR(i915))
> + return false;
> +
> + actual_refresh_k =
> + drm_mode_vrefresh(adjusted_mode) * FIXED_POINT_PRECISION;
> + pixel_clock_per_line =
> + adjusted_mode->crtc_clock * 1000 / adjusted_mode->crtc_htotal;
> + calculated_refresh_k =
> + pixel_clock_per_line * FIXED_POINT_PRECISION /
> adjusted_mode->crtc_vtotal;
> +
> + if ((actual_refresh_k - calculated_refresh_k) <
> CMRR_PRECISION_TOLERANCE)
> + return false;
> +
> + return true;
> +}
> +
> +static unsigned int
> +cmrr_get_vtotal(struct intel_crtc_state *crtc_state, bool
> video_mode_required)
> +{
> + int multiplier_m = 1, multiplier_n = 1, vtotal, desired_refresh_rate;
> + long long adjusted_pixel_rate;
> + struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> +
> + desired_refresh_rate = drm_mode_vrefresh(adjusted_mode);
> +
> + if (video_mode_required) {
> + multiplier_m = 1001;
> + multiplier_n = 1000;
> + }
> +
> + crtc_state->cmrr.cmrr_n =
> + desired_refresh_rate * adjusted_mode->crtc_htotal *
> multiplier_n;
> + vtotal = (adjusted_mode->crtc_clock * 1000 * multiplier_n) /
> crtc_state->cmrr.cmrr_n;
> + adjusted_pixel_rate = adjusted_mode->crtc_clock * 1000 * multiplier_m;
> + crtc_state->cmrr.cmrr_m = do_div(adjusted_pixel_rate,
> crtc_state->cmrr.cmrr_n);
> +
> + return vtotal;
> +}
This change is now in -next as commit 1676ecd303ac ("drm/i915: Compute
CMRR and calculate vtotal"), where it breaks the xe build for 32-bit
platforms with:
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- allmodconfig
drivers/gpu/drm/xe/i915-display/intel_vrr.o
In file included from arch/arm/include/asm/div64.h:107,
from include/linux/math.h:6,
from include/linux/kernel.h:27,
from include/linux/cpumask.h:11,
from include/linux/smp.h:13,
from include/linux/lockdep.h:14,
from include/linux/spinlock.h:63,
from include/linux/kref.h:16,
from include/drm/drm_device.h:5,
from include/drm/drm_drv.h:35,
from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:13,
from drivers/gpu/drm/i915/display/intel_vrr.c:7:
drivers/gpu/drm/i915/display/intel_vrr.c: In function 'cmrr_get_vtotal':
include/asm-generic/div64.h:222:35: error: comparison of distinct pointer
types lacks a cast [-Werror]
222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
| ^~
drivers/gpu/drm/i915/display/intel_vrr.c:155:35: note: in expansion of macro
'do_div'
155 | crtc_state->cmrr.cmrr_m = do_div(adjusted_pixel_rate,
crtc_state->cmrr.cmrr_n);
| ^~
cc1: all warnings being treated as errors
Also, is do_div() correct here? It is different from the other div_()
macros in that the "return value" is the remainder, not the result of
the division.
Cheers,
Nathan
Re: Linux 6.10-rc1
On Wed, 19 Jun 2024 at 03:44, Pavel Machek wrote: > > Ok, so machine is ready to be thrown out of window, again. Trying to > play 29C3 video should not make machine completely unusable ... as in > keyboard looses keystrokes in terminal. Well, that at least sounds like you can bisect it with a very clear test-case? Even if you don't bisect all the way, just doing a handful of bisections tends to narrow things down enough that we can at least guess at what general kind of area it is... Linus
✗ Fi.CI.SPARSE: warning for drm/i915: Polish plane surface alignment handling (rev3)
== Series Details == Series: drm/i915: Polish plane surface alignment handling (rev3) URL : https://patchwork.freedesktop.org/series/133564/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [PATCH v2 0/9] drm/i915: Polish plane surface alignment handling
On Wed, Jun 19, 2024 at 02:38:16PM +0300, Ville Syrjälä wrote: > On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > intel_surf_alignment() in particular has devolved into > > a complete mess. Redesign the code so that we can handle > > alignment restrictions in a nicer. Also adjust alignment > > for TGL+ to actually match the hardware requirements. > > > > v2: Drop the per-plane vma stuff as it was borked > > Don't temporarily remove the 2MiB DPT alignment for UV on TGL > > > > Ville Syrjälä (9): > > drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format() > > drm: Export drm_plane_has_format() > > Maarten/Maxime/Thomas, can I get an ack for merging these via > drm-intel please? > > > drm/i915: Introduce the plane->min_alignment() vfunc > > drm/i915: Introduce fb->min_alignment > > drm/i915: Split cursor alignment to per-platform vfuncs > > drm/i915: Split pre-skl platforms out from intel_surf_alignment() > > drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c > > drm/i915: Update plane alignment requirements for TGL+ > > drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff > > > > drivers/gpu/drm/drm_atomic.c | 7 +- > > drivers/gpu/drm/drm_crtc.c| 6 +- > > drivers/gpu/drm/drm_crtc_internal.h | 2 - > > drivers/gpu/drm/drm_plane.c | 23 ++- > > drivers/gpu/drm/i915/display/i9xx_plane.c | 75 - > > drivers/gpu/drm/i915/display/intel_cursor.c | 38 + > > .../drm/i915/display/intel_display_types.h| 5 + > > drivers/gpu/drm/i915/display/intel_fb.c | 151 -- > > drivers/gpu/drm/i915/display/intel_fb.h | 3 - > > drivers/gpu/drm/i915/display/intel_fb_pin.c | 39 +++-- > > drivers/gpu/drm/i915/display/intel_fb_pin.h | 3 +- > > drivers/gpu/drm/i915/display/intel_fbdev.c| 5 +- > > drivers/gpu/drm/i915/display/intel_sprite.c | 26 +++ > > .../drm/i915/display/skl_universal_plane.c| 85 +- > > drivers/gpu/drm/xe/display/xe_fb_pin.c| 3 +- > > drivers/gpu/drm/xe/display/xe_plane_initial.c | 4 +- > > Lucas, can you give me an ack for the merging the xe > changes via drm-intel? Apparently Lucas is out. Rodrigo, can you ack this? > > > include/drm/drm_plane.h | 2 + > > 17 files changed, 309 insertions(+), 168 deletions(-) > > > > -- > > 2.44.2 > > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel
✓ Fi.CI.BAT: success for drm/i915: Polish plane surface alignment handling (rev3)
== Series Details ==
Series: drm/i915: Polish plane surface alignment handling (rev3)
URL : https://patchwork.freedesktop.org/series/133564/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14972 -> Patchwork_133564v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/index.html
Participating hosts (35 -> 35)
--
Additional (2): bat-arlh-2 fi-kbl-8809g
Missing(2): bat-jsl-1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_133564v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-b-dp-7:
- {bat-mtlp-9}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-mtlp-9/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-dp-7.html
Known issues
Here are the changes found in Patchwork_133564v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-arlh-2: NOTRUN -> [SKIP][2] ([i915#9318])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@debugfs_t...@basic-hwmon.html
* igt@fbdev@eof:
- bat-arlh-2: NOTRUN -> [SKIP][3] ([i915#11345]) +3 other tests skip
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@fb...@eof.html
* igt@fbdev@info:
- bat-arlh-2: NOTRUN -> [SKIP][4] ([i915#1849])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@fb...@info.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-8809g: NOTRUN -> [SKIP][6] ([i915#4613]) +3 other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/fi-kbl-8809g/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-arlh-2: NOTRUN -> [SKIP][7] ([i915#10213]) +3 other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_mmap@basic:
- bat-arlh-2: NOTRUN -> [SKIP][8] ([i915#11343])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@gem_m...@basic.html
* igt@gem_render_tiled_blits@basic:
- bat-arlh-2: NOTRUN -> [SKIP][9] ([i915#10197])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@gem_render_tiled_bl...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-arlh-2: NOTRUN -> [SKIP][10] ([i915#10196]) +4 other tests
skip
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@gem_tiled_fence_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-arlh-2: NOTRUN -> [SKIP][11] ([i915#10206])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@gem_tiled_pread_basic.html
* igt@i915_pm_rps@basic-api:
- bat-arlh-2: NOTRUN -> [SKIP][12] ([i915#10209])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@i915_pm_...@basic-api.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-arlh-2: NOTRUN -> [SKIP][13] ([i915#10200]) +9 other tests
skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@kms_addfb_ba...@basic-x-tiled-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-8809g: NOTRUN -> [SKIP][14] +30 other tests skip
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/fi-kbl-8809g/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pm_backlight@basic-brightness:
- bat-arlh-2: NOTRUN -> [SKIP][15] ([i915#11346]) +32 other tests
skip
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@kms_pm_backli...@basic-brightness.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-arlh-2: NOTRUN -> [SKIP][16] ([i915#10208] / [i915#8809])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-read:
- bat-arlh-2: NOTRUN -> [SKIP][17] ([i915#10212])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/bat-arlh-2/igt@prime_v...@basic-fence-read.html
* igt@prime_vgem@basic-read:
- bat-arlh-2: NOTRUN -> [SKIP][18] ([i915#10214])
[18]:
https://intel-gfx-ci.
✓ Fi.CI.IGT: success for drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock (rev2)
== Series Details == Series: drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock (rev2) URL : https://patchwork.freedesktop.org/series/135056/ State : success == Summary == CI Bug Log - changes from CI_DRM_14970_full -> Patchwork_135056v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_135056v2_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-keep-cache: - shard-rkl: NOTRUN -> [SKIP][1] ([i915#8411]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html - shard-dg2: NOTRUN -> [SKIP][2] ([i915#8411]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg2-8/igt@api_intel...@object-reloc-keep-cache.html * igt@api_intel_bb@object-reloc-purge-cache: - shard-dg1: NOTRUN -> [SKIP][3] ([i915#8411]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg1-16/igt@api_intel...@object-reloc-purge-cache.html * igt@drm_fdinfo@all-busy-idle-check-all: - shard-mtlp: NOTRUN -> [SKIP][4] ([i915#8414]) +1 other test skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-mtlp-6/igt@drm_fdi...@all-busy-idle-check-all.html * igt@drm_fdinfo@isolation@vecs0: - shard-dg1: NOTRUN -> [SKIP][5] ([i915#8414]) +5 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg1-16/igt@drm_fdinfo@isolat...@vecs0.html * igt@drm_fdinfo@most-busy-idle-check-all@rcs0: - shard-rkl: [PASS][6] -> [FAIL][7] ([i915#7742]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14970/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html * igt@gem_ccs@suspend-resume: - shard-rkl: NOTRUN -> [SKIP][8] ([i915#9323]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-5/igt@gem_...@suspend-resume.html * igt@gem_ctx_freq@sysfs@gt0: - shard-dg2: [PASS][9] -> [FAIL][10] ([i915#9561]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14970/shard-dg2-6/igt@gem_ctx_freq@sy...@gt0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg2-10/igt@gem_ctx_freq@sy...@gt0.html * igt@gem_ctx_sseu@invalid-args: - shard-dg2: NOTRUN -> [SKIP][11] ([i915#280]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg2-8/igt@gem_ctx_s...@invalid-args.html - shard-rkl: NOTRUN -> [SKIP][12] ([i915#280]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-5/igt@gem_ctx_s...@invalid-args.html * igt@gem_eio@reset-stress: - shard-dg1: [PASS][13] -> [FAIL][14] ([i915#5784]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14970/shard-dg1-13/igt@gem_...@reset-stress.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg1-13/igt@gem_...@reset-stress.html * igt@gem_exec_balancer@parallel-bb-first: - shard-rkl: NOTRUN -> [SKIP][15] ([i915#4525]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-5/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_capture@capture-invisible@smem0: - shard-rkl: NOTRUN -> [SKIP][16] ([i915#6334]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-2/igt@gem_exec_capture@capture-invisi...@smem0.html * igt@gem_exec_fair@basic-deadline: - shard-glk: NOTRUN -> [FAIL][17] ([i915#2846]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3539] / [i915#4852]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg2-8/igt@gem_exec_f...@basic-none-rrul.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-rkl: NOTRUN -> [FAIL][19] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@rcs0: - shard-tglu: NOTRUN -> [FAIL][20] ([i915#2842]) +4 other tests fail [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-tglu-10/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fence@submit67: - shard-dg2: NOTRUN -> [SKIP][21] ([i915#4812]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135056v2/shard-dg2-1/igt@gem_exec_fe...@
[PULL] drm-intel-next
Hi Dave & Sima - The main i915 pull request for v6.11. A bit more commits than usual. Should've started sending periodic PR's earlier to keep it more manageable. My bad. Highlights are BMG display, panel replay enabling, and link training failure fallback for DP MST. A big chunk of the commit count comes from finally removing implicit dev_priv variable references from register macros. This is iterative preparation for better separation of display code from i915 and xe core code. Off to midsummer festivities, Jani. drm-intel-next-2024-06-19: drm/i915 feature pull for v6.11: Features and functionality: - Battlemage (BMG) Xe2 HPD display enabling (Balasubramani, Clint, Gustavo, José, Matt, Anusha, Lucas, Ravi, Radhakrishna, Nirmoy, Ankit, Matthew) - Panel Replay enabling (Jouni, Animesh) - DP AUX-less ALPM (Advanced Link Power Management) and LOBF (Link off between frames) enabling (Animesh, Jouni) - Enable link training failure fallback for DP MST links (Imre) - CMRR (Content Match Refresh Rate) enabling (Mitul) - Allow the first async flip to change modifier (Ville) - Enable eDP AUX based HDR backlight (Suraj) - Increase ADL-S/ADL-P/DG2+ max TMDS bitrate to 6 Gbps (Ville) Refactoring and cleanups: - Stop using implicit dev_priv local variable in macros (Jani) - Expand and clean up VBT table definitions (Ville) - PSR/ALPM refactoring (Jouni, Animesh) - Plane fb refactoring (Ville) - Rawclk, FSB, and mem frequency refactoring (Jani) - GVT register macro usage cleanups (Jani, Ville) - Plane, cursor, wm and ddb register macro and usage cleanups (Ville) - Pipe CRC register macro cleanups (Ville) - PCI ID macro cleanups and refactoring to match xe style (Jani) - Move drm-intel repo to gitlab.freedesktop.org (Ryszard) - Identify all platforms/subplatforms in display probe (Jani) - Move Intel drm headers under include/drm/intel (Jani) - Drop local redundant W=1 warnings in favour of drm subsystem warnigs (Jani) - Include cleanups; include what you use (Jani) - Convert overlay and DMC error state printing to drm_printer (Jani) - Joiner renames (Stan) - DSB interface cleanups (Ville) - Improve workaround for disabling FBC when VT-d is active (Vinod) - State checker refactoring and cleanups for color, planes and cdclk (Ville) - Cleanups around scanline arithmetic (Ville) - Use drm_crtc_vblank_crtc() instead of open coding (Ville) - DSC cleanups (Ville) Fixes: - Improve VBT array bounds check (Luca) - LNL PSR fixes (Jouni) - Audio workaround, disable min hblank fix (Uma) - Stop selecting ACPI_BUTTON config (Jani) - Add MTL Cx0 PHY config compare (Mika) - Fix MTL C20 PHY port clock verification (Mika) - Fix static analyzer warning for uapi.event access (Luca) - HDCP fixes and workarounds (Suraj) - Fix DP MST DSC input BPP computation (Imre) - Fix assert on pending async-put power domain work (Imre) - Fix documentation build for DMC wakelocks (Luca) - Disable DSC on eDP when indicated by VBT (Ville) DRM Core changes: - Various DPCD register additions for panel replay and ALPM (Jouni) - Add target_rr_divider to adaptive sync SDP (Mitul) Xe driver changes: - Remove unused xe->enabled_irq_mask and xe->sb_lock members (Jani) - i915 display compat header cleanups (Jani) - Remove redundant copy of intel_fbdev_fb.h (Ville) - Add process name to devcoredump (José) - Add xe_gt_err_once() (Matthew) - Implement transient flush for BMG/Xe3 (Nirmoy) Merges: - Backmerges to sync with xe, drm-misc and upstream (Rodrigo, Jani) BR, Jani. The following changes since commit 1ddaaa244021aba8496536a6627b4ad2bc0f936a: Merge tag 'amd-drm-next-6.11-2024-06-07' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2024-06-11 14:01:55 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-next-2024-06-19 for you to fetch changes up to d754ed2821fd9675d203cb73c4afcd593e28b7d0: Merge drm/drm-next into drm-intel-next (2024-06-19 11:38:31 +0300) drm/i915 feature pull for v6.11: Features and functionality: - Battlemage (BMG) Xe2 HPD display enabling (Balasubramani, Clint, Gustavo, José, Matt, Anusha, Lucas, Ravi, Radhakrishna, Nirmoy, Ankit, Matthew) - Panel Replay enabling (Jouni, Animesh) - DP AUX-less ALPM (Advanced Link Power Management) and LOBF (Link off between frames) enabling (Animesh, Jouni) - Enable link training failure fallback for DP MST links (Imre) - CMRR (Content Match Refresh Rate) enabling (Mitul) - Allow the first async flip to change modifier (Ville) - Enable eDP AUX based HDR backlight (Suraj) - Increase ADL-S/ADL-P/DG2+ max TMDS bitrate to 6 Gbps (Ville) Refactoring and cleanups: - Stop using implicit dev_priv local variable in macros (Jani) - Expand and clean up VBT table definitions (Ville) - PSR/ALPM refactoring (Jouni, Animesh) - Plane fb refactoring (Ville) - Rawclk, FSB, and mem frequency refactoring (Jani) - GVT register macro usage cleanups (Jani, Ville
Re: [PATCH 08/11] drm/i915/dsb: Add i915.enable_dsb module parameter
On Wed, 19 Jun 2024, Ville Syrjälä wrote: > On Wed, Jun 19, 2024 at 05:44:08PM +0300, Ville Syrjälä wrote: >> On Wed, Jun 19, 2024 at 04:24:16PM +0300, Ville Syrjälä wrote: >> > On Wed, Jun 19, 2024 at 04:11:08PM +0300, Jani Nikula wrote: >> > > On Wed, 19 Jun 2024, Ville Syrjälä wrote: >> > > > On Tue, Jun 18, 2024 at 02:07:56PM +0300, Jani Nikula wrote: >> > > >> On Tue, 11 Jun 2024, Ville Syrjala >> > > >> wrote: >> > > >> > From: Ville Syrjälä >> > > >> > >> > > >> > As we extend the use of DSB for critical pipe/plane register >> > > >> > programming, it'll be nice to have an escape valve at hand, >> > > >> > in case things go very poorly. To that end, add a i915.enable_dsb >> > > >> > modparam by which we can force the driver to take the pure mmio >> > > >> > path instead. >> > > >> > >> > > >> > Signed-off-by: Ville Syrjälä >> > > >> > --- >> > > >> > drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++ >> > > >> > drivers/gpu/drm/i915/display/intel_display_params.h | 1 + >> > > >> > drivers/gpu/drm/i915/display/intel_dsb.c| 3 +++ >> > > >> > 3 files changed, 7 insertions(+) >> > > >> > >> > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c >> > > >> > b/drivers/gpu/drm/i915/display/intel_display_params.c >> > > >> > index aebdb7b59dbf..449a31767791 100644 >> > > >> > --- a/drivers/gpu/drm/i915/display/intel_display_params.c >> > > >> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.c >> > > >> > @@ -54,6 +54,9 @@ intel_display_param_named_unsafe(enable_dc, int, >> > > >> > 0400, >> > > >> > intel_display_param_named_unsafe(enable_dpt, bool, 0400, >> > > >> > "Enable display page table (DPT) (default: true)"); >> > > >> > >> > > >> > +intel_display_param_named_unsafe(enable_dsb, bool, 0600, >> > > >> > + "Enable display state buffer (DSB) (default: true)"); >> > > >> >> > > >> Not much point in leaving the module param 0600, is there? >> > > > >> > > > It'll let you try both dsb and mmio paths at runtime without >> > > > having to do a full reboot/reload. >> > > >> > > I mean does any code actually look at the *module* parameter runtime? >> > > It's only the initial value for the device param? >> > >> > You can change it via the debugfs i915_params/* thing. >> >> Apparently the modparam vs. debugfs permissions are specified in two >> different places. This is rather confusing. >> >> Is there no way to put them in the same place? Or can we just nuke >> the permission stuff from the modparam macro entirely so it won't >> end up confusing me again? Looks like there is exactly one (gem related) >> modparam that uses 0600, everything else seems to be 0400. > > And even that seems to use the per-device copy in the actual code. > So looks to me like we can just rip out the macro argument and > make it 0400 always. Yeah, it's not great. I guess the only reason the modparams would need to be writable is to be able to use different values for different devices when the modparam values are needed at probe, before they can be changed via device param debugfs: - set modparam to x - probe device 1 - set modparam to y - probe device 2 I don't know if anyone really uses that. There are really no good solutions to this. :( BR, Jani. -- Jani Nikula, Intel
RE: [PATCH v16 9/9] drm/i915: Compute CMRR and calculate vtotal
Hi @Nathan Chancellor
Probably fix is merged in drm-intel-next
related patch: https://patchwork.freedesktop.org/series/134860/
Can you please check and suggest if this patch is merged ?
Thanks,
Mitul
> -Original Message-
> From: Nathan Chancellor
> Sent: Wednesday, June 19, 2024 9:12 PM
> To: Golani, Mitulkumar Ajitkumar
> Cc: intel-gfx@lists.freedesktop.org; Nautiyal, Ankit K
> ; intel...@lists.freedesktop.org
> Subject: Re: [PATCH v16 9/9] drm/i915: Compute CMRR and calculate vtotal
>
> Hi Mitul,
>
> On Mon, Jun 10, 2024 at 12:52:02PM +0530, Mitul Golani wrote:
> ...
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > index 4ad99a54aa83..05f67dc9d98d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > @@ -12,6 +12,9 @@
> > #include "intel_vrr_regs.h"
> > #include "intel_dp.h"
> >
> > +#define FIXED_POINT_PRECISION 100
> > +#define CMRR_PRECISION_TOLERANCE 10
> > +
> > bool intel_vrr_is_capable(struct intel_connector *connector) {
> > const struct drm_display_info *info = &connector->base.display_info;
> > @@ -107,6 +110,52 @@ int intel_vrr_vmax_vblank_start(const struct
> intel_crtc_state *crtc_state)
> > return crtc_state->vrr.vmax -
> > intel_vrr_vblank_exit_length(crtc_state);
> > }
> >
> > +static bool
> > +is_cmrr_frac_required(struct intel_crtc_state *crtc_state) {
> > + int calculated_refresh_k, actual_refresh_k, pixel_clock_per_line;
> > + struct drm_display_mode *adjusted_mode = &crtc_state-
> >hw.adjusted_mode;
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > +
> > + if (!HAS_CMRR(i915))
> > + return false;
> > +
> > + actual_refresh_k =
> > + drm_mode_vrefresh(adjusted_mode) *
> FIXED_POINT_PRECISION;
> > + pixel_clock_per_line =
> > + adjusted_mode->crtc_clock * 1000 / adjusted_mode-
> >crtc_htotal;
> > + calculated_refresh_k =
> > + pixel_clock_per_line * FIXED_POINT_PRECISION /
> > +adjusted_mode->crtc_vtotal;
> > +
> > + if ((actual_refresh_k - calculated_refresh_k) <
> CMRR_PRECISION_TOLERANCE)
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > +static unsigned int
> > +cmrr_get_vtotal(struct intel_crtc_state *crtc_state, bool
> > +video_mode_required) {
> > + int multiplier_m = 1, multiplier_n = 1, vtotal, desired_refresh_rate;
> > + long long adjusted_pixel_rate;
> > + struct drm_display_mode *adjusted_mode =
> > +&crtc_state->hw.adjusted_mode;
> > +
> > + desired_refresh_rate = drm_mode_vrefresh(adjusted_mode);
> > +
> > + if (video_mode_required) {
> > + multiplier_m = 1001;
> > + multiplier_n = 1000;
> > + }
> > +
> > + crtc_state->cmrr.cmrr_n =
> > + desired_refresh_rate * adjusted_mode->crtc_htotal *
> multiplier_n;
> > + vtotal = (adjusted_mode->crtc_clock * 1000 * multiplier_n) /
> crtc_state->cmrr.cmrr_n;
> > + adjusted_pixel_rate = adjusted_mode->crtc_clock * 1000 *
> multiplier_m;
> > + crtc_state->cmrr.cmrr_m = do_div(adjusted_pixel_rate,
> > +crtc_state->cmrr.cmrr_n);
> > +
> > + return vtotal;
> > +}
>
> This change is now in -next as commit 1676ecd303ac ("drm/i915: Compute
> CMRR and calculate vtotal"), where it breaks the xe build for 32-bit platforms
> with:
>
> $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> allmodconfig drivers/gpu/drm/xe/i915-display/intel_vrr.o
> In file included from arch/arm/include/asm/div64.h:107,
>from include/linux/math.h:6,
>from include/linux/kernel.h:27,
>from include/linux/cpumask.h:11,
>from include/linux/smp.h:13,
>from include/linux/lockdep.h:14,
>from include/linux/spinlock.h:63,
>from include/linux/kref.h:16,
>from include/drm/drm_device.h:5,
>from include/drm/drm_drv.h:35,
>from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:13,
>from drivers/gpu/drm/i915/display/intel_vrr.c:7:
> drivers/gpu/drm/i915/display/intel_vrr.c: In function 'cmrr_get_vtotal':
> include/asm-generic/div64.h:222:35: error: comparison of distinct pointer
> types lacks a cast [-Werror]
> 222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> | ^~
> drivers/gpu/drm/i915/display/intel_vrr.c:155:35: note: in expansion of macro
> 'do_div'
> 155 | crtc_state->cmrr.cmrr_m = do_div(adjusted_pixel_rate,
> crtc_state-
> >cmrr.cmrr_n);
> | ^~
> cc1: all warnings being treated as errors
>
> Also, is do_div() correct here? It is different from the other div_() macros
> in that
> the "return value" is the remainder, not the result of the division.
>
> Cheers,
> Nathan
Re: [PATCH v16 9/9] drm/i915: Compute CMRR and calculate vtotal
On Wed, Jun 19, 2024 at 06:10:34PM +, Golani, Mitulkumar Ajitkumar wrote:
> Hi @Nathan Chancellor
>
> Probably fix is merged in drm-intel-next
> related patch: https://patchwork.freedesktop.org/series/134860/
>
> Can you please check and suggest if this patch is merged ?
This is still reproducible at commit 851de367dede ("drm/i915: Enable
plane/pipeDMC ATS fault interrupts on mtl") in drm-intel-next, which
includes that change as commit e2dc7cb72b25 ("drm/i915/display: Update
calculation to avoid overflow"). The issue is the dividend in do_div()
is required to be an unsigned 64-bit type but you used a signed type.
Updating adjusted_pixel_rate to be a u64 should resolve the issue and
match the return type of mul_u32_u32(). I just wasn't sure if that was
the only fix this code would need, as do_div() is not typically used
with an assignment.
Cheers,
Nathan
> > -Original Message-
> > From: Nathan Chancellor
> > Sent: Wednesday, June 19, 2024 9:12 PM
> > To: Golani, Mitulkumar Ajitkumar
> > Cc: intel-gfx@lists.freedesktop.org; Nautiyal, Ankit K
> > ; intel...@lists.freedesktop.org
> > Subject: Re: [PATCH v16 9/9] drm/i915: Compute CMRR and calculate vtotal
> >
> > Hi Mitul,
> >
> > On Mon, Jun 10, 2024 at 12:52:02PM +0530, Mitul Golani wrote:
> > ...
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > index 4ad99a54aa83..05f67dc9d98d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > @@ -12,6 +12,9 @@
> > > #include "intel_vrr_regs.h"
> > > #include "intel_dp.h"
> > >
> > > +#define FIXED_POINT_PRECISION100
> > > +#define CMRR_PRECISION_TOLERANCE 10
> > > +
> > > bool intel_vrr_is_capable(struct intel_connector *connector) {
> > > const struct drm_display_info *info = &connector->base.display_info;
> > > @@ -107,6 +110,52 @@ int intel_vrr_vmax_vblank_start(const struct
> > intel_crtc_state *crtc_state)
> > > return crtc_state->vrr.vmax -
> > > intel_vrr_vblank_exit_length(crtc_state);
> > > }
> > >
> > > +static bool
> > > +is_cmrr_frac_required(struct intel_crtc_state *crtc_state) {
> > > + int calculated_refresh_k, actual_refresh_k, pixel_clock_per_line;
> > > + struct drm_display_mode *adjusted_mode = &crtc_state-
> > >hw.adjusted_mode;
> > > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > > +
> > > + if (!HAS_CMRR(i915))
> > > + return false;
> > > +
> > > + actual_refresh_k =
> > > + drm_mode_vrefresh(adjusted_mode) *
> > FIXED_POINT_PRECISION;
> > > + pixel_clock_per_line =
> > > + adjusted_mode->crtc_clock * 1000 / adjusted_mode-
> > >crtc_htotal;
> > > + calculated_refresh_k =
> > > + pixel_clock_per_line * FIXED_POINT_PRECISION /
> > > +adjusted_mode->crtc_vtotal;
> > > +
> > > + if ((actual_refresh_k - calculated_refresh_k) <
> > CMRR_PRECISION_TOLERANCE)
> > > + return false;
> > > +
> > > + return true;
> > > +}
> > > +
> > > +static unsigned int
> > > +cmrr_get_vtotal(struct intel_crtc_state *crtc_state, bool
> > > +video_mode_required) {
> > > + int multiplier_m = 1, multiplier_n = 1, vtotal, desired_refresh_rate;
> > > + long long adjusted_pixel_rate;
> > > + struct drm_display_mode *adjusted_mode =
> > > +&crtc_state->hw.adjusted_mode;
> > > +
> > > + desired_refresh_rate = drm_mode_vrefresh(adjusted_mode);
> > > +
> > > + if (video_mode_required) {
> > > + multiplier_m = 1001;
> > > + multiplier_n = 1000;
> > > + }
> > > +
> > > + crtc_state->cmrr.cmrr_n =
> > > + desired_refresh_rate * adjusted_mode->crtc_htotal *
> > multiplier_n;
> > > + vtotal = (adjusted_mode->crtc_clock * 1000 * multiplier_n) /
> > crtc_state->cmrr.cmrr_n;
> > > + adjusted_pixel_rate = adjusted_mode->crtc_clock * 1000 *
> > multiplier_m;
> > > + crtc_state->cmrr.cmrr_m = do_div(adjusted_pixel_rate,
> > > +crtc_state->cmrr.cmrr_n);
> > > +
> > > + return vtotal;
> > > +}
> >
> > This change is now in -next as commit 1676ecd303ac ("drm/i915: Compute
> > CMRR and calculate vtotal"), where it breaks the xe build for 32-bit
> > platforms
> > with:
> >
> > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> > allmodconfig drivers/gpu/drm/xe/i915-display/intel_vrr.o
> > In file included from arch/arm/include/asm/div64.h:107,
> >from include/linux/math.h:6,
> >from include/linux/kernel.h:27,
> >from include/linux/cpumask.h:11,
> >from include/linux/smp.h:13,
> >from include/linux/lockdep.h:14,
> >from include/linux/spinlock.h:63,
> >from include/linux/kref.h:16,
> >from include/drm/drm_device.h:5,
> >from include/drm/drm_drv.h:35,
> >from
> > drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:13,
> >from drivers/gpu/drm/i915/display
Re: [PATCH 1/6] drm/i915/display: use a macro to initialize subplatforms
On Tue, Jun 18, 2024 at 05:22:51PM +0300, Jani Nikula wrote:
> Make it easier to change the underlying structures by using a macro
> similar to PLATFORM() for initialization.
>
> The subplatform names in debug logs change slightly as they now reflect
> the enum rather than manually entered names. For example, RAPTORLAKE_S
> rather than RPL-S.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_device.c | 44 ++-
> 1 file changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index dd7dce4b0e7a..d900c30907ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -26,6 +26,10 @@ struct subplatform_desc {
> const u16 *pciidlist;
> };
>
> +#define SUBPLATFORM(_platform, _subplatform) \
> + .subplatform = (INTEL_DISPLAY_##_platform##_##_subplatform),\
> + .name = #_subplatform
> +
> struct platform_desc {
> enum intel_display_platform platform;
> const char *name;
> @@ -485,8 +489,8 @@ static const u16 hsw_ulx_ids[] = {
> static const struct platform_desc hsw_desc = {
> PLATFORM(HASWELL),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_HASWELL_ULT, "ULT", hsw_ult_ids },
> - { INTEL_DISPLAY_HASWELL_ULX, "ULX", hsw_ulx_ids },
> + { SUBPLATFORM(HASWELL, ULT), .pciidlist = hsw_ult_ids },
> + { SUBPLATFORM(HASWELL, ULX), .pciidlist = hsw_ulx_ids },
> {},
> },
> .info = &(const struct intel_display_device_info) {
> @@ -529,8 +533,8 @@ static const u16 bdw_ulx_ids[] = {
> static const struct platform_desc bdw_desc = {
> PLATFORM(BROADWELL),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_BROADWELL_ULT, "ULT", bdw_ult_ids },
> - { INTEL_DISPLAY_BROADWELL_ULX, "ULX", bdw_ulx_ids },
> + { SUBPLATFORM(BROADWELL, ULT), .pciidlist = bdw_ult_ids },
> + { SUBPLATFORM(BROADWELL, ULX), .pciidlist = bdw_ulx_ids },
> {},
> },
> .info = &(const struct intel_display_device_info) {
> @@ -613,8 +617,8 @@ static const u16 skl_ulx_ids[] = {
> static const struct platform_desc skl_desc = {
> PLATFORM(SKYLAKE),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_SKYLAKE_ULT, "ULT", skl_ult_ids },
> - { INTEL_DISPLAY_SKYLAKE_ULX, "ULX", skl_ulx_ids },
> + { SUBPLATFORM(SKYLAKE, ULT), .pciidlist = skl_ult_ids },
> + { SUBPLATFORM(SKYLAKE, ULX), .pciidlist = skl_ulx_ids },
> {},
> },
> .info = &skl_display,
> @@ -637,8 +641,8 @@ static const u16 kbl_ulx_ids[] = {
> static const struct platform_desc kbl_desc = {
> PLATFORM(KABYLAKE),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_KABYLAKE_ULT, "ULT", kbl_ult_ids },
> - { INTEL_DISPLAY_KABYLAKE_ULX, "ULX", kbl_ulx_ids },
> + { SUBPLATFORM(KABYLAKE, ULT), .pciidlist = kbl_ult_ids },
> + { SUBPLATFORM(KABYLAKE, ULX), .pciidlist = kbl_ulx_ids },
> {},
> },
> .info = &skl_display,
> @@ -661,8 +665,8 @@ static const u16 cfl_ulx_ids[] = {
> static const struct platform_desc cfl_desc = {
> PLATFORM(COFFEELAKE),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_COFFEELAKE_ULT, "ULT", cfl_ult_ids },
> - { INTEL_DISPLAY_COFFEELAKE_ULX, "ULX", cfl_ulx_ids },
> + { SUBPLATFORM(COFFEELAKE, ULT), .pciidlist = cfl_ult_ids },
> + { SUBPLATFORM(COFFEELAKE, ULX), .pciidlist = cfl_ulx_ids },
> {},
> },
> .info = &skl_display,
> @@ -677,7 +681,7 @@ static const u16 cml_ult_ids[] = {
> static const struct platform_desc cml_desc = {
> PLATFORM(COMETLAKE),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_COMETLAKE_ULT, "ULT", cml_ult_ids },
> + { SUBPLATFORM(COMETLAKE, ULT), .pciidlist = cml_ult_ids },
> {},
> },
> .info = &skl_display,
> @@ -776,7 +780,7 @@ static const u16 icl_port_f_ids[] = {
> static const struct platform_desc icl_desc = {
> PLATFORM(ICELAKE),
> .subplatforms = (const struct subplatform_desc[]) {
> - { INTEL_DISPLAY_ICELAKE_PORT_F, "Port F", icl_port_f_ids },
> + { SUBPLATFORM(ICELAKE, PORT_F), .pciidlist = icl_port_f_ids },
> {},
> },
> .info = &(const struct intel_display_device_info) {
> @@ -853,7 +857,7 @@ static const u16 tgl_uy_ids[] = {
> static const struct platform_desc tgl_desc = {
> PLATFORM(TIGERLAKE),
> .subplatforms = (const struct subplatform_desc[])
Re: [PATCH 2/6] drm/i915/display: use a macro to define platform enumerations
On Tue, Jun 18, 2024 at 05:22:52PM +0300, Jani Nikula wrote:
> We'll be needing a macro based list of platforms for more things in the
> future. Start by defining the platform enumerations with it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_device.h | 115 ++
> 1 file changed, 61 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index 13453ea4daea..aca3dfd5e7af 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -15,63 +15,70 @@ struct drm_i915_private;
> struct drm_printer;
>
> /* Keep in gen based order, and chronological order within a gen */
> +#define INTEL_DISPLAY_PLATFORMS(func) \
> + func(PLATFORM_UNINITIALIZED) \
> + /* Display ver 2 */ \
> + func(I830) \
> + func(I845G) \
> + func(I85X) \
> + func(I865G) \
> + /* Display ver 3 */ \
> + func(I915G) \
> + func(I915GM) \
> + func(I945G) \
> + func(I945GM) \
> + func(G33) \
> + func(PINEVIEW) \
> + /* Display ver 4 */ \
> + func(I965G) \
> + func(I965GM) \
> + func(G45) \
> + func(GM45) \
> + /* Display ver 5 */ \
> + func(IRONLAKE) \
> + /* Display ver 6 */ \
> + func(SANDYBRIDGE) \
> + /* Display ver 7 */ \
> + func(IVYBRIDGE) \
> + func(VALLEYVIEW) \
> + func(HASWELL) \
> + /* Display ver 8 */ \
> + func(BROADWELL) \
> + func(CHERRYVIEW) \
> + /* Display ver 9 */ \
> + func(SKYLAKE) \
> + func(BROXTON) \
> + func(KABYLAKE) \
> + func(GEMINILAKE) \
> + func(COFFEELAKE) \
> + func(COMETLAKE) \
> + /* Display ver 11 */ \
> + func(ICELAKE) \
> + func(JASPERLAKE) \
> + func(ELKHARTLAKE) \
> + /* Display ver 12 */ \
> + func(TIGERLAKE) \
> + func(ROCKETLAKE) \
> + func(DG1) \
> + func(ALDERLAKE_S) \
> + /* Display ver 13 */ \
> + func(ALDERLAKE_P) \
> + func(DG2) \
> + /* Display ver 14 (based on GMD ID) */ \
> + func(METEORLAKE) \
> + /* Display ver 20 (based on GMD ID) */ \
> + func(LUNARLAKE) \
> + /* Display ver 14.1 (based on GMD ID) */ \
> + func(BATTLEMAGE)
> +
> +#define ENUM(x) INTEL_DISPLAY_ ## x,
> +
> enum intel_display_platform {
> - INTEL_DISPLAY_PLATFORM_UNINITIALIZED = 0,
> - /* Display ver 2 */
> - INTEL_DISPLAY_I830,
> - INTEL_DISPLAY_I845G,
> - INTEL_DISPLAY_I85X,
> - INTEL_DISPLAY_I865G,
> - /* Display ver 3 */
> - INTEL_DISPLAY_I915G,
> - INTEL_DISPLAY_I915GM,
> - INTEL_DISPLAY_I945G,
> - INTEL_DISPLAY_I945GM,
> - INTEL_DISPLAY_G33,
> - INTEL_DISPLAY_PINEVIEW,
> - /* Display ver 4 */
> - INTEL_DISPLAY_I965G,
> - INTEL_DISPLAY_I965GM,
> - INTEL_DISPLAY_G45,
> - INTEL_DISPLAY_GM45,
> - /* Display ver 5 */
> - INTEL_DISPLAY_IRONLAKE,
> - /* Display ver 6 */
> - INTEL_DISPLAY_SANDYBRIDGE,
> - /* Display ver 7 */
> - INTEL_DISPLAY_IVYBRIDGE,
> - INTEL_DISPLAY_VALLEYVIEW,
> - INTEL_DISPLAY_HASWELL,
> - /* Display ver 8 */
> - INTEL_DISPLAY_BROADWELL,
> - INTEL_DISPLAY_CHERRYVIEW,
> - /* Display ver 9 */
> - INTEL_DISPLAY_SKYLAKE,
> - INTEL_DISPLAY_BROXTON,
> - INTEL_DISPLAY_KABYLAKE,
> - INTEL_DISPLAY_GEMINILAKE,
> - INTEL_DISPLAY_COFFEELAKE,
> - INTEL_DISPLAY_COMETLAKE,
> - /* Display ver 11 */
> - INTEL_DISPLAY_ICELAKE,
> - INTEL_DISPLAY_JASPERLAKE,
> - INTEL_DISPLAY_ELKHARTLAKE,
> - /* Display ver 12 */
> - INTEL_DISPLAY_TIGERLAKE,
> - INTEL_DISPLAY_ROCKETLAKE,
> - INTEL_DISPLAY_DG1,
> - INTEL_DISPLAY_ALDERLAKE_S,
> - /* Display ver 13 */
> - INTEL_DISPLAY_ALDERLAKE_P,
> - INTEL_DISPLAY_DG2,
> - /* Display ver 14 (based on GMD ID) */
> - INTEL_DISPLAY_METEORLAKE,
> - /* Display ver 20 (based on GMD ID) */
> - INTEL_DISPLAY_LUNARLAKE,
> - /* Display ver 14.1 (based on GMD ID) */
> - INTEL_DISPLAY_BATTLEMAGE,
> + INTEL_DISPLAY_PLATFORMS(ENUM)
> };
>
> +#undef ENUM
> +
> enum intel_display_subplatform {
> INTEL_DISPLAY_SUBPLATFORM_UNINITIALIZED = 0,
> INTEL_DISPLAY_HASWELL_ULT,
> --
> 2.39.2
>
Re: [PATCH 3/6] drm/i915/display: join the platform and subplatform macros
On Tue, Jun 18, 2024 at 05:22:53PM +0300, Jani Nikula wrote:
> We'll want to use the subplatforms similar to platforms.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_device.c | 2 +-
> .../drm/i915/display/intel_display_device.h | 51 +--
> 2 files changed, 25 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index d900c30907ac..80563af7ac71 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -21,7 +21,7 @@ __diag_push();
> __diag_ignore_all("-Woverride-init", "Allow field initialization overrides
> for display info");
>
> struct subplatform_desc {
> - enum intel_display_subplatform subplatform;
> + enum intel_display_platform subplatform;
> const char *name;
> const u16 *pciidlist;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index aca3dfd5e7af..50485235ef09 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -69,7 +69,29 @@ struct drm_printer;
> /* Display ver 20 (based on GMD ID) */ \
> func(LUNARLAKE) \
> /* Display ver 14.1 (based on GMD ID) */ \
> - func(BATTLEMAGE)
> + func(BATTLEMAGE) \
> + /* Subplatforms */ \
> + func(HASWELL_ULT) \
> + func(HASWELL_ULX) \
> + func(BROADWELL_ULT) \
> + func(BROADWELL_ULX) \
> + func(SKYLAKE_ULT) \
> + func(SKYLAKE_ULX) \
> + func(KABYLAKE_ULT) \
> + func(KABYLAKE_ULX) \
> + func(COFFEELAKE_ULT) \
> + func(COFFEELAKE_ULX) \
> + func(COMETLAKE_ULT) \
> + func(COMETLAKE_ULX) \
> + func(ICELAKE_PORT_F) \
> + func(TIGERLAKE_UY) \
> + func(ALDERLAKE_S_RAPTORLAKE_S) \
> + func(ALDERLAKE_P_ALDERLAKE_N) \
> + func(ALDERLAKE_P_RAPTORLAKE_P) \
> + func(ALDERLAKE_P_RAPTORLAKE_U) \
> + func(DG2_G10) \
> + func(DG2_G11) \
> + func(DG2_G12)
>
> #define ENUM(x) INTEL_DISPLAY_ ## x,
>
> @@ -79,31 +101,6 @@ enum intel_display_platform {
>
> #undef ENUM
>
> -enum intel_display_subplatform {
> - INTEL_DISPLAY_SUBPLATFORM_UNINITIALIZED = 0,
> - INTEL_DISPLAY_HASWELL_ULT,
> - INTEL_DISPLAY_HASWELL_ULX,
> - INTEL_DISPLAY_BROADWELL_ULT,
> - INTEL_DISPLAY_BROADWELL_ULX,
> - INTEL_DISPLAY_SKYLAKE_ULT,
> - INTEL_DISPLAY_SKYLAKE_ULX,
> - INTEL_DISPLAY_KABYLAKE_ULT,
> - INTEL_DISPLAY_KABYLAKE_ULX,
> - INTEL_DISPLAY_COFFEELAKE_ULT,
> - INTEL_DISPLAY_COFFEELAKE_ULX,
> - INTEL_DISPLAY_COMETLAKE_ULT,
> - INTEL_DISPLAY_COMETLAKE_ULX,
> - INTEL_DISPLAY_ICELAKE_PORT_F,
> - INTEL_DISPLAY_TIGERLAKE_UY,
> - INTEL_DISPLAY_ALDERLAKE_S_RAPTORLAKE_S,
> - INTEL_DISPLAY_ALDERLAKE_P_ALDERLAKE_N,
> - INTEL_DISPLAY_ALDERLAKE_P_RAPTORLAKE_P,
> - INTEL_DISPLAY_ALDERLAKE_P_RAPTORLAKE_U,
> - INTEL_DISPLAY_DG2_G10,
> - INTEL_DISPLAY_DG2_G11,
> - INTEL_DISPLAY_DG2_G12,
> -};
> -
> #define DEV_INFO_DISPLAY_FOR_EACH_FLAG(func) \
> /* Keep in alphabetical order */ \
> func(cursor_needs_physical); \
> @@ -203,7 +200,7 @@ enum intel_display_subplatform {
>
> struct intel_display_runtime_info {
> enum intel_display_platform platform;
> - enum intel_display_subplatform subplatform;
> + enum intel_display_platform subplatform;
>
> struct intel_display_ip_ver {
> u16 ver;
> --
> 2.39.2
>
Re: [PATCH 4/6] drm/i915/display: add "display is" structure with platform members
On Tue, Jun 18, 2024 at 05:22:54PM +0300, Jani Nikula wrote:
> Add a structure with a bitfield member for each platform and
> subplatform, and initialize them in platform and subplatform descs.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_display_device.h | 8
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 80563af7ac71..0c275d85bd30 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -21,6 +21,7 @@ __diag_push();
> __diag_ignore_all("-Woverride-init", "Allow field initialization overrides
> for display info");
>
> struct subplatform_desc {
> + struct intel_display_is is;
> enum intel_display_platform subplatform;
> const char *name;
> const u16 *pciidlist;
> @@ -28,9 +29,11 @@ struct subplatform_desc {
>
> #define SUBPLATFORM(_platform, _subplatform) \
> .subplatform = (INTEL_DISPLAY_##_platform##_##_subplatform),\
> - .name = #_subplatform
> + .name = #_subplatform, \
> + .is._platform##_##_subplatform = 1
>
> struct platform_desc {
> + struct intel_display_is is;
> enum intel_display_platform platform;
> const char *name;
> const struct subplatform_desc *subplatforms;
> @@ -39,7 +42,8 @@ struct platform_desc {
>
> #define PLATFORM(_platform) \
> .platform = (INTEL_DISPLAY_##_platform), \
> - .name = #_platform
> + .name = #_platform, \
> + .is._platform = 1
>
> #define ID(id) (id)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index 50485235ef09..73070c8487ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -101,6 +101,14 @@ enum intel_display_platform {
>
> #undef ENUM
>
> +#define MEMBER(name) u32 name:1;
> +
> +struct intel_display_is {
> + INTEL_DISPLAY_PLATFORMS(MEMBER);
> +};
> +
> +#undef MEMBER
> +
> #define DEV_INFO_DISPLAY_FOR_EACH_FLAG(func) \
> /* Keep in alphabetical order */ \
> func(cursor_needs_physical); \
> --
> 2.39.2
>
Re: [PATCH 6/6] drm/i915/display: remove the display platform enum as unnecessary
On Tue, Jun 18, 2024 at 05:22:56PM +0300, Jani Nikula wrote:
> The display platform enums are not really needed for anything. Remove.
>
Reviewed-by: Rodrigo Vivi
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 12 +++-
> drivers/gpu/drm/i915/display/intel_display_device.h | 11 ---
> 2 files changed, 3 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 954caea38005..6a71e7a8b686 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -22,26 +22,22 @@ __diag_ignore_all("-Woverride-init", "Allow field
> initialization overrides for d
>
> struct subplatform_desc {
> struct intel_display_is is;
> - enum intel_display_platform subplatform;
> const char *name;
> const u16 *pciidlist;
> };
>
> #define SUBPLATFORM(_platform, _subplatform) \
> - .subplatform = (INTEL_DISPLAY_##_platform##_##_subplatform),\
> .name = #_subplatform, \
> .is._platform##_##_subplatform = 1
>
> struct platform_desc {
> struct intel_display_is is;
> - enum intel_display_platform platform;
> const char *name;
> const struct subplatform_desc *subplatforms;
> const struct intel_display_device_info *info; /* NULL for GMD ID */
> };
>
> #define PLATFORM(_platform) \
> - .platform = (INTEL_DISPLAY_##_platform), \
> .name = #_platform, \
> .is._platform = 1
>
> @@ -1261,7 +1257,7 @@ find_subplatform_desc(struct pci_dev *pdev, const
> struct platform_desc *desc)
> const struct subplatform_desc *sp;
> const u16 *id;
>
> - for (sp = desc->subplatforms; sp && sp->subplatform; sp++)
> + for (sp = desc->subplatforms; sp && sp->pciidlist; sp++)
> for (id = sp->pciidlist; *id; id++)
> if (*id == pdev->device)
> return sp;
> @@ -1323,14 +1319,12 @@ void intel_display_device_probe(struct
> drm_i915_private *i915)
> &DISPLAY_INFO(i915)->__runtime_defaults,
> sizeof(*DISPLAY_RUNTIME_INFO(i915)));
>
> - drm_WARN_ON(&i915->drm, !desc->platform || !desc->name);
> - DISPLAY_RUNTIME_INFO(i915)->platform = desc->platform;
> + drm_WARN_ON(&i915->drm, !desc->name);
> display->is = desc->is;
>
> subdesc = find_subplatform_desc(pdev, desc);
> if (subdesc) {
> - drm_WARN_ON(&i915->drm, !subdesc->subplatform ||
> !subdesc->name);
> - DISPLAY_RUNTIME_INFO(i915)->subplatform = subdesc->subplatform;
> + drm_WARN_ON(&i915->drm, !subdesc->name);
> merge_display_is(&display->is, &subdesc->is);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index 73070c8487ff..97033d26c1b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -93,14 +93,6 @@ struct drm_printer;
> func(DG2_G11) \
> func(DG2_G12)
>
> -#define ENUM(x) INTEL_DISPLAY_ ## x,
> -
> -enum intel_display_platform {
> - INTEL_DISPLAY_PLATFORMS(ENUM)
> -};
> -
> -#undef ENUM
> -
> #define MEMBER(name) u32 name:1;
>
> struct intel_display_is {
> @@ -207,9 +199,6 @@ struct intel_display_is {
> (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
>
> struct intel_display_runtime_info {
> - enum intel_display_platform platform;
> - enum intel_display_platform subplatform;
> -
> struct intel_display_ip_ver {
> u16 ver;
> u16 rel;
> --
> 2.39.2
>
Re: [PATCH 5/6] drm/i915/display: add "is" member to struct intel_display
On Tue, Jun 18, 2024 at 05:22:55PM +0300, Jani Nikula wrote:
> Facilitate using display->is.HASWELL etc. for identifying platforms and
> subplatforms. Merge platform and subplatform members together.
>
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_display_core.h | 3 +++
> .../drm/i915/display/intel_display_device.c | 19 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index 7715fc329057..35bea92893af 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -286,6 +286,9 @@ struct intel_display {
> /* drm device backpointer */
> struct drm_device *drm;
>
> + /* Platform identification */
> + struct intel_display_is is;
> +
> /* Display functions */
> struct {
> /* Top level crtc-ish functions */
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 0c275d85bd30..954caea38005 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -1269,8 +1269,25 @@ find_subplatform_desc(struct pci_dev *pdev, const
> struct platform_desc *desc)
> return NULL;
> }
>
> +static void mem_or(void *_dst, const void *_src, size_t size)
> +{
> + const u8 *src = _src;
> + u8 *dst = _dst;
> + size_t i;
> +
> + for (i = 0; i < size; i++)
> + dst[i] |= src[i];
I confess that here I got a bit lost. But I believe it is just a matter of
adding a few comments in the code or perhaps adjusting function names...
If my coffee is working well still, what we are doing here is ensuring that:
is.HASWELL returns true regardless the subplatform this is coming from...
like is.HASWELL_ULT or is.HASWELL_ULX.
But since you are only doing dst |= src and not doing src |= dst and also
not calling this function for different subplatforms, then individually
is.HASWELL_ULT is false for ULX platform and vice-versa.
Perhaps the name 'merge' is not a good one?
> +}
> +
> +static void merge_display_is(struct intel_display_is *dst,
> + const struct intel_display_is *src)
> +{
> + mem_or(dst, src, sizeof(*dst));
and/or perhaps we don't need this extra indirection here?
> +}
> +
> void intel_display_device_probe(struct drm_i915_private *i915)
> {
> + struct intel_display *display = &i915->display;
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> const struct intel_display_device_info *info;
> struct intel_display_ip_ver ip_ver = {};
> @@ -1308,11 +1325,13 @@ void intel_display_device_probe(struct
> drm_i915_private *i915)
>
> drm_WARN_ON(&i915->drm, !desc->platform || !desc->name);
> DISPLAY_RUNTIME_INFO(i915)->platform = desc->platform;
> + display->is = desc->is;
>
> subdesc = find_subplatform_desc(pdev, desc);
> if (subdesc) {
> drm_WARN_ON(&i915->drm, !subdesc->subplatform ||
> !subdesc->name);
> DISPLAY_RUNTIME_INFO(i915)->subplatform = subdesc->subplatform;
> + merge_display_is(&display->is, &subdesc->is);
> }
>
> if (ip_ver.ver || ip_ver.rel || ip_ver.step)
> --
> 2.39.2
>
Re: [PATCH v2 0/9] drm/i915: Polish plane surface alignment handling
On Wed, Jun 19, 2024 at 07:53:23PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 19, 2024 at 02:38:16PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > intel_surf_alignment() in particular has devolved into
> > > a complete mess. Redesign the code so that we can handle
> > > alignment restrictions in a nicer. Also adjust alignment
> > > for TGL+ to actually match the hardware requirements.
> > >
> > > v2: Drop the per-plane vma stuff as it was borked
> > > Don't temporarily remove the 2MiB DPT alignment for UV on TGL
> > >
> > > Ville Syrjälä (9):
> > > drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()
> > > drm: Export drm_plane_has_format()
> >
> > Maarten/Maxime/Thomas, can I get an ack for merging these via
> > drm-intel please?
> >
> > > drm/i915: Introduce the plane->min_alignment() vfunc
> > > drm/i915: Introduce fb->min_alignment
> > > drm/i915: Split cursor alignment to per-platform vfuncs
> > > drm/i915: Split pre-skl platforms out from intel_surf_alignment()
> > > drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c
> > > drm/i915: Update plane alignment requirements for TGL+
> > > drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff
> > >
> > > drivers/gpu/drm/drm_atomic.c | 7 +-
> > > drivers/gpu/drm/drm_crtc.c| 6 +-
> > > drivers/gpu/drm/drm_crtc_internal.h | 2 -
> > > drivers/gpu/drm/drm_plane.c | 23 ++-
> > > drivers/gpu/drm/i915/display/i9xx_plane.c | 75 -
> > > drivers/gpu/drm/i915/display/intel_cursor.c | 38 +
> > > .../drm/i915/display/intel_display_types.h| 5 +
> > > drivers/gpu/drm/i915/display/intel_fb.c | 151 --
> > > drivers/gpu/drm/i915/display/intel_fb.h | 3 -
> > > drivers/gpu/drm/i915/display/intel_fb_pin.c | 39 +++--
> > > drivers/gpu/drm/i915/display/intel_fb_pin.h | 3 +-
> > > drivers/gpu/drm/i915/display/intel_fbdev.c| 5 +-
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 26 +++
> > > .../drm/i915/display/skl_universal_plane.c| 85 +-
> > > drivers/gpu/drm/xe/display/xe_fb_pin.c| 3 +-
> > > drivers/gpu/drm/xe/display/xe_plane_initial.c | 4 +-
> >
> > Lucas, can you give me an ack for the merging the xe
> > changes via drm-intel?
>
> Apparently Lucas is out. Rodrigo, can you ack this?
I wonder if we should start using some tag like
drm/{i915,xe}/display: or drm/{i915,xe}:
in cases like this, to make it easier to spot the patches
that are touching both sides...
anyway, that was just a random thought while seeing this and
searching for the actual patch to ack...
Acked-by: Rodrigo Vivi
them all...
>
> >
> > > include/drm/drm_plane.h | 2 +
> > > 17 files changed, 309 insertions(+), 168 deletions(-)
> > >
> > > --
> > > 2.44.2
> >
> > --
> > Ville Syrjälä
> > Intel
>
> --
> Ville Syrjälä
> Intel
✗ Fi.CI.IGT: failure for drm/i915: Polish plane surface alignment handling (rev3)
== Series Details == Series: drm/i915: Polish plane surface alignment handling (rev3) URL : https://patchwork.freedesktop.org/series/133564/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14972_full -> Patchwork_133564v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_133564v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_133564v3_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 (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_133564v3_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@pi@vecs0: - shard-dg2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg2-8/igt@gem_exec_capture@p...@vecs0.html Known issues Here are the changes found in Patchwork_133564v3_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-purge-cache: - shard-dg1: NOTRUN -> [SKIP][2] ([i915#8411]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg1-15/igt@api_intel...@object-reloc-purge-cache.html * igt@api_intel_bb@render-ccs: - shard-dg2: NOTRUN -> [FAIL][3] ([i915#10380]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg2-8/igt@api_intel...@render-ccs.html * igt@drm_fdinfo@busy-hang@bcs0: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#8414]) +13 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg2-2/igt@drm_fdinfo@busy-h...@bcs0.html * igt@drm_fdinfo@busy-idle-check-all@ccs0: - shard-mtlp: NOTRUN -> [SKIP][5] ([i915#8414]) +5 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-mtlp-5/igt@drm_fdinfo@busy-idle-check-...@ccs0.html * igt@drm_fdinfo@isolation@vecs0: - shard-dg1: NOTRUN -> [SKIP][6] ([i915#8414]) +5 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg1-15/igt@drm_fdinfo@isolat...@vecs0.html * igt@gem_ccs@block-multicopy-compressed: - shard-dg1: NOTRUN -> [SKIP][7] ([i915#9323]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg1-18/igt@gem_...@block-multicopy-compressed.html * igt@gem_ccs@suspend-resume: - shard-mtlp: NOTRUN -> [SKIP][8] ([i915#9323]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-mtlp-5/igt@gem_...@suspend-resume.html * igt@gem_exec_balancer@bonded-dual: - shard-mtlp: NOTRUN -> [SKIP][9] ([i915#4771]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-mtlp-5/igt@gem_exec_balan...@bonded-dual.html - shard-dg2: NOTRUN -> [SKIP][10] ([i915#4771]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg2-8/igt@gem_exec_balan...@bonded-dual.html * igt@gem_exec_balancer@bonded-pair: - shard-dg1: NOTRUN -> [SKIP][11] ([i915#4771]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg1-15/igt@gem_exec_balan...@bonded-pair.html * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-rkl: NOTRUN -> [SKIP][12] ([i915#4525]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-rkl-1/igt@gem_exec_balan...@parallel-keep-in-fence.html * igt@gem_exec_fair@basic-deadline: - shard-glk: NOTRUN -> [FAIL][13] ([i915#2846]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-glk3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none: - shard-dg1: NOTRUN -> [SKIP][14] ([i915#3539] / [i915#4852]) +3 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg1-15/igt@gem_exec_f...@basic-none.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: NOTRUN -> [FAIL][15] ([i915#2842]) +1 other test fail [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fence@submit3: - shard-dg2: NOTRUN -> [SKIP][16] ([i915#4812]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-dg2-8/igt@gem_exec_fe...@submit3.html - shard-mtlp: NOTRUN -> [SKIP][17] ([i915#4812]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133564v3/shard-mtlp-5/igt@gem_exec_fe...@submit3.html * igt@gem_exec_flush@basic-batch-kernel-default-uc:
RE: [PATCH v3] drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
> -Original Message-
> From: Intel-gfx On Behalf Of Mitul
> Golani
> Sent: Wednesday, June 19, 2024 4:08 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v3] drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc
> clock
>
> The dispcnlunit1_cp_xosc_clk should be de-asserted in display off and only
> asserted in display on. But during observation it found clk remains active in
> display
> OFF. As workaround, Display driver shall execute set-reset sequence at the
> end of
> the Initialize Sequence.
>
> Wa_15013987218
>
> Signed-off-by: Mitul Golani
Reviewed-by: Nemesa Garg
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index e288a1b21d7e..aef54c1a2ba9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1704,6 +1704,14 @@ static void icl_display_core_init(struct
> drm_i915_private *dev_priv,
> /* Wa_14011503030:xelpd */
> if (DISPLAY_VER(dev_priv) == 13)
> intel_de_write(dev_priv, XELPD_DISPLAY_ERR_FATAL_MASK,
> ~0);
> +
> + /* Wa_15013987218 */
> + if (DISPLAY_VER(dev_priv) == 20) {
> + intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D,
> +PCH_GMBUSUNIT_CLOCK_GATE_DISABLE);
Nit: we can replace the above statement with this intel_de_rmw(dev_priv,
SOUTH_DSPCLK_GATE_D, 0, PCH_GMBUSUNIT_CLOCK_GATE_DISABLE) so that code
consistency can be maintained in the code block.
otherwise LGTM.
> + intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
> + PCH_GMBUSUNIT_CLOCK_GATE_DISABLE, 0);
> + }
> }
>
> static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
> --
> 2.45.2
✓ Fi.CI.BAT: success for Panel Replay eDP support (rev10)
== Series Details ==
Series: Panel Replay eDP support (rev10)
URL : https://patchwork.freedesktop.org/series/133684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14967 -> Patchwork_133684v10
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/index.html
Participating hosts (43 -> 42)
--
Additional (2): fi-tgl-1115g4 fi-kbl-8809g
Missing(3): bat-kbl-2 bat-arls-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_133684v10 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([i915#9318])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][4] ([i915#4613]) +3 other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#4103]) +1 other test skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_dsc@dsc-basic:
- fi-kbl-8809g: NOTRUN -> [SKIP][7] +30 other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-kbl-8809g/igt@kms_...@dsc-basic.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#3555] / [i915#3840])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4: NOTRUN -> [SKIP][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@hang-read-crc@pipe-b-dp-1:
- bat-dg2-8: [PASS][10] -> [FAIL][11] ([i915#11379])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-dg2-8/igt@kms_pipe_crc_basic@hang-read-...@pipe-b-dp-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-dg2-8/igt@kms_pipe_crc_basic@hang-read-...@pipe-b-dp-1.html
* igt@kms_pm_backlight@basic-brightness:
- fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#9812])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_pm_backli...@basic-brightness.html
* igt@kms_psr@psr-primary-page-flip:
- fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([i915#9732]) +3 other tests skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_...@psr-primary-page-flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#3555])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {bat-mtlp-9}: [FAIL][15] ([i915#11395]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-mtlp-9/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-mtlp-9/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {bat-mtlp-9}: [DMESG-FAIL][17] ([i915#11009]) -> [PASS][18] +1
other test pass
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-mtlp-9/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-mtlp-9/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- {bat-mtlp-9}: [DMESG-WARN][19] ([i915#11009]) -> [PASS][20] +1
other test pass
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14967/bat-mtlp-9/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_133684v10/bat-mtlp-9/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_cursor_legacy@basic-flip-be
✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Move encoder suspend/shutdown helpers to intel_encoder.c
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move encoder suspend/shutdown helpers to intel_encoder.c URL : https://patchwork.freedesktop.org/series/135014/ State : success == Summary == CI Bug Log - changes from CI_DRM_14963 -> Patchwork_135014v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/index.html Participating hosts (42 -> 41) -- Additional (3): fi-cfl-8109u bat-mtlp-8 fi-elk-e7500 Missing(4): bat-kbl-2 bat-jsl-1 fi-snb-2520m fi-kbl-8809g Known issues Here are the changes found in Patchwork_135014v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#9318]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4613]) +3 other tests skip [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][4] ([i915#4613]) +3 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#4083]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@gem_m...@basic.html * igt@gem_render_tiled_blits@basic: - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#4079]) +1 other test skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#4077]) +2 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@gem_tiled_fence_bl...@basic.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#6621]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#5190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4212]) +8 other tests skip [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#4213]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - fi-cfl-8109u: NOTRUN -> [SKIP][12] +11 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/fi-cfl-8109u/igt@kms_...@dsc-basic.html - bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840] / [i915#9159]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-mtlp-8: NOTRUN -> [SKIP][14] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#5274]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-mtlp-8/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-hdmi-a-1: - fi-elk-e7500: NOTRUN -> [SKIP][16] +24 other tests skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/fi-elk-e7500/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-hdmi-a-1.html * igt@kms_pipe_crc_basic@hang-read-crc@pipe-b-dp-1: - bat-dg2-8: [PASS][17] -> [FAIL][18] ([i915#11379]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14963/bat-dg2-8/igt@kms_pipe_crc_basic@hang-read-...@pipe-b-dp-1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135014v1/bat-dg2-8/igt@kms_pipe_crc_basic@hang-read-...@pipe-b-dp-1.html * igt@kms_psr@psr-primary-mmap-gtt@
