RE: [PATCH] drm/i915/psr: Implment WA to help reach PC10
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, September 9, 2024 12:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Hogander, Jouni
> ; Deak, Imre ; Kandpal, Suraj
>
> Subject: [PATCH] drm/i915/psr: Implment WA to help reach PC10
Not: Typo in implement
> To reach PC10 when PKG_C_LATENCY is configure we must do the following
> things
> 1) Enter PSR1 only when delayed_vblank < 6 lines and DC5 can be entered
> 2) Allow PSR2 deep sleep when DC5 can be entered
> 3) DC5 can be entered when all transocoder have either PSR1, PSR2 or eDP 1.5
> PR
> ALPM enabled and VBI is disabled and flips and pushes are not happening.
>
> --v2
> -Switch condition and do an early return [Jani] -Do some checks in
> compute_config [Jani] -Do not use register reads as a method of checking
> states
> for DPKGC or delayed vblank [Jani] -Use another way to see is vblank
> interrupts
> are disabled or not [Jani]
>
> --v3
> -Use has_psr to check if psr can be enabled or not for dc5_entry cond [Uma] -
> Move the dc5 entry computation to psr_compute_config [Jouni] -No need to
> change sequence of enabled and activate, so dont make hsw_psr1_activate
> return anything [Jouni] -Use has_psr to stop psr1 activation [Jouni] -Use
> lineage
> no. in WA -Add the display ver restrictions for WA
>
> --v4
> -use more appropriate name for check_vblank_limit() [Jouni] -Cover the case
> for
> idle frames when dpkgc is not configured [Jouni] -Check psr only for edp
> [Jouni]
>
> --v5
> -move psr1 handling to plane update [Jouni] -add todo for cases when vblank is
> enabled when psr enabled [Jouni] -use intel_display instead of
> drm_i915_private
>
> --v6
> -check target_dc_state [Jouni]
> -fix condition in pre/post plane update [Jouni]
>
> WA: 22019444797
> Signed-off-by: Suraj Kandpal
> ---
> .../drm/i915/display/intel_display_types.h| 3 +
> drivers/gpu/drm/i915/display/intel_psr.c | 112 +-
> 2 files changed, 114 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 733de5edcfdb..59c81f0a3abd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1577,6 +1577,9 @@ struct intel_psr {
> #define I915_PSR_DEBUG_PANEL_REPLAY_DISABLE 0x40
>
> u32 debug;
> + bool is_dpkgc_configured;
> + bool is_dc5_entry_possible;
> + bool is_wa_delayed_vblank_limit;
> bool sink_support;
> bool source_support;
> bool enabled;
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b30fa067ce6e..e50b476494a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_drv.h"
> #include "i915_reg.h"
> @@ -874,6 +875,78 @@ static u8 psr_compute_idle_frames(struct intel_dp
> *intel_dp)
> return idle_frames;
> }
>
> +static bool
> +intel_psr_check_wa_delayed_vblank(const struct drm_display_mode
> +*adjusted_mode) {
> + return (adjusted_mode->crtc_vblank_start -
> +adjusted_mode->crtc_vdisplay) >= 6; }
> +
> +/*
> + * PKG_C_LATENCY is configured only when DISPLAY_VER >= 20 and
> + * VRR is not enabled
> + */
> +static bool intel_psr_is_dpkgc_configured(struct intel_display *display,
> + struct intel_atomic_state *state) {
> + struct intel_crtc *intel_crtc;
> + struct intel_crtc_state *crtc_state;
> + int i;
> +
> + if (DISPLAY_VER(display) < 20)
> + return false;
> +
> + for_each_new_intel_crtc_in_state(state, intel_crtc, crtc_state, i) {
> + if (!intel_crtc->active)
> + continue;
> +
> + if (crtc_state->vrr.enable)
> + return false;
> + }
> +
> + return true;
> +}
> +
> +/*
> + * DC5 entry is only possible if vblank interrupt is disabled
> + * and either psr1, psr2, edp 1.5 pr alpm is enabled on all
> + * enabled encoders.
> + */
> +static bool
> +intel_psr_is_dc5_entry_possible(struct intel_display *display,
> + struct intel_atomic_state *state)
> +{
> + struct intel_crtc *intel_crtc;
> + struct intel_crtc_state *crtc_state;
> + int i;
> +
> + if ((display->power.domains.target_dc_state &
> + DC_STATE_EN_UPTO_DC5_DC6_MASK)
RE: [PATCH 3/5] Add crtc properties for global histogram
> -Original Message-
> From: Intel-gfx On Behalf Of Arun R
> Murthy
> Sent: Friday, July 5, 2024 3:26 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R
> Subject: [PATCH 3/5] Add crtc properties for global histogram
>
> CRTC properties have been added for enable/disable histogram, reading the
> histogram data and writing the IET data.
> "HISTOGRAM_EN" is the crtc property to enable/disable the global histogram and
> takes a value 0/1 accordingly.
> "Histogram" is a crtc property to read the binary histogram data.
> "Global IET" is a crtc property to write the IET binary LUT data.
+ CC'ing Abhinav from QC
Hi Abhinav,
As discussed in Display Hackfest, can you please share your thoughts and inputs
on this series.
Thanks & Regards,
Uma Shankar
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 5 +
> drivers/gpu/drm/i915/display/intel_crtc.c | 202 +-
> drivers/gpu/drm/i915/display/intel_crtc.h | 5 +
> drivers/gpu/drm/i915/display/intel_display.c | 13 ++
> .../drm/i915/display/intel_display_types.h| 17 ++
> .../gpu/drm/i915/display/intel_histogram.c| 1 +
> 6 files changed, 242 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 76aa10b6f647..693a22089937 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -246,6 +246,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>
> __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->uapi);
>
> + if (crtc_state->global_iet)
> + drm_property_blob_get(crtc_state->global_iet);
> /* copy color blobs */
> if (crtc_state->hw.degamma_lut)
> drm_property_blob_get(crtc_state->hw.degamma_lut);
> @@ -277,6 +279,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> crtc_state->fb_bits = 0;
> crtc_state->update_planes = 0;
> crtc_state->dsb = NULL;
> + crtc_state->histogram_en_changed = false;
>
> return &crtc_state->uapi;
> }
> @@ -312,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
>
> drm_WARN_ON(crtc->dev, crtc_state->dsb);
>
> + if (crtc_state->global_iet)
> + drm_property_blob_put(crtc_state->global_iet);
> __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
> intel_crtc_free_hw_state(crtc_state);
> if (crtc_state->dp_tunnel_ref.tunnel)
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 1b578cad2813..24f160359422 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_vgpu.h"
> #include "i9xx_plane.h"
> @@ -26,6 +27,7 @@
> #include "intel_drrs.h"
> #include "intel_dsi.h"
> #include "intel_fifo_underrun.h"
> +#include "intel_histogram.h"
> #include "intel_pipe_crc.h"
> #include "intel_psr.h"
> #include "intel_sprite.h"
> @@ -201,6 +203,7 @@ static struct intel_crtc *intel_crtc_alloc(void) static
> void
> intel_crtc_free(struct intel_crtc *crtc) {
> intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> + intel_histogram_deinit(crtc);
> kfree(crtc);
> }
>
> @@ -220,6 +223,100 @@ static int intel_crtc_late_register(struct drm_crtc
> *crtc)
> return 0;
> }
>
> +static int intel_crtc_get_property(struct drm_crtc *crtc,
> +const struct drm_crtc_state *state,
> +struct drm_property *property,
> +uint64_t *val)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc->dev);
> + const struct intel_crtc_state *intel_crtc_state =
> + to_intel_crtc_state(state);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +
> + if (property == intel_crtc->histogram_en_property) {
> + *val = intel_crtc_state->histogram_en;
> + } else if (property == intel_crtc->global_iet_property) {
> + *val = (intel_crtc_state->global_iet) ?
> + intel_crtc_state->global_iet->base.id : 0;
> + } else if (property == intel_crtc->histogram_property) {
> + *val = (intel_crtc_state->histogram) ?
> + intel_crtc_state->histogram->base.id : 0;
> + } else {
> + drm_err(&i915->drm,
> + "Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +intel_atomic_replace_property_blob_from_id(struct drm_device *dev,
> +struct drm_property_blob **blob,
> +u64 blob_id,
> +ssize_t expected_s
RE: [1/5] drm: Introduce sharpness mode property
> -Original Message-
> From: Intel-gfx On Behalf Of Nemesa
> Garg
> Sent: Monday, July 8, 2024 1:39 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Garg, Nemesa
> Subject: [1/5] drm: Introduce sharpness mode property
Nit: Rename it to sharpness strength instead of mode.
> Introduces the new crtc property "SHARPNESS_STRENGTH" that allows the user
> to set the intensity so as to get the sharpness effect.
> The value of this property can be set from 0-255.
> It is useful in scenario when the output is blurry and user want to sharpen
> the
> pixels. User can increase/decrease the sharpness level depending on the
> content
> displayed.
>
> Signed-off-by: Nemesa Garg
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_crtc.c| 35 +++
> include/drm/drm_crtc.h| 17 +++
> 3 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 22bbb2d83e30..825640ab39f6 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -417,6 +417,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> } else if (property == crtc->scaling_filter_property) {
> state->scaling_filter = val;
> + } else if (property == crtc->sharpness_strength_prop) {
Agree with Arun, spell property fully for consistency.
> + state->sharpness_strength = val;
> } else if (crtc->funcs->atomic_set_property) {
> return crtc->funcs->atomic_set_property(crtc, state, property,
> val);
> } else {
> @@ -454,6 +456,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = 0;
> else if (property == crtc->scaling_filter_property)
> *val = state->scaling_filter;
> + else if (property == crtc->sharpness_strength_prop)
> + *val = state->sharpness_strength;
> else if (crtc->funcs->atomic_get_property)
> return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> else {
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index
> 3488ff067c69..4ff18786a226 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -229,6 +229,24 @@ struct dma_fence *drm_crtc_create_fence(struct
> drm_crtc *crtc)
> * Driver's default scaling filter
> * Nearest Neighbor:
> * Nearest Neighbor scaling filter
> + * SHARPNESS_STRENGTH:
> + * Atomic property for setting the sharpness strength/intensity by
> userspace.
> + *
> + * The value of this property is set as an integer value ranging
> + * from 0 - 255 where:
> + *
> + * 0 means feature is disabled.
> + *
> + * 1 means minimum sharpness.
> + *
> + * 255 means maximum sharpness.
> + *
> + * User can gradually increase or decrease the sharpness level and can
> + * set the optimum value depending on content and this value will be
> + * passed to kernel through the Uapi.
> + * The sharpness effect takes place post blending on the final composed
> output.
> + * If the feature is disabled, the content remains same without any
> sharpening effect
> + * and when this feature is applied, it enhances the clarity of the
> content.
Can you also mention the modeset requirement that this can be done with no
modeset
and can be managed as normal flip.
> */
>
> __printf(6, 0)
> @@ -939,3 +957,20 @@ int drm_crtc_create_scaling_filter_property(struct
> drm_crtc *crtc,
> return 0;
> }
> EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
> +
> +int drm_crtc_create_sharpness_strength_property(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> +
> + struct drm_property *prop =
> + drm_property_create_range(dev, 0, "SHARPNESS_STRENGTH", 0,
> 255);
> +
> + if (!prop)
> + return -ENOMEM;
> +
> + crtc->sharpness_strength_prop = prop;
> + drm_object_attach_property(&crtc->base, prop, 0);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_crtc_create_sharpness_strength_property);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> 8b48a1974da3..1cdca5c82753 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -317,6 +317,16 @@ struct drm_crtc_state {
>*/
> enum drm_scaling_filter scaling_filter;
>
> + /**
> + * @sharpness_strength
> + *
> + * Used by the user to set the sharpness intensity.
> + * The value ranges from 0-255.
> + * Any value greater than 0 means enabling the featuring
> + * along with setting the value for sharpness.
> + */
> + u8 sharpness_strength;
> +
> /**
>* @event:
>*
> @@ -1088,6 +1098,12 @@ struct drm_crtc {
>*/
> struct drm_property *scaling_filter_property;
>
RE: [PATCH] drm/i915: Fix readout degamma_lut mismatch on ilk/snb
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, July 10, 2024 6:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org
> Subject: [PATCH] drm/i915: Fix readout degamma_lut mismatch on ilk/snb
>
> From: Ville Syrjälä
>
> On ilk/snb the pipe may be configured to place the LUT before or after the CSC
> depending on various factors, but as there is only one LUT (no split mode
> like on
> IVB+) we only advertise a gamma_lut and no degamma_lut in the uapi to avoid
> confusing userspace.
>
> This can cause a problem during readout if the VBIOS/GOP enabled the LUT in
> the
> pre CSC configuration. The current code blindly assigns the results of the
> readout
> to the degamma_lut, which will cause a failure during the next atomic_check()
> as
> we aren't expecting anything to be in degamma_lut since it's not visible to
> userspace.
>
> Fix the problem by assigning whatever LUT we read out from the hardware into
> gamma_lut.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: sta...@vger.kernel.org
> Fixes: d2559299d339 ("drm/i915: Make ilk_read_luts() capable of degamma
> readout")
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11608
> Signed-off-by: Ville Syrjälä
> ---
> .../drm/i915/display/intel_modeset_setup.c| 31 ---
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> index 7602cb30ebf1..e1213f3d93cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> @@ -326,6 +326,8 @@ static void
> intel_modeset_update_connector_atomic_state(struct drm_i915_private
>
> static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> *crtc_state)
> {
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> if (intel_crtc_is_joiner_secondary(crtc_state))
> return;
>
> @@ -337,11 +339,30 @@ static void intel_crtc_copy_hw_to_uapi_state(struct
> intel_crtc_state *crtc_state
> crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
> crtc_state->uapi.scaling_filter = crtc_state->hw.scaling_filter;
>
> - /* assume 1:1 mapping */
> - drm_property_replace_blob(&crtc_state->hw.degamma_lut,
> - crtc_state->pre_csc_lut);
> - drm_property_replace_blob(&crtc_state->hw.gamma_lut,
> - crtc_state->post_csc_lut);
> + if (DISPLAY_INFO(i915)->color.degamma_lut_size) {
> + /* assume 1:1 mapping */
> + drm_property_replace_blob(&crtc_state->hw.degamma_lut,
> + crtc_state->pre_csc_lut);
> + drm_property_replace_blob(&crtc_state->hw.gamma_lut,
> + crtc_state->post_csc_lut);
> + } else {
> + /*
> + * ilk/snb hw may be configured for either pre_csc_lut
> + * or post_csc_lut, but we don't advertise degamma_lut as
> + * being available in the uapi since there is only one
> + * hardware LUT. Always assign the result of the readout
> + * to gamma_lut as that is the only valid source of LUTs
> + * in the uapi.
> + */
> + drm_WARN_ON(&i915->drm, crtc_state->post_csc_lut &&
> + crtc_state->pre_csc_lut);
> +
> + drm_property_replace_blob(&crtc_state->hw.degamma_lut,
> + NULL);
> + drm_property_replace_blob(&crtc_state->hw.gamma_lut,
> + crtc_state->post_csc_lut ?:
> + crtc_state->pre_csc_lut);
> + }
>
> drm_property_replace_blob(&crtc_state->uapi.degamma_lut,
> crtc_state->hw.degamma_lut);
> --
> 2.44.2
RE: [PATCH 2/2] drm/i915/psr: Implment WA to help reach PC10
> -Original Message-
> From: Intel-gfx On Behalf Of Suraj
> Kandpal
> Sent: Wednesday, June 19, 2024 10:08 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Murthy, Arun R
> ; Hogander, Jouni ;
> jani.nik...@linux.intel.com; Kandpal, Suraj
> Subject: [PATCH 2/2] drm/i915/psr: Implment WA to help reach PC10
Nit: Typo in Implement
> To reach PC10 when PKG_C_LATENCY is configure we must do the following
> things
> 1) Enter PSR1 only when delayed_vblank < 6 lines and DC5 can be entered
> 2) Allow PSR2 deep sleep when DC5 can be entered
> 3) DC5 can be entered when all transocoder have either PSR1, PSR2 or eDP 1.5
> PR
> ALPM enabled and VBI is disabled and flips and pushes are not happening.
>
> --v2
> -Switch condition and do an early return [Jani] -Do some checks in
> compute_config [Jani] -Do not use register reads as a method of checking
> states
> for DPKGC or delayed vblank [Jani] -Use another way to see is vblank
> interrupts
> are disabled or not [Jani]
>
> WA: 16023497226
> Signed-off-by: Suraj Kandpal
> ---
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_psr.c | 82 ++-
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 46b3cbeb4a82..031f8e889b65 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1708,6 +1708,8 @@ struct intel_psr {
> bool sink_support;
> bool source_support;
> bool enabled;
> + bool delayed_vblank;
> + bool is_dpkgc_configured;
> bool paused;
> enum pipe pipe;
> enum transcoder transcoder;
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 080bf5e51148..4ddea6737386 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -808,6 +808,73 @@ static u8 psr_compute_idle_frames(struct intel_dp
> *intel_dp)
> return idle_frames;
> }
>
> +static bool intel_psr_check_delayed_vblank_limit(struct
> +intel_crtc_state *crtc_state) {
> + struct drm_display_mode *adjusted_mode =
> +&crtc_state->hw.adjusted_mode;
> +
> + return (adjusted_mode->crtc_vblank_start -
> +adjusted_mode->crtc_vdisplay) >= 6; }
> +
> +/*
> + * PKG_C_LATENCY is configured only when DISPLAY_VER >= 20 and
> + * VRR is not enabled
> + */
> +static bool intel_psr_is_dpkgc_configured(struct drm_i915_private
> +*i915) {
> + struct intel_crtc *intel_crtc;
> +
> + if (DISPLAY_VER(i915) < 20)
> + return false;
> +
> + for_each_intel_crtc(&i915->drm, intel_crtc) {
> + struct intel_crtc_state *crtc_state;
> +
> + if (!intel_crtc->active)
> + continue;
> +
> + crtc_state = intel_crtc->config;
> +
> + if (crtc_state->vrr.enable)
> + return false;
> + }
> +
> + return true;
> +}
> +
> +/*
> + * DC5 entry is only possible if vblank interrupt is disabled
> + * and either psr1, psr2, edp 1.5 pr alpm is enabled on all
> + * enabled encoders.
> + */
> +static bool intel_psr_is_dc5_entry_possible(struct drm_i915_private
> +*i915) {
> + struct intel_crtc *intel_crtc;
> +
> + for_each_intel_crtc(&i915->drm, intel_crtc) {
> + struct intel_encoder *encoder;
> + struct drm_crtc *crtc = &intel_crtc->base;
> + struct drm_vblank_crtc *vblank;
> +
> + if (!intel_crtc->active)
> + continue;
> +
> + vblank = drm_crtc_vblank_crtc(crtc);
> +
> + if (vblank->enabled)
> + return false;
> +
> + for_each_encoder_on_crtc(&i915->drm, crtc, encoder) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
All encoders on crtc may not be of type DP, need to be handled here.
> + struct intel_psr *psr = &intel_dp->psr;
> +
> + if (!psr->enabled)
> + return false;
> + }
> + }
> +
> + return true;
> +}
> +
> static bool hsw_activate_psr1(struct intel_dp *intel_dp) {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); @@ -815,6
> +882,14 @@ static bool hsw_activate_psr1(struct intel_dp *intel_dp)
> u32 max_sleep_time = 0x1f;
> u32 val = EDP_PSR_ENABLE;
>
> + /* WA: 16023497226*/
> + if (intel_dp->psr.is_dpkgc_configured &&
> + (intel_dp->psr.delayed_vblank ||
> intel_psr_is_dc5_entry_possible(dev_priv))) {
In intel_psr_is_dc5_entry_possible function we use psr->enabled and based on
that deciding
to return from PSR1 activate, logic looks suspicious. Can you re-check once.
> + drm_dbg_kms(&dev_priv->drm,
> + "PSR1 not activated as it doesn't meet require
RE: [PATCH 1/2] drm/i915/psr: Add return bool value for hsw_activate_psr1
> -Original Message-
> From: Intel-gfx On Behalf Of Suraj
> Kandpal
> Sent: Wednesday, June 19, 2024 10:08 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Murthy, Arun R
> ; Hogander, Jouni ;
> jani.nik...@linux.intel.com; Kandpal, Suraj
> Subject: [PATCH 1/2] drm/i915/psr: Add return bool value for hsw_activate_psr1
>
> Convert hsw_activate_psr1 from void to bool as going forward there is a chance
> psr1 is not enabled.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 920186c2264d..080bf5e51148 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -808,7 +808,7 @@ static u8 psr_compute_idle_frames(struct intel_dp
> *intel_dp)
> return idle_frames;
> }
>
> -static void hsw_activate_psr1(struct intel_dp *intel_dp)
> +static bool hsw_activate_psr1(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> enum transcoder cpu_transcoder = intel_dp->psr.transcoder; @@ -836,6
> +836,8 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
>
> intel_de_rmw(dev_priv, psr_ctl_reg(dev_priv, cpu_transcoder),
>~EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK, val);
> +
> + return true;
> }
>
> static u32 intel_psr2_get_tp_time(struct intel_dp *intel_dp) @@ -1560,6
> +1562,7 @@ static void intel_psr_activate(struct intel_dp *intel_dp) {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> + bool ret = true;
>
> drm_WARN_ON(&dev_priv->drm,
> transcoder_has_psr2(dev_priv, cpu_transcoder) && @@ -
> 1578,9 +1581,9 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
> else if (intel_dp->psr.sel_update_enabled)
> hsw_activate_psr2(intel_dp);
> else
> - hsw_activate_psr1(intel_dp);
> + ret = hsw_activate_psr1(intel_dp);
>
> - intel_dp->psr.active = true;
> + intel_dp->psr.active = ret;
> }
>
> static u32 wa_16013835468_bit_get(struct intel_dp *intel_dp)
> --
> 2.43.2
RE: [v4] drm/xe/fbdev: Limit the usage of stolen for LNL+
> -Original Message-
> From: Shankar, Uma
> Sent: Wednesday, July 17, 2024 1:53 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Ceraolo Spurio, Daniele
> ; Belgaumkar, Vinay
> ; Roper, Matthew D
> ; De Marchi, Lucas ;
> Shankar, Uma
> Subject: [v4] drm/xe/fbdev: Limit the usage of stolen for LNL+
>
> As per recommendation in the workarounds:
> WA_22019338487
>
> There is an issue with accessing Stolen memory pages due a hardware
> limitation.
> Limit the usage of stolen memory for fbdev for LNL+. Don't use BIOS FB from
> stolen on LNL+ and assign the same from system memory.
>
> v2: Corrected the WA Number, limited WA to LNL and
> Adopted XE_WA framework as suggested by Lucas and Matt.
>
> v3: Introduced the waxxx_display to implement display side
> of WA changes on Lunarlake. Used xe_root_mmio_gt and
> avoid the for loop (Suggested by Lucas)
>
> v4: Fixed some nits (Luca)
Pushed the change to drm-xe-next. Thanks for the reviews and suggestions.
Regards,
Uma Shankar
> Reviewed-by: Lucas De Marchi
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 6 +-
> drivers/gpu/drm/xe/display/xe_plane_initial.c | 6 ++
> drivers/gpu/drm/xe/xe_wa_oob.rules| 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> index 816ad13821a8..cd8948c08661 100644
> --- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> +++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> @@ -10,6 +10,9 @@
> #include "xe_bo.h"
> #include "xe_gt.h"
> #include "xe_ttm_stolen_mgr.h"
> +#include "xe_wa.h"
> +
> +#include
>
> struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size
> *sizes) @@ -37,7 +40,7 @@ struct intel_framebuffer
> *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> size = PAGE_ALIGN(size);
> obj = ERR_PTR(-ENODEV);
>
> - if (!IS_DGFX(xe)) {
> + if (!IS_DGFX(xe) && !XE_WA(xe_root_mmio_gt(xe),
> 22019338487_display))
> +{
> obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> NULL, size,
> ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | @@ -48,6 +51,7 @@ struct intel_framebuffer
> *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> else
> drm_info(&xe->drm, "Allocated fbdev into stolen failed:
> %li\n", PTR_ERR(obj));
> }
> +
> if (IS_ERR(obj)) {
> obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> NULL, size,
> ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | diff --git
> a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> index 5eccd6abb3ef..a50ab9eae40a 100644
> --- a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> +++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> @@ -18,6 +18,9 @@
> #include "intel_frontbuffer.h"
> #include "intel_plane_initial.h"
> #include "xe_bo.h"
> +#include "xe_wa.h"
> +
> +#include
>
> static bool
> intel_reuse_initial_plane_obj(struct intel_crtc *this, @@ -104,6 +107,9 @@
> initial_plane_bo(struct xe_device *xe,
> phys_base = base;
> flags |= XE_BO_FLAG_STOLEN;
>
> + if (XE_WA(xe_root_mmio_gt(xe), 22019338487_display))
> + return NULL;
> +
> /*
>* If the FB is too big, just don't use it since fbdev is not
> very
>* important and we should probably use that space with FBC or
> other diff --git a/drivers/gpu/drm/xe/xe_wa_oob.rules
> b/drivers/gpu/drm/xe/xe_wa_oob.rules
> index 08f7336881e3..540d38603f32 100644
> --- a/drivers/gpu/drm/xe/xe_wa_oob.rules
> +++ b/drivers/gpu/drm/xe/xe_wa_oob.rules
> @@ -29,4 +29,5 @@
> 13011645652 GRAPHICS_VERSION(2004)
> 22019338487 MEDIA_VERSION(2000)
> GRAPHICS_VERSION(2001)
> +22019338487_display PLATFORM(LUNARLAKE)
> 16023588340 GRAPHICS_VERSION(2001)
> --
> 2.42.0
RE: [PATCH] RFC: drm/drm_plane: Expose the plane capability and interoperability
> -Original Message-
> From: Intel-gfx On Behalf Of Xaver
> Hugl
> Sent: Thursday, July 11, 2024 9:06 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] RFC: drm/drm_plane: Expose the plane capability and
> interoperability
>
> Hi,
>
> On Dienstag, 9. Juli 2024 09:46:56 MESZ Arun R Murthy wrote:
> > Each plane has its own capability or interoperability based on the
> > harware restrictions. If this is exposed to the user, then user can
> > read it once on boot and store this. Later can be used as a lookup
> > table to check a corresponding capability is supported by plane then
> > only go ahead with the framebuffer creation/calling atomic_ioctl.
> >
> > For Ex: There are few restiction as to async flip doesnt support all
> > the formats/modifiers. Similar restrictions on scaling. With the
> > availabililty of this info to user, failures in atomic_check can be
> > avoided as these are more the hardware capabilities.
> >
> > There are two options on how this can be acheived.
> > Option 1:
> >
> > Add a new element to struct drm_mode_get_plane that holds the addr to
> > the array of a new struct. This new struct consists of the formats
> > supported and the corresponding plane capabilities.
> >
> > Option 2:
> >
> > These can be exposed to user as a plane property so that the user can
> > get to know the limitation ahead and avoid failures in atomic_check.
> >
> > Usually atomic_get_property is controlled over the state struct for
> > the parameters/elements that can change. But here these capabilities
> > or the interoperabilities are rather hardware restrictions and wont
> > change over flips. Hence having as a plane_property may not make much sense.
> > On the other hand, Option 1 include changes in the uapi struct
> > drm_mode_get_plane. Shouldnt have impact on backward compatibility,
> > but if userspace has some implementation so as to check the size of
> > the struct, then it might a challenge.
>
> Adding fields to the struct should be okay, but adding a per-plane immutable
> property is also fine and IMO the cleaner option. We already have the same
> thing
> with "IN_FORMATS" and "type" that don't ever change either.
>
> Either way, having a capability flag per format+modifier pair sounds good to
> me
> and should be both easy to make use of in userspace.
Adding new fields to a structure part of an existing UAPI may not be a great
idea.
This can have some issues of backward compatibility and multiple structure
definitions
with various kernel and user space header versions. So this doesn't look very
promising.
Others can chime in and share their perspective.
We can expose an immutable plane capability property (with interoperability
info) which userspace
can read and based on the capabilities exposed plane the composition. So,
option 2 looks more
viable to me.
Regards,
Uma Shankar
> > Signed-off-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > include/drm/drm_plane.h | 8
> > include/uapi/drm/drm_mode.h | 20
> > 3 files changed, 31 insertions(+)
> >
> > =Option 2
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c index 22bbb2d83e30..b46177d5fc8c
> > 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -631,6 +631,9 @@ drm_atomic_plane_get_property(struct drm_plane
> *plane,
> > *val = state->hotspot_x;
> > } else if (property == plane->hotspot_y_property) {
> > *val = state->hotspot_y;
> > + } else if (property == config->prop_plane_caps) {
> > + *val = (state->plane_caps) ?
> > + state->plane_caps->base.id : 0;
> > } else {
> > drm_dbg_atomic(dev,
> >"[PLANE:%d:%s] unknown property
> [PROP:%d:%s]\n",
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index
> > dd718c62ac31..dfe931677d0a 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -260,6 +260,14 @@ struct drm_plane_state {
> > * flow.
> > */
> > bool color_mgmt_changed : 1;
> > +
> > + /**
> > +* @plane_caps:
> > +*
> > +* Blob representing plane capcabilites and interoperability.
> > +* This element is a pointer to the array of struct
> drm_format_blob.
> > +*/
> > + struct drm_property_blob *plane_caps;
> > };
> >
> > static inline struct drm_rect
> >
> > =Option 1
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index d390011b89b4..0b5c1b65ef63 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -312,6 +312,20 @@ struct drm_mode_set_plane {
> > __u32 src_w;
> > };
> >
> > +#define DRM_FORMAT_PLANE_CAP_LINEAR_TILE BIT(0)
> > +#define DRM_FORMAT_PLANE_CAP_X_TILEBIT(1)
> > +#define DRM_FO
RE: [v3] drm/xe/fbdev: Limit the usage of stolen for LNL+
> -Original Message-
> From: De Marchi, Lucas
> Sent: Tuesday, July 16, 2024 9:19 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; Ceraolo Spurio, Daniele
> ; Belgaumkar, Vinay
> ; Roper, Matthew D
>
> Subject: Re: [v3] drm/xe/fbdev: Limit the usage of stolen for LNL+
>
> On Tue, Jul 16, 2024 at 12:30:43AM GMT, Uma Shankar wrote:
> >As per recommendation in the workarounds:
> >WA_22019338487
> >
> >There is an issue with accessing Stolen memory pages due a hardware
> >limitation. Limit the usage of stolen memory for fbdev for LNL+. Don't
> >use BIOS FB from stolen on LNL+ and assign the same from system memory.
> >
> >v2: Corrected the WA Number, limited WA to LNL and
> >Adopted XE_WA framework as suggested by Lucas and Matt.
> >
> >v3: Introduced the waxxx_display to avoid tipping on other WA.
>
> it's actually the same WA, just a different part of it
>
> a few nits below, otherwise this is
> // Reviewed-by: Lucas De Marchi
Thanks Lucas for the review. Will address the nits and float a next version.
Regards,
Uma Shankar
> >Used xe_root_mmio_gt and avoid the for loop.
> >(Suggested by Lucas)
> >
> >Signed-off-by: Uma Shankar
> >---
> > drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 10 +-
> > drivers/gpu/drm/xe/display/xe_plane_initial.c | 6 ++
> > drivers/gpu/drm/xe/xe_wa_oob.rules| 1 +
> > 3 files changed, 16 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >index 816ad13821a8..0f02e6222ada 100644
> >--- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >+++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >@@ -10,6 +10,9 @@
> > #include "xe_bo.h"
> > #include "xe_gt.h"
> > #include "xe_ttm_stolen_mgr.h"
> >+#include "xe_wa.h"
> >+
> >+#include
> >
> > struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> >struct drm_fb_helper_surface_size
> *sizes) @@ -20,6 +23,7
> >@@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper
> *helper,
> > struct drm_mode_fb_cmd2 mode_cmd = {};
> > struct drm_i915_gem_object *obj;
> > int size;
> >+bool wa_22019338487 = false;
>
> no need for the bool, just use XE_WA() in the one place needed.
>
> >
> > /* we don't do packed 24bpp */
> > if (sizes->surface_bpp == 24)
> >@@ -37,7 +41,10 @@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct
> drm_fb_helper *helper,
> > size = PAGE_ALIGN(size);
> > obj = ERR_PTR(-ENODEV);
> >
> >-if (!IS_DGFX(xe)) {
> >+if (XE_WA(xe_root_mmio_gt(xe), 22019338487_display))
> >+wa_22019338487 = true;
> >+
> >+if (!IS_DGFX(xe) && !wa_22019338487) {
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> >NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | @@ -48,6 +55,7 @@
> >struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> > else
> > drm_info(&xe->drm, "Allocated fbdev into stolen failed:
> %li\n", PTR_ERR(obj));
> > }
> >+
> > if (IS_ERR(obj)) {
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | diff --git
> >a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >index 5eccd6abb3ef..a50ab9eae40a 100644
> >--- a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >+++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >@@ -18,6 +18,9 @@
> > #include "intel_frontbuffer.h"
> > #include "intel_plane_initial.h"
> > #include "xe_bo.h"
> >+#include "xe_wa.h"
> >+
> >+#include
> >
> > static bool
> > intel_reuse_initial_plane_obj(struct intel_crtc *this, @@ -104,6
> >+107,9 @@ initial_plane_bo(struct xe_device *xe,
> > phys_base = base;
> > flags |= XE_BO_FLAG_STOLEN;
> >
> >+if (XE_WA(xe_root_mmio_gt(xe), 22019338487_display))
> >+return NULL;
> >+
> > /*
&g
RE: [v2] drm/xe/fbdev: Limit the usage of stolen for LNL+
> -Original Message-
> From: De Marchi, Lucas
> Sent: Monday, July 15, 2024 6:53 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; Ceraolo Spurio, Daniele
> ; Belgaumkar, Vinay
> ; Roper, Matthew D
>
> Subject: Re: [v2] drm/xe/fbdev: Limit the usage of stolen for LNL+
>
> On Mon, Jul 15, 2024 at 02:26:59AM GMT, Uma Shankar wrote:
> >As per recommendation in the workarounds:
> >WA_22019338487
> >
> >There is an issue with accessing Stolen memory pages due a hardware
> >limitation. Limit the usage of stolen memory for fbdev for LNL+. Don't
> >use BIOS FB from stolen on LNL+ and assign the same from system memory.
> >
> >v2: Corrected the WA Number, limited WA to LNL and
> >Adopted XE_WA framework as suggested by Lucas and Matt.
> >
> >Signed-off-by: Uma Shankar
> >---
> > drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 20 ++-
> > drivers/gpu/drm/xe/display/xe_plane_initial.c | 12 +++
> > drivers/gpu/drm/xe/xe_wa_oob.rules| 1 +
> > 3 files changed, 32 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >index 816ad13821a8..9c70c9158108 100644
> >--- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >+++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >@@ -10,6 +10,8 @@
> > #include "xe_bo.h"
> > #include "xe_gt.h"
> > #include "xe_ttm_stolen_mgr.h"
> >+#include "xe_wa.h"
>
> missing newline
>
> >+#include
> >
> > struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> >struct drm_fb_helper_surface_size
> *sizes) @@ -20,6 +22,9
> >@@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper
> *helper,
> > struct drm_mode_fb_cmd2 mode_cmd = {};
> > struct drm_i915_gem_object *obj;
> > int size;
> >+bool wa_22019338487 = false;
> >+struct xe_gt *gt;
> >+u8 id;
> >
> > /* we don't do packed 24bpp */
> > if (sizes->surface_bpp == 24)
> >@@ -37,7 +42,19 @@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct
> drm_fb_helper *helper,
> > size = PAGE_ALIGN(size);
> > obj = ERR_PTR(-ENODEV);
> >
> >-if (!IS_DGFX(xe)) {
> >+/*
> >+ * WA_22019338487:
> >+ * There is an issue with accessing Stolen memory pages
> >+ * due a hardware limitation. Limit the usage of stolen
> >+ * memory for fbdev for LNL+. Don't use BIOS FB from
> >+ * stolen on LNL+ and assign the same from system memory
> >+ */
> >+for_each_gt(gt, xe, id) {
>
> why do you loop here, but in the other path you use main_gt of tile0?
>
> I think at this point it's pretty safe to just do:
>
> if (XE_WA(xe_root_mmio_gt(xe), 22019338487))
Yeah this sound a better choice here. Will drop the for loop and use this.
Thanks for pointing out.
> Also, no need for the comment above, the commit message and WA
> documentation is sufficient.
Sure, will do.
> >+if (XE_WA(gt, 22019338487))
> >+wa_22019338487 = true;
> >+}
> >+
> >+if (!IS_DGFX(xe) && !wa_22019338487) {
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> >NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | @@ -48,6 +65,7 @@
> >struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> > else
> > drm_info(&xe->drm, "Allocated fbdev into stolen failed:
> %li\n", PTR_ERR(obj));
> > }
> >+
> > if (IS_ERR(obj)) {
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | diff --git
> >a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >index 5eccd6abb3ef..7e93ddad6df8 100644
> >--- a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >+++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >@@ -18,6 +18,8 @@
> > #include "intel_frontbuffer.h"
> > #include "intel_plane_initial.h"
> > #include "xe_bo.h"
> >+#include "xe_wa.h"
> >+#include
> >
> > static bool
RE: [PATCH] drm/xe/fbdev: Limit the usage of stolen for LNL+
> -Original Message- > From: De Marchi, Lucas > Sent: Thursday, July 11, 2024 10:37 PM > To: Roper, Matthew D > Cc: Shankar, Uma ; intel-gfx@lists.freedesktop.org; > intel...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Ceraolo Spurio, > Daniele ; Belgaumkar, Vinay > > Subject: Re: [PATCH] drm/xe/fbdev: Limit the usage of stolen for LNL+ > > On Thu, Jul 11, 2024 at 09:37:41AM GMT, Matt Roper wrote: > >On Thu, Jul 11, 2024 at 10:43:39AM +0530, Uma Shankar wrote: > >> As per recommendation in the workarounds: > >> WA_14021987551, Wa_16023588340: > > > >The first one here isn't a valid workaround lineage number, just a > >per-platform ticket number. I think you meant Wa_22019338487, which is > >the lineage number that can be used to track the applicability of the > >workaround across all potentially relevant platform(s). > > > >> > >> There is an issue with accessing Stolen memory pages due a hardware > >> limitation. Limit the usage of stolen memory for fbdev for LNL+. > >> Don't use BIOS FB from stolen on LNL+ and > > > >From a quick skim of these workarounds I don't see a clear indication > >that we need to avoid using stolen FB's? I thought these workarounds > >were already being implemented separately (and aside from disabling > >FBC, most of the necessary changes are on the GT side to adjust > >frequencies and change caching behavior of LMEMBAR accesses). I.e., > > one part of Wa_22019338487 is what is implemented in > ggtt_update_access_counter(), because ggtt is in stolen. This can be done for > things under kernel-only control. For other things like the fb we need to > avoid > them. Yeah right. > > Also, while thinking about that... Did we check if we also need > something for DPT? AFAICS for LNL we will end up in > > dpt = xe_bo_create_pin_map(xe, tile0, NULL, dpt_size, > ttm_bo_type_kernel, > XE_BO_FLAG_STOLEN | > XE_BO_FLAG_GGTT | > XE_BO_FLAG_PAGETABLE); > > > ... and I don't see anything fencing the writes like we have in ggtt. For DPT as per some discussions with windows team, it seems this should not harm as CPU accesses will be limited. Will move this out if we encounter any corner case. So far this seems to be ok as per the CI and local testing. Regards, Uma Shankar > > > > > - Wa_16023588340: https://patchwork.freedesktop.org/series/135699/ > > - Wa_22019338487: https://patchwork.freedesktop.org/series/135460/ > > > >One other nitpick: we've been trying to avoid using "+" as shorthand > >for "and beyond" lately since some of our IP names contain literal +'s > >in their name (e.g., Xe_LPD+, Xe_LPM+, etc.). We don't want confusion > >about whether "LNL+" refers to "LNL and beyond" (as you mean here) or > >some other platform that's distinct from LNL. > > > >But in general we usually don't treat workarounds as "forever" logic > >unless they get written into the spec as new "official" programming. It > >looks like these workarounds apply to LNL/BMG today, but we shouldn't > >assume in advance that they'll automatically apply to platforms n+1, > >n+2, etc. as well. > > > >If we're making a concious decision to apply workaround programming to > >more platforms than it's technically needed on (e.g., in cases where a > >workaround doesn't have any negative impact, but applying it > >unconditionally simplifies the driver logic), that should be called out > >specifically in the commit message and comments to make it clear it > >isn't a mistake. But I don't think that's the case here, since > >otherwise we wouldn't be bothering with the DISPLAY_VER < 20 condition > >either. > > this is basically Wa_22019338487 and not exactly related with the > *display* version, hence my suggestion in the other reply to use XE_WA() > and tie it either to the platform or GRAPHICS_VERSION(2004) > > Lucas De Marchi > > > > > > >Matt > > > >> assign the same from system memory. > >> > >> Signed-off-by: Uma Shankar > >> --- > >> drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 10 +- > >> drivers/gpu/drm/xe/display/xe_plane_initial.c | 10 ++ > >> 2 files changed, 19 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu
RE: [PATCH] drm/xe/fbdev: Limit the usage of stolen for LNL+
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, July 11, 2024 10:08 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; Ceraolo Spurio, Daniele
> ; Belgaumkar, Vinay
>
> Subject: Re: [PATCH] drm/xe/fbdev: Limit the usage of stolen for LNL+
>
> On Thu, Jul 11, 2024 at 10:43:39AM +0530, Uma Shankar wrote:
> > As per recommendation in the workarounds:
> > WA_14021987551, Wa_16023588340:
>
> The first one here isn't a valid workaround lineage number, just a
> per-platform
> ticket number. I think you meant Wa_22019338487, which is the lineage number
> that can be used to track the applicability of the workaround across all
> potentially
> relevant platform(s).
It was showing up as the WA with wa_status moved to pending_dem_decision so used
that number. But sure, will update the same to 22019338487 to get it correct.
> >
> > There is an issue with accessing Stolen memory pages due a hardware
> > limitation. Limit the usage of stolen memory for fbdev for LNL+. Don't
> > use BIOS FB from stolen on LNL+ and
>
> From a quick skim of these workarounds I don't see a clear indication that we
> need to avoid using stolen FB's? I thought these workarounds were already
> being
> implemented separately (and aside from disabling FBC, most of the necessary
> changes are on the GT side to adjust frequencies and change caching behavior
> of
> LMEMBAR accesses). I.e.,
>
> - Wa_16023588340: https://patchwork.freedesktop.org/series/135699/
> - Wa_22019338487: https://patchwork.freedesktop.org/series/135460/
There is a restriction of accessing stolen with CPU also be able to access it.
So adding the change to avoid this situation.
> One other nitpick: we've been trying to avoid using "+" as shorthand for "and
> beyond" lately since some of our IP names contain literal +'s in their name
> (e.g.,
> Xe_LPD+, Xe_LPM+, etc.). We don't want confusion about whether "LNL+" refers
> to "LNL and beyond" (as you mean here) or some other platform that's distinct
> from LNL.
>
> But in general we usually don't treat workarounds as "forever" logic unless
> they
> get written into the spec as new "official" programming. It looks like these
> workarounds apply to LNL/BMG today, but we shouldn't assume in advance that
> they'll automatically apply to platforms n+1,
> n+2, etc. as well.
>
> If we're making a concious decision to apply workaround programming to more
> platforms than it's technically needed on (e.g., in cases where a workaround
> doesn't have any negative impact, but applying it unconditionally simplifies
> the
> driver logic), that should be called out specifically in the commit message
> and
> comments to make it clear it isn't a mistake. But I don't think that's the
> case
> here, since otherwise we wouldn't be bothering with the DISPLAY_VER < 20
> condition either.
Thanks for clarifying Matt, will update the change and restrict it to
GRAPHICS_VERSION 2004.
>
> Matt
>
> > assign the same from system memory.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 10 +-
> > drivers/gpu/drm/xe/display/xe_plane_initial.c | 10 ++
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> > b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> > index 816ad13821a8..8fda8745ce0a 100644
> > --- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> > +++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> > @@ -37,7 +37,14 @@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct
> drm_fb_helper *helper,
> > size = PAGE_ALIGN(size);
> > obj = ERR_PTR(-ENODEV);
> >
> > - if (!IS_DGFX(xe)) {
> > + /*
> > +* WA_14021987551, Wa_16023588340:
> > +* There is an issue with accessing Stolen memory pages
> > +* due a hardware limitation. Limit the usage of stolen
> > +* memory for fbdev for LNL+. Don't use BIOS FB from
> > +* stolen on LNL+ and assign the same from system memory
> > +*/
> > + if (!IS_DGFX(xe) && (DISPLAY_VER(xe) < 20)) {
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> >NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | @@ -48,6 +55,7 @@
> > struct intel_framebuffer *intel_fbdev_fb_alloc(str
RE: [PATCH] drm/xe/fbdev: Limit the usage of stolen for LNL+
> -Original Message-
> From: De Marchi, Lucas
> Sent: Thursday, July 11, 2024 10:02 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; Ceraolo Spurio, Daniele
> ; Belgaumkar, Vinay
>
> Subject: Re: [PATCH] drm/xe/fbdev: Limit the usage of stolen for LNL+
>
> On Thu, Jul 11, 2024 at 10:43:39AM GMT, Uma Shankar wrote:
> >As per recommendation in the workarounds:
> >WA_14021987551, Wa_16023588340:
> >
> >There is an issue with accessing Stolen memory pages due a hardware
> >limitation. Limit the usage of stolen memory for fbdev for LNL+. Don't
> >use BIOS FB from stolen on LNL+ and assign the same from system memory.
> >
> >Signed-off-by: Uma Shankar
> >---
> > drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 10 +-
> > drivers/gpu/drm/xe/display/xe_plane_initial.c | 10 ++
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >index 816ad13821a8..8fda8745ce0a 100644
> >--- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >+++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> >@@ -37,7 +37,14 @@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct
> drm_fb_helper *helper,
> > size = PAGE_ALIGN(size);
> > obj = ERR_PTR(-ENODEV);
> >
> >-if (!IS_DGFX(xe)) {
> >+/*
> >+ * WA_14021987551, Wa_16023588340:
>
> not the proper way to handle WAs in xe. Please use XE_WA()
Sure Lucas, will update the patch.
>
> >+ * There is an issue with accessing Stolen memory pages
> >+ * due a hardware limitation. Limit the usage of stolen
> >+ * memory for fbdev for LNL+. Don't use BIOS FB from
> >+ * stolen on LNL+ and assign the same from system memory
>
> I wonder if we can't simply set to 0 the available stolen space after the
> places
> that really need it already had their allocation done.
We will need it for FBC, so making it all 0 will not be good.
> >+ */
> >+if (!IS_DGFX(xe) && (DISPLAY_VER(xe) < 20)) {
>
> extra parenthesis not needed and I think the rule to be added in
> xe_wa_oob.rules
> would be about GRAPHICS_VERSION(2004) or
> PLATFORM(LUNARLAKE) to avoid this propagating to future platforms.
>
Yeah got it, will change to GRPAHICS_VERSION and restrict it to LNL.
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> >NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | @@ -48,6 +55,7 @@
> >struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> > else
> > drm_info(&xe->drm, "Allocated fbdev into stolen failed:
> %li\n", PTR_ERR(obj));
> > }
> >+
> > if (IS_ERR(obj)) {
> > obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> NULL, size,
> >ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT | diff --git
> >a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >index 5eccd6abb3ef..80dd6b64c921 100644
> >--- a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >+++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> >@@ -104,6 +104,16 @@ initial_plane_bo(struct xe_device *xe,
> > phys_base = base;
> > flags |= XE_BO_FLAG_STOLEN;
> >
> >+/*
> >+ * WA_14021987551, Wa_16023588340:
> >+ * There is an issue with accessing Stolen memory pages
> >+ * due a hardware limitation. Limit the usage of stolen
> >+ * memory for fbdev for LNL+. Don't use BIOS FB from
> >+ * stolen on LNL+ and assign the same from system memory
> >+ */
> >+if (DISPLAY_VER(xe) >= 20)
> >+return NULL;
>
> same as above
>
> Lucas De Marchi
>
> >+
> > /*
> > * If the FB is too big, just don't use it since fbdev is not
> > very
> > * important and we should probably use that space with FBC or
> other
> >--
> >2.42.0
> >
RE: [PATCH 20/20] drm/xe/fbdev: Adjust fbdev stolen mem usage heuristic
> -Original Message- > From: Intel-xe On Behalf Of Ville > Syrjala > Sent: Friday, July 5, 2024 8:23 PM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org > Subject: [PATCH 20/20] drm/xe/fbdev: Adjust fbdev stolen mem usage heuristic > > From: Ville Syrjälä > > Replace the "1/2 of stolen size" fbdev fb size heuristic with something a bit > more > clever, that is ask the FBC code how much stolen mem it would like to have > avaialable for its CFB use. Looks Good to me. Reviewed-by: Uma Shankar > TODO: > - This doesn't account for the fact that FBC's idea > usable stolen size might differ from other users of stolen > - Would be nice to share the code with i915, but need to > figure out how to abstract the stolen size and > dgpu/lmem stuff > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c > b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c > index f67bc0fd803b..62e1d176b07f 100644 > --- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c > +++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c > @@ -24,12 +24,11 @@ bool intel_fbdev_fb_prefer_stolen(struct intel_display > *display, > if (!stolen) > return false; > > - /* > - * If the FB is too big, just don't use it since fbdev is not very > - * important and we should probably use that space with FBC or other > - * features. > - */ > - return stolen->size >= size * 2; > + if (size > stolen->size) > + return false; > + > + /* try to ensure FBC has enough stolen to do its job well */ > + return stolen->size - size >= > +intel_fbc_preferred_cfb_size(&xe->display); > } > > struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper, > -- > 2.44.2
RE: [PATCH 19/20] drm/i915/fbdev: Adjust fbdev stolen mem usage heuristic
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 19/20] drm/i915/fbdev: Adjust fbdev stolen mem usage heuristic
>
> From: Ville Syrjälä
>
> Replace the "1/2 of stolen size" fbdev fb size heuristic with something a bit
> more
> clever, that is ask the FBC code how much stolen mem it would like to have
> avaialable for its CFB use.
Looks Good to me.
Reviewed-by: Uma Shankar
> TODO:
> - This doesn't account for the fact that FBC's idea
> usable stolen size might differ from other users of stolen
> - Would be nice to share the code with xe, but need to
> figure out how to abstract the stolen size and
> dgpu/lmem stuff
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> index 0a6445acb100..29f3241c9270 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> @@ -16,12 +16,11 @@ bool intel_fbdev_fb_prefer_stolen(struct intel_display
> *display, {
> struct drm_i915_private *i915 = to_i915(display->drm);
>
> - /*
> - * If the FB is too big, just don't use it since fbdev is not very
> - * important and we should probably use that space with FBC or other
> - * features.
> - */
> - return i915->dsm.usable_size >= size * 2;
> + if (size > i915->dsm.usable_size)
> + return false;
> +
> + /* try to ensure FBC has enough stolen to do its job well */
> + return i915->dsm.usable_size - size >=
> +intel_fbc_preferred_cfb_size(&i915->display);
> }
>
> struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> --
> 2.44.2
RE: [PATCH 18/20] drm/xe/fbdev: Use the same logic for fbdev stolen takever and fresh allocation
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 18/20] drm/xe/fbdev: Use the same logic for fbdev stolen
> takever and fresh allocation
>
> From: Ville Syrjälä
>
> Currently xe only checks that the BIOS FB doesn't take up too much stolen
> memory, but does no such check when allocating a fresh FB from stolen. Use the
> same rule for both, just like i915 does.
Would be good to add restriction for LNL+ as well.
However, current change looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> index f7905b382d06..f67bc0fd803b 100644
> --- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> +++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> @@ -17,6 +17,9 @@ bool intel_fbdev_fb_prefer_stolen(struct intel_display
> *display,
> struct xe_device *xe = to_xe_device(display->drm);
> struct ttm_resource_manager *stolen;
>
> + if (IS_DGFX(xe))
> + return false;
> +
> stolen = ttm_manager_type(&xe->ttm, XE_PL_STOLEN);
> if (!stolen)
> return false;
> @@ -55,7 +58,7 @@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct
> drm_fb_helper *helper,
> size = PAGE_ALIGN(size);
> obj = ERR_PTR(-ENODEV);
>
> - if (!IS_DGFX(xe)) {
> + if (intel_fbdev_fb_prefer_stolen(&xe->display, size)) {
> obj = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe),
> NULL, size,
> ttm_bo_type_kernel,
> XE_BO_FLAG_SCANOUT |
> --
> 2.44.2
RE: [PATCH 17/20] drm/xe/fbdev: Extract intel_fbdev_fb_prefer_stolen()
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 17/20] drm/xe/fbdev: Extract intel_fbdev_fb_prefer_stolen()
>
> From: Ville Syrjälä
>
> Pull the "should we keep the bios fb in stolen?" logic into into a helper
> function,
> same as was done for i915. Gives us a single place where to tweak the
> heuristics.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 18 ++
> drivers/gpu/drm/xe/display/xe_plane_initial.c | 8 ++--
> 2 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> index 816ad13821a8..f7905b382d06 100644
> --- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> +++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
> @@ -11,6 +11,24 @@
> #include "xe_gt.h"
> #include "xe_ttm_stolen_mgr.h"
>
> +bool intel_fbdev_fb_prefer_stolen(struct intel_display *display,
> + unsigned int size)
> +{
> + struct xe_device *xe = to_xe_device(display->drm);
> + struct ttm_resource_manager *stolen;
> +
> + stolen = ttm_manager_type(&xe->ttm, XE_PL_STOLEN);
> + if (!stolen)
> + return false;
> +
> + /*
> + * If the FB is too big, just don't use it since fbdev is not very
> + * important and we should probably use that space with FBC or other
> + * features.
> + */
> + return stolen->size >= size * 2;
> +}
> +
> struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size
> *sizes) { diff --git a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> index 21965cc8a9ca..4c000e95aea5 100644
> --- a/drivers/gpu/drm/xe/display/xe_plane_initial.c
> +++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c
> @@ -15,6 +15,7 @@
> #include "intel_display_types.h"
> #include "intel_fb.h"
> #include "intel_fb_pin.h"
> +#include "intel_fbdev_fb.h"
> #include "intel_frontbuffer.h"
> #include "intel_plane_initial.h"
> #include "xe_bo.h"
> @@ -104,13 +105,8 @@ initial_plane_bo(struct xe_device *xe,
> phys_base = base;
> flags |= XE_BO_FLAG_STOLEN;
>
> - /*
> - * If the FB is too big, just don't use it since fbdev is not
> very
> - * important and we should probably use that space with FBC or
> other
> - * features.
> - */
> if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
> - plane_config->size * 2 > stolen->size)
> + !intel_fbdev_fb_prefer_stolen(&xe->display, plane_config-
> >size))
> return NULL;
> }
>
> --
> 2.44.2
RE: [PATCH 16/20] drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen()
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 16/20] drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen()
>
> From: Ville Syrjälä
>
> Consolidate the "should we allocate fbdev fb in stolen?"
> check into a helper function. Makes it easier to change the heuristics without
> having to change so many places.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 24 ---
> drivers/gpu/drm/i915/display/intel_fbdev_fb.h | 5 +++-
> .../drm/i915/display/intel_plane_initial.c| 10 +++-
> 3 files changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> index 497525ef9668..0a6445acb100 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> @@ -11,6 +11,19 @@
> #include "intel_display_types.h"
> #include "intel_fbdev_fb.h"
>
> +bool intel_fbdev_fb_prefer_stolen(struct intel_display *display,
> + unsigned int size)
> +{
> + struct drm_i915_private *i915 = to_i915(display->drm);
> +
> + /*
> + * If the FB is too big, just don't use it since fbdev is not very
> + * important and we should probably use that space with FBC or other
> + * features.
> + */
> + return i915->dsm.usable_size >= size * 2; }
> +
> struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size
> *sizes) { @@ -42,14 +55,9 @@ struct intel_framebuffer
> *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
>
> I915_BO_ALLOC_CONTIGUOUS |
> I915_BO_ALLOC_USER);
> } else {
> - /*
> - * If the FB is too big, just don't use it since fbdev is not
> very
> - * important and we should probably use that space with FBC or
> other
> - * features.
> - *
> - * Also skip stolen on MTL as Wa_22018444074 mitigation.
> - */
> - if (!(IS_METEORLAKE(dev_priv)) && size * 2 < dev_priv-
> >dsm.usable_size)
> + /* skip stolen on MTL as Wa_22018444074 mitigation */
> + if (!IS_METEORLAKE(dev_priv) &&
Its better to move this platform check as well to the helper.
Also maybe we can extend this to LNL+ as well given the limitations (can be a
separate change though).
Thoughts ?
> + intel_fbdev_fb_prefer_stolen(&dev_priv->display, size))
> obj = i915_gem_object_create_stolen(dev_priv, size);
> if (IS_ERR(obj))
> obj = i915_gem_object_create_shmem(dev_priv, size);
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
> b/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
> index 4832fe688fbf..3b9033bd2160 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
> @@ -6,16 +6,19 @@
> #ifndef __INTEL_FBDEV_FB_H__
> #define __INTEL_FBDEV_FB_H__
>
> +#include
> +
> struct drm_fb_helper;
> struct drm_fb_helper_surface_size;
> struct drm_i915_gem_object;
> struct drm_i915_private;
> struct fb_info;
> struct i915_vma;
> +struct intel_display;
>
> struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size
> *sizes); int intel_fbdev_fb_fill_info(struct drm_i915_private *i915, struct
> fb_info
> *info,
>struct drm_i915_gem_object *obj, struct i915_vma
> *vma);
> -
> +bool intel_fbdev_fb_prefer_stolen(struct intel_display *display,
> +unsigned int size);
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index ada1792df5b3..4622bb5f3426 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -11,6 +11,7 @@
> #include "intel_display.h"
> #include "intel_display_types.h"
> #include "intel_fb.h"
> +#include "intel_fbdev_fb.h"
> #include "intel_frontbuffer.h"
> #include "intel_plane_initial.h"
>
> @@ -160,15 +161,10 @@ initial_plane_vma(struct drm_i915_private *i915,
> mem->min_page_size);
> size -= base;
>
> - /*
> - * If the FB is too big, just don't use it since fbdev is not very
> - * important and we should probably use that space with FBC or other
> - * features.
> - */
> if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
> mem == i915->mm.stolen_region &&
> - size * 2 > i915->dsm.usable_size) {
> - drm_dbg_kms(&i915->drm, "Initial FB size exceeds half
RE: [PATCH 15/20] drm/xe/fbdev: Fix BIOS FB vs.s stolen size checke
> -Original Message- > From: Intel-xe On Behalf Of Ville > Syrjala > Sent: Friday, July 5, 2024 8:23 PM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org > Subject: [PATCH 15/20] drm/xe/fbdev: Fix BIOS FB vs.s stolen size checke Nit: Typo in vs and check > From: Ville Syrjälä > > Looks like stolen->size is in bytes, not pages. Remove the bogus PAGE_SHIFT > stuff. > > Also for some rnadom reason xe rejects the FB if it takes up exactly half of > stolen, Typo in random. > whereas i915 allows it to be used in that case. Adjust xe to follow the i915 > rule for > consistency. With the typos fixed, Looks Good to me. Reviewed-by: Uma Shankar > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/xe/display/xe_plane_initial.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/display/xe_plane_initial.c > b/drivers/gpu/drm/xe/display/xe_plane_initial.c > index 5eccd6abb3ef..21965cc8a9ca 100644 > --- a/drivers/gpu/drm/xe/display/xe_plane_initial.c > +++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c > @@ -110,7 +110,7 @@ initial_plane_bo(struct xe_device *xe, >* features. >*/ > if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) && > - plane_config->size * 2 >> PAGE_SHIFT >= stolen->size) > + plane_config->size * 2 > stolen->size) > return NULL; > } > > -- > 2.44.2
RE: [PATCH 14/20] drm/i915/fbc: Introduce intel_fbc_preferred_cfb_size()
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 14/20] drm/i915/fbc: Introduce intel_fbc_preferred_cfb_size()
>
> From: Ville Syrjälä
>
> Allow the code to declare roughly how much stolen memory should remain
> available for the CFB. Since we don't know the actual resolutions that will
> eventually be used simply assume that the maximum plane size (with no extra
> stride
> padding) is enough, with 1:1 compression ratio limit.
>
> This should be useful for the fbdev code to determine whether to allocate/keep
> the fbdev framebuffer in stolen or not.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 17 +
> drivers/gpu/drm/i915/display/intel_fbc.h | 1 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index a0e539bc80f1..efe0a554a281 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1911,6 +1911,23 @@ static int intel_sanitize_fbc_option(struct
> intel_display *display)
> return 0;
> }
>
> +unsigned int intel_fbc_preferred_cfb_size(struct intel_display
> +*display) {
> + unsigned int cpp, width, height, stride;
> +
> + if (!HAS_FBC(display))
> + return 0;
> +
> + intel_fbc_max_plane_size(display, &width, &height);
> +
> + cpp = intel_fbc_cfb_cpp();
> +
> + /* assume stride matches width to keep this simple */
> + stride = _intel_fbc_cfb_stride(display, cpp, width, width * cpp);
> +
> + return _intel_fbc_cfb_size(display, height, stride); }
> +
> void intel_fbc_add_plane(struct intel_fbc *fbc, struct intel_plane *plane) {
> plane->fbc = fbc;
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h
> b/drivers/gpu/drm/i915/display/intel_fbc.h
> index 834b271505b1..40d8efec6d9d 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.h
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.h
> @@ -46,6 +46,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
> void intel_fbc_add_plane(struct intel_fbc *fbc, struct intel_plane *plane);
> void
> intel_fbc_handle_fifo_underrun_irq(struct intel_display *display); void
> intel_fbc_reset_underrun(struct intel_display *display);
> +unsigned int intel_fbc_preferred_cfb_size(struct intel_display
> +*display);
> void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc); void
> intel_fbc_debugfs_register(struct intel_display *display);
>
> --
> 2.44.2
RE: [PATCH 13/20] drm/i915/fbc: Extract intel_fbc_cfb_cpp()
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 13/20] drm/i915/fbc: Extract intel_fbc_cfb_cpp()
>
> From: Ville Syrjälä
>
> Extract a helper to determine the CFB bytes per pixel value.
> Currently this is always 4, but that could change in the future.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 293e1a3b9a9d..a0e539bc80f1 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -140,20 +140,24 @@ static unsigned int intel_fbc_plane_stride(const struct
> intel_plane_state *plane
> return stride;
> }
>
> +static unsigned int intel_fbc_cfb_cpp(void) {
> + return 4; /* FBC always 4 bytes per pixel */ }
> +
> /* plane stride based cfb stride in bytes, assuming 1:1 compression limit */
> static
> unsigned int intel_fbc_plane_cfb_stride(const struct intel_plane_state
> *plane_state) {
> - unsigned int cpp = 4; /* FBC always 4 bytes per pixel */
> + unsigned int cpp = intel_fbc_cfb_cpp();
>
> return intel_fbc_plane_stride(plane_state) * cpp; }
>
> /* minimum acceptable cfb stride in bytes, assuming 1:1 compression limit */
> static unsigned int skl_fbc_min_cfb_stride(struct intel_display *display,
> -unsigned int width)
> +unsigned int cpp, unsigned int width)
> {
> unsigned int limit = 4; /* 1:4 compression limit is the worst case */
> - unsigned int cpp = 4; /* FBC always 4 bytes per pixel */
> unsigned int height = 4; /* FBC segment is 4 lines */
> unsigned int stride;
>
> @@ -179,7 +183,8 @@ static unsigned int skl_fbc_min_cfb_stride(struct
> intel_display *display,
>
> /* properly aligned cfb stride in bytes, assuming 1:1 compression limit */
> static
> unsigned int _intel_fbc_cfb_stride(struct intel_display *display,
> - unsigned int width, unsigned int
> stride)
> + unsigned int cpp, unsigned int width,
> + unsigned int stride)
> {
> /*
>* At least some of the platforms require each 4 line segment to @@ -
> 187,7 +192,7 @@ static unsigned int _intel_fbc_cfb_stride(struct intel_display
> *display,
>* that regardless of the compression limit we choose later.
>*/
> if (DISPLAY_VER(display) >= 9)
> - return max(ALIGN(stride, 512), skl_fbc_min_cfb_stride(display,
> width));
> + return max(ALIGN(stride, 512), skl_fbc_min_cfb_stride(display,
> cpp,
> +width));
> else
> return stride;
> }
> @@ -197,8 +202,9 @@ static unsigned int intel_fbc_cfb_stride(const struct
> intel_plane_state *plane_s
> struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> unsigned int stride = intel_fbc_plane_cfb_stride(plane_state);
> unsigned int width = drm_rect_width(&plane_state->uapi.src) >> 16;
> + unsigned int cpp = intel_fbc_cfb_cpp();
>
> - return _intel_fbc_cfb_stride(display, width, stride);
> + return _intel_fbc_cfb_stride(display, cpp, width, stride);
> }
>
> /*
> --
> 2.44.2
RE: [PATCH 12/20] drm/i915/fbc: Extract _intel_fbc_cfb_size()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 12/20] drm/i915/fbc: Extract _intel_fbc_cfb_size()
>
> From: Ville Syrjälä
>
> Pull the lower level stuff out from intel_fbc_cfb_size() into a separate
> function
> that doesn't depend on the plane_state.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 47b715e5d533..293e1a3b9a9d 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -218,13 +218,18 @@ static unsigned int intel_fbc_max_cfb_height(struct
> intel_display *display)
> return 1536;
> }
>
> +static unsigned int _intel_fbc_cfb_size(struct intel_display *display,
> + unsigned int height, unsigned int
> stride)
> {
> + return min(height, intel_fbc_max_cfb_height(display)) * stride; }
> +
> static unsigned int intel_fbc_cfb_size(const struct intel_plane_state
> *plane_state) {
> struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> unsigned int height = drm_rect_height(&plane_state->uapi.src) >> 16;
>
> - return min(height, intel_fbc_max_cfb_height(display)) *
> - intel_fbc_cfb_stride(plane_state);
> + return _intel_fbc_cfb_size(display, height,
> +intel_fbc_cfb_stride(plane_state));
> }
>
> static u16 intel_fbc_override_cfb_stride(const struct intel_plane_state
> *plane_state)
> --
> 2.44.2
RE: [PATCH 11/20] drm/i915/fbc: Extract intel_fbc_max_cfb_height()
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 11/20] drm/i915/fbc: Extract intel_fbc_max_cfb_height()
>
> From: Ville Syrjälä
>
> Pull the code to determine the maximum CFB height into a separate function.
> For
> pre-HSW the maximum CFB height is the same as the maximum plane height (ie.
> the older hardware supposedely doens't have the trick of leaving the extra
> lines
> uncompressed).
>
Nit: Typo in supposedly and doesn't.
Limit is also altered along with refactor; would a separate patch be better ?
Leave it your judgement. Overall logic looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 27 ++--
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index cf5750ed4681..47b715e5d533 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -201,17 +201,30 @@ static unsigned int intel_fbc_cfb_stride(const struct
> intel_plane_state *plane_s
> return _intel_fbc_cfb_stride(display, width, stride); }
>
> -static unsigned int intel_fbc_cfb_size(const struct intel_plane_state
> *plane_state)
> +/*
> + * Maximum height the hardware will compress, on HSW+
> + * additional lines (up to the actual plane height) will
> + * remain uncompressed.
> + */
> +static unsigned int intel_fbc_max_cfb_height(struct intel_display
> +*display)
> {
> - struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> - int height = drm_rect_height(&plane_state->uapi.src) >> 16;
> + struct drm_i915_private *i915 = to_i915(display->drm);
>
> if (DISPLAY_VER(display) >= 8)
> - height = min(height, 2560);
> - else if (DISPLAY_VER(display) == 7)
> - height = min(height, 2048);
> + return 2560;
> + else if (DISPLAY_VER(display) >= 5 || IS_G4X(i915))
> + return 2048;
> + else
> + return 1536;
> +}
>
> - return height * intel_fbc_cfb_stride(plane_state);
> +static unsigned int intel_fbc_cfb_size(const struct intel_plane_state
> +*plane_state) {
> + struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> + unsigned int height = drm_rect_height(&plane_state->uapi.src) >> 16;
> +
> + return min(height, intel_fbc_max_cfb_height(display)) *
> + intel_fbc_cfb_stride(plane_state);
> }
>
> static u16 intel_fbc_override_cfb_stride(const struct intel_plane_state
> *plane_state)
> --
> 2.44.2
RE: [PATCH 08/20] drm/i915/fbc: Extract _intel_fbc_cfb_stride()
> -Original Message-
> From: Intel-xe On Behalf Of Ville
> Syrjala
> Sent: Friday, July 5, 2024 8:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Subject: [PATCH 08/20] drm/i915/fbc: Extract _intel_fbc_cfb_stride()
>
> From: Ville Syrjälä
>
> Pull the lower level stuff out from intel_fbc_cfb_stride() into a separate
> function
> that doesn't depend on the plane_state.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 5ba3d8797243..4a9321f5218f 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -149,12 +149,11 @@ static unsigned int intel_fbc_plane_cfb_stride(const
> struct intel_plane_state *p }
>
> /* minimum acceptable cfb stride in bytes, assuming 1:1 compression limit */
> -
> static unsigned int skl_fbc_min_cfb_stride(const struct intel_plane_state
> *plane_state)
> +static unsigned int skl_fbc_min_cfb_stride(struct intel_display *display,
> +unsigned int width)
> {
> - struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> unsigned int limit = 4; /* 1:4 compression limit is the worst case */
> unsigned int cpp = 4; /* FBC always 4 bytes per pixel */
> - unsigned int width = drm_rect_width(&plane_state->uapi.src) >> 16;
> unsigned int height = 4; /* FBC segment is 4 lines */
> unsigned int stride;
>
> @@ -179,22 +178,29 @@ static unsigned int skl_fbc_min_cfb_stride(const struct
> intel_plane_state *plane }
>
> /* properly aligned cfb stride in bytes, assuming 1:1 compression limit */
> -static
> unsigned int intel_fbc_cfb_stride(const struct intel_plane_state *plane_state)
> +static unsigned int _intel_fbc_cfb_stride(struct intel_display *display,
> + unsigned int width, unsigned int
> stride)
> {
> - struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> - unsigned int stride = intel_fbc_plane_cfb_stride(plane_state);
> -
> /*
>* At least some of the platforms require each 4 line segment to
>* be 512 byte aligned. Aligning each line to 512 bytes guarantees
>* that regardless of the compression limit we choose later.
>*/
> if (DISPLAY_VER(display) >= 9)
> - return max(ALIGN(stride, 512),
> skl_fbc_min_cfb_stride(plane_state));
> + return max(ALIGN(stride, 512), skl_fbc_min_cfb_stride(display,
> +width));
> else
> return stride;
> }
>
> +static unsigned int intel_fbc_cfb_stride(const struct intel_plane_state
> +*plane_state) {
> + struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> + unsigned int stride = intel_fbc_plane_cfb_stride(plane_state);
> + unsigned int width = drm_rect_width(&plane_state->uapi.src) >> 16;
> +
> + return _intel_fbc_cfb_stride(display, width, stride); }
> +
> static unsigned int intel_fbc_cfb_size(const struct intel_plane_state
> *plane_state) {
> struct intel_display *display =
> to_intel_display(plane_state->uapi.plane-
> >dev);
> --
> 2.44.2
RE: [v6 0/3] Fix cursor FB unpinning.
> -Original Message- > From: Intel-xe On Behalf Of Maarten > Lankhorst > Sent: Wednesday, May 22, 2024 11:04 AM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org; Maarten Lankhorst > > Subject: [v6 0/3] Fix cursor FB unpinning. > > Hopefully last attempt. > Small bug in drm_vblank_work_flush_all left, fixed now hopefully. > > Maarten Lankhorst (2): > drm: Add drm_vblank_work_flush_all(). > drm/i915: Use the same vblank worker for atomic unpin > > Ville Syrjälä (1): > drm/i915: Use vblank worker to unpin old legacy cursor fb safely The series looks good now, please get the CI clearance and plan for merge. Regards, Uma Shankar > drivers/gpu/drm/drm_vblank_work.c | 22 + > .../gpu/drm/i915/display/intel_atomic_plane.c | 13 +++- > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 ++ > drivers/gpu/drm/i915/display/intel_crtc.c | 31 +++ > drivers/gpu/drm/i915/display/intel_cursor.c | 26 ++-- > drivers/gpu/drm/i915/display/intel_cursor.h | 3 ++ > drivers/gpu/drm/i915/display/intel_display.c | 3 ++ > .../drm/i915/display/intel_display_types.h| 3 ++ > include/drm/drm_vblank_work.h | 2 ++ > 9 files changed, 102 insertions(+), 3 deletions(-) > > -- > 2.43.0
RE: [v6 3/3] drm/i915: Use the same vblank worker for atomic unpin
> -Original Message-
> From: Intel-xe On Behalf Of Maarten
> Lankhorst
> Sent: Wednesday, May 22, 2024 11:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Maarten Lankhorst
>
> Subject: [v6 3/3] drm/i915: Use the same vblank worker for atomic unpin
>
> In case of legacy cursor update, the cursor VMA needs to be unpinned only
> after
> vblank. This exceeds the lifetime of the whole atomic commit.
>
> Any trick I attempted to keep the atomic commit alive didn't work, as
> drm_atomic_helper_setup_commit() force throttles on any old commit that
> wasn't cleaned up.
>
> The only option remaining is to remove the plane from the atomic commit, and
> use the same path as the legacy cursor update to clean the state after vblank.
>
> Changes since previous version:
> - Call the memset for plane state immediately when scheduling vblank,
> this prevents a use-after-free in cursor cleanup.
Have checked and followed the changes along with testing the same with
Chaitanya. This looks good now.
Reviewed-by: Uma Shankar
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 13 +++-
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 ++
> drivers/gpu/drm/i915/display/intel_crtc.c | 31 +++
> drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> drivers/gpu/drm/i915/display/intel_cursor.h | 3 ++
> 5 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 27224ecdc94c..a06c676c9bb3 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -42,6 +42,7 @@
> #include "i915_reg.h"
> #include "intel_atomic_plane.h"
> #include "intel_cdclk.h"
> +#include "intel_cursor.h"
> #include "intel_display_rps.h"
> #include "intel_display_trace.h"
> #include "intel_display_types.h"
> @@ -1188,7 +1189,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
>
> intel_display_rps_mark_interactive(dev_priv, state, false);
>
> - /* Should only be called after a successful intel_prepare_plane_fb()! */
> intel_plane_unpin_fb(old_plane_state);
> }
>
> @@ -1201,3 +1201,14 @@ void intel_plane_helper_add(struct intel_plane
> *plane) {
> drm_plane_helper_add(&plane->base, &intel_plane_helper_funcs); }
> +
> +void intel_plane_init_cursor_vblank_work(struct intel_plane_state
> *old_plane_state,
> + struct intel_plane_state
> *new_plane_state) {
> + if (!old_plane_state->ggtt_vma ||
> + old_plane_state->ggtt_vma == new_plane_state->ggtt_vma)
> + return;
> +
> + drm_vblank_work_init(&old_plane_state->unpin_work, old_plane_state-
> >uapi.crtc,
> + intel_cursor_unpin_work);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index e7a0699f17c8..4c2031fc3504 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -67,5 +67,7 @@ void intel_plane_set_invisible(struct intel_crtc_state
> *crtc_state,
> struct intel_plane_state *plane_state); void
> intel_plane_helper_add(struct intel_plane *plane); bool
> intel_plane_needs_physical(struct intel_plane *plane);
> +void intel_plane_init_cursor_vblank_work(struct intel_plane_state
> *old_plane_state,
> + struct intel_plane_state
> *new_plane_state);
>
> #endif /* __INTEL_ATOMIC_PLANE_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 339010384b86..283106558b2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -499,6 +499,19 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
> if (intel_crtc_needs_vblank_work(new_crtc_state))
> intel_crtc_vblank_work_init(new_crtc_state);
>
> + if (state->base.legacy_cursor_update) {
> + struct intel_plane *plane;
> + struct intel_plane_state *old_plane_state, *new_plane_state;
> + int i;
> +
> + for_each_oldnew_intel_plane_in_state(state, plane,
> old_plane_state,
> + new_plane_state, i) {
> + if (old_plane_state->uapi.crtc == &crtc->base)
> +
> intel_plane_init_cursor_vblank_work(old_plane_state,
> +
> new_plane_state);
> + }
> + }
> +
> intel_vblank_evade_init(old_crtc_state, new_crtc_state, &evade);
>
> if (drm_WARN_ON(&dev_priv->drm, drm_crtc_vblank_get(&crtc-
> >base)))
> @@ -615,6 +628,24 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> new_crtc_state->uapi.event = NULL;
> }
>
>
RE: [v6 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb safely
> -Original Message-
> From: Intel-xe On Behalf Of Maarten
> Lankhorst
> Sent: Wednesday, May 22, 2024 11:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Ville Syrjälä
> ;
> Maarten Lankhorst
> Subject: [v6 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb
> safely
>
> From: Ville Syrjälä
>
> The cursor hardware only does sync updates, and thus the hardware will be
> scanning out from the old fb until the next start of vblank.
> So in order to make the legacy cursor fastpath actually safe we should not
> unpin
> the old fb until we're sure the hardware has ceased accessing it. The simplest
> approach is to just use a vblank work here to do the delayed unpin.
>
> Not 100% sure it's a good idea to put this onto the same high priority vblank
> worker as eg. our timing critical gamma updates.
> But let's keep it simple for now, and it we later discover that this is
> causing
> problems we can think about adding a lower priority worker for such things.
>
> This patch is slightly reworked by Maarten
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Maarten Lankhorst
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_cursor.c | 26 +--
> drivers/gpu/drm/i915/display/intel_display.c | 3 +++
> .../drm/i915/display/intel_display_types.h| 3 +++
> 3 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index c780ce146131..36e2dcbe3614 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -710,6 +710,17 @@ static bool intel_cursor_format_mod_supported(struct
> drm_plane *_plane,
> return format == DRM_FORMAT_ARGB;
> }
>
> +static void intel_cursor_unpin_work(struct kthread_work *base) {
> + struct drm_vblank_work *work = to_drm_vblank_work(base);
> + struct intel_plane_state *plane_state =
> + container_of(work, typeof(*plane_state), unpin_work);
> + struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
> +
> + intel_plane_unpin_fb(plane_state);
> + intel_plane_destroy_state(&plane->base, &plane_state->uapi); }
> +
> static int
> intel_legacy_cursor_update(struct drm_plane *_plane,
> struct drm_crtc *_crtc,
> @@ -853,14 +864,25 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>
> intel_psr_unlock(crtc_state);
>
> - intel_plane_unpin_fb(old_plane_state);
> + if (old_plane_state->ggtt_vma != new_plane_state->ggtt_vma) {
> + drm_vblank_work_init(&old_plane_state->unpin_work, &crtc-
> >base,
> + intel_cursor_unpin_work);
> +
> + drm_vblank_work_schedule(&old_plane_state->unpin_work,
> +
> drm_crtc_accurate_vblank_count(&crtc->base) + 1,
> + false);
> +
> + old_plane_state = NULL;
> + } else {
> + intel_plane_unpin_fb(old_plane_state);
> + }
>
> out_free:
> if (new_crtc_state)
> intel_crtc_destroy_state(&crtc->base, &new_crtc_state->uapi);
> if (ret)
> intel_plane_destroy_state(&plane->base, &new_plane_state-
> >uapi);
> - else
> + else if (old_plane_state)
> intel_plane_destroy_state(&plane->base, &old_plane_state-
> >uapi);
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index cce1420fb541..715672c142b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -66,6 +66,7 @@
> #include "intel_crtc.h"
> #include "intel_crtc_state_dump.h"
> #include "intel_cursor_regs.h"
> +#include "intel_cursor.h"
> #include "intel_ddi.h"
> #include "intel_de.h"
> #include "intel_display_driver.h"
> @@ -6925,6 +6926,8 @@ static void intel_commit_modeset_disables(struct
> intel_atomic_state *state)
> continue;
>
> intel_crtc_disable_planes(state, crtc);
> +
> + drm_vblank_work_flush_all(&crtc->base);
> }
>
> /* Only disable port sync and MST slaves */ diff --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 9678c2b157f6..51fa73a2a161 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -735,6 +735,9 @@ struct intel_plane_state {
> struct intel_fb_view view;
> u32 phys_dma_addr; /* for cursor_needs_physical */
>
> + /* for legacy cursor fb unpin */
> + struct drm_vblank_work unpin_work;
> +
> /* Plane pxp decryption state */
> bool decrypt;
>
> --
> 2.43.0
RE: [v6 1/3] drm: Add drm_vblank_work_flush_all().
> -Original Message-
> From: Intel-xe On Behalf Of Maarten
> Lankhorst
> Sent: Wednesday, May 22, 2024 11:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Maarten Lankhorst
> ; Borah, Chaitanya Kumar
>
> Subject: [v6 1/3] drm: Add drm_vblank_work_flush_all().
Nit: Drop the "." from patch header
> In some cases we want to flush all vblank work, right before vblank_off for
> example. Add a simple function to make this possible.
>
> Check that both pending_work and running work are empty when flushing.
Have been closely following the developments and approaches.
This version looks good to me.
Reviewed-by: Uma Shankar
> Co-Developed-by: Chaitanya Kumar Borah
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_vblank_work.c | 22 ++
> include/drm/drm_vblank_work.h | 2 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_vblank_work.c
> b/drivers/gpu/drm/drm_vblank_work.c
> index 4fe9b1d3b00f..1752ffb44e1d 100644
> --- a/drivers/gpu/drm/drm_vblank_work.c
> +++ b/drivers/gpu/drm/drm_vblank_work.c
> @@ -232,6 +232,28 @@ void drm_vblank_work_flush(struct drm_vblank_work
> *work) } EXPORT_SYMBOL(drm_vblank_work_flush);
>
> +/**
> + * drm_vblank_work_flush_all - flush all currently pending vblank work on
> crtc.
> + * @crtc: crtc for which vblank work to flush
> + *
> + * Wait until all currently queued vblank work on @crtc
> + * has finished executing once.
> + */
> +void drm_vblank_work_flush_all(struct drm_crtc *crtc) {
> + struct drm_device *dev = crtc->dev;
> + struct drm_vblank_crtc *vblank = &dev->vblank[drm_crtc_index(crtc)];
> +
> + spin_lock_irq(&dev->event_lock);
> + wait_event_lock_irq(vblank->work_wait_queue,
> + list_empty(&vblank->pending_work),
> + dev->event_lock);
> + spin_unlock_irq(&dev->event_lock);
> +
> + kthread_flush_worker(vblank->worker);
> +}
> +EXPORT_SYMBOL(drm_vblank_work_flush_all);
> +
> /**
> * drm_vblank_work_init - initialize a vblank work item
> * @work: vblank work item
> diff --git a/include/drm/drm_vblank_work.h b/include/drm/drm_vblank_work.h
> index eb41d0810c4f..e04d436b7297 100644
> --- a/include/drm/drm_vblank_work.h
> +++ b/include/drm/drm_vblank_work.h
> @@ -17,6 +17,7 @@ struct drm_crtc;
> * drm_vblank_work_init()
> * drm_vblank_work_cancel_sync()
> * drm_vblank_work_flush()
> + * drm_vblank_work_flush_all()
> */
> struct drm_vblank_work {
> /**
> @@ -67,5 +68,6 @@ void drm_vblank_work_init(struct drm_vblank_work *work,
> struct drm_crtc *crtc,
> void (*func)(struct kthread_work *work)); bool
> drm_vblank_work_cancel_sync(struct drm_vblank_work *work); void
> drm_vblank_work_flush(struct drm_vblank_work *work);
> +void drm_vblank_work_flush_all(struct drm_crtc *crtc);
>
> #endif /* !_DRM_VBLANK_WORK_H_ */
> --
> 2.43.0
RE: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 63
> -Original Message- > From: Hogander, Jouni > Sent: Friday, May 17, 2024 1:02 PM > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line > count maximums are 63 > > On Fri, 2024-05-17 at 06:28 +, Shankar, Uma wrote: > > > > > > > -Original Message- > > > From: Intel-gfx On Behalf > > > Of Jouni Högander > > > Sent: Friday, May 3, 2024 11:36 AM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: Hogander, Jouni > > > Subject: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time > > > line count maximums are 63 > > > > > > On LunarLake maximum for IO and Fast Wake times are 63. Take this > > > into account in calculation and when writing the IO Wake lines. > > > > > > Bspec: 69885, 70294 > > > > > > Signed-off-by: Jouni Högander > > > --- > > > drivers/gpu/drm/i915/display/intel_psr.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > > > b/drivers/gpu/drm/i915/display/intel_psr.c > > > index f5b5a9ae..678987bbe168 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > > > @@ -1364,8 +1364,9 @@ static bool _compute_alpm_params(struct > > > intel_dp *intel_dp, > > > fast_wake_time = precharge + preamble + phy_wake + > > > tfw_exit_latency; > > > > > > - if (DISPLAY_VER(i915) >= 12) > > > - /* TODO: Check how we can use ALPM_CTL fast wake > > > extended field */ > > > + if (DISPLAY_VER(i915) >= 20) > > > + max_wake_lines = 63; > > > > As per spec, hardware will add 5 extra lines to the programmed value. > > For prior platforms it was set to 12 as 7 (3bits) + 5. I guess we > > should make this consistent. > > Thank you Uma for pointing this out. I have fixed this and the typo you > mentioned > on patch 3. Please recheck. Hi Jouni, Looks good, RB'ed now. You can go ahead for merge (seems some unrelated CI failures are there). Regards, Uma Shankar > BR, > > Jouni Högander > > > > Regards, > > Uma Shankar > > > > > + else if (DISPLAY_VER(i915) >= 12) > > > max_wake_lines = 12; > > > else > > > max_wake_lines = 8; > > > -- > > > 2.34.1 > >
RE: [PATCH v2 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 68
> -Original Message- > From: Hogander, Jouni > Sent: Friday, May 17, 2024 1:00 PM > To: intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Hogander, Jouni > > Subject: [PATCH v2 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line > count maximums are 68 > > On LunarLake maximum for IO and Fast Wake time line counts are 68: 6 bits + > 5 lines added by the HW. Take this into account in calculation and when > writing > the IO Wake lines. > > v2: maximum line count is 68 (6 bits + 5 lines added by HW) Looks Good to me. Reviewed-by: Uma Shankar > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/display/intel_psr.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index df0d14a5023f..f5d3eb776833 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -1421,8 +1421,9 @@ static bool _compute_alpm_params(struct intel_dp > *intel_dp, > fast_wake_time = precharge + preamble + phy_wake + > tfw_exit_latency; > > - if (DISPLAY_VER(i915) >= 12) > - /* TODO: Check how we can use ALPM_CTL fast wake extended > field */ > + if (DISPLAY_VER(i915) >= 20) > + max_wake_lines = 68; > + else if (DISPLAY_VER(i915) >= 12) > max_wake_lines = 12; > else > max_wake_lines = 8; > -- > 2.34.1
RE: [PATCH 3/3] drm/i915/psr: PSR2_CTL[Block Count Number] no needed for LunarLake
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Friday, May 3, 2024 11:36 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH 3/3] drm/i915/psr: PSR2_CTL[Block Count Number] no needed
> for LunarLake
Nit: s/no/not
Looks Good to me.
Reviewed-by: Uma Shankar
>
> PSR2_CTL[Block Count Number] is not used by LunarLake do not configure it.
>
> Bspec: 69885
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 4d67a384e149..5ebfe4244d51 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -869,7 +869,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> val |= intel_psr2_get_tp_time(intel_dp);
>
> - if (DISPLAY_VER(dev_priv) >= 12) {
> + if (DISPLAY_VER(dev_priv) >= 12 && DISPLAY_VER(dev_priv) < 20) {
> if (psr2_block_count(intel_dp) > 2)
> val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_3;
> else
> --
> 2.34.1
RE: [PATCH 2/3] drm/i915/psr: LunarLake PSR2_CTL[IO Wake Lines] is 6 bits wide
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Friday, May 3, 2024 11:36 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH 2/3] drm/i915/psr: LunarLake PSR2_CTL[IO Wake Lines] is 6 bits
> wide
>
> On LunarLake PSR2_CTL[IO Wake Lines] contains now bit 13:18. Take this into
> account when enabling PSR2_CTL.
Looks Good to me.
Reviewed-by: Uma Shankar
> Bspec: 69885
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 2 ++
> drivers/gpu/drm/i915/display/intel_psr_regs.h | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 678987bbe168..4d67a384e149 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -900,6 +900,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> tmp = map[psr->alpm_parameters.fast_wake_lines -
> TGL_EDP_PSR2_FAST_WAKE_MIN_LINES];
> val |= TGL_EDP_PSR2_FAST_WAKE(tmp +
> TGL_EDP_PSR2_FAST_WAKE_MIN_LINES);
> + } else if (DISPLAY_VER(dev_priv) >= 20) {
> + val |=
> +LNL_EDP_PSR2_IO_BUFFER_WAKE(psr->alpm_parameters.io_wake_lines);
> } else if (DISPLAY_VER(dev_priv) >= 12) {
> val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(psr-
> >alpm_parameters.io_wake_lines);
> val |= TGL_EDP_PSR2_FAST_WAKE(psr-
> >alpm_parameters.fast_wake_lines);
> diff --git a/drivers/gpu/drm/i915/display/intel_psr_regs.h
> b/drivers/gpu/drm/i915/display/intel_psr_regs.h
> index ebc22999572c..68381bbf462e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_psr_regs.h
> @@ -172,6 +172,10 @@
> #define TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES 5
> #define TGL_EDP_PSR2_IO_BUFFER_WAKE(lines)
> REG_FIELD_PREP(TGL_EDP_PSR2_IO_BUFFER_WAKE_MASK, \
> (lines) -
> TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES)
> +#define LNL_EDP_PSR2_IO_BUFFER_WAKE_MASK REG_GENMASK(18, 13)
> +#define LNL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES 5
> +#define LNL_EDP_PSR2_IO_BUFFER_WAKE(lines)
> REG_FIELD_PREP(LNL_EDP_PSR2_IO_BUFFER_WAKE_MASK, \
> +(lines) -
> LNL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES)
> #define EDP_PSR2_FAST_WAKE_MASKREG_GENMASK(12, 11)
> #define EDP_PSR2_FAST_WAKE_MAX_LINES 8
> #define EDP_PSR2_FAST_WAKE(lines)
> REG_FIELD_PREP(EDP_PSR2_FAST_WAKE_MASK, \
> --
> 2.34.1
RE: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 63
> -Original Message- > From: Intel-gfx On Behalf Of Jouni > Högander > Sent: Friday, May 3, 2024 11:36 AM > To: intel-gfx@lists.freedesktop.org > Cc: Hogander, Jouni > Subject: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count > maximums are 63 > > On LunarLake maximum for IO and Fast Wake times are 63. Take this into > account in calculation and when writing the IO Wake lines. > > Bspec: 69885, 70294 > > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/display/intel_psr.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index f5b5a9ae..678987bbe168 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -1364,8 +1364,9 @@ static bool _compute_alpm_params(struct intel_dp > *intel_dp, > fast_wake_time = precharge + preamble + phy_wake + > tfw_exit_latency; > > - if (DISPLAY_VER(i915) >= 12) > - /* TODO: Check how we can use ALPM_CTL fast wake extended > field */ > + if (DISPLAY_VER(i915) >= 20) > + max_wake_lines = 63; As per spec, hardware will add 5 extra lines to the programmed value. For prior platforms it was set to 12 as 7 (3bits) + 5. I guess we should make this consistent. Regards, Uma Shankar > + else if (DISPLAY_VER(i915) >= 12) > max_wake_lines = 12; > else > max_wake_lines = 8; > -- > 2.34.1
RE: [v4] drm/i915: Implement Audio WA_14020863754
> -Original Message-
> From: Shankar, Uma
> Sent: Thursday, May 9, 2024 11:05 AM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ;
> jani.nik...@linux.intel.com; Roper, Matthew D ;
> Shankar, Uma
> Subject: [v4] drm/i915: Implement Audio WA_14020863754
>
> WA_14020863754: Corner case with Min Hblank Fix can cause audio hang
>
> Issue: Previously a fix was made to avoid issues with extremely small hblanks,
> called the "Min Hblank Fix". However, this can potentially cause an audio
> hang.
>
> Workaround :
> During "Audio Programming Sequence" Audio Enabling - When DP mode is
> enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable audio
> Presence Detect"
>
> During "Audio Programming Sequence" Audio Disabling - When DP mode is
> enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable Audio PD
> (Presence Detect)"
> If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = 1b)
>
> v2: Update the platform checks (Jani Nikula)
>
> v3: Limited the WA to LNL and BMG, added a helper (Matt Roper)
>
> v4: Updated the bit naming, fixed redundant if statement
Pushed to drm-intel-next. Thanks for the reviews.
Regards,
Uma Shankar
> Signed-off-by: Uma Shankar
> Reviewed-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 15 +++
> drivers/gpu/drm/i915/display/intel_audio_regs.h | 3 +++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index ed81e1466c4b..adde87900557 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -183,6 +183,15 @@ static const struct hdmi_aud_ncts
> hdmi_aud_ncts_36bpp[] = {
> { 192000, TMDS_445_5M, 20480, 371250 }, };
>
> +/*
> + * WA_14020863754: Implement Audio Workaround
> + * Corner case with Min Hblank Fix can cause audio hang */ static bool
> +needs_wa_14020863754(struct drm_i915_private *i915) {
> + return (DISPLAY_VER(i915) == 20 || IS_BATTLEMAGE(i915)); }
> +
> /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */ static u32
> audio_config_hdmi_pixel_clock(const struct intel_crtc_state *crtc_state) {
> @@ -
> 415,6 +424,9 @@ static void hsw_audio_codec_disable(struct intel_encoder
> *encoder,
> intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
>AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0);
>
> + if (needs_wa_14020863754(i915))
> + intel_de_rmw(i915, AUD_CHICKENBIT_REG3,
> DACBE_DISABLE_MIN_HBLANK_FIX,
> +0);
> +
> mutex_unlock(&i915->display.audio.mutex);
> }
>
> @@ -540,6 +552,9 @@ static void hsw_audio_codec_enable(struct
> intel_encoder *encoder,
> if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP))
> enable_audio_dsc_wa(encoder, crtc_state);
>
> + if (needs_wa_14020863754(i915))
> + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0,
> +DACBE_DISABLE_MIN_HBLANK_FIX);
> +
> /* Enable audio presence detect */
> intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
>0, AUDIO_OUTPUT_ENABLE(cpu_transcoder));
> diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> index 88ea2740365d..4c31844d21df 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> @@ -164,4 +164,7 @@
>
> _VLV_AUD_PORT_EN_D_DBG)
> #define VLV_AMP_MUTE (1 << 1)
>
> +#define AUD_CHICKENBIT_REG3 _MMIO(0x65F1C)
> +#define DACBE_DISABLE_MIN_HBLANK_FIXREG_BIT(18)
> +
> #endif /* __INTEL_AUDIO_REGS_H__ */
> --
> 2.42.0
RE: [PATCH 0/7] Enable Aux Based EDP HDR
> -Original Message- > From: Kandpal, Suraj > Sent: Tuesday, May 7, 2024 9:34 AM > To: intel-gfx@lists.freedesktop.org > Cc: Borah, Chaitanya Kumar ; Shankar, Uma > ; Nautiyal, Ankit K ; > Murthy, Arun R ; Kandpal, Suraj > > Subject: [PATCH 0/7] Enable Aux Based EDP HDR > > This series enables Aux based EDP HDR and backlight controls. > The DPCD written to are intel proprietary and are filled based on the specs > that > were provided to TCON vendors. Merged to drm-intel-next. Thanks for the patches and reviews. Regards, Uma Shankar > Signed-off-by: Suraj Kandpal > > Suraj Kandpal (7): > drm/i915/dp: Make has_gamut_metadata_dip() non static > drm/i915/dp: Rename intel struct inside intel_panel > drm/i915/dp: Add TCON HDR capability checks > drm/i915/dp: Fix Register bit naming > drm/i915/dp: Drop comments on EDP HDR DPCD registers > drm/i915/dp: Enable AUX based backlight for HDR > drm/i915/dp: Write panel override luminance values > > .../drm/i915/display/intel_display_types.h| 7 +- > drivers/gpu/drm/i915/display/intel_dp.c | 6 +- > drivers/gpu/drm/i915/display/intel_dp.h | 1 + > .../drm/i915/display/intel_dp_aux_backlight.c | 149 +++--- > 4 files changed, 140 insertions(+), 23 deletions(-) > > -- > 2.43.2
RE: [v3] drm/i915: Implement Audio WA_14020863754
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, May 7, 2024 4:12 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> intel...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Roper,
> Matthew D ; Shankar, Uma
>
> Subject: Re: [v3] drm/i915: Implement Audio WA_14020863754
>
> On Mon, 06 May 2024, Uma Shankar wrote:
> > WA_14020863754: Corner case with Min Hblank Fix can cause audio hang
> >
> > Issue: Previously a fix was made to avoid issues with extremely small
> > hblanks, called the "Min Hblank Fix". However, this can potentially
> > cause an audio hang.
> >
> > Workaround :
> > During "Audio Programming Sequence" Audio Enabling - When DP mode is
> > enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable
> > audio Presence Detect"
> >
> > During "Audio Programming Sequence" Audio Disabling - When DP mode is
> > enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable
> > Audio PD (Presence Detect)"
> > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave =
> > 1b)
> >
> > v2: Update the platform checks (Jani Nikula)
> >
> > v3: Limited the WA to LNL and BMG, added a helper (Matt Roper)
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_audio.c | 18 ++
> > .../gpu/drm/i915/display/intel_audio_regs.h| 3 +++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index ed81e1466c4b..cb055c16dd98 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -183,6 +183,18 @@ static const struct hdmi_aud_ncts
> hdmi_aud_ncts_36bpp[] = {
> > { 192000, TMDS_445_5M, 20480, 371250 }, };
> >
> > +/*
> > + * WA_14020863754: Implement Audio Workaround
> > + * Corner case with Min Hblank Fix can cause audio hang */ static
> > +bool needs_wa_14020863754(struct drm_i915_private *i915) {
> > + if (DISPLAY_VER(i915) == 20 || IS_BATTLEMAGE(i915))
>
> Why do we need to check for both display version and the platform?
> Especially weird that it's || and not &&.
Hi Jani,
WA is applicable for display version 20 and any derivative, but it was also
needed on BMG (which is based out of MTL i.e ver14).
Hence added this condition along with a ||.
> > + return true;
> > +
> > + return false;
>
> The whole function is just "return ver == 20 || is_bmg", there's no need to
> have
> the if and two different return locations.
Yeah right, will drop the redundant if.
Regards,
Uma Shankar
>
> BR,
> Jani.
>
>
> > +}
> > +
> > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */ static u32
> > audio_config_hdmi_pixel_clock(const struct intel_crtc_state
> > *crtc_state) { @@ -415,6 +427,9 @@ static void
> > hsw_audio_codec_disable(struct intel_encoder *encoder,
> > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
> > AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0);
> >
> > + if (needs_wa_14020863754(i915))
> > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3,
> CHICKEN3_SPARE18, 0);
> > +
> > mutex_unlock(&i915->display.audio.mutex);
> > }
> >
> > @@ -540,6 +555,9 @@ static void hsw_audio_codec_enable(struct
> intel_encoder *encoder,
> > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP))
> > enable_audio_dsc_wa(encoder, crtc_state);
> >
> > + if (needs_wa_14020863754(i915))
> > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0,
> CHICKEN3_SPARE18);
> > +
> > /* Enable audio presence detect */
> > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
> > 0, AUDIO_OUTPUT_ENABLE(cpu_transcoder));
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > index 88ea2740365d..7de82cd3380e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > @@ -164,4 +164,7 @@
> >
> _VLV_AUD_PORT_EN_D_DBG)
> > #define VLV_AMP_MUTE (1 << 1)
> >
> > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C)
> > +#define CHICKEN3_SPARE18 REG_BIT(18)
> > +
> > #endif /* __INTEL_AUDIO_REGS_H__ */
>
> --
> Jani Nikula, Intel
RE: [v3] drm/i915: Implement Audio WA_14020863754
> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Tuesday, May 7, 2024 1:48 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> intel...@lists.freedesktop.org
> Cc: jani.nik...@linux.intel.com; Roper, Matthew D
> Subject: RE: [v3] drm/i915: Implement Audio WA_14020863754
>
>
>
> > -Original Message-
> > From: Shankar, Uma
> > Sent: Monday, May 6, 2024 3:48 PM
> > To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> > Cc: Borah, Chaitanya Kumar ;
> > jani.nik...@linux.intel.com; Roper, Matthew D
> > ; Shankar, Uma
> > Subject: [v3] drm/i915: Implement Audio WA_14020863754
> >
> > WA_14020863754: Corner case with Min Hblank Fix can cause audio hang
> >
> > Issue: Previously a fix was made to avoid issues with extremely small
> > hblanks, called the "Min Hblank Fix". However, this can potentially
> > cause an audio hang.
> >
> > Workaround :
> > During "Audio Programming Sequence" Audio Enabling - When DP mode is
> > enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable
> > audio Presence Detect"
> >
> > During "Audio Programming Sequence" Audio Disabling - When DP mode is
> > enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable
> > Audio PD (Presence Detect)"
> > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave =
> > 1b)
> >
> > v2: Update the platform checks (Jani Nikula)
> >
> > v3: Limited the WA to LNL and BMG, added a helper (Matt Roper)
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_audio.c | 18 ++
> > .../gpu/drm/i915/display/intel_audio_regs.h| 3 +++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index ed81e1466c4b..cb055c16dd98 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -183,6 +183,18 @@ static const struct hdmi_aud_ncts
> > hdmi_aud_ncts_36bpp[] = {
> > { 192000, TMDS_445_5M, 20480, 371250 }, };
> >
> > +/*
> > + * WA_14020863754: Implement Audio Workaround
> > + * Corner case with Min Hblank Fix can cause audio hang */ static
> > +bool needs_wa_14020863754(struct drm_i915_private *i915) {
> > + if (DISPLAY_VER(i915) == 20 || IS_BATTLEMAGE(i915))
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */ static u32
> > audio_config_hdmi_pixel_clock(const struct intel_crtc_state
> > *crtc_state) { @@ -415,6 +427,9 @@ static void
> > hsw_audio_codec_disable(struct intel_encoder *encoder,
> > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
> > AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0);
> >
> > + if (needs_wa_14020863754(i915))
> > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3,
> > CHICKEN3_SPARE18, 0);
> > +
> > mutex_unlock(&i915->display.audio.mutex);
> > }
> >
> > @@ -540,6 +555,9 @@ static void hsw_audio_codec_enable(struct
> > intel_encoder *encoder,
> > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP))
> > enable_audio_dsc_wa(encoder, crtc_state);
> >
> > + if (needs_wa_14020863754(i915))
> > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0,
> > CHICKEN3_SPARE18);
> > +
> > /* Enable audio presence detect */
> > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
> > 0, AUDIO_OUTPUT_ENABLE(cpu_transcoder));
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > index 88ea2740365d..7de82cd3380e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > @@ -164,4 +164,7 @@
> >
> > _VLV_AUD_PORT_EN_D_DBG)
> > #define VLV_AMP_MUTE (1 << 1)
> >
> > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C)
> > +#define CHICKEN3_SPARE18 REG_BIT(18)
>
> Nit. This bit seems to have a name now (Bspec-69036). Otherwise, LGTM.
Yeah this got renamed now, will update the name.
Thanks for the review.
Regards,
Uma Shankar
> Reviewed-by: Chaitanya Kumar Borah
>
>
> > +
> > #endif /* __INTEL_AUDIO_REGS_H__ */
> > --
> > 2.42.0
RE: [PATCH] drm/i915/audio: Fix audio time stamp programming for DP
> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Tuesday, April 30, 2024 2:48 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vehmanen, Kai ; Saarinen, Jani
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; Yang, Libin ; Shankar, Uma
>
> Subject: [PATCH] drm/i915/audio: Fix audio time stamp programming for DP
>
> Intel hardware is capable of programming the Maud/Naud SDPs on its own based
> on real-time clocks. While doing so, it takes care of any deviations from the
> theoretical values. Programming the registers explicitly with static values
> can
> interfere with this logic. Therefore, let the HW decide the Maud and Naud SDPs
> on it's own.
Based on internal discussions with hardware team and validation on various
platforms,
Maud/Naud programming can be dropped. Looks ok to me.
Reviewed-by: Uma Shankar
> Cc: sta...@vger.kernel.org # v5.17
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097
> Co-developed-by: Kai Vehmanen
> Signed-off-by: Kai Vehmanen
> Signed-off-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 113 ++---
> 1 file changed, 8 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 07e0c73204f3..ed81e1466c4b 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -76,19 +76,6 @@ struct intel_audio_funcs {
> struct intel_crtc_state *crtc_state); };
>
> -/* DP N/M table */
> -#define LC_810M 81
> -#define LC_540M 54
> -#define LC_270M 27
> -#define LC_162M 162000
> -
> -struct dp_aud_n_m {
> - int sample_rate;
> - int clock;
> - u16 m;
> - u16 n;
> -};
> -
> struct hdmi_aud_ncts {
> int sample_rate;
> int clock;
> @@ -96,60 +83,6 @@ struct hdmi_aud_ncts {
> int cts;
> };
>
> -/* Values according to DP 1.4 Table 2-104 */ -static const struct dp_aud_n_m
> dp_aud_n_m[] = {
> - { 32000, LC_162M, 1024, 10125 },
> - { 44100, LC_162M, 784, 5625 },
> - { 48000, LC_162M, 512, 3375 },
> - { 64000, LC_162M, 2048, 10125 },
> - { 88200, LC_162M, 1568, 5625 },
> - { 96000, LC_162M, 1024, 3375 },
> - { 128000, LC_162M, 4096, 10125 },
> - { 176400, LC_162M, 3136, 5625 },
> - { 192000, LC_162M, 2048, 3375 },
> - { 32000, LC_270M, 1024, 16875 },
> - { 44100, LC_270M, 784, 9375 },
> - { 48000, LC_270M, 512, 5625 },
> - { 64000, LC_270M, 2048, 16875 },
> - { 88200, LC_270M, 1568, 9375 },
> - { 96000, LC_270M, 1024, 5625 },
> - { 128000, LC_270M, 4096, 16875 },
> - { 176400, LC_270M, 3136, 9375 },
> - { 192000, LC_270M, 2048, 5625 },
> - { 32000, LC_540M, 1024, 33750 },
> - { 44100, LC_540M, 784, 18750 },
> - { 48000, LC_540M, 512, 11250 },
> - { 64000, LC_540M, 2048, 33750 },
> - { 88200, LC_540M, 1568, 18750 },
> - { 96000, LC_540M, 1024, 11250 },
> - { 128000, LC_540M, 4096, 33750 },
> - { 176400, LC_540M, 3136, 18750 },
> - { 192000, LC_540M, 2048, 11250 },
> - { 32000, LC_810M, 1024, 50625 },
> - { 44100, LC_810M, 784, 28125 },
> - { 48000, LC_810M, 512, 16875 },
> - { 64000, LC_810M, 2048, 50625 },
> - { 88200, LC_810M, 1568, 28125 },
> - { 96000, LC_810M, 1024, 16875 },
> - { 128000, LC_810M, 4096, 50625 },
> - { 176400, LC_810M, 3136, 28125 },
> - { 192000, LC_810M, 2048, 16875 },
> -};
> -
> -static const struct dp_aud_n_m *
> -audio_config_dp_get_n_m(const struct intel_crtc_state *crtc_state, int rate)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(dp_aud_n_m); i++) {
> - if (rate == dp_aud_n_m[i].sample_rate &&
> - crtc_state->port_clock == dp_aud_n_m[i].clock)
> - return &dp_aud_n_m[i];
> - }
> -
> - return NULL;
> -}
> -
> static const struct {
> int clock;
> u32 config;
> @@ -387,47 +320,17 @@ hsw_dp_audio_config_update(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *crtc_state) {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> - struct i915_audio_component *acomp = i915->display.audio.component;
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - enum port port = encoder->port;
> - const struct dp_aud_n_m *nm;
> - int rate;
> - u32 tmp;
> -
> - rate = acomp ? acomp->aud_sample_rate[
RE: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks
> -Original Message- > From: Luca Coelho > Sent: Friday, April 12, 2024 5:57 PM > To: Shankar, Uma ; Coelho, Luciano > ; intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula, > Jani > > Subject: Re: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks > > On Fri, 2024-04-12 at 10:30 +, Shankar, Uma wrote: > > > > > -Original Message- > > > From: Coelho, Luciano > > > Sent: Friday, April 12, 2024 3:12 PM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: intel...@lists.freedesktop.org; Shankar, Uma > > > ; ville.syrj...@linux.intel.com; Nikula, Jani > > > > > > Subject: [PATCH v5 1/4] drm/i915/display: add support for DMC > > > wakelocks > > > > > > In order to reduce the DC5->DC2 restore time, wakelocks have been > > > introduced in DMC so the driver can tell it when registers and other > > > memory areas are going to be accessed and keep their respective blocks > awake. > > > > > > Implement this in the driver by adding the concept of DMC wakelocks. > > > When the driver needs to access memory which lies inside pre-defined > > > ranges, it will tell DMC to set the wakelock, access the memory, > > > then wait for a while and clear the wakelock. > > > > > > The wakelock state is protected in the driver with spinlocks to > > > prevent concurrency issues. > > > > Hi Luca, > > Seems you missed to add the version history. > > I've been sending the version history in the cover letter, because I don't > think it > adds any information after it gets to the mainline kernel. The history is > lost > anyway, so the mailing list is a better place to store it (it's unique and > meaningful > there). Its matter of preference, but being part of the patch's commit message it stays with it and can be checked with a git show. Cover letter details gets lost though as it doesn't end up in the tree. > Bur as I said to someone else before, I can add it to the commit message if > you > think that it's needed. Not needed Luca, it was a simple nitpick 😊. You can skip that. > > > > Anyways, changes look good to me. > > Reviewed-by: Uma Shankar > > Thanks a lot! > > Though you didn't review patch 3/4, the one about the module parameter. > Was that intentional or did you just miss it? I think I have reviewed and RB'ed it. The entire series is RB'ed now. Regards, Uma Shankar > -- > Cheers, > Luca.
RE: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks
> -Original Message-
> From: Coelho, Luciano
> Sent: Friday, April 12, 2024 3:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani
> Subject: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks
>
> In order to reduce the DC5->DC2 restore time, wakelocks have been introduced
> in DMC so the driver can tell it when registers and other memory areas are
> going
> to be accessed and keep their respective blocks awake.
>
> Implement this in the driver by adding the concept of DMC wakelocks.
> When the driver needs to access memory which lies inside pre-defined ranges,
> it
> will tell DMC to set the wakelock, access the memory, then wait for a while
> and
> clear the wakelock.
>
> The wakelock state is protected in the driver with spinlocks to prevent
> concurrency issues.
Hi Luca,
Seems you missed to add the version history.
Anyways, changes look good to me.
Reviewed-by: Uma Shankar
Regards,
Uma Shankar
> BSpec: 71583
> Signed-off-by: Luca Coelho
> ---
> Documentation/gpu/i915.rst| 9 +
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_de.h | 97 +++-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +
> drivers/gpu/drm/i915/display/intel_dmc_regs.h | 6 +
> drivers/gpu/drm/i915/display/intel_dmc_wl.c | 234 ++
> drivers/gpu/drm/i915/display/intel_dmc_wl.h | 31 +++
> drivers/gpu/drm/xe/Makefile | 1 +
> 8 files changed, 373 insertions(+), 8 deletions(-) create mode 100644
> drivers/gpu/drm/i915/display/intel_dmc_wl.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_dmc_wl.h
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index
> 0ca1550fd9dc..17261ba18313 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -204,6 +204,15 @@ DMC Firmware Support .. kernel-doc::
> drivers/gpu/drm/i915/display/intel_dmc.c
> :internal:
>
> +DMC wakelock support
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> + :doc: DMC wakelock support
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> + :internal:
> +
> Video BIOS Table (VBT)
> --
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index af9e871daf1d..7cad944b825c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -266,6 +266,7 @@ i915-y += \
> display/intel_display_rps.o \
> display/intel_display_wa.o \
> display/intel_dmc.o \
> + display/intel_dmc_wl.o \
> display/intel_dpio_phy.o \
> display/intel_dpll.o \
> display/intel_dpll_mgr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index ba7a1c6ebc2a..0a0fba81e7af 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -13,52 +13,125 @@
> static inline u32
> intel_de_read(struct drm_i915_private *i915, i915_reg_t reg) {
> - return intel_uncore_read(&i915->uncore, reg);
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> }
>
> static inline u8
> intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg) {
> - return intel_uncore_read8(&i915->uncore, reg);
> + u8 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read8(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> }
>
> static inline u64
> intel_de_read64_2x32(struct drm_i915_private *i915,
>i915_reg_t lower_reg, i915_reg_t upper_reg) {
> - return intel_uncore_read64_2x32(&i915->uncore, lower_reg,
> upper_reg);
> + u64 val;
> +
> + intel_dmc_wl_get(i915, lower_reg);
> + intel_dmc_wl_get(i915, upper_reg);
> +
> + val = intel_uncore_read64_2x32(&i915->uncore, lower_reg, upper_reg);
> +
> + intel_dmc_wl_put(i915, upper_reg);
> + intel_dmc_wl_put(i915, lower_reg);
> +
> + return val;
> }
>
> static inline void
> intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg) {
> + intel_dmc_wl_get(i915, reg);
> +
> intel_uncore_posting_read(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> }
>
> static in
RE: [v2] drm/i915: Implement Audio WA_14020863754
> -Original Message- > From: Roper, Matthew D > Sent: Friday, April 12, 2024 4:07 AM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org; Borah, > Chaitanya Kumar ; > jani.nik...@linux.intel.com > Subject: Re: [v2] drm/i915: Implement Audio WA_14020863754 > > On Wed, Apr 10, 2024 at 07:20:46PM +0530, Uma Shankar wrote: > > WA_14020863754: Corner case with Min Hblank Fix can cause audio hang > > > > Issue: Previously a fix was made to avoid issues with extremely small > > hblanks, called the "Min Hblank Fix". However, this can potentially > > cause an audio hang. > > > > Workaround : > > During "Audio Programming Sequence" Audio Enabling - When DP mode is > > enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable > > audio Presence Detect" > > > > During "Audio Programming Sequence" Audio Disabling - When DP mode is > > enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable > > Audio PD (Presence Detect)" > > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = > > 1b) > > > > v2: Update the platform checks (Jani Nikula) > > > > Signed-off-by: Uma Shankar > > --- > > drivers/gpu/drm/i915/display/intel_audio.c | 14 ++ > > drivers/gpu/drm/i915/display/intel_audio_regs.h | 3 +++ > > 2 files changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c > > b/drivers/gpu/drm/i915/display/intel_audio.c > > index 07e0c73204f3..61df5115c970 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio.c > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > > @@ -512,6 +512,13 @@ static void hsw_audio_codec_disable(struct > intel_encoder *encoder, > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0); > > > > + /* > > +* WA_14020863754: Implement Audio Workaround > > +* Corner case with Min Hblank Fix can cause audio hang > > +*/ > > + if (DISPLAY_VER(i915) >= 20) > > The workaround is currently listed as applying to both Xe2_LPD (20.00) and > Xe2_HPD (14.01). So we should match on those precise IP versions for now. > Future platforms and/or refreshes may or may not need this workaround and we > don't want to just assume the workaround will carry forward forever, so the > condition may get updated further as new platforms/IP versions are added to > the > driver. Hi Matt, Yes, agree to limit till platforms where we have visibility. Should I just keep it for LNL and add BMG later once the PE changes get merged and the macros become available? Also, will add the helper as you suggested. Regards, Uma Shankar > > Matt > > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, > CHICKEN3_SPARE18, 0); > > + > > mutex_unlock(&i915->display.audio.mutex); > > } > > > > @@ -637,6 +644,13 @@ static void hsw_audio_codec_enable(struct > intel_encoder *encoder, > > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP)) > > enable_audio_dsc_wa(encoder, crtc_state); > > > > + /* > > +* WA_14020863754: Implement Audio Workaround > > +* Corner case with Min Hblank Fix can cause audio hang > > +*/ > > + if (DISPLAY_VER(i915) >= 20) > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0, > CHICKEN3_SPARE18); > > + > > /* Enable audio presence detect */ > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > 0, AUDIO_OUTPUT_ENABLE(cpu_transcoder)); > > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > index 616e7b1275c4..6f8d33299ecd 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > @@ -148,4 +148,7 @@ > > #define HBLANK_START_COUNT_96 4 > > #define HBLANK_START_COUNT_128 5 > > > > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C) > > +#define CHICKEN3_SPARE18 REG_BIT(18) > > + > > #endif /* __INTEL_AUDIO_REGS_H__ */ > > -- > > 2.42.0 > > > > -- > Matt Roper > Graphics Software Engineer > Linux GPU Platform Enablement > Intel Corporation
RE: [PATCH v4 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state transitions
> -Original Message- > From: Coelho, Luciano > Sent: Thursday, April 4, 2024 5:12 PM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org; Shankar, Uma ; > ville.syrj...@linux.intel.com; Nikula, Jani > Subject: [PATCH v4 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state > transitions > > We only need DMC wakelocks when we allow DC5 and DC6 states. Add the calls > to enable and disable DMC wakelock accordingly. Looks Good to me. Reviewed-by: Uma Shankar > Signed-off-by: Luca Coelho > --- > drivers/gpu/drm/i915/display/intel_display_power_well.c | 7 +++ > drivers/gpu/drm/i915/display/intel_dmc.c| 4 > 2 files changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c > b/drivers/gpu/drm/i915/display/intel_display_power_well.c > index e4de40228997..7f4b7602cf02 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c > @@ -17,6 +17,7 @@ > #include "intel_dkl_phy.h" > #include "intel_dkl_phy_regs.h" > #include "intel_dmc.h" > +#include "intel_dmc_wl.h" > #include "intel_dp_aux_regs.h" > #include "intel_dpio_phy.h" > #include "intel_dpll.h" > @@ -821,6 +822,8 @@ void gen9_enable_dc5(struct drm_i915_private > *dev_priv) > intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, >0, SKL_SELECT_ALTERNATE_DC_EXIT); > > + intel_dmc_wl_enable(dev_priv); > + > gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC5); } > > @@ -850,6 +853,8 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv) > intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, >0, SKL_SELECT_ALTERNATE_DC_EXIT); > > + intel_dmc_wl_enable(dev_priv); > + > gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6); } > > @@ -970,6 +975,8 @@ void gen9_disable_dc_states(struct drm_i915_private > *dev_priv) > if (!HAS_DISPLAY(dev_priv)) > return; > > + intel_dmc_wl_disable(dev_priv); > + > intel_cdclk_get_cdclk(dev_priv, &cdclk_config); > /* Can't read out voltage_level so can't use intel_cdclk_changed() */ > drm_WARN_ON(&dev_priv->drm, > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c > b/drivers/gpu/drm/i915/display/intel_dmc.c > index 3fa851b5c7a6..b20cc018b9a8 100644 > --- a/drivers/gpu/drm/i915/display/intel_dmc.c > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c > @@ -550,6 +550,8 @@ void intel_dmc_disable_program(struct > drm_i915_private *i915) > pipedmc_clock_gating_wa(i915, true); > disable_all_event_handlers(i915); > pipedmc_clock_gating_wa(i915, false); > + > + intel_dmc_wl_disable(i915); > } > > void assert_dmc_loaded(struct drm_i915_private *i915) @@ -1079,6 +1081,8 > @@ void intel_dmc_suspend(struct drm_i915_private *i915) > if (dmc) > flush_work(&dmc->work); > > + intel_dmc_wl_disable(i915); > + > /* Drop the reference held in case DMC isn't loaded. */ > if (!intel_dmc_has_payload(i915)) > intel_dmc_runtime_pm_put(i915); > -- > 2.39.2
RE: [PATCH v4 2/4] drm/i915/display: don't allow DMC wakelock on older hardware
> -Original Message-
> From: Coelho, Luciano
> Sent: Thursday, April 4, 2024 5:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani
> Subject: [PATCH v4 2/4] drm/i915/display: don't allow DMC wakelock on older
> hardware
>
> Only allow running DMC wakelock code if the display version is 20 or greater.
> Also
> check if DMC is loaded before enabling.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Luca Coelho
> ---
> .../drm/i915/display/intel_display_driver.c | 1 +
> drivers/gpu/drm/i915/display/intel_dmc_wl.c | 26 +++
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 87dd07e0d138..e4015557af6a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -198,6 +198,7 @@ void intel_display_driver_early_probe(struct
> drm_i915_private *i915)
> intel_dpll_init_clock_hook(i915);
> intel_init_display_hooks(i915);
> intel_fdi_init_hook(i915);
> + intel_dmc_wl_init(i915);
> }
>
> /* part #1: call before irq install */
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> index 3d7cf47321c2..065652fc475c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> @@ -6,6 +6,7 @@
> #include
>
> #include "intel_de.h"
> +#include "intel_dmc.h"
> #include "intel_dmc_regs.h"
> #include "intel_dmc_wl.h"
>
> @@ -110,10 +111,23 @@ static bool intel_dmc_wl_check_range(u32 address)
> return wl_needed;
> }
>
> +static bool __intel_dmc_wl_supported(struct drm_i915_private *i915) {
> + if (DISPLAY_VER(i915) < 20 ||
> + !intel_dmc_has_payload(i915))
> + return false;
> +
> + return true;
> +}
> +
> void intel_dmc_wl_init(struct drm_i915_private *i915) {
> struct intel_dmc_wl *wl = &i915->display.wl;
>
> + /* don't call __intel_dmc_wl_supported(), DMC is not loaded yet */
> + if (DISPLAY_VER(i915) < 20)
> + return;
> +
> INIT_DELAYED_WORK(&wl->work, intel_dmc_wl_work);
> spin_lock_init(&wl->lock);
> refcount_set(&wl->refcount, 0);
> @@ -124,6 +138,9 @@ void intel_dmc_wl_enable(struct drm_i915_private
> *i915)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
> spin_lock_irqsave(&wl->lock, flags);
>
> if (wl->enabled)
> @@ -148,6 +165,9 @@ void intel_dmc_wl_disable(struct drm_i915_private
> *i915)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
> flush_delayed_work(&wl->work);
>
> spin_lock_irqsave(&wl->lock, flags);
> @@ -171,6 +191,9 @@ void intel_dmc_wl_get(struct drm_i915_private *i915,
> i915_reg_t reg)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
> if (!intel_dmc_wl_check_range(reg.reg))
> return;
>
> @@ -215,6 +238,9 @@ void intel_dmc_wl_put(struct drm_i915_private *i915,
> i915_reg_t reg)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
> if (!intel_dmc_wl_check_range(reg.reg))
> return;
>
> --
> 2.39.2
RE: [PATCH v4 1/4] drm/i915/display: add support for DMC wakelocks
> -Original Message-
> From: Coelho, Luciano
> Sent: Thursday, April 4, 2024 5:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani
> Subject: [PATCH v4 1/4] drm/i915/display: add support for DMC wakelocks
>
> In order to reduce the DC5->DC2 restore time, wakelocks have been introduced
> in DMC so the driver can tell it when registers and other memory areas are
> going
> to be accessed and keep their respective blocks awake.
>
> Implement this in the driver by adding the concept of DMC wakelocks.
> When the driver needs to access memory which lies inside pre-defined ranges,
> it
> will tell DMC to set the wakelock, access the memory, then wait for a while
> and
> clear the wakelock.
>
> The wakelock state is protected in the driver with spinlocks to prevent
> concurrency issues.
>
> BSpec: 71583
> Signed-off-by: Luca Coelho
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_de.h | 97 ++-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +
> drivers/gpu/drm/i915/display/intel_dmc_regs.h | 6 +
> drivers/gpu/drm/i915/display/intel_dmc_wl.c | 238 ++
> drivers/gpu/drm/i915/display/intel_dmc_wl.h | 31 +++
> drivers/gpu/drm/xe/Makefile | 1 +
> 7 files changed, 368 insertions(+), 8 deletions(-) create mode 100644
> drivers/gpu/drm/i915/display/intel_dmc_wl.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_dmc_wl.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index af9e871daf1d..7cad944b825c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -266,6 +266,7 @@ i915-y += \
> display/intel_display_rps.o \
> display/intel_display_wa.o \
> display/intel_dmc.o \
> + display/intel_dmc_wl.o \
> display/intel_dpio_phy.o \
> display/intel_dpll.o \
> display/intel_dpll_mgr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index ba7a1c6ebc2a..0a0fba81e7af 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -13,52 +13,125 @@
> static inline u32
> intel_de_read(struct drm_i915_private *i915, i915_reg_t reg) {
> - return intel_uncore_read(&i915->uncore, reg);
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> }
>
> static inline u8
> intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg) {
> - return intel_uncore_read8(&i915->uncore, reg);
> + u8 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read8(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> }
>
> static inline u64
> intel_de_read64_2x32(struct drm_i915_private *i915,
>i915_reg_t lower_reg, i915_reg_t upper_reg) {
> - return intel_uncore_read64_2x32(&i915->uncore, lower_reg,
> upper_reg);
> + u64 val;
> +
> + intel_dmc_wl_get(i915, lower_reg);
> + intel_dmc_wl_get(i915, upper_reg);
> +
> + val = intel_uncore_read64_2x32(&i915->uncore, lower_reg, upper_reg);
> +
> + intel_dmc_wl_put(i915, upper_reg);
> + intel_dmc_wl_put(i915, lower_reg);
> +
> + return val;
> }
>
> static inline void
> intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg) {
> + intel_dmc_wl_get(i915, reg);
> +
> intel_uncore_posting_read(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> }
>
> static inline void
> intel_de_write(struct drm_i915_private *i915, i915_reg_t reg, u32 val) {
> + intel_dmc_wl_get(i915, reg);
> +
> intel_uncore_write(&i915->uncore, reg, val);
> +
> + intel_dmc_wl_put(i915, reg);
> }
>
> static inline u32
> -intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear, u32
> set)
> +__intel_de_rmw_nowl(struct drm_i915_private *i915, i915_reg_t reg,
> + u32 clear, u32 set)
> {
> return intel_uncore_rmw(&i915->uncore, reg, clear, set); }
>
> +static inline u32
> +intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear,
> +u32 set) {
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = __intel_de_rmw_nowl(i915, reg, clear, set);
> +
> + intel_dmc_w
RE: [PATCH] drm/i915: Implement Audio WA_14020863754
> -Original Message- > From: Jani Nikula > Sent: Wednesday, April 10, 2024 3:47 PM > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; > intel...@lists.freedesktop.org > Cc: Borah, Chaitanya Kumar ; Shankar, Uma > > Subject: Re: [PATCH] drm/i915: Implement Audio WA_14020863754 > > On Wed, 10 Apr 2024, Uma Shankar wrote: > > WA_14020863754: Corner case with Min Hblank Fix can cause audio hang > > > > Issue: Previously a fix was made to avoid issues with extremely small > > hblanks, called the "Min Hblank Fix". However, this can potentially > > cause an audio hang. > > > > Workaround : > > During "Audio Programming Sequence" Audio Enabling - When DP mode is > > enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable > > audio Presence Detect" > > > > During "Audio Programming Sequence" Audio Disabling - When DP mode is > > enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable > > Audio PD (Presence Detect)" > > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = > > 1b) > > hsw_audio_codec_disable/enable get called on hsw and display ver >= 8, but a > lot > of those platforms have the bit reserved MBZ. I didn't go through all the > platforms > in bspec, but enough to notice this needs some platform check. Yes Jani, realized it after sending. Will update and re-float. Thanks for spotting it. Regards, Uma Shankar > BR, > Jani. > > > > > Signed-off-by: Uma Shankar > > --- > > drivers/gpu/drm/i915/display/intel_audio.c | 12 > > drivers/gpu/drm/i915/display/intel_audio_regs.h | 3 +++ > > 2 files changed, 15 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c > > b/drivers/gpu/drm/i915/display/intel_audio.c > > index 07e0c73204f3..a8e3e515aaa0 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio.c > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > > @@ -512,6 +512,12 @@ static void hsw_audio_codec_disable(struct > intel_encoder *encoder, > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0); > > > > + /* > > +* WA_14020863754: Implement Audio Workaround > > +* Corner case with Min Hblank Fix can cause audio hang > > +*/ > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, CHICKEN3_SPARE18, 0); > > + > > mutex_unlock(&i915->display.audio.mutex); > > } > > > > @@ -637,6 +643,12 @@ static void hsw_audio_codec_enable(struct > intel_encoder *encoder, > > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP)) > > enable_audio_dsc_wa(encoder, crtc_state); > > > > + /* > > +* WA_14020863754: Implement Audio Workaround > > +* Corner case with Min Hblank Fix can cause audio hang > > +*/ > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0, CHICKEN3_SPARE18); > > + > > /* Enable audio presence detect */ > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > 0, AUDIO_OUTPUT_ENABLE(cpu_transcoder)); > > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > index 616e7b1275c4..6f8d33299ecd 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > @@ -148,4 +148,7 @@ > > #define HBLANK_START_COUNT_96 4 > > #define HBLANK_START_COUNT_128 5 > > > > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C) > > +#define CHICKEN3_SPARE18 REG_BIT(18) > > + > > #endif /* __INTEL_AUDIO_REGS_H__ */ > > -- > Jani Nikula, Intel
RE: [PATCH 14/22] drm/i915/mst: Reject FEC+MST on ICL
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Friday, March 29, 2024 6:43 AM > To: intel-gfx@lists.freedesktop.org > Subject: [PATCH 14/22] drm/i915/mst: Reject FEC+MST on ICL > > From: Ville Syrjälä > > ICL supposedly doesn't support FEC on MST. Reject it. Looks Good to me. Reviewed-by: Uma Shankar > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index cbabd1924474..8b8059b6bb21 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -1415,7 +1415,8 @@ static bool intel_dp_source_supports_fec(struct > intel_dp *intel_dp, > if (DISPLAY_VER(dev_priv) >= 12) > return true; > > - if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A) > + if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A && > + !intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) > return true; > > return false; > -- > 2.43.2
RE: [PATCH 13/22] drm/i915/mst: Limit MST+DSC to TGL+
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 13/22] drm/i915/mst: Limit MST+DSC to TGL+
>
> From: Ville Syrjälä
>
> The MST code currently assumes that glk+ alerady supports MST+DSC, which is
Nit: Typo in already
> incorrect. We need to check for TGL+ actually. ICL does support SST+DSC, but
> supposedly it can't do MST+FEC which will also rule MST+DSC.
>
> Note that a straight TGL+ check doesn't work here because DSC support can get
> fused out, so we do need to also check 'has_dsc'.
Yeah right.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display_device.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index fe4268813786..9b1bce2624b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -47,6 +47,7 @@ struct drm_printer;
> #define HAS_DPT(i915)(DISPLAY_VER(i915) >= 13)
> #define HAS_DSB(i915)(DISPLAY_INFO(i915)->has_dsb)
> #define HAS_DSC(__i915)
> (DISPLAY_RUNTIME_INFO(__i915)->has_dsc)
> +#define HAS_DSC_MST(__i915) (DISPLAY_VER(__i915) >= 12 &&
> HAS_DSC(__i915))
> #define HAS_FBC(i915)(DISPLAY_RUNTIME_INFO(i915)-
> >fbc_mask != 0)
> #define HAS_FPGA_DBG_UNCLAIMED(i915) (DISPLAY_INFO(i915)-
> >has_fpga_dbg)
> #define HAS_FW_BLC(i915) (DISPLAY_VER(i915) >= 3)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index a3b0026adb2d..de364ed77c08 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1352,7 +1352,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> return 0;
> }
>
> - if (DISPLAY_VER(dev_priv) >= 10 &&
> + if (HAS_DSC_MST(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
> /*
>* TBD pass the connector BPC,
> --
> 2.43.2
RE: [PATCH 12/22] drm/i915: Pass connector to intel_dp_need_bigjoiner()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 12/22] drm/i915: Pass connector to intel_dp_need_bigjoiner()
>
> From: Ville Syrjälä
>
> Pass the connector explicitly to intel_dp_need_bigjoiner() so that it'll
> actually
> check the correct place for the bigjoiner force flag.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++--
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6fa8fc56a39c..cbabd1924474 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1194,10 +1194,10 @@ intel_dp_mode_valid_downstream(struct
> intel_connector *connector, }
>
> bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> + struct intel_connector *connector,
>int hdisplay, int clock)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_connector *connector = intel_dp->attached_connector;
>
> if (!intel_dp_has_bigjoiner(intel_dp))
> return false;
> @@ -1241,7 +1241,8 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> target_clock = fixed_mode->clock;
> }
>
> - if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
> + if (intel_dp_need_bigjoiner(intel_dp, connector,
> + mode->hdisplay, target_clock)) {
> bigjoiner = true;
> max_dotclk *= 2;
> }
> @@ -2409,7 +2410,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder, {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> - const struct intel_connector *connector =
> + struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> const struct drm_display_mode *adjusted_mode =
> &pipe_config->hw.adjusted_mode;
> @@ -2422,7 +2423,8 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> !intel_dp_supports_fec(intel_dp, connector, pipe_config))
> return -EINVAL;
>
> - if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
> + if (intel_dp_need_bigjoiner(intel_dp, connector,
> + adjusted_mode->crtc_hdisplay,
> adjusted_mode->crtc_clock))
> pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, crtc-
> >pipe);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index d5697b99ac21..cd6969d05fe3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -150,6 +150,7 @@ u8 intel_dp_dsc_get_slice_count(const struct
> intel_connector *connector,
> int mode_clock, int mode_hdisplay,
> bool bigjoiner);
> bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> + struct intel_connector *connector,
>int hdisplay, int clock);
>
> static inline unsigned int intel_dp_unused_lane_mask(int lane_count) diff
> --git
> a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 1cf6241a7d53..a3b0026adb2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -527,7 +527,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> struct intel_atomic_state *state = to_intel_atomic_state(conn_state-
> >state);
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_dp *intel_dp = &intel_mst->primary->dp;
> - const struct intel_connector *connector =
> + struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> const struct drm_display_mode *adjusted_mode =
> &pipe_config->hw.adjusted_mode;
> @@ -1342,7 +1342,8 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> *status = MODE_CLOCK_HIGH;
> return 0;
> }
> - if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
> + if (intel_dp_need_bigjoiner(intel_dp, intel_connector,
> + mode->hdisplay, target_clock)) {
> bigjoiner = true;
> max_dotclk *= 2;
>
> --
> 2.43.2
RE: [PATCH 11/22] drm/i915/mst: Check intel_dp_joiner_needs_dsc()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 11/22] drm/i915/mst: Check intel_dp_joiner_needs_dsc()
>
> From: Ville Syrjälä
>
> intel_dp_mst_compute_config() is missing the "does the joiner need DSC?" check
> despite claiming to have a lot of other joiner/dsc stuff in there (albeit
> disabled).
> Replicate the logic from the SST side.
>
> TODO: refactor all this duplicated code!
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 6da031f9724d..1cf6241a7d53 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -532,7 +532,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> const struct drm_display_mode *adjusted_mode =
> &pipe_config->hw.adjusted_mode;
> struct link_config_limits limits;
> - bool dsc_needed;
> + bool dsc_needed, joiner_needs_dsc;
> int ret = 0;
>
> if (pipe_config->fec_enable &&
> @@ -546,7 +546,9 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> pipe_config->has_pch_encoder = false;
>
> - dsc_needed = intel_dp->force_dsc_en ||
> + joiner_needs_dsc = intel_dp_joiner_needs_dsc(dev_priv,
> +pipe_config->bigjoiner_pipes);
> +
> + dsc_needed = joiner_needs_dsc || intel_dp->force_dsc_en ||
>!intel_dp_mst_compute_config_limits(intel_dp,
>connector,
>pipe_config,
> @@ -566,8 +568,8 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>
> /* enable compression if the mode doesn't fit available BW */
> if (dsc_needed) {
> - drm_dbg_kms(&dev_priv->drm, "Try DSC (fallback=%s,
> force=%s)\n",
> - str_yes_no(ret),
> + drm_dbg_kms(&dev_priv->drm, "Try DSC (fallback=%s,
> joiner=%s, force=%s)\n",
> + str_yes_no(ret), str_yes_no(joiner_needs_dsc),
> str_yes_no(intel_dp->force_dsc_en));
>
> if (!intel_dp_mst_dsc_source_support(pipe_config))
> --
> 2.43.2
RE: [PATCH 10/22] drm/i915: Extract intel_dp_joiner_needs_dsc()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 10/22] drm/i915: Extract intel_dp_joiner_needs_dsc()
>
> From: Ville Syrjälä
>
> Pull the "does joiner need DSC?" check into a helper. MST will want to use
> this too
> at some point.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 26 ++---
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +
> 3 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 402b3b8f6382..6fa8fc56a39c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1302,11 +1302,7 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> dsc = dsc_max_compressed_bpp && dsc_slice_count;
> }
>
> - /*
> - * Big joiner configuration needs DSC for TGL which is not true for
> - * XE_LPD where uncompressed joiner is supported.
> - */
> - if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc)
> + if (intel_dp_joiner_needs_dsc(dev_priv, bigjoiner) && !dsc)
> return MODE_CLOCK_HIGH;
>
> if (mode_rate > max_rate && !dsc)
> @@ -2395,6 +2391,16 @@ int intel_dp_config_required_rate(const struct
> intel_crtc_state *crtc_state)
> return intel_dp_link_required(adjusted_mode->crtc_clock, bpp); }
>
> +bool intel_dp_joiner_needs_dsc(struct drm_i915_private *i915, bool
> +use_joiner) {
> + /*
> + * Pipe joiner needs compression up to display 12 due to bandwidth
> + * limitation. DG2 onwards pipe joiner can be enabled without
> + * compression.
> + */
> + return DISPLAY_VER(i915) < 13 && use_joiner; }
> +
> static int
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config, @@ -2409,8
> +2415,7 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
> &pipe_config->hw.adjusted_mode;
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> struct link_config_limits limits;
> - bool joiner_needs_dsc = false;
> - bool dsc_needed;
> + bool dsc_needed, joiner_needs_dsc;
> int ret = 0;
>
> if (pipe_config->fec_enable &&
> @@ -2421,12 +2426,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> adjusted_mode->crtc_clock))
> pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, crtc-
> >pipe);
>
> - /*
> - * Pipe joiner needs compression up to display 12 due to bandwidth
> - * limitation. DG2 onwards pipe joiner can be enabled without
> - * compression.
> - */
> - joiner_needs_dsc = DISPLAY_VER(i915) < 13 && pipe_config-
> >bigjoiner_pipes;
> + joiner_needs_dsc = intel_dp_joiner_needs_dsc(i915,
> +pipe_config->bigjoiner_pipes);
>
> dsc_needed = joiner_needs_dsc || intel_dp->force_dsc_en ||
>!intel_dp_compute_config_limits(intel_dp, pipe_config,
> diff --
> git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 4a4b39f2748b..d5697b99ac21 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -119,6 +119,7 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
>int bw_overhead);
> int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> int max_dprx_rate, int max_dprx_lanes);
> +bool intel_dp_joiner_needs_dsc(struct drm_i915_private *i915, bool
> +use_joiner);
> bool intel_dp_has_bigjoiner(struct intel_dp *intel_dp); bool
> intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state); diff
> --
> git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 1405ab5e3acc..6da031f9724d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1377,11 +1377,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> dsc = dsc_max_compressed_bpp && dsc_slice_count;
> }
>
> - /*
> - * Big joiner configuration needs DSC for TGL which is not true for
> - * XE_LPD where uncompressed joiner is supported.
> - */
> - if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc) {
> + if (intel_dp_joiner_needs_dsc(dev_priv, bigjoiner) && !dsc) {
> *status = MODE_CLOCK_HIGH;
> return 0;
> }
> --
> 2.43.2
RE: [PATCH 00/13] drm/i915: Implemnt vblank sycnhronized mbus joining changes
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Wednesday, March 27, 2024 11:16 PM > To: intel-gfx@lists.freedesktop.org > Subject: [PATCH 00/13] drm/i915: Implemnt vblank sycnhronized mbus joining > changes Nit: Typo in implement and synchronized > From: Ville Syrjälä > > Get rid of the full modeset requirement for changing mbus joining. Things got > quite a bit more complicated than originally envisioned due to the dynamic > cdclk/mdclk ratio. > Sadly we have to do a fairly careful dance between the dbuf and cdclk code to > make sure everything is programmed in the correct sequence. > > Stan did the grunt work, but the sequence vs. cdclk updates was still not > right so I > finished that part. > I also reorganized the code quite a bit to make the resulting patches more > legible. > And I tossed in more debugs and whatnot so we can actually observe what it's > doing. > > Quickly smoke tested on tgl and adl, and things seem pretty decent. > Unfortunately I don't have a LNL on me right now so I haven't fully tested the > mdclk/cdclk ratio changes on real hw, but I did hack my adl to pretend that > the > ratio changes with cdclk and double checked that the logs look sensible for > all the > combinations of cdclk increase/decrease and mbus join enable/disable. > So should work (tm) on real hw too. Reviewed the series and it looks good to me. This is ready for merge. Reviewed-by: Uma Shankar Regards, Uma Shankar > Stanislav Lisovskiy (3): > drm/i915: Loop over all active pipes in intel_mbus_dbox_update > drm/i915: Use old mbus_join value when increasing CDCLK > drm/i915: Implement vblank synchronized MBUS join changes > > Ville Syrjälä (10): > drm/i915/cdclk: Fix CDCLK programming order when pipes are active > drm/i915/cdclk: Fix voltage_level programming edge case > drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks > drm/i915/cdclk: Indicate whether CDCLK change happens during pre or > post plane update > drm/i915: Relocate intel_mbus_dbox_update() > drm/i915: Extract intel_dbuf_mbus_join_update() > drm/i915: Extract intel_dbuf_mdclk_min_tracker_update() > drm/i915: Add debugs for mbus joining and dbuf ratio programming > drm/i915: Use a plain old int for the cdclk/mdclk ratio > drm/i915: Optimize out redundant dbuf slice updates > > drivers/gpu/drm/i915/display/intel_cdclk.c | 85 +++-- > drivers/gpu/drm/i915/display/intel_cdclk.h | 8 +- > drivers/gpu/drm/i915/display/intel_display.c | 5 +- > drivers/gpu/drm/i915/display/skl_watermark.c | 344 --- > drivers/gpu/drm/i915/display/skl_watermark.h | 9 +- > 5 files changed, 271 insertions(+), 180 deletions(-) > > -- > 2.43.2
RE: [PATCH 13/13] drm/i915: Optimize out redundant dbuf slice updates
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Wednesday, March 27, 2024 11:16 PM > To: intel-gfx@lists.freedesktop.org > Subject: [PATCH 13/13] drm/i915: Optimize out redundant dbuf slice updates > > From: Ville Syrjälä > > if the new dbuf slices are a superset of the old dbuf slices then we don't > have to > do anything in intel_dbuf_post_plane_update(). Restructure the code to skip > such > redundant dbuf slice updates. The main benefit is slightly less confusing > logs. Looks Good to me. Reviewed-by: Uma Shankar > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/skl_watermark.c | 27 +--- > 1 file changed, 18 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c > b/drivers/gpu/drm/i915/display/skl_watermark.c > index 1b48009efe2b..50ec51065118 100644 > --- a/drivers/gpu/drm/i915/display/skl_watermark.c > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c > @@ -3788,16 +3788,20 @@ void intel_dbuf_pre_plane_update(struct > intel_atomic_state *state) > intel_atomic_get_new_dbuf_state(state); > const struct intel_dbuf_state *old_dbuf_state = > intel_atomic_get_old_dbuf_state(state); > + u8 old_slices, new_slices; > > - if (!new_dbuf_state || > - new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices) > + if (!new_dbuf_state) > + return; > + > + old_slices = old_dbuf_state->enabled_slices; > + new_slices = old_dbuf_state->enabled_slices | > +new_dbuf_state->enabled_slices; > + > + if (old_slices == new_slices) > return; > > WARN_ON(!new_dbuf_state->base.changed); > > - gen9_dbuf_slices_update(i915, > - old_dbuf_state->enabled_slices | > - new_dbuf_state->enabled_slices); > + gen9_dbuf_slices_update(i915, new_slices); > } > > void intel_dbuf_post_plane_update(struct intel_atomic_state *state) @@ - > 3807,15 +3811,20 @@ void intel_dbuf_post_plane_update(struct > intel_atomic_state *state) > intel_atomic_get_new_dbuf_state(state); > const struct intel_dbuf_state *old_dbuf_state = > intel_atomic_get_old_dbuf_state(state); > + u8 old_slices, new_slices; > > - if (!new_dbuf_state || > - new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices) > + if (!new_dbuf_state) > + return; > + > + old_slices = old_dbuf_state->enabled_slices | new_dbuf_state- > >enabled_slices; > + new_slices = new_dbuf_state->enabled_slices; > + > + if (old_slices == new_slices) > return; > > WARN_ON(!new_dbuf_state->base.changed); > > - gen9_dbuf_slices_update(i915, > - new_dbuf_state->enabled_slices); > + gen9_dbuf_slices_update(i915, new_slices); > } > > static int skl_watermark_ipc_status_show(struct seq_file *m, void *data) > -- > 2.43.2
RE: [PATCH 12/13] drm/i915: Use a plain old int for the cdclk/mdclk ratio
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 12/13] drm/i915: Use a plain old int for the cdclk/mdclk ratio
>
> From: Ville Syrjälä
>
> No point in throwing around u8 when we're dealing with just an integer. Use a
> plain old boring 'int'.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_cdclk.h | 4 ++--
> drivers/gpu/drm/i915/display/skl_watermark.c | 6 --
> drivers/gpu/drm/i915/display/skl_watermark.h | 6 --
> 4 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 66c161d7b485..5cba0d08189b 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1893,8 +1893,8 @@ static u32 xe2lpd_mdclk_source_sel(struct
> drm_i915_private *i915)
> return MDCLK_SOURCE_SEL_CD2XCLK;
> }
>
> -u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> -const struct intel_cdclk_config *cdclk_config)
> +int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> + const struct intel_cdclk_config *cdclk_config)
> {
> if (mdclk_source_is_cdclk_pll(i915))
> return DIV_ROUND_UP(cdclk_config->vco, cdclk_config->cdclk);
> @@ -3321,7 +3321,7 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
>
> if (intel_mdclk_cdclk_ratio(dev_priv, &old_cdclk_state->actual) !=
> intel_mdclk_cdclk_ratio(dev_priv, &new_cdclk_state->actual)) {
> - u8 ratio = intel_mdclk_cdclk_ratio(dev_priv, &new_cdclk_state-
> >actual);
> + int ratio = intel_mdclk_cdclk_ratio(dev_priv,
> +&new_cdclk_state->actual);
>
> ret = intel_dbuf_state_set_mdclk_cdclk_ratio(state, ratio);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 5d4faf401774..cfdcdec07a4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -67,8 +67,8 @@ void intel_update_cdclk(struct drm_i915_private
> *dev_priv);
> u32 intel_read_rawclk(struct drm_i915_private *dev_priv); bool
> intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
> const struct intel_cdclk_config *b);
> -u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> -const struct intel_cdclk_config *cdclk_config);
> +int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> + const struct intel_cdclk_config *cdclk_config);
> bool intel_cdclk_is_decreasing_later(struct intel_atomic_state *state); void
> intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state); void
> intel_set_cdclk_post_plane_update(struct intel_atomic_state *state); diff
> --git
> a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index ca0f1f89e6d9..1b48009efe2b 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3616,7 +3616,8 @@ static void intel_mbus_dbox_update(struct
> intel_atomic_state *state)
> }
> }
>
> -int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state,
> u8
> ratio)
> +int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state,
> +int ratio)
> {
> struct intel_dbuf_state *dbuf_state;
>
> @@ -3629,7 +3630,8 @@ int intel_dbuf_state_set_mdclk_cdclk_ratio(struct
> intel_atomic_state *state, u8
> return intel_atomic_lock_global_state(&dbuf_state->base);
> }
>
> -void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private *i915, u8
> ratio, bool joined_mbus)
> +void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private *i915,
> + int ratio, bool joined_mbus)
> {
> enum dbuf_slice slice;
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.h
> b/drivers/gpu/drm/i915/display/skl_watermark.h
> index 3323a1d973f9..ef1a008466be 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.h
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.h
> @@ -74,11 +74,13 @@ intel_atomic_get_dbuf_state(struct intel_atomic_state
> *state);
> to_intel_dbuf_state(intel_atomic_get_new_global_obj_state(state,
> &to_i915(state->base.dev)->display.dbuf.obj))
>
> int intel_dbuf_init(struct drm_i915_private *i915); -int
> intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state, u8
> ratio);
> +int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state,
> +int ratio);
>
> void intel_dbuf_pre
RE: [PATCH 11/13] drm/i915: Implement vblank synchronized MBUS join changes
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: [PATCH 11/13] drm/i915: Implement vblank synchronized MBUS join
> changes
>
> From: Stanislav Lisovskiy
>
> Currently we can't change MBUS join status without doing a modeset, because
> we are lacking mechanism to synchronize those with vblank.
> However then this means that we can't do a fastset, if there is a need to
> change
> MBUS join state. Fix that by implementing such change.
> We already call correspondent check and update at pre_plane dbuf update, so
> the
> only thing left is to have a non-modeset version of that.
> If active pipes stay the same then fastset is possible and only MBUS join
> state/ddb allocation updates would be committed.
>
> The full mbus/cdclk sequence will look as follows:
> 1. disable pipes
> 2. increase cdclk if necessary
> 2.1 reprogram cdclk
> 2.2 update dbuf tracker value
> 3. enable mbus joining if necessary
> 3.1 update mbus_ctl
> 3.2 update dbuf tracker value
> 4. reallocate dbuf for planes on active pipes 5. disable mbus joining if
> necessary
> 5.1 update dbuf tracker value
> 5.2 update mbus_ctl
> 6. enable pipes
> 7. decrease cdclk if necessary
> 7.1 update dbuf tracker value
> 7.2 reprogram cdclk
>
> And in order to keep things in sync we need:
> Step 2:
> - mbus_join == old
> - mdclk/cdclk ratio == new
> Step 3:
> - mbus_join == new
> - mdclk/cdclk ratio == old when cdclk is changing in step 7
> - mdclk/cdclk ratio == new when cdclk is changing in step 2 Step 5:
> - mbus_join == new
> - mdclk/cdclk ratio == old when cdclk is changing in step 7
> - mdclk/cdclk ratio == new when cdclk is changing in step 2 Step 7:
> - mbus_join == new
> - mdclk/cdclk ratio == new
>
> v2: - Removed redundant parentheses(Ville Syrjälä)
> - Constified new_crtc_state in intel_mbus_joined_pipe(Ville Syrjälä)
> - Removed pipe_select variable(Ville Syrjälä)
> [v3: vsyrjala: Correctly sequence vs. cdclk updates,
>properly describe the full sequence,
> shuffle code around to make the diff more legible,
> streamline a few things]
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Stanislav Lisovskiy
> Co-developed-by: Ville Syrjälä
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 11 ++
> drivers/gpu/drm/i915/display/intel_cdclk.h | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 5 +-
> drivers/gpu/drm/i915/display/skl_watermark.c | 141 ---
> drivers/gpu/drm/i915/display/skl_watermark.h | 3 +-
> 5 files changed, 112 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 4024118a7ffb..66c161d7b485 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2576,6 +2576,17 @@ static void intel_cdclk_pcode_post_notify(struct
> intel_atomic_state *state)
> update_cdclk, update_pipe_count); }
>
> +bool intel_cdclk_is_decreasing_later(struct intel_atomic_state *state)
> +{
> + const struct intel_cdclk_state *old_cdclk_state =
> + intel_atomic_get_old_cdclk_state(state);
> + const struct intel_cdclk_state *new_cdclk_state =
> + intel_atomic_get_new_cdclk_state(state);
> +
> + return new_cdclk_state && !new_cdclk_state->disable_pipes &&
> + new_cdclk_state->actual.cdclk < old_cdclk_state->actual.cdclk;
> }
> +
> /**
> * intel_set_cdclk_pre_plane_update - Push the CDCLK state to the hardware
> * @state: intel atomic state
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 2843fc091086..5d4faf401774 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -69,6 +69,7 @@ bool intel_cdclk_clock_changed(const struct
> intel_cdclk_config *a,
> const struct intel_cdclk_config *b);
> u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> const struct intel_cdclk_config *cdclk_config);
> +bool intel_cdclk_is_decreasing_later(struct intel_atomic_state *state);
> void intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state);
> void
> intel_set_cdclk_post_plane_update(struct intel_atomic_state *state); void
> intel_cdclk_dump_config(struct drm_i915_private *i915, diff --git
> a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4d6668a5f1ab..023cf4a77e6f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6915,6 +6915,8 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
> intel_pre_update_crtc(state, c
RE: [PATCH 10/13] drm/i915: Use old mbus_join value when increasing CDCLK
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 10/13] drm/i915: Use old mbus_join value when increasing
> CDCLK
>
> From: Stanislav Lisovskiy
>
> In order to make sure we are not breaking the proper sequence lets to updates
Nit: %s/lets to/lets do
> step by step and don't change MBUS join value during MDCLK/CDCLK
> programming stage.
> MBUS join programming would be taken care by pre/post ddb hooks.
>
> v2: - Reworded comment about using old mbus_join value in
> intel_set_cdclk(Ville Syrjälä)
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Stanislav Lisovskiy
> [v3: vsyrjala: rebase on top of cdclk changes, reword a bit more]
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 98546f384023..4024118a7ffb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2612,6 +2612,12 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>old_cdclk_state-
> >actual.voltage_level);
> }
>
> + /*
> + * mbus joining will be changed later by
> + * intel_dbuf_mbus_{pre,post}_ddb_update()
> + */
> + cdclk_config.joined_mbus = old_cdclk_state->actual.joined_mbus;
> +
> drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
>
> intel_set_cdclk(i915, &cdclk_config, new_cdclk_state->pipe,
> --
> 2.43.2
RE: [PATCH 09/13] drm/i915: Add debugs for mbus joining and dbuf ratio programming
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 09/13] drm/i915: Add debugs for mbus joining and dbuf ratio
> programming
Looks Good to me.
Reviewed-by: Uma Shankar
> From: Ville Syrjälä
>
> Add some debugs so that we can actually observe what is actually happening
> during the mbus/dbuf programming steps.
> We can just shove them into fairly low level functions as none of them are
> called
> during any critical sections/etc.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 7767c5eada36..a118ecf9e532 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3647,6 +3647,9 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct
> drm_i915_private *i915, u8 ratio
> if (joined_mbus)
> ratio *= 2;
>
> + drm_dbg_kms(&i915->drm, "Updating dbuf ratio to %d (mbus joined:
> %s)\n",
> + ratio, str_yes_no(joined_mbus));
> +
> for_each_dbuf_slice(i915, slice)
> intel_de_rmw(i915, DBUF_CTL_S(slice),
>DBUF_MIN_TRACKER_STATE_SERVICE_MASK,
> @@ -3680,10 +3683,16 @@ static void
> intel_dbuf_mdclk_min_tracker_update(struct intel_atomic_state *state static
> void intel_dbuf_mbus_join_update(struct intel_atomic_state *state) {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
> const struct intel_dbuf_state *new_dbuf_state =
> intel_atomic_get_new_dbuf_state(state);
> u32 mbus_ctl;
>
> + drm_dbg_kms(&i915->drm, "Changing mbus joined: %s -> %s\n",
> + str_yes_no(old_dbuf_state->joined_mbus),
> + str_yes_no(new_dbuf_state->joined_mbus));
> +
> /*
>* TODO: Implement vblank synchronized MBUS joining changes.
>* Must be properly coordinated with dbuf reprogramming.
> --
> 2.43.2
RE: [PATCH 08/13] drm/i915: Extract intel_dbuf_mdclk_min_tracker_update()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 08/13] drm/i915: Extract
> intel_dbuf_mdclk_min_tracker_update()
>
> From: Ville Syrjälä
>
> Extact the stuff that writes the dbuf/mbus ration stuff into its own
> function. Will
Nit: Typo in extract and ratio
Looks Good to me.
Reviewed-by: Uma Shankar
> help with correctly sequencing the operations done during mbus programming.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 43
> 1 file changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index f7e03078bd43..7767c5eada36 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3653,6 +3653,30 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct
> drm_i915_private *i915, u8 ratio
>DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1)); }
>
> +static void intel_dbuf_mdclk_min_tracker_update(struct
> +intel_atomic_state *state) {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> +
> + if (DISPLAY_VER(i915) >= 20 &&
> + old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state-
> >mdclk_cdclk_ratio) {
> + /*
> + * For Xe2LPD and beyond, when there is a change in the ratio
> + * between MDCLK and CDCLK, updates to related registers need
> to
> + * happen at a specific point in the CDCLK change sequence. In
> + * that case, we defer to the call to
> + * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> + */
> + return;
> + }
> +
> + intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state-
> >mdclk_cdclk_ratio,
> + new_dbuf_state->joined_mbus);
> +}
> +
> static void intel_dbuf_mbus_join_update(struct intel_atomic_state *state) {
> struct drm_i915_private *i915 = to_i915(state->base.dev); @@ -3683,10
> +3707,6 @@ static void intel_dbuf_mbus_join_update(struct intel_atomic_state
> *state) static void update_mbus_pre_enable(struct intel_atomic_state *state)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> - const struct intel_dbuf_state *old_dbuf_state =
> - intel_atomic_get_old_dbuf_state(state);
> - const struct intel_dbuf_state *new_dbuf_state =
> - intel_atomic_get_new_dbuf_state(state);
>
> if (!HAS_MBUS_JOINING(i915))
> return;
> @@ -3697,20 +3717,7 @@ static void update_mbus_pre_enable(struct
> intel_atomic_state *state)
>*/
> intel_dbuf_mbus_join_update(state);
>
> - if (DISPLAY_VER(i915) >= 20 &&
> - old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state-
> >mdclk_cdclk_ratio) {
> - /*
> - * For Xe2LPD and beyond, when there is a change in the ratio
> - * between MDCLK and CDCLK, updates to related registers need
> to
> - * happen at a specific point in the CDCLK change sequence. In
> - * that case, we defer to the call to
> - * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> - */
> - return;
> - }
> -
> - intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state-
> >mdclk_cdclk_ratio,
> - new_dbuf_state->joined_mbus);
> + intel_dbuf_mdclk_min_tracker_update(state);
> }
>
> void intel_dbuf_pre_plane_update(struct intel_atomic_state *state)
> --
> 2.43.2
RE: [PATCH 07/13] drm/i915: Extract intel_dbuf_mbus_join_update()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 07/13] drm/i915: Extract intel_dbuf_mbus_join_update()
>
> From: Ville Syrjälä
>
> Extact the stuff that writes the joining bits in MBUS_CTL into its own
> function.
> Will help with correctly sequencing the operations done during mbus
> programming.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 37 +---
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 6bd3fec0aa56..f7e03078bd43 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3653,21 +3653,12 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct
> drm_i915_private *i915, u8 ratio
>DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1)); }
>
> -/*
> - * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus state
> before
> - * update the request state of all DBUS slices.
> - */
> -static void update_mbus_pre_enable(struct intel_atomic_state *state)
> +static void intel_dbuf_mbus_join_update(struct intel_atomic_state
> +*state)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> u32 mbus_ctl;
> - const struct intel_dbuf_state *old_dbuf_state =
> - intel_atomic_get_old_dbuf_state(state);
> - const struct intel_dbuf_state *new_dbuf_state =
> - intel_atomic_get_new_dbuf_state(state);
> -
> - if (!HAS_MBUS_JOINING(i915))
> - return;
>
> /*
>* TODO: Implement vblank synchronized MBUS joining changes.
> @@ -3683,6 +3674,28 @@ static void update_mbus_pre_enable(struct
> intel_atomic_state *state)
> intel_de_rmw(i915, MBUS_CTL,
>MBUS_HASHING_MODE_MASK | MBUS_JOIN |
>MBUS_JOIN_PIPE_SELECT_MASK, mbus_ctl);
> +}
> +
> +/*
> + * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus
> +state before
> + * update the request state of all DBUS slices.
> + */
> +static void update_mbus_pre_enable(struct intel_atomic_state *state) {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> +
> + if (!HAS_MBUS_JOINING(i915))
> + return;
> +
> + /*
> + * TODO: Implement vblank synchronized MBUS joining changes.
> + * Must be properly coordinated with dbuf reprogramming.
> + */
> + intel_dbuf_mbus_join_update(state);
>
> if (DISPLAY_VER(i915) >= 20 &&
> old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state-
> >mdclk_cdclk_ratio) {
> --
> 2.43.2
RE: [PATCH 06/13] drm/i915: Relocate intel_mbus_dbox_update()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 06/13] drm/i915: Relocate intel_mbus_dbox_update()
>
> From: Ville Syrjälä
>
> intel_mbus_dbox_update() will become static soon. Relocate it into a place
> that
> avoids having to add a forward declaration for it.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 166 +--
> 1 file changed, 83 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index f582992592c1..6bd3fec0aa56 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3540,6 +3540,89 @@ int intel_dbuf_init(struct drm_i915_private *i915)
> return 0;
> }
>
> +static bool xelpdp_is_only_pipe_per_dbuf_bank(enum pipe pipe, u8
> +active_pipes) {
> + switch (pipe) {
> + case PIPE_A:
> + return !(active_pipes & BIT(PIPE_D));
> + case PIPE_D:
> + return !(active_pipes & BIT(PIPE_A));
> + case PIPE_B:
> + return !(active_pipes & BIT(PIPE_C));
> + case PIPE_C:
> + return !(active_pipes & BIT(PIPE_B));
> + default: /* to suppress compiler warning */
> + MISSING_CASE(pipe);
> + break;
> + }
> +
> + return false;
> +}
> +
> +void intel_mbus_dbox_update(struct intel_atomic_state *state) {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *new_dbuf_state, *old_dbuf_state;
> + const struct intel_crtc *crtc;
> + u32 val = 0;
> +
> + if (DISPLAY_VER(i915) < 11)
> + return;
> +
> + new_dbuf_state = intel_atomic_get_new_dbuf_state(state);
> + old_dbuf_state = intel_atomic_get_old_dbuf_state(state);
> + if (!new_dbuf_state ||
> + (new_dbuf_state->joined_mbus == old_dbuf_state->joined_mbus &&
> + new_dbuf_state->active_pipes == old_dbuf_state->active_pipes))
> + return;
> +
> + if (DISPLAY_VER(i915) >= 14)
> + val |= MBUS_DBOX_I_CREDIT(2);
> +
> + if (DISPLAY_VER(i915) >= 12) {
> + val |= MBUS_DBOX_B2B_TRANSACTIONS_MAX(16);
> + val |= MBUS_DBOX_B2B_TRANSACTIONS_DELAY(1);
> + val |= MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN;
> + }
> +
> + if (DISPLAY_VER(i915) >= 14)
> + val |= new_dbuf_state->joined_mbus ?
> MBUS_DBOX_A_CREDIT(12) :
> + MBUS_DBOX_A_CREDIT(8);
> + else if (IS_ALDERLAKE_P(i915))
> + /* Wa_22010947358:adl-p */
> + val |= new_dbuf_state->joined_mbus ?
> MBUS_DBOX_A_CREDIT(6) :
> + MBUS_DBOX_A_CREDIT(4);
> + else
> + val |= MBUS_DBOX_A_CREDIT(2);
> +
> + if (DISPLAY_VER(i915) >= 14) {
> + val |= MBUS_DBOX_B_CREDIT(0xA);
> + } else if (IS_ALDERLAKE_P(i915)) {
> + val |= MBUS_DBOX_BW_CREDIT(2);
> + val |= MBUS_DBOX_B_CREDIT(8);
> + } else if (DISPLAY_VER(i915) >= 12) {
> + val |= MBUS_DBOX_BW_CREDIT(2);
> + val |= MBUS_DBOX_B_CREDIT(12);
> + } else {
> + val |= MBUS_DBOX_BW_CREDIT(1);
> + val |= MBUS_DBOX_B_CREDIT(8);
> + }
> +
> + for_each_intel_crtc_in_pipe_mask(&i915->drm, crtc, new_dbuf_state-
> >active_pipes) {
> + u32 pipe_val = val;
> +
> + if (DISPLAY_VER(i915) >= 14) {
> + if (xelpdp_is_only_pipe_per_dbuf_bank(crtc->pipe,
> + new_dbuf_state-
> >active_pipes))
> + pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
> + else
> + pipe_val |= MBUS_DBOX_BW_4CREDITS_MTL;
> + }
> +
> + intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe),
> pipe_val);
> + }
> +}
> +
> int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state,
> u8
> ratio) {
> struct intel_dbuf_state *dbuf_state;
> @@ -3657,89 +3740,6 @@ void intel_dbuf_post_plane_update(struct
> intel_atomic_state *state)
> new_dbuf_state->enabled_slices);
> }
>
> -static bool xelpdp_is_only_pipe_per_dbuf_bank(enum pipe pipe, u8
> active_pipes) -{
> - switch (pipe) {
> - case PIPE_A:
> - return !(active_pipes & BIT(PIPE_D));
> - case PIPE_D:
> - return !(active_pipes & BIT(PIPE_A));
> - case PIPE_B:
> - return !(active_pipes & BIT(PIPE_C));
> - case PIPE_C:
> - return !(active_pipes & BIT(PIPE_B));
> - default: /* to suppress compiler warning */
> - MISSING_CASE(pipe);
> - break;
> - }
RE: [PATCH 05/13] drm/i915: Loop over all active pipes in intel_mbus_dbox_update
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 05/13] drm/i915: Loop over all active pipes in
> intel_mbus_dbox_update
>
> From: Stanislav Lisovskiy
>
> We need to loop through all active pipes, not just the ones, that are in
> current
> state, because disabling and enabling even a particular pipe affects credits
> in
> another one.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index bc341abcab2f..f582992592c1 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3680,10 +3680,8 @@ void intel_mbus_dbox_update(struct
> intel_atomic_state *state) {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> const struct intel_dbuf_state *new_dbuf_state, *old_dbuf_state;
> - const struct intel_crtc_state *new_crtc_state;
> const struct intel_crtc *crtc;
> u32 val = 0;
> - int i;
>
> if (DISPLAY_VER(i915) < 11)
> return;
> @@ -3727,12 +3725,9 @@ void intel_mbus_dbox_update(struct
> intel_atomic_state *state)
> val |= MBUS_DBOX_B_CREDIT(8);
> }
>
> - for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + for_each_intel_crtc_in_pipe_mask(&i915->drm, crtc,
> +new_dbuf_state->active_pipes) {
> u32 pipe_val = val;
>
> - if (!new_crtc_state->hw.active)
> - continue;
> -
> if (DISPLAY_VER(i915) >= 14) {
> if (xelpdp_is_only_pipe_per_dbuf_bank(crtc->pipe,
> new_dbuf_state-
> >active_pipes))
> --
> 2.43.2
RE: [PATCH 04/13] drm/i915/cdclk: Indicate whether CDCLK change happens during pre or post plane update
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 04/13] drm/i915/cdclk: Indicate whether CDCLK change happens
> during pre or post plane update
>
> From: Ville Syrjälä
>
> Currently we just get a plain "Changing CDCLK to ..." in the logs. It would
> actually
> be interesting to see whether we're doing the programming during the pre or
> post
> plane phase of the commit. Include that information in the debug message.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 19 ++-
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 99d2657f29a7..98546f384023 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2434,18 +2434,9 @@ static void intel_pcode_notify(struct
> drm_i915_private *i915,
> ret);
> }
>
> -/**
> - * intel_set_cdclk - Push the CDCLK configuration to the hardware
> - * @dev_priv: i915 device
> - * @cdclk_config: new CDCLK configuration
> - * @pipe: pipe with which to synchronize the update
> - *
> - * Program the hardware based on the passed in CDCLK state,
> - * if necessary.
> - */
> static void intel_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> - enum pipe pipe)
> + enum pipe pipe, const char *context)
> {
> struct intel_encoder *encoder;
>
> @@ -2455,7 +2446,7 @@ static void intel_set_cdclk(struct drm_i915_private
> *dev_priv,
> if (drm_WARN_ON_ONCE(&dev_priv->drm, !dev_priv-
> >display.funcs.cdclk->set_cdclk))
> return;
>
> - intel_cdclk_dump_config(dev_priv, cdclk_config, "Changing CDCLK to");
> + intel_cdclk_dump_config(dev_priv, cdclk_config, context);
>
> for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder); @@ -
> 2623,7 +2614,8 @@ intel_set_cdclk_pre_plane_update(struct intel_atomic_state
> *state)
>
> drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
>
> - intel_set_cdclk(i915, &cdclk_config, new_cdclk_state->pipe);
> + intel_set_cdclk(i915, &cdclk_config, new_cdclk_state->pipe,
> + "Pre changing CDCLK to");
> }
>
> /**
> @@ -2651,7 +2643,8 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
>
> drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual, new_cdclk_state-
> >pipe);
> + intel_set_cdclk(i915, &new_cdclk_state->actual, new_cdclk_state->pipe,
> + "Post changing CDCLK to");
> }
>
> static int intel_pixel_rate_to_cdclk(const struct intel_crtc_state
> *crtc_state)
> --
> 2.43.2
RE: [PATCH 03/13] drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 03/13] drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks
>
> From: Ville Syrjälä
>
> No ever figured out why bumping the cdclk helped with whatever issue we were
> having at the time.
> Remove the hacks and start from scratch so that we can actually see if any
> problems still remain.
Yeah, there can be cases where bumping the clock can help avoid the latency
and suppress an issue. However, this is not recommended by hardware and we
should be able to drive the display as per the calculated clock based on pixel
rate.
Having said that, we should brace ourselves for the issues which it was fixing.
Ok to drop the hack,
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 19 ---
> 1 file changed, 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 504c5cbbcfff..99d2657f29a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2802,25 +2802,6 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
> if (crtc_state->dsc.compression_enable)
> min_cdclk = max(min_cdclk, intel_vdsc_min_cdclk(crtc_state));
>
> - /*
> - * HACK. Currently for TGL/DG2 platforms we calculate
> - * min_cdclk initially based on pixel_rate divided
> - * by 2, accounting for also plane requirements,
> - * however in some cases the lowest possible CDCLK
> - * doesn't work and causing the underruns.
> - * Explicitly stating here that this seems to be currently
> - * rather a Hack, than final solution.
> - */
> - if (IS_TIGERLAKE(dev_priv) || IS_DG2(dev_priv)) {
> - /*
> - * Clamp to max_cdclk_freq in case pixel rate is higher,
> - * in order not to break an 8K, but still leave W/A at place.
> - */
> - min_cdclk = max_t(int, min_cdclk,
> - min_t(int, crtc_state->pixel_rate,
> - dev_priv-
> >display.cdclk.max_cdclk_freq));
> - }
> -
> return min_cdclk;
> }
>
> --
> 2.43.2
RE: [PATCH 02/13] drm/i915/cdclk: Fix voltage_level programming edge case
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 02/13] drm/i915/cdclk: Fix voltage_level programming edge case
>
> From: Ville Syrjälä
>
> Currently we only consider the relationship of the old and new CDCLK
> frequencies
> when determining whether to do the repgramming from
> intel_set_cdclk_pre_plane_update()
> or intel_set_cdclk_post_plane_update().
>
> It is technically possible to have a situation where the CDCLK frequency is
> decreasing, but the voltage_level is increasing due a DDI port. In this case
> we
> should bump the voltage level already in intel_set_cdclk_pre_plane_update()
> (so that the voltage_level will have been increased by the time the port gets
> enabled), while leaving the CDCLK frequency unchanged (as active planes/etc.
> may still depend on it).
> We can then reduce the CDCLK frequency to its final value from
> intel_set_cdclk_post_plane_update().
>
> In order to handle that correctly we shall construct a suitable amalgam of
> the old
> and new cdclk states in intel_set_cdclk_pre_plane_update().
>
> And we can simply call intel_set_cdclk() unconditionally in both places as it
> will
> not do anything if nothing actually changes vs. the current hw state.
>
> v2: Handle cdclk_state->disable_pipes
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 27 +-
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 619529dba095..504c5cbbcfff 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2600,6 +2600,7 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
> intel_atomic_get_old_cdclk_state(state);
> const struct intel_cdclk_state *new_cdclk_state =
> intel_atomic_get_new_cdclk_state(state);
> + struct intel_cdclk_config cdclk_config;
>
> if (!intel_cdclk_changed(&old_cdclk_state->actual,
>&new_cdclk_state->actual))
> @@ -2608,13 +2609,21 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
> if (IS_DG2(i915))
> intel_cdclk_pcode_pre_notify(state);
>
> - if (new_cdclk_state->disable_pipes ||
> - old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
> - drm_WARN_ON(&i915->drm, !new_cdclk_state-
> >base.changed);
> + if (new_cdclk_state->disable_pipes) {
> + cdclk_config = new_cdclk_state->actual;
> + } else {
> + if (new_cdclk_state->actual.cdclk >= old_cdclk_state-
> >actual.cdclk)
> + cdclk_config = new_cdclk_state->actual;
> + else
> + cdclk_config = old_cdclk_state->actual;
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual,
> - new_cdclk_state->pipe);
> + cdclk_config.voltage_level = max(new_cdclk_state-
> >actual.voltage_level,
> + old_cdclk_state-
> >actual.voltage_level);
> }
> +
> + drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
> +
> + intel_set_cdclk(i915, &cdclk_config, new_cdclk_state->pipe);
> }
>
> /**
> @@ -2640,13 +2649,9 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
> if (IS_DG2(i915))
> intel_cdclk_pcode_post_notify(state);
>
> - if (!new_cdclk_state->disable_pipes &&
> - old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
> - drm_WARN_ON(&i915->drm, !new_cdclk_state-
> >base.changed);
> + drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual,
> - new_cdclk_state->pipe);
> - }
> + intel_set_cdclk(i915, &new_cdclk_state->actual,
> +new_cdclk_state->pipe);
> }
>
> static int intel_pixel_rate_to_cdclk(const struct intel_crtc_state
> *crtc_state)
> --
> 2.43.2
RE: [PATCH 01/13] drm/i915/cdclk: Fix CDCLK programming order when pipes are active
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 01/13] drm/i915/cdclk: Fix CDCLK programming order when
> pipes are active
>
> From: Ville Syrjälä
>
> Currently we always reprogram CDCLK from the
> intel_set_cdclk_pre_plane_update() when using squahs/crawl.
Nitpick: Typo in squash
Change Looks Good to me.
Reviewed-by: Uma Shankar
> The code only works correctly for the cd2x update or full modeset cases, and
> it
> was simply never updated to deal with squash/crawl.
>
> If the CDCLK frequency is increasing we must reprogram it before we do
> anything
> else that might depend on the new higher frequency, and conversely we must not
> decrease the frequency until everything that might still depend on the old
> higher
> frequency has been dealt with.
>
> Since cdclk_state->pipe is only relevant when doing a cd2x update we can't
> use it
> to determine the correct sequence during squash/crawl. To that end introduce
> cdclk_state->disable_pipes which simply indicates that we must perform the
> update while the pipes are disable (ie. during
> intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new
> CDCLK frequency comparsiong as for cd2x updates.
>
> The only remaining problem case is when the voltage_level needs to increase
> due
> to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are
> being
> disabled). The current approach will not bump the voltage level up until
> after the
> port has already been enabled, which is too late.
> But we'll take care of that case separately.
>
> v2: Don't break the "must disable pipes case"
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +--
> drivers/gpu/drm/i915/display/intel_cdclk.h | 3 +++
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 31aaa9780dfc..619529dba095 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2600,7 +2600,6 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
> intel_atomic_get_old_cdclk_state(state);
> const struct intel_cdclk_state *new_cdclk_state =
> intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
>
> if (!intel_cdclk_changed(&old_cdclk_state->actual,
>&new_cdclk_state->actual))
> @@ -2609,11 +2608,12 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
> if (IS_DG2(i915))
> intel_cdclk_pcode_pre_notify(state);
>
> - if (pipe == INVALID_PIPE ||
> + if (new_cdclk_state->disable_pipes ||
> old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
> drm_WARN_ON(&i915->drm, !new_cdclk_state-
> >base.changed);
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, &new_cdclk_state->actual,
> + new_cdclk_state->pipe);
> }
> }
>
> @@ -2632,7 +2632,6 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
> intel_atomic_get_old_cdclk_state(state);
> const struct intel_cdclk_state *new_cdclk_state =
> intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
>
> if (!intel_cdclk_changed(&old_cdclk_state->actual,
>&new_cdclk_state->actual))
> @@ -2641,11 +2640,12 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
> if (IS_DG2(i915))
> intel_cdclk_pcode_post_notify(state);
>
> - if (pipe != INVALID_PIPE &&
> + if (!new_cdclk_state->disable_pipes &&
> old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
> drm_WARN_ON(&i915->drm, !new_cdclk_state-
> >base.changed);
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, &new_cdclk_state->actual,
> + new_cdclk_state->pipe);
> }
> }
>
> @@ -3124,6 +3124,7 @@ static struct intel_global_state
> *intel_cdclk_duplicate_state(struct intel_globa
> return NULL;
>
> cdclk_state->pipe = INVALID_PIPE;
> + cdclk_state->disable_pipes = false;
>
> return &cdclk_state->base;
> }
> @@ -3316,6 +3317,8 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> if (ret)
> return ret;
>
> + new_cdclk_state->disable_pipes = true;
> +
> drm_dbg_kms(&dev_priv->drm,
> "Modeset required for cdclk change\n");
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/
RE: [PATCH v2 1/3] drm/i915/cdclk: Fix CDCLK programming order when pipes are active
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 3:40 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v2 1/3] drm/i915/cdclk: Fix CDCLK programming order when
> pipes are active
>
> From: Ville Syrjälä
>
> Currently we always reprogram CDCLK from the
> intel_set_cdclk_pre_plane_update() when using squahs/crawl.
Nitpick: Typo in squash
Change Looks Good to me.
Reviewed-by: Uma Shankar
> The code only works correctly for the cd2x update or full modeset cases, and
> it
> was simply never updated to deal with squash/crawl.
>
> If the CDCLK frequency is increasing we must reprogram it before we do
> anything
> else that might depend on the new higher frequency, and conversely we must not
> decrease the frequency until everything that might still depend on the old
> higher
> frequency has been dealt with.
>
> Since cdclk_state->pipe is only relevant when doing a cd2x update we can't
> use it
> to determine the correct sequence during squash/crawl. To that end introduce
> cdclk_state->disable_pipes which simply indicates that we must perform the
> update while the pipes are disable (ie. during
> intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new
> CDCLK frequency comparsiong as for cd2x updates.
>
> The only remaining problem case is when the voltage_level needs to increase
> due
> to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are
> being
> disabled). The current approach will not bump the voltage level up until
> after the
> port has already been enabled, which is too late.
> But we'll take care of that case separately.
>
> v2: Don't break the "must disable pipes case"
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +--
> drivers/gpu/drm/i915/display/intel_cdclk.h | 3 +++
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 31aaa9780dfc..619529dba095 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2600,7 +2600,6 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
> intel_atomic_get_old_cdclk_state(state);
> const struct intel_cdclk_state *new_cdclk_state =
> intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
>
> if (!intel_cdclk_changed(&old_cdclk_state->actual,
>&new_cdclk_state->actual))
> @@ -2609,11 +2608,12 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
> if (IS_DG2(i915))
> intel_cdclk_pcode_pre_notify(state);
>
> - if (pipe == INVALID_PIPE ||
> + if (new_cdclk_state->disable_pipes ||
> old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
> drm_WARN_ON(&i915->drm, !new_cdclk_state-
> >base.changed);
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, &new_cdclk_state->actual,
> + new_cdclk_state->pipe);
> }
> }
>
> @@ -2632,7 +2632,6 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
> intel_atomic_get_old_cdclk_state(state);
> const struct intel_cdclk_state *new_cdclk_state =
> intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
>
> if (!intel_cdclk_changed(&old_cdclk_state->actual,
>&new_cdclk_state->actual))
> @@ -2641,11 +2640,12 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
> if (IS_DG2(i915))
> intel_cdclk_pcode_post_notify(state);
>
> - if (pipe != INVALID_PIPE &&
> + if (!new_cdclk_state->disable_pipes &&
> old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
> drm_WARN_ON(&i915->drm, !new_cdclk_state-
> >base.changed);
>
> - intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, &new_cdclk_state->actual,
> + new_cdclk_state->pipe);
> }
> }
>
> @@ -3124,6 +3124,7 @@ static struct intel_global_state
> *intel_cdclk_duplicate_state(struct intel_globa
> return NULL;
>
> cdclk_state->pipe = INVALID_PIPE;
> + cdclk_state->disable_pipes = false;
>
> return &cdclk_state->base;
> }
> @@ -3316,6 +3317,8 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> if (ret)
> return ret;
>
> + new_cdclk_state->disable_pipes = true;
> +
> drm_dbg_kms(&dev_priv->drm,
> "Modeset required for cdclk change\n");
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/
RE: [PATCH v3 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state transitions
> -Original Message- > From: Coelho, Luciano > Sent: Monday, March 18, 2024 7:08 PM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org; Shankar, Uma ; > ville.syrj...@linux.intel.com; Nikula, Jani > Subject: [PATCH v3 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state > transitions > > We only need DMC wakelocks when we allow DC5 and DC6 states. Add the calls > to enable and disable DMC wakelock accordingly. > Signed-off-by: Luca Coelho > --- > drivers/gpu/drm/i915/display/intel_display_power_well.c | 7 +++ > drivers/gpu/drm/i915/display/intel_dmc.c| 4 > 2 files changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c > b/drivers/gpu/drm/i915/display/intel_display_power_well.c > index 217f82f1da84..367464f5c5cd 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c > @@ -17,6 +17,7 @@ > #include "intel_dkl_phy.h" > #include "intel_dkl_phy_regs.h" > #include "intel_dmc.h" > +#include "intel_dmc_wl.h" > #include "intel_dp_aux_regs.h" > #include "intel_dpio_phy.h" > #include "intel_dpll.h" > @@ -821,6 +822,8 @@ void gen9_enable_dc5(struct drm_i915_private > *dev_priv) > intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, >0, SKL_SELECT_ALTERNATE_DC_EXIT); > > + intel_dmc_wl_enable(dev_priv); We can have platform checks here and call only when its supported. No strong objection but doing it here seems better than calling for all and then checking for platform inside. > gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC5); } > > @@ -850,6 +853,8 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv) > intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, >0, SKL_SELECT_ALTERNATE_DC_EXIT); > > + intel_dmc_wl_enable(dev_priv); > + > gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6); } > > @@ -970,6 +975,8 @@ void gen9_disable_dc_states(struct drm_i915_private > *dev_priv) > if (!HAS_DISPLAY(dev_priv)) > return; > > + intel_dmc_wl_disable(dev_priv); > + > intel_cdclk_get_cdclk(dev_priv, &cdclk_config); > /* Can't read out voltage_level so can't use intel_cdclk_changed() */ > drm_WARN_ON(&dev_priv->drm, > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c > b/drivers/gpu/drm/i915/display/intel_dmc.c > index 3fa851b5c7a6..b20cc018b9a8 100644 > --- a/drivers/gpu/drm/i915/display/intel_dmc.c > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c > @@ -550,6 +550,8 @@ void intel_dmc_disable_program(struct > drm_i915_private *i915) > pipedmc_clock_gating_wa(i915, true); > disable_all_event_handlers(i915); > pipedmc_clock_gating_wa(i915, false); > + > + intel_dmc_wl_disable(i915); > } > > void assert_dmc_loaded(struct drm_i915_private *i915) @@ -1079,6 +1081,8 > @@ void intel_dmc_suspend(struct drm_i915_private *i915) > if (dmc) > flush_work(&dmc->work); > > + intel_dmc_wl_disable(i915); > + > /* Drop the reference held in case DMC isn't loaded. */ > if (!intel_dmc_has_payload(i915)) > intel_dmc_runtime_pm_put(i915); > -- > 2.39.2
RE: [PATCH v3 3/4] drm/i915/display: add module parameter to enable DMC wakelock
> -Original Message-
> From: Coelho, Luciano
> Sent: Monday, March 18, 2024 7:08 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani
> Subject: [PATCH v3 3/4] drm/i915/display: add module parameter to enable DMC
> wakelock
>
> This feature should be disabled by default until properly tested and mature.
> Add
> a module parameter to enable the feature for testing, while keeping it
> disabled by
> default for now.
>
> Signed-off-by: Luca Coelho
> ---
> drivers/gpu/drm/i915/display/intel_display_params.c | 5 +
> drivers/gpu/drm/i915/display/intel_display_params.h | 1 +
> drivers/gpu/drm/i915/display/intel_dmc_wl.c | 12
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c
> b/drivers/gpu/drm/i915/display/intel_display_params.c
> index 11e03cfb774d..f40b223cc8a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.c
> @@ -116,6 +116,11 @@
> intel_display_param_named_unsafe(enable_psr2_sel_fetch, bool, 0400,
> "(0=disabled, 1=enabled) "
> "Default: 1");
>
> +intel_display_param_named_unsafe(enable_dmc_wl, bool, 0400,
> + "Enable DMC wakelock "
> + "(0=disabled, 1=enabled) "
> + "Default: 0");
> +
> __maybe_unused
> static void _param_print_bool(struct drm_printer *p, const char *driver_name,
> const char *name, bool val)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h
> b/drivers/gpu/drm/i915/display/intel_display_params.h
> index 6206cc51df04..bf8dbbdb20a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.h
> @@ -46,6 +46,7 @@ struct drm_i915_private;
> param(int, enable_psr, -1, 0600) \
> param(bool, psr_safest_params, false, 0400) \
> param(bool, enable_psr2_sel_fetch, true, 0400) \
> + param(bool, enable_dmc_wl, false, 0400) \
>
> #define MEMBER(T, member, ...) T member; struct intel_display_params { diff
> --
> git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> index 7c991e22c616..84d054bcb2c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> @@ -120,7 +120,8 @@ void intel_dmc_wl_enable(struct drm_i915_private
> *i915)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
Extend this check to init as well. Else it looks ok to protect under a module
parameter.
Reviewed-by: Uma Shankar
> return;
>
> spin_lock_irqsave(&wl->lock, flags);
> @@ -146,7 +147,8 @@ void intel_dmc_wl_disable(struct drm_i915_private
> *i915)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
> return;
>
> flush_delayed_work(&wl->work);
> @@ -177,7 +179,8 @@ void intel_dmc_wl_get(struct drm_i915_private *i915,
> i915_reg_t reg)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
> return;
>
> if (!intel_dmc_wl_check_range(reg.reg))
> @@ -212,7 +215,8 @@ void intel_dmc_wl_put(struct drm_i915_private *i915,
> i915_reg_t reg)
> struct intel_dmc_wl *wl = &i915->display.wl;
> unsigned long flags;
>
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
> return;
>
> if (!intel_dmc_wl_check_range(reg.reg))
> --
> 2.39.2
RE: [PATCH v3 2/4] drm/i915/display: don't allow DMC wakelock on older hardware
> -Original Message- > From: Coelho, Luciano > Sent: Monday, March 18, 2024 7:08 PM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org; Shankar, Uma ; > ville.syrj...@linux.intel.com; Nikula, Jani > Subject: [PATCH v3 2/4] drm/i915/display: don't allow DMC wakelock on older > hardware > > Only allow running DMC wakelock code if the display version is 20 or greater. One for previous one, don't do intel_dmc_wl_init unconditionally but protect it with Platform check. > Signed-off-by: Luca Coelho > --- > drivers/gpu/drm/i915/display/intel_dmc_wl.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c > b/drivers/gpu/drm/i915/display/intel_dmc_wl.c > index 5c3d8204ae7e..7c991e22c616 100644 > --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c > +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c > @@ -120,6 +120,9 @@ void intel_dmc_wl_enable(struct drm_i915_private > *i915) > struct intel_dmc_wl *wl = &i915->display.wl; > unsigned long flags; > > + if (DISPLAY_VER(i915) < 20) > + return; > + > spin_lock_irqsave(&wl->lock, flags); > > if (wl->enabled) > @@ -143,6 +146,9 @@ void intel_dmc_wl_disable(struct drm_i915_private > *i915) > struct intel_dmc_wl *wl = &i915->display.wl; > unsigned long flags; > > + if (DISPLAY_VER(i915) < 20) > + return; There can be case where DMC is not loaded, address that as well. We should not do wakelock in that case. > flush_delayed_work(&wl->work); > > spin_lock_irqsave(&wl->lock, flags); > @@ -171,6 +177,9 @@ void intel_dmc_wl_get(struct drm_i915_private *i915, > i915_reg_t reg) > struct intel_dmc_wl *wl = &i915->display.wl; > unsigned long flags; > > + if (DISPLAY_VER(i915) < 20) > + return; > + > if (!intel_dmc_wl_check_range(reg.reg)) > return; > > @@ -203,6 +212,9 @@ void intel_dmc_wl_put(struct drm_i915_private *i915, > i915_reg_t reg) > struct intel_dmc_wl *wl = &i915->display.wl; > unsigned long flags; > > + if (DISPLAY_VER(i915) < 20) > + return; > + > if (!intel_dmc_wl_check_range(reg.reg)) > return; > > -- > 2.39.2
RE: [PATCH v3 1/4] drm/i915/display: add support for DMC wakelocks
> -Original Message-
> From: Coelho, Luciano
> Sent: Monday, March 18, 2024 7:08 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani
> Subject: [PATCH v3 1/4] drm/i915/display: add support for DMC wakelocks
>
> In order to reduce the DC5->DC2 restore time, wakelocks have been introduced
> in DMC so the driver can tell it when registers and other memory areas are
> going
> to be accessed and keep their respective blocks awake.
>
> Implement this in the driver by adding the concept of DMC wakelocks.
> When the driver needs to access memory which lies inside pre-defined ranges,
> it
> will tell DMC to set the wakelock, access the memory, then wait for a while
> and
> clear the wakelock.
>
> The wakelock state is protected in the driver with spinlocks to prevent
> concurrency issues.
>
> BSpec: 71583
These are internal links, not sure how useful they will be for upstream
discussions.
Give the relevant details here which is better I believe instead of an internal
link.
> Signed-off-by: Luca Coelho
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_de.h | 97 +++-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +
> .../drm/i915/display/intel_display_driver.c | 1 +
> drivers/gpu/drm/i915/display/intel_dmc_regs.h | 6 +
> drivers/gpu/drm/i915/display/intel_dmc_wl.c | 226 ++
> drivers/gpu/drm/i915/display/intel_dmc_wl.h | 30 +++
> drivers/gpu/drm/xe/Makefile | 1 +
> 8 files changed, 356 insertions(+), 8 deletions(-) create mode 100644
> drivers/gpu/drm/i915/display/intel_dmc_wl.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_dmc_wl.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3ef6ed41e62b..af83ea94c771 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -270,6 +270,7 @@ i915-y += \
> display/intel_display_rps.o \
> display/intel_display_wa.o \
> display/intel_dmc.o \
> + display/intel_dmc_wl.o \
> display/intel_dpio_phy.o \
> display/intel_dpll.o \
> display/intel_dpll_mgr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index 42552d8c151e..6728a0077793 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -13,52 +13,125 @@
> static inline u32
> intel_de_read(struct drm_i915_private *i915, i915_reg_t reg) {
> - return intel_uncore_read(&i915->uncore, reg);
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
I think one fundamental issue in taking the lock at the granularity of
every MMIO, we risk adding latency here. We should profile the time
it adds.
For modeset for ex, we will end up programming multiple MMIO's from 1 place
But every MMIO call will take the wakelock. This is overkill, instead we can
just take
the lock once, do our stuff and then release it.
> +
> + val = intel_uncore_read(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> }
>
> static inline u8
> intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg) {
> - return intel_uncore_read8(&i915->uncore, reg);
> + u8 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read8(&i915->uncore, reg);
Same here and all similar functions.
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> }
>
> static inline u64
> intel_de_read64_2x32(struct drm_i915_private *i915,
>i915_reg_t lower_reg, i915_reg_t upper_reg) {
> - return intel_uncore_read64_2x32(&i915->uncore, lower_reg,
> upper_reg);
> + u64 val;
> +
> + intel_dmc_wl_get(i915, lower_reg);
> + intel_dmc_wl_get(i915, upper_reg);
I guess if the register falls in the range, taking just 1 wakelock should be
enough.
> +
> + val = intel_uncore_read64_2x32(&i915->uncore, lower_reg, upper_reg);
> +
> + intel_dmc_wl_put(i915, upper_reg);
> + intel_dmc_wl_put(i915, lower_reg);
> +
> + return val;
> }
>
> static inline void
> intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg) {
> + intel_dmc_wl_get(i915, reg);
> +
> intel_uncore_posting_read(&i915->uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> }
>
> static inline void
> intel_de_write(struct drm_i915_private *i915, i915_reg_t reg, u32 val) {
> + intel_dmc_wl_get(i915, reg);
> +
>
RE: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation
> -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:49 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation > > Add support to enable the DP tunnel BW allocation mode. Follow-up patches will > call the required helpers added here to prepare for a modeset on a link with > DP > tunnels, the last change in the patchset actually enabling BWA. > > With BWA enabled, the driver will expose the full mode list a display > supports, > regardless of any BW limitation on a shared (Thunderbolt) link. Such BW > limits will > be checked against only during a modeset, when the driver has the full > knowledge > of each display's BW requirement. > > If the link BW changes in a way that a connector's modelist may also change, > userspace will get a hotplug notification for all the connectors sharing the > same > link (so it can adjust the mode used for a display). > > The BW limitation can change at any point, asynchronously to modesets on a > given connector, so a modeset can fail even though the atomic check for it > passed. In such scenarios userspace will get a bad link notification and in > response is supposed to retry the modeset. > > v2: > - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state(). > (Ville) > - Fix propagating the error from > intel_dp_tunnel_atomic_compute_stream_bw(). (Ville) > - Move tunnel==NULL checks from driver to DRM core helpers. (Ville) > - Simplify return flow from intel_dp_tunnel_detect(). (Ville) > - s/dp_tunnel_state/inherited_dp_tunnels (Ville) > - Simplify struct intel_dp_tunnel_inherited_state. (Ville) > - Unconstify object pointers (vs. states) where possible. (Ville) > - Init crtc_state while declaring it in check_group_state(). (Ville) > - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC. > (Ville) > - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the > BW allocation from encoder hooks up to intel_atomic_commit_tail() > later in the patchset. > - Disable BW alloc mode during system suspend. > - Allocate the required BW for all tunnels during system resume. > - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded > sequence in a follow-up patch. > - Add function documentation to all exported functions. > - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL. Changes look good to me. Reviewed-by: Uma Shankar > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/Kconfig | 14 + > drivers/gpu/drm/i915/Kconfig.debug| 1 + > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/display/intel_atomic.c | 2 + > drivers/gpu/drm/i915/display/intel_crtc.c | 25 + > drivers/gpu/drm/i915/display/intel_crtc.h | 1 + > .../gpu/drm/i915/display/intel_display_core.h | 1 + > .../drm/i915/display/intel_display_types.h| 9 + > .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 ++ > .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 +++ > 10 files changed, 1004 insertions(+) > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index > 3089029abba48..5932024f8f954 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -155,6 +155,20 @@ config DRM_I915_PXP > protected session and manage the status of the alive software session, > as well as its life cycle. > > +config DRM_I915_DP_TUNNEL > + bool "Enable DP tunnel support" > + depends on DRM_I915 > + depends on USB4 > + select DRM_DISPLAY_DP_TUNNEL > + default y > + help > + Choose this option to detect DP tunnels and enable the Bandwidth > + Allocation mode for such tunnels. This allows using the maximum > + resolution allowed by the link BW on all displays sharing the > + link BW, for instance on a Thunderbolt link. > + > + If in doubt, say "Y". > + > menu "drm/i915 Debugging" > depends on DRM_I915 > depends on EXPERT > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 5b7162076850c..bc18e2d9ea05d 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -28,6 +28,7 @@ config DRM_I915_DEBUG > select STACKDEPOT > select STACKTRACE > select DRM_DP_AUX_CHARDEV > + select DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE if > DRM_I915_DP_TUNNEL > select X86_MSR # used by igt/pm_rpm > select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) > select DRM_DEBUG_MM if DRM=y > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index c13f14edb5088..3ef6
RE: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
>
> Detect DP tunnels and enable the BW allocation mode on them. Send a hotplug
> notification to userspace in response to a BW change.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_display_driver.c | 20 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--
> 2 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 4f7ba7eb03d27..87dd07e0d138d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -35,6 +35,7 @@
> #include "intel_dkl_phy.h"
> #include "intel_dmc.h"
> #include "intel_dp.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpll.h"
> #include "intel_dpll_mgr.h"
> #include "intel_fb.h"
> @@ -434,10 +435,8 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
>
> for_each_pipe(i915, pipe) {
> ret = intel_crtc_init(i915, pipe);
> - if (ret) {
> - intel_mode_config_cleanup(i915);
> - return ret;
> - }
> + if (ret)
> + goto err_mode_config;
> }
>
> intel_plane_possible_crtcs_init(i915);
> @@ -457,6 +456,10 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
> intel_vga_disable(i915);
> intel_setup_outputs(i915);
>
> + ret = intel_dp_tunnel_mgr_init(i915);
> + if (ret)
> + goto err_hdcp;
> +
> intel_display_driver_disable_user_access(i915);
>
> drm_modeset_lock_all(dev);
> @@ -475,6 +478,13 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
> ilk_wm_sanitize(i915);
>
> return 0;
> +
> +err_hdcp:
> + intel_hdcp_component_fini(i915);
> +err_mode_config:
> + intel_mode_config_cleanup(i915);
> +
> + return ret;
> }
>
> /* part #3: call after gem init */
> @@ -599,6 +609,8 @@ void intel_display_driver_remove_noirq(struct
> drm_i915_private *i915)
>
> intel_mode_config_cleanup(i915);
>
> + intel_dp_tunnel_mgr_cleanup(i915);
> +
> intel_overlay_cleanup(i915);
>
> intel_gmbus_teardown(i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f7f8bd5742ad4..789b5fa074fd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5726,6 +5726,7 @@ intel_dp_detect(struct drm_connector *connector,
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = &dig_port->base;
> enum drm_connector_status status;
> + int ret;
>
> drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name); @@ -5761,9 +5762,18
> @@ intel_dp_detect(struct drm_connector *connector,
> intel_dp->is_mst);
> }
>
> + intel_dp_tunnel_disconnect(intel_dp);
> +
> goto out;
> }
>
> + ret = intel_dp_tunnel_detect(intel_dp, ctx);
> + if (ret == -EDEADLK)
> + return ret;
> +
> + if (ret == 1)
> + intel_connector->base.epoch_counter++;
> +
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> intel_dp_configure_mst(intel_dp);
> @@ -5794,8 +5804,6 @@ intel_dp_detect(struct drm_connector *connector,
>* with an IRQ_HPD, so force a link status check.
>*/
> if (!intel_dp_is_edp(intel_dp)) {
> - int ret;
> -
> ret = intel_dp_retrain_link(encoder, ctx);
> if (ret)
> return ret;
> @@ -5935,6 +5943,8 @@ void intel_dp_encoder_flush_work(struct
> drm_encoder *encoder)
>
> intel_dp_mst_encoder_cleanup(dig_port);
>
> + intel_dp_tunnel_destroy(intel_dp);
> +
> intel_pps_vdd_off_sync(intel_dp);
>
> /*
> --
> 2.39.2
RE: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
>
> The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
> depends on the GFX driver reading out the sink's DPRX capabilities in
> response to
> a long HPD pulse. Since in i915 this read-out can be blocked by another
> connector's/encoder's hotplug event handling (which is serialized by
> drm_mode_config::connection_mutex), do a dummy DPRX read-out in the
> encoder's HPD pulse handler (which is not blocked by other encoders).
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 35ef17439038a..f7f8bd5742ad4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6162,6 +6162,7 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
> bool long_hpd) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_dp *intel_dp = &dig_port->dp;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
>
> if (dig_port->base.type == INTEL_OUTPUT_EDP &&
> (long_hpd || !intel_pps_have_panel_power_or_vdd(intel_dp))) { @@ -
> 6184,6 +6185,17 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
> bool long_hpd)
> dig_port->base.base.name,
> long_hpd ? "long" : "short");
>
> + /*
> + * TBT DP tunnels require the GFX driver to read out the DPRX caps in
> + * response to long HPD pulses. The DP hotplug handler does that,
> + * however the hotplug handler may be blocked by another
> + * connector's/encoder's hotplug handler. Since the TBT CM may not
> + * complete the DP tunnel BW request for the latter connector/encoder
> + * waiting for this encoder's DPRX read, perform a dummy read here.
> + */
> + if (long_hpd)
> + intel_dp_read_dprx_caps(intel_dp, dpcd);
> +
> if (long_hpd) {
> intel_dp->reset_link_params = true;
> return IRQ_NONE;
> --
> 2.39.2
RE: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
>
> Suspend and resume DP tunnels during system suspend/resume, disabling the BW
> allocation mode during suspend, re-enabling it after resume. This reflects the
> link's BW management component (Thunderbolt CM) disabling BWA during
> suspend. Before any BW requests the driver must read the sink's DPRX
> capabilities (since the BW manager requires this information, so snoops for
> it on
> AUX), so ensure this read takes place.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a3dfcbb710027..35ef17439038a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -36,6 +36,7 @@
> #include
>
> #include
> +#include
> #include #include
> #include @@ -
> 3313,18 +3314,21 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> - if (!crtc_state)
> - return;
> + bool dpcd_updated = false;
>
> /*
>* Don't clobber DPCD if it's been already read out during output
>* setup (eDP) or detect.
>*/
> - if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> + if (crtc_state && intel_dp->dpcd[DP_DPCD_REV] == 0) {
> intel_dp_get_dpcd(intel_dp);
> + dpcd_updated = true;
> + }
>
> - intel_dp_reset_max_link_params(intel_dp);
> + intel_dp_tunnel_resume(intel_dp, crtc_state, dpcd_updated);
> +
> + if (crtc_state)
> + intel_dp_reset_max_link_params(intel_dp);
> }
>
> bool intel_dp_initial_fastset_check(struct intel_encoder *encoder, @@ -5947,6
> +5951,8 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
>
> intel_pps_vdd_off_sync(intel_dp);
> +
> + intel_dp_tunnel_suspend(intel_dp);
> }
>
> void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
> --
> 2.39.2
RE: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
>
> Handle DP tunnel IRQs a sink (or rather a BW management component like the
> Thunderbolt Connection Manager) raises to signal the completion of a BW
> request by the driver, or to signal any state change related to the link BW.
Looks Good to me.
Reviewed-by: Uma Shankar
X`
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
> include/drm/display/drm_dp.h| 1 +
> 2 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5ad7808788745..a3dfcbb710027 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4904,13 +4904,15 @@ static bool intel_dp_mst_link_status(struct intel_dp
> *intel_dp)
> * - %true if pending interrupts were serviced (or no interrupts were
> * pending) w/o detecting an error condition.
> * - %false if an error condition - like AUX failure or a loss of link - is
> - * detected, which needs servicing from the hotplug work.
> + * detected, or another condition - like a DP tunnel BW state change -
> needs
> + * servicing from the hotplug work.
> */
> static bool
> intel_dp_check_mst_status(struct intel_dp *intel_dp) {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> bool link_ok = true;
> + bool reprobe_needed = false;
>
> drm_WARN_ON_ONCE(&i915->drm, intel_dp->active_mst_links < 0);
>
> @@ -4937,6 +4939,13 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>
> intel_dp_mst_hpd_irq(intel_dp, esi, ack);
>
> + if (esi[3] & DP_TUNNELING_IRQ) {
> + if (drm_dp_tunnel_handle_irq(i915-
> >display.dp_tunnel_mgr,
> + &intel_dp->aux))
> + reprobe_needed = true;
> + ack[3] |= DP_TUNNELING_IRQ;
> + }
> +
> if (!memchr_inv(ack, 0, sizeof(ack)))
> break;
>
> @@ -4947,7 +4956,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> drm_dp_mst_hpd_irq_send_new_request(&intel_dp-
> >mst_mgr);
> }
>
> - return link_ok;
> + return link_ok && !reprobe_needed;
> }
>
> static void
> @@ -5304,23 +5313,32 @@ static void
> intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
> drm_dbg_kms(&i915->drm, "Sink specific irq unhandled\n"); }
>
> -static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> +static bool intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool reprobe_needed = false;
> u8 val;
>
> if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
> - return;
> + return false;
>
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
> !val)
> - return;
> + return false;
> +
> + if ((val & DP_TUNNELING_IRQ) &&
> + drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
> + &intel_dp->aux))
> + reprobe_needed = true;
>
> if (drm_dp_dpcd_writeb(&intel_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
> - return;
> + return reprobe_needed;
>
> if (val & HDMI_LINK_STATUS_CHANGED)
> intel_dp_handle_hdmi_link_status_change(intel_dp);
> +
> + return reprobe_needed;
> }
>
> /*
> @@ -5341,6 +5359,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp) {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u8 old_sink_count = intel_dp->sink_count;
> + bool reprobe_needed = false;
> bool ret;
>
> /*
> @@ -5363,7 +5382,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> }
>
> intel_dp_check_device_service_irq(intel_dp);
> - intel_dp_check_link_service_irq(intel_dp);
> + reprobe_needed = intel_dp_check_link_service_irq(intel_dp);
>
> /* Handle CEC interrupts, if any */
> drm_dp_cec_irq(&intel_dp->aux);
> @@ -5390,10 +5409,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>* FIXME get rid of the ad-hoc phy test modeset code
>* and properly incorporate it into the normal modeset.
>*/
> - return false;
> + reprobe_needed = true;
> }
>
> - return true;
> + return !reprobe_needed;
> }
>
> /* XXX this is probably wrong for multiple downstream ports */ diff --git
> a/include/drm/display/drm_dp.h b/include/drm/display/drm_
RE: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check BW limit
> -Original Message- > From: dri-devel On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:49 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check > BW limit > > Add the atomic state during a modeset required to enable the DP tunnel BW > allocation mode on links where such a tunnel was detected. This state applies > to > an already enabled output, the state added for a newly enabled output will be > computed and added/cleared to/from the atomic state in a follow-up patch. > > v2: > - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state(). > - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up > patch adding the corresponding state. (Ville) > - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up > patch adding the corresponding state. Looks Good to me. Reviewed-by: Uma Shankar > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++ > drivers/gpu/drm/i915/display/intel_display.c | 12 > drivers/gpu/drm/i915/display/intel_link_bw.c | 5 + > 3 files changed, 23 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > b/drivers/gpu/drm/i915/display/intel_atomic.c > index 96ab37e158995..798cb90361a83 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > @@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc) > if (crtc_state->post_csc_lut) > drm_property_blob_get(crtc_state->post_csc_lut); > > + if (crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_get(crtc_state->dp_tunnel_ref.tunnel, > + &crtc_state->dp_tunnel_ref); > + > crtc_state->update_pipe = false; > crtc_state->update_m_n = false; > crtc_state->update_lrr = false; > @@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc, > > __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi); > intel_crtc_free_hw_state(crtc_state); > + if (crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_put(&crtc_state->dp_tunnel_ref); > kfree(crtc_state); > } > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index e1a4200f67a7e..16973ebb7865d 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -33,6 +33,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -73,6 +74,7 @@ > #include "intel_dp.h" > #include "intel_dp_link_training.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_dpll.h" > #include "intel_dpll_mgr.h" > #include "intel_dpt.h" > @@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct > intel_atomic_state *state, > saved_state->crc_enabled = slave_crtc_state->crc_enabled; > > intel_crtc_free_hw_state(slave_crtc_state); > + if (slave_crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_put(&slave_crtc_state->dp_tunnel_ref); > memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state)); > kfree(saved_state); > > @@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct > intel_atomic_state *state, > &master_crtc_state->hw.adjusted_mode); > slave_crtc_state->hw.scaling_filter = master_crtc_state- > >hw.scaling_filter; > > + if (master_crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_get(master_crtc_state- > >dp_tunnel_ref.tunnel, > + &slave_crtc_state->dp_tunnel_ref); > + > copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc); > > slave_crtc_state->uapi.mode_changed = master_crtc_state- > >uapi.mode_changed; > @@ -5365,6 +5373,10 @@ static int intel_modeset_pipe(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc); > + if (ret) > + return ret; > + > ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c > b/drivers/gpu/drm/i915/display/intel_link_bw.c > index 27ea858897c9f..dfd7d5e23f3fa 100644 > --- a/drivers/gpu/drm/i915/display/intel_link_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c > @@ -9,6 +9,7 @@ > #include "intel_crtc.h" > #include "intel_display_types.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_fdi.h" > #include "intel_link_bw.h" > > @@ -163,6 +164,10 @@ static int check_all_link_config(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_check_link(sta
RE: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with
> syncing
> commits
>
> Add a way to get the active pipes through a given DP port by syncing against a
> related pending non-blocking commit. Atm
> intel_dp_get_active_pipes() will only try to sync a given pipe and if that
> would
> block ignore the pipe. A follow-up change enabling the DP tunnel BW allocation
> mode will need to ensure that all active pipes are returned.
>
> This change will use intel_crtc_state::uapi.commit instead of the
> corresponding
> commit in the connector state. This shouldn't make a difference, since the two
> commit objects match for an active pipe.
>
> A follow-up patchset will remove syncing during TC port reset, which should
> reset
> a port/pipe even if syncing against a commit would block.
> Syncing OTOH is not needed there, since the commit used for the reset implies
> a
> sync already. For now add a TODO comment for this.
>
> v2:
> - Add a separate function to try-sync the pipes. (Ville)
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> 4 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 25593f6aae7de..17ed2e62cc66a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> out:
> intel_psr_unlock(new_crtc_state);
> }
> +
> +/**
> + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of
> +pipes
> + * @i915: i915 device object
> + * @pipe_mask: Mask of pipes to sync
> + *
> + * Try to sync a pending non-blocking commit for the provided pipes in
> + * @pipe_mask. The commit won't be synced if this would block.
> + *
> + * Return a mask of the pipes that got synced or didn't need syncing.
> + */
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> +pipe_mask) {
> + struct intel_crtc *crtc;
> + u32 synced = 0;
> +
> + for_each_intel_crtc_in_pipe_mask(&i915->drm, crtc, pipe_mask) {
> + const struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
> +
> + if (!crtc_state->uapi.commit ||
> + try_wait_for_completion(&crtc_state->uapi.commit-
> >hw_done))
> + synced |= BIT(crtc->pipe);
> + }
> +
> + return synced;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> b/drivers/gpu/drm/i915/display/intel_crtc.h
> index 22d7993d1f0ba..71a5b93166da7 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> drm_i915_private *i915, void intel_wait_for_vblank_if_active(struct
> drm_i915_private *i915,
>enum pipe pipe);
> void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> +pipe_mask);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d9e75922ff8f5..d0452d3e534a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> *intel_dp,
> if (!crtc_state->hw.active)
> continue;
>
> - if (conn_state->commit &&
> - !try_wait_for_completion(&conn_state->commit->hw_done))
> - continue;
> -
> *pipe_mask |= BIT(crtc->pipe);
> }
> drm_connector_list_iter_end(&conn_iter);
> @@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder
> *encoder,
> if (ret)
> return ret;
>
> + pipe_mask &= intel_crtc_try_sync_pipes(dev_priv, pipe_mask);
> +
> if (pipe_mask == 0)
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 6b374d481cd9e..14d17903a81f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -7,6 +7,7 @@
> #include "i915_reg.h"
> #include "intel_atomic.h"
> #include "intel_cx0_phy_regs.h"
> +#include "intel_crtc.h"
> #include "intel_ddi.h"
> #include "intel_de.h"
> #include "intel_display.h"
> @@ -1663,
RE: [PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to retry modesets
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to
> retry modesets
>
> On shared (Thunderbolt) links with DP tunnels, the modeset may need to be
> retried on all connectors on the link due to a link BW limitation arising
> only after
> the atomic check phase. To support this add a helper function queuing a work
> to
> retry the modeset on a given port's connector and at the same time any MST
> connector with streams through the same port. A follow-up change enabling the
> DP tunnel Bandwidth Allocation Mode will take this into use.
>
> v2:
> - Send the uevent only to enabled MST connectors. (Jouni)
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Jouni Högander
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 5 ++-
> drivers/gpu/drm/i915/display/intel_dp.c | 45 ++-
> drivers/gpu/drm/i915/display/intel_dp.h | 6 +++
> .../drm/i915/display/intel_dp_link_training.c | 3 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +
> 5 files changed, 55 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 485c38d71f106..2ee26d19c200b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8085,8 +8085,9 @@ void intel_hpd_poll_fini(struct drm_i915_private
> *i915)
> /* Kill all the work that may have been queued by hpd. */
> drm_connector_list_iter_begin(&i915->drm, &conn_iter);
> for_each_intel_connector_iter(connector, &conn_iter) {
> - if (connector->modeset_retry_work.func)
> - cancel_work_sync(&connector->modeset_retry_work);
> + if (connector->modeset_retry_work.func &&
> + cancel_work_sync(&connector->modeset_retry_work))
> + drm_connector_put(&connector->base);
> if (connector->hdcp.shim) {
> cancel_delayed_work_sync(&connector-
> >hdcp.check_work);
> cancel_work_sync(&connector->hdcp.prop_work);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 217196196e50a..88606e336a920 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2842,6 +2842,40 @@ intel_dp_audio_compute_config(struct intel_encoder
> *encoder,
> intel_dp_is_uhbr(pipe_config);
> }
>
> +void intel_dp_queue_modeset_retry_work(struct intel_connector
> +*connector) {
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
> +
> + drm_connector_get(&connector->base);
> + if (!queue_work(i915->unordered_wq, &connector-
> >modeset_retry_work))
> + drm_connector_put(&connector->base);
> +}
> +
> +void
> +intel_dp_queue_modeset_retry_for_link(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *crtc_state) {
> + struct intel_connector *connector;
> + struct intel_digital_connector_state *conn_state;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + int i;
> +
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
> + intel_dp_queue_modeset_retry_work(intel_dp-
> >attached_connector);
> +
> + return;
> + }
> +
> + for_each_new_intel_connector_in_state(state, connector, conn_state, i) {
> + if (!conn_state->base.crtc)
> + continue;
> +
> + if (connector->mst_port == intel_dp)
> + intel_dp_queue_modeset_retry_work(connector);
> + }
> +}
> +
> int
> intel_dp_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config, @@ -6441,6
> +6475,14 @@ static void intel_dp_modeset_retry_work_fn(struct work_struct
> *work)
> mutex_unlock(&connector->dev->mode_config.mutex);
> /* Send Hotplug uevent so userspace can reprobe */
> drm_kms_helper_connector_hotplug_event(connector);
> +
> + drm_connector_put(connector);
> +}
> +
> +void intel_dp_init_modeset_retry_work(struct intel_connector
> +*connector) {
> + INIT_WORK(&connector->modeset_retry_work,
> + intel_dp_modeset_retry_work_fn);
> }
>
> bool
> @@ -6457,8 +6499,7 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
> int type;
>
> /* Initialize the work for modeset in case of link train failure */
> - INIT_WORK(&intel_connector->modeset_retry_work,
> - intel_dp_modeset_retry_work_fn);
> + intel_dp_init_modes
RE: [PATCH v2 03/21] drm/i915: Fix display bpp limit computation during system resume
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 03/21] drm/i915: Fix display bpp limit computation during
> system resume
>
> The system resume display mode restoration should happen with an output
> configuration matching that of the suspend time saved mode. Since the restored
> mode configuration is subject to the bpp fallback logic, starting out with an
> unlimited bpp and reducing the bpp as required by any (MST) link BW limit, the
> resulting bpp will match the one during suspend only if the BW limit checks
> during
> suspend and resume are applied in an identical way. The latter is not
> guaranteed
> at the moment, since the pre-suspend MST topology may not be in place during
> resume (for instance if the MST sink was disconnected while being suspended),
> which makes the MST link BW check accept the unlimited bpp mode
> configuration unconditionally without ensuring that the required BW fits into
> the
> available MST link BW.
>
> To fix the above, initialize the bpp fallback logic with the max link bpp /
> force-FEC
> limits left behind by the suspend time mode save.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 +--
> drivers/gpu/drm/i915/display/intel_link_bw.c | 22
> drivers/gpu/drm/i915/display/intel_link_bw.h | 2 +-
> 3 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 00ac65a140298..485c38d71f106 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6252,12 +6252,11 @@ static int intel_atomic_check_config(struct
> intel_atomic_state *state,
>
> static int intel_atomic_check_config_and_link(struct intel_atomic_state
> *state) {
> - struct drm_i915_private *i915 = to_i915(state->base.dev);
> struct intel_link_bw_limits new_limits;
> struct intel_link_bw_limits old_limits;
> int ret;
>
> - intel_link_bw_init_limits(i915, &new_limits);
> + intel_link_bw_init_limits(state, &new_limits);
> old_limits = new_limits;
>
> while (true) {
> diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c
> b/drivers/gpu/drm/i915/display/intel_link_bw.c
> index 9c6d35a405a18..27ea858897c9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_link_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
> @@ -6,6 +6,7 @@
> #include "i915_drv.h"
>
> #include "intel_atomic.h"
> +#include "intel_crtc.h"
> #include "intel_display_types.h"
> #include "intel_dp_mst.h"
> #include "intel_fdi.h"
> @@ -13,19 +14,32 @@
>
> /**
> * intel_link_bw_init_limits - initialize BW limits
> - * @i915: device instance
> + * @state: Atomic state
> * @limits: link BW limits
> *
> * Initialize @limits.
> */
> -void intel_link_bw_init_limits(struct drm_i915_private *i915, struct
> intel_link_bw_limits *limits)
> +void intel_link_bw_init_limits(struct intel_atomic_state *state,
> +struct intel_link_bw_limits *limits)
> {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> enum pipe pipe;
>
> limits->force_fec_pipes = 0;
> limits->bpp_limit_reached_pipes = 0;
> - for_each_pipe(i915, pipe)
> - limits->max_bpp_x16[pipe] = INT_MAX;
> + for_each_pipe(i915, pipe) {
> + const struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state,
> +
> intel_crtc_for_pipe(i915, pipe));
> +
> + if (state->base.duplicated && crtc_state) {
> + limits->max_bpp_x16[pipe] = crtc_state-
> >max_link_bpp_x16;
> + if (crtc_state->fec_enable)
> + limits->force_fec_pipes |= BIT(pipe);
> + } else {
> + limits->max_bpp_x16[pipe] = INT_MAX;
> + }
> + }
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.h
> b/drivers/gpu/drm/i915/display/intel_link_bw.h
> index 2cf57307cc249..6b0ccfff59dab 100644
> --- a/drivers/gpu/drm/i915/display/intel_link_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_link_bw.h
> @@ -22,7 +22,7 @@ struct intel_link_bw_limits {
> int max_bpp_x16[I915_MAX_PIPES];
> };
>
> -void intel_link_bw_init_limits(struct drm_i915_private *i915,
> +void intel_link_bw_init_limits(struct intel_atomic_state *state,
> struct intel_link_bw_limits *limits); int
> intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
>struct intel_link_bw_limits *limits,
> --
> 2.39.2
RE: [PATCH v2 02/21] drm/dp: Add support for DP tunneling
> -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:48 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 02/21] drm/dp: Add support for DP tunneling > > Add support for Display Port tunneling. For now this includes the > support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay > support for later. > > BWA allows using displays that share the same (Thunderbolt) link with > their maximum resolution. Atm, this may not be possible due to the > coarse granularity of partitioning the link BW among the displays on the > link: the BW allocation policy is in a SW/FW/HW component on the link > (on Thunderbolt it's the SW or FW Connection Manager), independent of > the driver. This policy will set the DPRX maximum rate and lane count > DPCD registers the GFX driver will see (0x0, 0x1, 0x02200, > 0x02201) based on the available link BW. > > The granularity of the current BW allocation policy is coarse, based on > the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent > using higher resolutions all together: the display connected first will > get a share of the link BW which corresponds to its full DPRX capability > (regardless of the actual mode it uses). A subsequent display connected > will only get the remaining BW, which could be well below its full > capability. > > BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps > range) and first-come/first-served issues by letting the driver request > the BW for each display on a link which reflects the actual modes the > displays use. > > This patch adds the DRM core helper functions, while a follow-up change > in the patchset takes them into use in the i915 driver. > > v2: > - Fix prepare_to_wait vs. wake-up cond check order in > allocate_tunnel_bw(). (Ville) > - Move tunnel==NULL checks from callers in drivers to here. (Ville) > - Avoid var inits in declaration blocks that can fail or have > side-effects. (Ville) > - Use u8 for driver and group IDs. (Ville) > - Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville) > - Reuse str_yes_no() instead of a local yes_no_chr(). (Ville) > - s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport > the function. (Ville) > - s/clear_tunnel_group_state()/free_group_state() and move kfree() to > this function. (Ville) > - Add separate group_free_bw() helper and describe what the tunnel > estimated BW includes. (Ville) > - Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville) > - Add code comment explaining the purpose of DPCD reg read helpers. > (Ville) > - Add code comment describing the tunnel group name prefix format. > (Ville) > - Report the allocated BW as undetermined until the first allocation > request. > - Skip allocation requests matching the previous request. > - Clear any stale BW request status flags before a new request. > - Add missing error return check of drm_dp_tunnel_atomic_get_group_state() > in drm_dp_tunnel_atomic_set_stream_bw(). > - Add drm_dp_tunnel_get_allocated_bw(). > - > s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_ > bw > - Fix return value description in function doc of drm_dp_tunnel_detect(). > - Add function documentation to all exported functions. > > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/display/Kconfig | 21 + > drivers/gpu/drm/display/Makefile|2 + > drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 +++ > include/drm/display/drm_dp.h| 60 + > include/drm/display/drm_dp_tunnel.h | 248 +++ > 5 files changed, 2260 insertions(+) > create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c > create mode 100644 include/drm/display/drm_dp_tunnel.h > > diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig > index 09712b88a5b83..c0f56888c3280 100644 > --- a/drivers/gpu/drm/display/Kconfig > +++ b/drivers/gpu/drm/display/Kconfig > @@ -17,6 +17,27 @@ config DRM_DISPLAY_DP_HELPER > help > DRM display helpers for DisplayPort. > > +config DRM_DISPLAY_DP_TUNNEL > + bool > + select DRM_DISPLAY_DP_HELPER > + help > + Enable support for DisplayPort tunnels. This allows drivers to use > + DP tunnel features like the Bandwidth Allocation mode to maximize the > + BW utilization for display streams on Thunderbolt links. > + > +config DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE > + bool "Enable debugging the DP tunnel state" > + depends on REF_TRACKER > + depends on DRM_DISPLAY_DP_TUNNEL > + depends on DEBUG_KERNEL > + depends on EXPERT > + help > + Enables debugging the DP tunnel manager's state, including the > + consistency of all managed tunnels' reference counting and the state > of > + streams contained in tunnels. > + > + If in doubt, say "N". >
RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> -Original Message- > From: Harry Wentland > Sent: Saturday, February 17, 2024 3:17 AM > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: ville.syrj...@linux.intel.com; pekka.paala...@collabora.com; > cont...@emersion.fr; m...@igalia.com; jad...@redhat.com; > sebastian.w...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com; > jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org; > xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch; > quic_nas...@quicinc.com; quic_cbr...@quicinc.com; > quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st; > liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run; Borah, > Chaitanya Kumar > Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms > > > > On 2024-02-13 01:48, Uma Shankar wrote: > > This series intends to add support for Plane Color Management for > > Intel platforms. This is based on the design which has been agreed > > upon by the community. Series implementing the design for generic DRM > > core has been sent out by Harry Wentland and is under review > > below: > > https://patchwork.freedesktop.org/series/123446/ > > > > The base work of above series is squashed under 1 patch and support > > for Intel platform is added on top of it. > > Any reviews on the original core design is expected to be done in > > Harry's series to avoid any forking of the discussion. > > > > We have added some changes/fixes to the Harry's core DRM changes, > > being put up as separate patches on top of squashed patch. These are > > expected to get included in the main series from Harry once agreed upon. > > > > Changes added on core design: > > 1. Below patches implement some fixes on original series > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > > > 2. Implemented a HW capability property to expose segmented luts. > > drm: Add Color lut range attributes > > drm: Add Color ops capability property > > drm: Define helper to create color ops capability property > > drm: Define helper for adding capability property for 1D LUT > > > > This helps in generically defining the hardware lut capabilities, lut > > distribution, precision, segmented or PWL LUTS. > > > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > > drm: Add Enhanced LUT precision structure > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > > > On top of this base work for DRM core plane color pipeline design, > > implementation is done for Intel hardware platforms. Below patches > > include the same: > > > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > > drm/i915/color: Add and attach COLORPIPELINE plane property > > drm/i915/color: Add framework to set colorop > > drm/i915/color: Add callbacks to set plane CTM > > drm/i915/color: Add framework to program PRE/POST CSC LUT > > FIXME: force disable legacy plane color properties for TGL and beyond > > drm/i915/color: Enable Plane Color Pipelines > > drm/i915: Define segmented Lut and add capabilities to colorop > > drm/i915/color: Add plane CTM callback for TGL and beyond > > drm/i915: Add register definitions for Plane Degamma > > drm/i915: Add register definitions for Plane Post CSC > > drm/i915/color: Program Pre-CSC registers > > drm/i915/xelpd: Program Plane Post CSC Registers > > > > Bhanu from Intel will be sending out the igt changes to help test the > > color pipeline implementation based on the current igt changes sent > > out by Harry. > > https://patchwork.freedesktop.org/series/123448/ > > > > Planned Next Steps: > > 1. Work with Harry and community and get DRM core changes for color > > pipeline merged. > > We'll need a userspace to implement support before merging, but we're working > to enabling all color properties gamescope currently uses for the SteamDeck > color > management to the Color Pipeline API, which should help us get there. It's > still a > journey but I think the path is clear. Yeah, thanks Harry for driving it. > I'll send a new version of my patch series next week, including some AMD > implementation (not the entire AMD pipeline yet). Oh ok, Nice. One more i
RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, February 14, 2024 2:34 PM
> To: Shankar, Uma
> Cc: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
>
> On Wed, 14 Feb 2024 07:28:37 +
> "Shankar, Uma" wrote:
>
> > > -Original Message-
> > > From: dri-devel On Behalf
> > > Of Pekka Paalanen
> > > Sent: Tuesday, February 13, 2024 3:07 PM
> > > To: Shankar, Uma
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> > > cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> > > jad...@redhat.com; sebastian.w...@redhat.com;
> > > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> > > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> > > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> > > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com;
> > > arthurgri...@riseup.net; mar...@marcan.st; liviu.du...@arm.com;
> > > sashamcint...@google.com; s...@poorly.run
> > > Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add
> > > capabilities to colorop
> > >
> > > On Tue, 13 Feb 2024 12:18:24 +0530
> > > Uma Shankar wrote:
> > >
> > > > This defines the lut segments and create the color pipeline
> > > >
> > > > Signed-off-by: Uma Shankar
> > > > Signed-off-by: Chaitanya Kumar Borah
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_color.c | 109
> > > > +
> > > > 1 file changed, 109 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > > index e223edbe4c13..223cd1ff7291 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> > > ilk_color_funcs = {
> > > > .get_config = ilk_get_config,
> > > > };
> > > >
> > > > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > > > + /* segment 1 */
> > > > + {
> > > > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > > + DRM_MODE_LUT_INTERPOLATE |
> > > > + DRM_MODE_LUT_NON_DECREASING),
> > >
> > > Hi Uma,
> > >
> > > is it a good idea to have these flags per-segment?
> > >
> > > I would find it very strange, unusable really, if REFLECT_NEGATIVE
> > > applied on some but not all segments, for example. Is such
> > > flexibility really necessary in the hardware description?
> >
> > Hi Pekka,
> > Idea to have these flags is to just have some option in case there are
> > some differences across segments. Most cases this should not be the
> > case, just helps to future proof the implementation.
> >
> > Based on how the community feels on the usability of it, we can take a
> > call on the flags and the expected interpretation for the same. We are open
> > for
> suggestions on the same.
> >
> > >
> > > > + .count = 128,
> > > > + .input_bpc = 24, .output_bpc = 16,
> > >
> > > The same question about input_bpc and output_bpc.
> >
> > Same for these as well, userspace can just ignore these if no usage.
> > However, for some clients it may help in Lut computations.
> > The original idea for the structure came from Ville (missed to mention
> > that in cover letter, will get that updated in next version).
> >
> > @ville.syrj...@linux.intel.com Please share your inputs on the usability of
> > these
> attributes.
>
> Userspace will al
RE: [PATCH 09/28] drm: Add Color ops capability property
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:35 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 09/28] drm: Add Color ops capability property
>
> On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> > Add capability property which a colorop can expose it's hardware's
> > abilities. It's a blob property that can be filled with respective
> > data structures depending on the colorop. The user space is expected
> > to read this property and program the colorop accordingly.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > include/drm/drm_colorop.h | 13 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9f6a3a1c8020..95f1df73209c 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> > *val = state->curve_1d_type;
> > } else if (property == colorop->data_property) {
> > *val = (state->data) ? state->data->base.id : 0;
> > + } else if (property == colorop->hw_caps_property) {
> > + *val = state->hw_caps ?
> > + state->hw_caps->base.id : 0;
> > } else {
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index 5b8c36538491..f417e109c40a 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -59,6 +59,12 @@ struct drm_colorop_state {
> > */
> > enum drm_colorop_curve_1d_type curve_1d_type;
> >
> > + /**
> > +* @hw_caps:
> > +*
> > +*/
> > + struct drm_property_blob *hw_caps;
> > +
>
> Is this supposed to be generic for any colorop or specifically for
> DRM_COLOROP_1D_LUT?
We have intentionally kept it generic so that it can be used for any kind
of hardware color block (1D LUT, 3D LUT etc.). Differentiation can be done
by using the Color op type.
Regards,
Uma Shankar
> > /**
> > * @data:
> > *
> > @@ -167,6 +173,13 @@ struct drm_colorop {
> > */
> > struct drm_property *bypass_property;
> >
> > + /**
> > +* @hwlut_caps_property:
> > +*
> > +* Property to expose hardware lut capbilities.
> > +*/
> > + struct drm_property *hw_caps_property;
> > +
> > /**
> > * @curve_1d_type:
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 08/28] drm: Add Color lut range attributes
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:34 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 08/28] drm: Add Color lut range attributes
>
> On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> > This defines a new structure to define color lut ranges, along with
> > related macro definitions and enums. This will help describe segmented
> > lut ranges/PWL LUTs in the hardware.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > include/uapi/drm/drm_mode.h | 58
> > +
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index af67f32e0087..376498715d0e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> > DRM_MODE_PAGE_FLIP_ASYNC | \
> > DRM_MODE_PAGE_FLIP_TARGET)
> >
>
> All of this uses DRM_MODE_LUT namespace but it seems specifically for the drm
> colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the naming.
Yeah Sebastian, we will update this and get it aligned.
Thanks for pointing out.
Regards,
Uma Shankar
> > +/**
> > + * DRM_MODE_LUT_INTERPOLATE
> > + *
> > + * linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(0)
> > +
> > +/**
> > + * DRM_MODE_LUT_REUSE_LAST
> > + *
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> > +
> > +/**
> > + * DRM_MODE_LUT_NON_DECREASING
> > + *
> > + * the curve must be non-decreasing
> > + */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> > +
> > +/**
> > + * DRM_MODE_LUT_REFLECT_NEGATIVE
> > + *
> > + * the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> > +
> > +/**
> > + * DRM_MODE_LUT_SINGLE_CHANNEL
> > + *
> > + * the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> > +
> > +/**
> > + * struct drm_color_lut_range
> > + *
> > + * structure to advertise capability of a color hardware
> > + * block that accepts LUT values. It can represent LUTs with
> > + * varied number of entries and distributions
> > + * (Multi segmented, Logarithmic etc).
> > + */
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > /*
> > * Request a page flip on the specified crtc.
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, February 13, 2024 4:32 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com; > m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com; > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es; > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com; > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com; > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net; > mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com; > s...@poorly.run; Borah, Chaitanya Kumar > Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms > > On Tue, 13 Feb 2024 12:18:07 +0530 > Uma Shankar wrote: > > > This series intends to add support for Plane Color Management for > > Intel platforms. This is based on the design which has been agreed > > upon by the community. Series implementing the design for generic DRM > > core has been sent out by Harry Wentland and is under review > > below: > > https://patchwork.freedesktop.org/series/123446/ > > > > The base work of above series is squashed under 1 patch and support > > for Intel platform is added on top of it. > > Any reviews on the original core design is expected to be done in > > Harry's series to avoid any forking of the discussion. > > > > We have added some changes/fixes to the Harry's core DRM changes, > > being put up as separate patches on top of squashed patch. These are > > expected to get included in the main series from Harry once agreed upon. > > > > Changes added on core design: > > 1. Below patches implement some fixes on original series > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > > > 2. Implemented a HW capability property to expose segmented luts. > > drm: Add Color lut range attributes > > drm: Add Color ops capability property > > drm: Define helper to create color ops capability property > > drm: Define helper for adding capability property for 1D LUT > > > > This helps in generically defining the hardware lut capabilities, lut > > distribution, precision, segmented or PWL LUTS. > > > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > > drm: Add Enhanced LUT precision structure > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > > > On top of this base work for DRM core plane color pipeline design, > > implementation is done for Intel hardware platforms. Below patches > > include the same: > > > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > > drm/i915/color: Add and attach COLORPIPELINE plane property > > drm/i915/color: Add framework to set colorop > > drm/i915/color: Add callbacks to set plane CTM > > drm/i915/color: Add framework to program PRE/POST CSC LUT > > FIXME: force disable legacy plane color properties for TGL and beyond > > drm/i915/color: Enable Plane Color Pipelines > > drm/i915: Define segmented Lut and add capabilities to colorop > > drm/i915/color: Add plane CTM callback for TGL and beyond > > drm/i915: Add register definitions for Plane Degamma > > drm/i915: Add register definitions for Plane Post CSC > > drm/i915/color: Program Pre-CSC registers > > drm/i915/xelpd: Program Plane Post CSC Registers > > > > Bhanu from Intel will be sending out the igt changes to help test the > > color pipeline implementation based on the current igt changes sent > > out by Harry. > > https://patchwork.freedesktop.org/series/123448/ > > > > Planned Next Steps: > > 1. Work with Harry and community and get DRM core changes for color > > pipeline merged. > > 2. Implement pipe color management (post blending) based on the > > current color pipeline design. > > 3. Work with compositor maintainers to get color processing > > implemented using display hardware, thereby avoid any GL or GPU shaders. > > > > Thanks to all the community maintainers and contributors who have > > helped to get this support in upstream Linux. Looking forward to > > collaborate, work together and get this merged. > > > > ... > > > Chaitanya
RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Tuesday, February 13, 2024 3:07 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
>
> On Tue, 13 Feb 2024 12:18:24 +0530
> Uma Shankar wrote:
>
> > This defines the lut segments and create the color pipeline
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 109
> > +
> > 1 file changed, 109 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index e223edbe4c13..223cd1ff7291 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> ilk_color_funcs = {
> > .get_config = ilk_get_config,
> > };
> >
> > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
>
> Hi Uma,
>
> is it a good idea to have these flags per-segment?
>
> I would find it very strange, unusable really, if REFLECT_NEGATIVE applied on
> some but not all segments, for example. Is such flexibility really necessary
> in the
> hardware description?
Hi Pekka,
Idea to have these flags is to just have some option in case there are some
differences
across segments. Most cases this should not be the case, just helps to future
proof
the implementation.
Based on how the community feels on the usability of it, we can take a call on
the flags
and the expected interpretation for the same. We are open for suggestions on
the same.
>
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
>
> The same question about input_bpc and output_bpc.
Same for these as well, userspace can just ignore these if no usage. However,
for some clients
it may help in Lut computations.
The original idea for the structure came from Ville (missed to mention that in
cover letter, will get that
updated in next version).
@ville.syrj...@linux.intel.com Please share your inputs on the usability of
these attributes.
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
>
> What if there is a gap or overlap between the previous segment .end and the
> next
> segment .start? Is it forbidden? Will the kernel common code verify that
> drivers
> don't make mistakes? Or IGT?
This is just to help give some reference to userspace. As of now, driver
trusts the values
coming from userspace if it sends wrong values its on him and driver can't help
much.
However, we surely can have some sanity check like non decreasing luts etc. to
driver.
Ideally LUT values should not overlap, but we can indicate this explicitly with
flag to
hint the userspace (for overlap or otherwise) and also get a check in driver
for the same.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > +
RE: [PATCH 05/28] drm: Add support for 3x3 CTM
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, February 13, 2024 2:45 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run; Borah, Chaitanya Kumar
> Subject: Re: [PATCH 05/28] drm: Add support for 3x3 CTM
>
> On Tue, 13 Feb 2024 12:18:12 +0530
> Uma Shankar wrote:
>
> > From: Chaitanya Kumar Borah
> >
> > Add support for 3x3 Color Transformation Matrices in Color Pipeline.
> >
> > Signed-off-by: Chaitanya Kumar Borah
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_colorop.c | 2 +-
> > include/uapi/drm/drm_mode.h | 1 +
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index e7bf1fb054af..c54b0d6c133e 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> > case DRM_COLOROP_CTM_3X4:
> > size = sizeof(struct drm_color_ctm_3x4);
> > break;
> > + case DRM_COLOROP_CTM_3X3:
> > + size = sizeof(struct drm_color_ctm);
> > + break;
> > default:
> > /* should never get here */
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c index 462ffec42cdf..6bae6dc8e54b
> > 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> >0);
> >
> > /* data */
> > - if (type == DRM_COLOROP_CTM_3X4) {
> > + if (type == DRM_COLOROP_CTM_3X4 || type ==
> DRM_COLOROP_CTM_3X3) {
> > prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLOB,
> >"DATA", 0);
> > if (!prop)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index f16318f1785f..68696253867e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -868,6 +868,7 @@ struct drm_color_lut {
> >
> > enum drm_colorop_type {
> > DRM_COLOROP_1D_CURVE,
> > + DRM_COLOROP_CTM_3X3,
> > DRM_COLOROP_CTM_3X4,
> > };
> >
>
> Hi,
>
> where are the docs for DRM_COLOROP_CTM_3X3?
Hi Pekka,
Sorry, we missed this in the current version. Will update the same in next
revision.
Regards,
Uma Shankar
>
> Thanks,
> pq
RE: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
> -Original Message-
> From: Rodrigo Vivi
> Sent: Tuesday, February 13, 2024 8:26 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Lisovskiy, Stanislav
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com
> Subject: Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
>
> On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> > From: Stanislav Lisovskiy
> >
> > For validation purposes, it might be useful to be able to force
> > Bigjoiner mode, even if current dotclock/resolution do not require
> > that.
> > Lets add such to option to debugfs.
> >
> > v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> > debugfs entry is created so lets just check manually
> > the DISPLAY_VER.
> >
> > v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> > - Remove redundant modeset lock(Jani Nikula)
> > - Use kstrtobool_from_user for boolean value(Jani Nikula)
> >
> > v4: - Apply the changes to proper function(Jani Nikula)
> >
> > v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> > (Ville Syrjälä)
> > - Added eDP connector check to intel_connector_debugfs_add
> > (Ville Syrjälä)
> > - Removed debug message in order to prevent dmesg flooding
> > (Ville Syrjälä)
> >
> > v6: - Assume now always that m->private is intel_connector
> > - Fixed other similar conflicts
> >
> > v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> > - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> > manually.(Ville Syrjälä)
> >
> > v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
> > (Jani Nikula)
> >
> > Signed-off-by: Stanislav Lisovskiy
>
> please remind to sign-off when sending someone else's patch.
Oh yeah, sorry missed it. Was filling in for Stan while he was OOO.
@Lisovskiy, Stanislav Please address rest of the comments raised by Rodrigo.
Regards,
Uma Shankar
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 47 +++
> > .../drm/i915/display/intel_display_types.h| 2 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> > 3 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 6f2d13c8ccf7..a962b48bcf13 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1391,6 +1391,20 @@ out: drm_modeset_unlock(&i915-
> >drm.mode_config.connection_mutex);
> > return ret;
> > }
> >
> > +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> > +{
> > + struct intel_connector *connector = m->private;
> > + struct drm_crtc *crtc;
> > +
> > + crtc = connector->base.state->crtc;
> > + if (connector->base.status != connector_status_connected || !crtc)
> > + return -ENODEV;
> > +
> > + seq_printf(m, "Bigjoiner enable: %d\n",
> > +connector->force_bigjoiner_enable);
>
> probably better with a yes_or_no string?
>
> > +
> > + return 0;
> > +}
> > +
> > static ssize_t i915_dsc_output_format_write(struct file *file,
> > const char __user *ubuf,
> > size_t len, loff_t *offp)
> > @@ -1412,6 +1426,30 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
> > return len;
> > }
> >
> > +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + struct seq_file *m = file->private_data;
> > + struct intel_connector *connector = m->private;
> > + struct drm_crtc *crtc;
> > + bool bigjoiner_en = 0;
> > + int ret;
> > +
> > + crtc = connector->base.state->crtc;
> > + if (connector->base.status != connector_status_connected || !crtc)
> > + return -ENODEV;
> > +
> > + ret = kstrtobool_from_user(ubuf, len, &bigjoiner_en);
> > + if (ret < 0)
> > + return ret;
> > +
> > + connector->force_bigjoiner_enable = bigjoiner_en;
> > + *offp += len;
> > +
> > + return len;
> > +}
> > +
&g
RE: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
> -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Tuesday, January 23, 2024 3:59 PM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Subject: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI > DP encoders > > A follow-up change will need to resume DP tunnels during system resume, so > call > intel_dp_sync_state() always for DDI encoders, so this function can resume the > tunnels for all DP connectors. Looks good to me. Reviewed-by: Uma Shankar > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index aa6e7da08fbce..1e26e62b82d48 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -4131,7 +4131,7 @@ static void intel_ddi_sync_state(struct intel_encoder > *encoder, > intel_tc_port_sanitize_mode(enc_to_dig_port(encoder), > crtc_state); > > - if (crtc_state && intel_crtc_has_dp_encoder(crtc_state)) > + if (intel_encoder_is_dp(encoder)) > intel_dp_sync_state(encoder, crtc_state); } > > -- > 2.39.2
RE: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder
> enable/disable hooks
>
> Allocate and free the DP tunnel BW required by a stream while
> enabling/disabling
> the stream during a modeset.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c| 28
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index dfe0b07a122d1..1e498e1510adf 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -19,6 +19,7 @@
> #include "intel_dp.h"
> #include "intel_dp_aux.h"
> #include "intel_dp_link_training.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_fifo_underrun.h"
> #include "intel_hdmi.h"
> @@ -729,6 +730,24 @@ static void vlv_enable_dp(struct intel_atomic_state
> *state,
> encoder->audio_enable(encoder, pipe_config, conn_state); }
>
> +static void g4x_dp_pre_pll_enable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state *new_crtc_state,
> + const struct drm_connector_state
> *new_conn_state) {
> + intel_dp_tunnel_atomic_alloc_bw(state, encoder,
> + new_crtc_state, new_conn_state);
> +}
> +
> +static void g4x_dp_post_pll_disable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *old_crtc_state,
> + const struct drm_connector_state
> *old_conn_state) {
> + intel_dp_tunnel_atomic_free_bw(state, encoder,
> +old_crtc_state, old_conn_state); }
> +
> static void g4x_pre_enable_dp(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config, @@ -
> 762,6 +781,8 @@ static void vlv_dp_pre_pll_enable(struct intel_atomic_state
> *state,
> intel_dp_prepare(encoder, pipe_config);
>
> vlv_phy_pre_pll_enable(encoder, pipe_config);
> +
> + g4x_dp_pre_pll_enable(state, encoder, pipe_config, conn_state);
> }
>
> static void chv_pre_enable_dp(struct intel_atomic_state *state, @@ -785,6
> +806,8 @@ static void chv_dp_pre_pll_enable(struct intel_atomic_state *state,
> intel_dp_prepare(encoder, pipe_config);
>
> chv_phy_pre_pll_enable(encoder, pipe_config);
> +
> + g4x_dp_pre_pll_enable(state, encoder, pipe_config, conn_state);
> }
>
> static void chv_dp_post_pll_disable(struct intel_atomic_state *state, @@
> -792,6
> +815,8 @@ static void chv_dp_post_pll_disable(struct intel_atomic_state
> *state,
> const struct intel_crtc_state
> *old_crtc_state,
> const struct drm_connector_state
> *old_conn_state) {
> + g4x_dp_post_pll_disable(state, encoder, old_crtc_state,
> +old_conn_state);
> +
> chv_phy_post_pll_disable(encoder, old_crtc_state); }
>
> @@ -1349,11 +1374,14 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
> intel_encoder->enable = vlv_enable_dp;
> intel_encoder->disable = vlv_disable_dp;
> intel_encoder->post_disable = vlv_post_disable_dp;
> + intel_encoder->post_pll_disable = g4x_dp_post_pll_disable;
> } else {
> + intel_encoder->pre_pll_enable = g4x_dp_pre_pll_enable;
> intel_encoder->pre_enable = g4x_pre_enable_dp;
> intel_encoder->enable = g4x_enable_dp;
> intel_encoder->disable = g4x_disable_dp;
> intel_encoder->post_disable = g4x_post_disable_dp;
> + intel_encoder->post_pll_disable = g4x_dp_post_pll_disable;
> }
> intel_encoder->audio_enable = g4x_dp_audio_enable;
> intel_encoder->audio_disable = g4x_dp_audio_disable; diff --git
> a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 922194b957be2..aa6e7da08fbce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -54,6 +54,7 @@
> #include "intel_dp_aux.h"
> #include "intel_dp_link_training.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_dsi.h"
> #include "intel_fdi.h"
> @@ -3141,6 +3142,9 @@ static void intel_ddi_post_pll_disable(struct
> intel_atomic_state *state,
>
> main_link_aux_power_domain_put(
RE: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state computation
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state
> computation
>
> Compute the BW required through a DP tunnel on links with such tunnels
> detected and add the corresponding atomic state during a modeset.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 +
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 78dfe8be6031d..6968fdb7ffcdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2880,6 +2880,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
> struct drm_connector_state *conn_state) {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> +to_intel_atomic_state(conn_state->state);
> struct drm_display_mode *adjusted_mode = &pipe_config-
> >hw.adjusted_mode;
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> const struct drm_display_mode *fixed_mode; @@ -2980,6 +2981,9 @@
> intel_dp_compute_config(struct intel_encoder *encoder,
> intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
> intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
> conn_state);
>
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> + pipe_config);
> +
> return 0;
> }
>
> @@ -6087,6 +6091,15 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> return ret;
> }
>
> + if (!intel_connector_needs_modeset(state, conn))
> + return 0;
> +
> + ret = intel_dp_tunnel_atomic_check_state(state,
> + intel_dp,
> + intel_conn);
> + if (ret)
> + return ret;
> +
> /*
>* We don't enable port sync on BDW due to missing w/as and
>* due to not having adjusted the modeset sequence appropriately.
> @@ -6094,9 +6107,6 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> if (DISPLAY_VER(dev_priv) < 9)
> return 0;
>
> - if (!intel_connector_needs_modeset(state, conn))
> - return 0;
> -
> if (conn->has_tile) {
> ret = intel_modeset_tile_group(state, conn->tile_group->id);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 520393dc8b453..cbfab3173b9ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -42,6 +42,7 @@
> #include "intel_dp.h"
> #include "intel_dp_hdcp.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_hdcp.h"
> #include "intel_hotplug.h"
> @@ -523,6 +524,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> +to_intel_atomic_state(conn_state->state);
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_dp *intel_dp = &intel_mst->primary->dp;
> const struct intel_connector *connector = @@ -619,6 +621,9 @@ static
> int intel_dp_mst_compute_config(struct intel_encoder *encoder,
>
> intel_psr_compute_config(intel_dp, pipe_config, conn_state);
>
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> + pipe_config);
> +
> return 0;
> }
>
> @@ -876,6 +881,14 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> if (ret)
> return ret;
>
> + if (intel_connector_needs_modeset(state, connector)) {
> + ret = intel_dp_tunnel_atomic_check_state(state,
> + intel_connector-
> >mst_port,
> + intel_connector);
> + if (ret)
> + return ret;
> + }
> +
> return drm_dp_atomic_release_time_slots(&state->base,
> &intel_connector->mst_port-
> >mst_mgr,
> intel_connector->port);
> --
> 2.39.2
RE: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in
> intel_dp_max_link_data_rate()
>
> Take any link BW limitation into account in intel_dp_max_link_data_rate().
> Such a
> limitation can be due to multiple displays on (Thunderbolt) links with DP
> tunnels
> sharing the link BW.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 323475569ee7f..78dfe8be6031d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -63,6 +63,7 @@
> #include "intel_dp_hdcp.h"
> #include "intel_dp_link_training.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_dpll.h"
> #include "intel_fifo_underrun.h"
> @@ -152,6 +153,22 @@ int intel_dp_link_symbol_clock(int rate)
> return DIV_ROUND_CLOSEST(rate * 10, intel_dp_link_symbol_size(rate));
> }
>
> +static int max_dprx_rate(struct intel_dp *intel_dp) {
> + if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + return drm_dp_tunnel_max_dprx_rate(intel_dp->tunnel);
> +
> + return drm_dp_bw_code_to_link_rate(intel_dp-
> >dpcd[DP_MAX_LINK_RATE]);
> +}
> +
> +static int max_dprx_lane_count(struct intel_dp *intel_dp) {
> + if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + return drm_dp_tunnel_max_dprx_lane_count(intel_dp->tunnel);
> +
> + return drm_dp_max_lane_count(intel_dp->dpcd);
> +}
> +
> static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp) {
> intel_dp->sink_rates[0] = 162000;
> @@ -180,7 +197,7 @@ static void intel_dp_set_dpcd_sink_rates(struct intel_dp
> *intel_dp)
> /*
>* Sink rates for 8b/10b.
>*/
> - max_rate = drm_dp_bw_code_to_link_rate(intel_dp-
> >dpcd[DP_MAX_LINK_RATE]);
> + max_rate = max_dprx_rate(intel_dp);
> max_lttpr_rate = drm_dp_lttpr_max_link_rate(intel_dp-
> >lttpr_common_caps);
> if (max_lttpr_rate)
> max_rate = min(max_rate, max_lttpr_rate); @@ -259,7 +276,7
> @@ static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = &intel_dig_port->base;
>
> - intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp-
> >dpcd);
> + intel_dp->max_sink_lane_count = max_dprx_lane_count(intel_dp);
>
> switch (intel_dp->max_sink_lane_count) {
> case 1:
> @@ -389,14 +406,21 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
> * @max_dprx_rate: Maximum data rate of the DPRX
> * @max_dprx_lanes: Maximum lane count of the DPRX
> *
> - * Calculate the maximum data rate for the provided link parameters.
> + * Calculate the maximum data rate for the provided link parameters
> + taking into
> + * account any BW limitations by a DP tunnel attached to @intel_dp.
> *
> * Returns the maximum data rate in kBps units.
> */
> int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> int max_dprx_rate, int max_dprx_lanes) {
> - return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
> + int max_rate = drm_dp_max_dprx_data_rate(max_dprx_rate,
> +max_dprx_lanes);
> +
> + if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + max_rate = min(max_rate,
> +drm_dp_tunnel_available_bw(intel_dp->tunnel));
> +
> + return max_rate;
> }
>
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
> --
> 2.39.2
RE: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()
>
> Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX BW used
> by a follow-up patch enabling the DP tunnel BW allocation mode.
> The link BW can be below the DPRX BW due to a BW limitation on a link shared
> by multiple sinks.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
> 3 files changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 23434d0aba188..9cd675c6d0ee8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -383,6 +383,22 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
> 100 * 16 * 8);
> }
>
> +/**
> + * intel_dp_max_link_data_rate: Calculate the maximum rate for the
> +given link params
> + * @intel_dp: Intel DP object
> + * @max_dprx_rate: Maximum data rate of the DPRX
> + * @max_dprx_lanes: Maximum lane count of the DPRX
> + *
> + * Calculate the maximum data rate for the provided link parameters.
> + *
> + * Returns the maximum data rate in kBps units.
> + */
> +int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> + int max_dprx_rate, int max_dprx_lanes) {
> + return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes); }
> +
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp) {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); @@
> -612,7 +628,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
> intel_dp *intel_dp,
> int mode_rate, max_rate;
>
> mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> - max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
> + max_rate = intel_dp_max_link_data_rate(intel_dp, link_rate,
> +lane_count);
> if (mode_rate > max_rate)
> return false;
>
> @@ -1214,7 +1230,8 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> max_lanes = intel_dp_max_lane_count(intel_dp);
>
> - max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
> + max_rate = intel_dp_max_link_data_rate(intel_dp, max_link_clock,
> +max_lanes);
> +
> mode_rate = intel_dp_link_required(target_clock,
>
> intel_dp_mode_min_output_bpp(connector, mode));
>
> @@ -1564,8 +1581,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> for (lane_count = limits->min_lane_count;
>lane_count <= limits->max_lane_count;
>lane_count <<= 1) {
> - link_avail =
> drm_dp_max_dprx_data_rate(link_rate,
> -
> lane_count);
> + link_avail =
> intel_dp_max_link_data_rate(intel_dp,
> +
> link_rate,
> +
> lane_count);
> +
>
> if (mode_rate <= link_avail) {
> pipe_config->lane_count = lane_count;
> @@ -2422,8 +2441,9 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> pipe_config->pipe_bpp,
> BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
> intel_dp_config_required_rate(pipe_config),
> - drm_dp_max_dprx_data_rate(pipe_config->port_clock,
> - pipe_config->lane_count));
> + intel_dp_max_link_data_rate(intel_dp,
> + pipe_config->port_clock,
> + pipe_config->lane_count));
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 49553e43add22..8b0dfbf06afff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -117,6 +117,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp
> *intel_dp); int intel_dp_link_required(int pixel_clock, int bpp); int
> intel_dp_effective_data_rate(int pixel_clock, int bpp_x16,
>int bw_overhead);
> +int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> + int max_dprx_rate, int max_dprx_lanes);
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp); bool
> intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state); diff
> --
> git a/
RE: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
>
> Factor out a function to read the sink's DPRX capabilities used by a follow-up
> patch enabling the DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 30 +++
> .../drm/i915/display/intel_dp_link_training.h | 1 +
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 7b140cbf8dd31..fb84ca98bb7ab 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -162,6 +162,28 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp,
> const u8 dpcd[DP_RECEI
> return lttpr_count;
> }
>
> +int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8
> +dpcd[DP_RECEIVER_CAP_SIZE]) {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (intel_dp_is_edp(intel_dp))
> + return 0;
> +
> + /*
> + * Detecting LTTPRs must be avoided on platforms with an AUX timeout
> + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> + */
> + if (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))
> + if (drm_dp_dpcd_probe(&intel_dp->aux,
> +
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> + return -EIO;
> +
> + if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd))
> + return -EIO;
> +
> + return 0;
> +}
> +
> /**
> * intel_dp_init_lttpr_and_dprx_caps - detect LTTPR and DPRX caps, init the
> LTTPR link training mode
> * @intel_dp: Intel DP struct
> @@ -192,12 +214,10 @@ int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp
> *intel_dp)
> if (!intel_dp_is_edp(intel_dp) &&
> (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> + int err = intel_dp_read_dprx_caps(intel_dp, dpcd);
>
> - if (drm_dp_dpcd_probe(&intel_dp->aux,
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> - return -EIO;
> -
> - if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd))
> - return -EIO;
> + if (err != 0)
> + return err;
>
> lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index 2c8f2775891b0..19836a8a4f904 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -11,6 +11,7 @@
> struct intel_crtc_state;
> struct intel_dp;
>
> +int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8
> +dpcd[DP_RECEIVER_CAP_SIZE]);
> int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp);
>
> void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> --
> 2.39.2
RE: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()
>
> Factor out a function updating the sink's link rate and lane count
> capabilities, used
> by a follow-up patch enabling the DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f40706c5d1aad..23434d0aba188 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3949,6 +3949,13 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> &intel_dp->desc);
> }
>
> +void intel_dp_update_sink_caps(struct intel_dp *intel_dp) {
> + intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
> + intel_dp_set_common_rates(intel_dp);
> +}
> +
> static bool
> intel_dp_get_dpcd(struct intel_dp *intel_dp) { @@ -3965,9 +3972,7 @@
> intel_dp_get_dpcd(struct intel_dp *intel_dp)
> drm_dp_read_desc(&intel_dp->aux, &intel_dp->desc,
>drm_dp_is_branch(intel_dp->dpcd));
>
> - intel_dp_set_sink_rates(intel_dp);
> - intel_dp_set_max_sink_lane_count(intel_dp);
> - intel_dp_set_common_rates(intel_dp);
> + intel_dp_update_sink_caps(intel_dp);
> }
>
> if (intel_dp_has_sink_count(intel_dp)) { diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index a7906d8738c4a..49553e43add22 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -106,6 +106,7 @@ int intel_dp_config_required_rate(const struct
> intel_crtc_state *crtc_state); int intel_dp_rate_select(struct intel_dp
> *intel_dp,
> int rate); int intel_dp_max_common_rate(struct intel_dp *intel_dp); int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
> +void intel_dp_update_sink_caps(struct intel_dp *intel_dp);
>
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> u8 *link_bw, u8 *rate_select);
> --
> 2.39.2
RE: [PATCH 06/19] drm/i915/dp: Export intel_dp_max_common_rate/lane_count()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 06/19] drm/i915/dp: Export
> intel_dp_max_common_rate/lane_count()
>
> Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by a
> follow-up patch enabling the DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a5c60428ffb7..f40706c5d1aad 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -309,7 +309,7 @@ static int intel_dp_common_rate(struct intel_dp
> *intel_dp, int index) }
>
> /* Theoretical max between source and sink */ -static int
> intel_dp_max_common_rate(struct intel_dp *intel_dp)
> +int intel_dp_max_common_rate(struct intel_dp *intel_dp)
> {
> return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates -
> 1); } @@ -326,7 +326,7 @@ static int intel_dp_max_source_lane_count(struct
> intel_digital_port *dig_port) }
>
> /* Theoretical max between source and sink */ -static int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
> +int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> int source_max = intel_dp_max_source_lane_count(dig_port);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 37274e3c2902f..a7906d8738c4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -104,6 +104,8 @@ int intel_dp_max_link_rate(struct intel_dp *intel_dp);
> int
> intel_dp_max_lane_count(struct intel_dp *intel_dp); int
> intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state); int
> intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
> +int intel_dp_max_common_rate(struct intel_dp *intel_dp); int
> +intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
>
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> u8 *link_bw, u8 *rate_select);
> --
> 2.39.2
RE: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()
>
> Factor out intel_dp_config_required_rate() used by a follow-up patch enabling
> the
> DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> 2 files changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c7b06a9b197cc..0a5c60428ffb7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2338,6 +2338,17 @@ intel_dp_compute_config_limits(struct intel_dp
> *intel_dp,
> limits);
> }
>
> +int intel_dp_config_required_rate(const struct intel_crtc_state
> +*crtc_state) {
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->hw.adjusted_mode;
> + int bpp = crtc_state->dsc.compression_enable ?
> + to_bpp_int_roundup(crtc_state->dsc.compressed_bpp_x16) :
> + crtc_state->pipe_bpp;
> +
> + return intel_dp_link_required(adjusted_mode->crtc_clock, bpp); }
> +
> static int
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config, @@ -2405,31
> +2416,15 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
> return ret;
> }
>
> - if (pipe_config->dsc.compression_enable) {
> - drm_dbg_kms(&i915->drm,
> - "DP lane count %d clock %d Input bpp %d Compressed
> bpp " BPP_X16_FMT "\n",
> - pipe_config->lane_count, pipe_config->port_clock,
> - pipe_config->pipe_bpp,
> - BPP_X16_ARGS(pipe_config-
> >dsc.compressed_bpp_x16));
> + drm_dbg_kms(&i915->drm,
> + "DP lane count %d clock %d bpp input %d compressed "
> BPP_X16_FMT " link rate required %d available %d\n",
> + pipe_config->lane_count, pipe_config->port_clock,
> + pipe_config->pipe_bpp,
> + BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
> + intel_dp_config_required_rate(pipe_config),
> + drm_dp_max_dprx_data_rate(pipe_config->port_clock,
> + pipe_config->lane_count));
>
> - drm_dbg_kms(&i915->drm,
> - "DP link rate required %i available %i\n",
> - intel_dp_link_required(adjusted_mode->crtc_clock,
> -
> to_bpp_int_roundup(pipe_config->dsc.compressed_bpp_x16)),
> - drm_dp_max_dprx_data_rate(pipe_config-
> >port_clock,
> - pipe_config->lane_count));
> - } else {
> - drm_dbg_kms(&i915->drm, "DP lane count %d clock %d bpp
> %d\n",
> - pipe_config->lane_count, pipe_config->port_clock,
> - pipe_config->pipe_bpp);
> -
> - drm_dbg_kms(&i915->drm,
> - "DP link rate required %i available %i\n",
> - intel_dp_link_required(adjusted_mode->crtc_clock,
> -pipe_config->pipe_bpp),
> - drm_dp_max_dprx_data_rate(pipe_config-
> >port_clock,
> - pipe_config->lane_count));
> - }
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 46f79747f807d..37274e3c2902f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -102,6 +102,7 @@ void intel_dp_mst_suspend(struct drm_i915_private
> *dev_priv); void intel_dp_mst_resume(struct drm_i915_private *dev_priv); int
> intel_dp_max_link_rate(struct intel_dp *intel_dp); int
> intel_dp_max_lane_count(struct intel_dp *intel_dp);
> +int intel_dp_config_required_rate(const struct intel_crtc_state
> +*crtc_state);
> int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
>
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> --
> 2.39.2
RE: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
>
> Instead of intel_dp_max_data_rate() use the equivalent
> drm_dp_max_dprx_data_rate() which was copied from the former one in a
> previous patch.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 62 +++-
> drivers/gpu/drm/i915/display/intel_dp.h | 1 -
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> 4 files changed, 10 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0caebbb3e2dbb..b9f985a5e705b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2478,7 +2478,7 @@ intel_link_compute_m_n(u16 bits_per_pixel_x16, int
> nlanes,
> u32 link_symbol_clock = intel_dp_link_symbol_clock(link_clock);
> u32 data_m = intel_dp_effective_data_rate(pixel_clock,
> bits_per_pixel_x16,
> bw_overhead);
> - u32 data_n = intel_dp_max_data_rate(link_clock, nlanes);
> + u32 data_n = drm_dp_max_dprx_data_rate(link_clock, nlanes);
>
> /*
>* Windows/BIOS uses fixed M/N values always. Follow suit.
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4e36c2c39888e..c7b06a9b197cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -383,52 +383,6 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
> 100 * 16 * 8);
> }
>
> -/*
> - * Given a link rate and lanes, get the data bandwidth.
> - *
> - * Data bandwidth is the actual payload rate, which depends on the data
> - * bandwidth efficiency and the link rate.
> - *
> - * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth
> efficiency
> - * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80 * (1/8) =
> - * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol clock. Just by
> - * coincidence, the port clock in kHz matches the data bandwidth in kBps, and
> - * they equal the link bit rate in Gbps multiplied by 10. (Note that
> this no
> - * longer holds for data bandwidth as soon as FEC or MST is taken into
> account!)
> - *
> - * For 128b/132b channel encoding, the data bandwidth efficiency is 96.71%.
> For
> - * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) = 1208875
> - * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The value
> 100
> - * does not match the symbol clock, the port clock (not even if you think in
> - * terms of a byte clock), nor the data bandwidth. It only matches the link
> bit
> - * rate in units of 1 bps.
> - */
> -int
> -intel_dp_max_data_rate(int max_link_rate, int max_lanes) -{
> - int ch_coding_efficiency =
> -
> drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_
> rate));
> - int max_link_rate_kbps = max_link_rate * 10;
> -
> - /*
> - * UHBR rates always use 128b/132b channel encoding, and have
> - * 97.71% data bandwidth efficiency. Consider max_link_rate the
> - * link bit rate in units of 1 bps.
> - */
> - /*
> - * Lower than UHBR rates always use 8b/10b channel encoding, and have
> - * 80% data bandwidth efficiency for SST non-FEC. However, this turns
> - * out to be a nop by coincidence:
> - *
> - * int max_link_rate_kbps = max_link_rate * 10;
> - * max_link_rate_kbps =
> DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 10);
> - * max_link_rate = max_link_rate_kbps / 8;
> - */
> - return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate_kbps *
> max_lanes,
> - ch_coding_efficiency),
> - 100 * 8);
> -}
> -
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp) {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); @@
> -658,7 +612,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
> intel_dp *intel_dp,
> int mode_rate, max_rate;
>
> mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> - max_rate = intel_dp_max_data_rate(link_rate, lane_count);
> + max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
> if (mode_rate > max_rate)
> return false;
>
> @@ -1260,7 +1214,7 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> max_lanes = intel_dp_max_lane_count(intel_dp);
>
> - max_rate = intel_dp_max_da
RE: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Friday, January 26, 2024 6:58 PM
> To: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()
>
> On Fri, Jan 26, 2024 at 01:36:02PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:32PM +0200, Imre Deak wrote:
> > > Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
> > > follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
> > > supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
> > > clarity. This patchset will also switch calling the new DRM function
> > > in i915 instead of intel_dp_max_data_rate().
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/display/drm_dp_helper.c | 58
> +
> > > include/drm/display/drm_dp_helper.h | 2 +
> > > 2 files changed, 60 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > > b/drivers/gpu/drm/display/drm_dp_helper.c
> > > index b1ca3a1100dab..24911243d4d3a 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > > @@ -4058,3 +4058,61 @@ int drm_dp_bw_channel_coding_efficiency(bool
> is_uhbr)
> > > return 80;
> > > }
> > > EXPORT_SYMBOL(drm_dp_bw_channel_coding_efficiency);
> > > +
> > > +/*
> > > + * Given a link rate and lanes, get the data bandwidth.
> > > + *
> > > + * Data bandwidth is the actual payload rate, which depends on the
> > > +data
> > > + * bandwidth efficiency and the link rate.
> > > + *
> > > + * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth
> > > +efficiency
> > > + * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80
> > > +* (1/8) =
> > > + * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol
> > > +clock. Just by
> > > + * coincidence, the port clock in kHz matches the data bandwidth in
> > > +kBps, and
> > > + * they equal the link bit rate in Gbps multiplied by 10. (Note
> > > +that this no
> > > + * longer holds for data bandwidth as soon as FEC or MST is taken
> > > +into account!)
> > > + *
> > > + * For 128b/132b channel encoding, the data bandwidth efficiency is
> > > +96.71%. For
> > > + * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) =
> > > +1208875
> > > + * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The
> > > +value 100
> > > + * does not match the symbol clock, the port clock (not even if you
> > > +think in
> > > + * terms of a byte clock), nor the data bandwidth. It only matches
> > > +the link bit
> > > + * rate in units of 1 bps.
> > > + *
> > > + * Note that protocol layers above the DPRX link level considered
> > > +here can
> > > + * further limit the maximum data rate. Such layers are the MST
> > > +topology (with
> > > + * limits on the link between the source and first branch device as
> > > +well as on
> > > + * the whole MST path until the DPRX link) and (Thunderbolt) DP
> > > +tunnels -
> > > + * which in turn can encapsulate an MST link with its own limit -
> > > +with each
> > > + * SST or MST encapsulated tunnel sharing the BW of a tunnel group.
> > > + *
> > > + * TODO: Add support for querying the max data rate with the above
> > > +limits as
> > > + * well.
> > > + *
> > > + * Returns the maximum data rate in kBps units.
> > > + */
> > > +int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes) {
> > > + int ch_coding_efficiency =
> > > +
> drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_
> rate));
> > > + int max_link_rate_kbps = max_link_rate * 10;
> >
> > That x10 value seems rather pointless.
>
> I suppose the point was to make the units clearer, but it could be clarified
> instead
> in max_link_rates' documentation, which is missing atm.
>
> > > +
> > > + /*
> > > + * UHBR rates always use 128b/132b channel encoding, and have
> > > + * 97.71% data bandwidth efficiency. Consider max_link_rate the
> > > + * link bit rate in units of 1 bps.
> > > + */
> > > + /*
> > > + * Lower than UHBR rates always use 8b/10b channel encoding, and have
> > > + * 80% data bandwidth efficiency for SST non-FEC. However, this turns
> > > + * out to be a nop by coincidence:
> > > + *
> > > + * int max_link_rate_kbps = max_link_rate * 10;
> > > + * max_link_rate_kbps =
> DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 10);
> > > + * max_link_rate = max_link_rate_kbps / 8;
> > > + */
> >
> > Not sure why we are repeating the nuts and bolts detils in the
> > comments so much? Doesn't drm_dp_bw_channel_coding_efficiency()
> > explain all this already?
>
> I simply copied the function, but yes in this context there is duplication,
> thanks for
> reading through all that. Will consolidate both the above and the bigger
> comment
> before the function with the existing docs here.
Changes look good to me. W
RE: [PATCH] drm/i915/fbc: Allow FBC with CCS modifiers on SKL+
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, January 24, 2024 9:13 AM
> To: Vivi, Rodrigo
> Cc: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/fbc: Allow FBC with CCS modifiers on SKL+
>
> On Tue, Jan 23, 2024 at 05:44:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Jan 23, 2024 at 11:02:44AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Only display workarounds 0391 and 0475 call for disabling FBC with
> > > render compression, and those are listed only for pre-prod SKL
> > > steppings. So it should be safe to enable
> > > FB+CCS on production hardware.
> > >
> > > AFAIK CCS is limited to 50% bandwidth reduction (perhaps clear color
> > > can do better?). FBC can exceed that number by quite a bit, given
> > > the right kind of framebuffer contents. So piling on both kinds of
> > > compressions could still make sense.
> >
> > yeap, I think so.
> > The risk is to hit a workaround that is not ducumented in the BSpec
> > cases after gen11...
> >
> > Uma, do you recall having seen lately any workaround with FBC and
> > render compression?
Sorry missed to reply earlier.
I don't see any restriction called out on this, so we should be good enabling
them both.
Let's enable and uncover bugs if any 😊 (have been a touchy area anyways)
Regards,
Uma Shankar
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10125
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_fbc.c | 13 +
> > > 1 file changed, 1 insertion(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index f17a1afb4929..b453fcbd67da 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -1087,18 +1087,7 @@ static bool i8xx_fbc_tiling_valid(const
> > > struct intel_plane_state *plane_state)
> > >
> > > static bool skl_fbc_tiling_valid(const struct intel_plane_state
> > > *plane_state) {
> > > - const struct drm_framebuffer *fb = plane_state->hw.fb;
> > > -
> > > - switch (fb->modifier) {
> > > - case DRM_FORMAT_MOD_LINEAR:
> > > - case I915_FORMAT_MOD_Y_TILED:
> > > - case I915_FORMAT_MOD_Yf_TILED:
> > > - case I915_FORMAT_MOD_4_TILED:
> > > - case I915_FORMAT_MOD_X_TILED:
> > > - return true;
> > > - default:
> > > - return false;
> > > - }
> > > + return true;
> >
> > we could also simply kill this function... the compiler does the right
> > thing, but users navigating on the code needs to do an extra
> > ctag/cscope inspections to see that it is a simple return. But well,
> > the code do gets prettier with the function :)
>
> I've been thinking of converting a bunch of this stuff to vfuncs, so keeping
> the
> function around in anticipation of that seemed semi-reasonable.
>
> > So, up to you:
> >
> > Reviewed-by: Rodrigo Vivi
>
> Thanks.
>
> >
> > > }
> > >
> > > static bool tiling_is_valid(const struct intel_plane_state
> > > *plane_state)
> > > --
> > > 2.43.0
> > >
>
> --
> Ville Syrjälä
> Intel
RE: [PATCH v3 16/16] drm/i915: Annotate more of the BIOS fb takeover failure paths
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Tuesday, January 16, 2024 1:27 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v3 16/16] drm/i915: Annotate more of the BIOS fb takeover
> failure paths
>
> From: Ville Syrjälä
>
> Annotate a few more of the failure paths on the initial BIOS fb takeover to
> avoid
> having to guess why things aren't working the way we expect.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_plane_initial.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 00e194ee129a..d9a356d5661b 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -167,14 +167,19 @@ initial_plane_vma(struct drm_i915_private *i915,
>*/
> if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
> mem == i915->mm.stolen_region &&
> - size * 2 > i915->dsm.usable_size)
> + size * 2 > i915->dsm.usable_size) {
> + drm_dbg_kms(&i915->drm, "Initial FB size exceeds half of stolen,
> +discarding\n");
> return NULL;
> + }
>
> obj = i915_gem_object_create_region_at(mem, phys_base, size,
> I915_BO_ALLOC_USER |
> I915_BO_PREALLOC);
> - if (IS_ERR(obj))
> + if (IS_ERR(obj)) {
> + drm_dbg_kms(&i915->drm, "Failed to preallocate initial FB in
> %s\n",
> + mem->region.name);
> return NULL;
> + }
>
> /*
>* Mark it WT ahead of time to avoid changing the
> --
> 2.41.0
