Re: [Intel-gfx] [PATCH] drm/i915: Fix timeslots argument for DP DSC SST case
On Mon, Jan 02, 2023 at 03:23:06PM +0200, Stanislav Lisovskiy wrote: > We now accept timeslots param exactly how the variable > sounds: amount of timeslots, but not ratio timeslots/64. > So for SST case(when we have all timeslots for use), it > should be 64, but not 1. > This caused some issues in the tests. > > Signed-off-by: Stanislav Lisovskiy Looks good to me, Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 13baf3cb5f934..362fb394d613c 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -1696,7 +1696,7 @@ intel_dp_compute_link_config(struct intel_encoder > *encoder, > str_yes_no(ret), str_yes_no(joiner_needs_dsc), > str_yes_no(intel_dp->force_dsc_en)); > ret = intel_dp_dsc_compute_config(intel_dp, pipe_config, > - conn_state, , 1, true); > + conn_state, , 64, > true); > if (ret < 0) > return ret; > } > -- > 2.37.3 >
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+
On Wed, Dec 07, 2022 at 11:35:24PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2022 at 01:05:15PM -0800, Navare, Manasi wrote:
> > On Wed, Dec 07, 2022 at 05:10:54PM +0200, Ville Syrjälä wrote:
> > > On Mon, Dec 05, 2022 at 12:34:25PM -0800, Navare, Manasi wrote:
> > > > On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > We are miscalculating both the guardband value, and the resulting
> > > > > vblank exit length on adl+. This means that our start of vblank
> > > > > (double buffered register latch point) is incorrect, and we also
> > > > > think that it's not where it actually is (hence vblank evasion/etc.
> > > > > may not work properly). Fix up the calculations to match the real
> > > > > hardware behaviour (as reverse engineered by intel_display_poller).
> > > > >
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > index 6655dd2c1684..753e7b211708 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > @@ -78,10 +78,10 @@ static int intel_vrr_vblank_exit_length(const
> > > > > struct intel_crtc_state *crtc_stat
> > > > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > >
> > > > > - /* The hw imposes the extra scanline before frame start */
> > > > > if (DISPLAY_VER(i915) >= 13)
> > > > > - return crtc_state->vrr.guardband +
> > > > > crtc_state->framestart_delay + 1;
> > > > > + return crtc_state->vrr.guardband;
> > > >
> > > > This makes sense since with guardband, there is no framestart delay
> > >
> > > framestart delay is still a thing. But it's not something that
> > > affects how the hardware interprets the guardband value.
> > >
> > > >
> > > > > else
> > > > > + /* The hw imposes the extra scanline before frame start
> > > > > */
> > > > > return crtc_state->vrr.pipeline_full +
> > > > > crtc_state->framestart_delay + 1;
> > > > > }
> > > > >
> > > > > @@ -151,7 +151,7 @@ intel_vrr_compute_config(struct intel_crtc_state
> > > > > *crtc_state,
> > > > >* number of scan lines. Assuming 0 for no DSB.
> > > > >*/
> > > > > crtc_state->vrr.guardband =
> > > > > - crtc_state->vrr.vmin -
> > > > > adjusted_mode->crtc_vdisplay;
> > > > > + crtc_state->vrr.vmin + 1 -
> > > > > adjusted_mode->crtc_vdisplay;
> > > >
> > > > Why are we adding + 1 here? The bspec says guardband should be :
> > > > Guardband = Vmin - Vactive - Window2 where in our case Window2 = 0
> > > > If we need that + 1 to get this working, then perhaps we need to update
> > > > Bspec?
> > >
> > > flipline is what actaully determines the start of vblank, and
> > > 'flipline>=vmin+1' always.
> >
> > Flipline would be always >=vmin as per the bspec,
>
> Not sure where in bspec you see that. All I see is >vmin,
> and it even says you et an extra line if you try to set them
> equal. Pretty sure I verified that behaviour on the hw on icl/tgl
> since I put the extra -1 to the vmin calculation. Though I haven't
> actually tested it on adl+.
You are right for these current platforms it still needs >=Vmin + 1.
Reviewed-by: Manasi Navare
Manasi
>
> > have we tried with
> > that or if that definitely doesnt work then we need to have this changed
> > in the bspec.
> >
> > Either way if this is the only value that works then with this change
> > added to bspec:
> >
> > Reviewed-by: Manasi Navare
> >
> > Manasi
> >
> > >
> > > >
> > > > I kind of want to see if this is still breaking if we dont have that +
> > > > 1?
> > >
> > > Without it start of vblank happens one line later than where we want it
> > > to happen.
> > >
> > > >
> > > > Manasi
> > > >
> > > > > } else {
> > > > > crtc_state->vrr.pipeline_full =
> > > > > min(255, crtc_state->vrr.vmin -
> > > > > adjusted_mode->crtc_vdisplay -
> > > > > --
> > > > > 2.37.4
> > > > >
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function
On Wed, Nov 23, 2022 at 12:05:51PM +0200, Stanislav Lisovskiy wrote:
> We might to use that function separately from intel_dp_dsc_compute_config
> for DP DSC over MST case, because allocating bandwidth in that
> case can be a bit more tricky. So in order to avoid code copy-pasta
> lets extract this to separate function and reuse it for both SST
> and MST cases.
>
> v2: Removed multiple blank lines
> v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp
> to reflect its meaning more properly.
> (Manasi Navare)
>
> Signed-off-by: Stanislav Lisovskiy
Looks good now,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 50 +
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 -
> 3 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 44e2424a54c0..d78216fba0a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -672,6 +672,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
> return 6144 * 8;
> }
>
> +u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp)
> +{
> + u32 bits_per_pixel = bpp;
> + int i;
> +
> + /* Error out if the max bpp is less than smallest allowed valid bpp */
> + if (bits_per_pixel < valid_dsc_bpp[0]) {
> + drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> + return 0;
> + }
> +
> + /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> + if (DISPLAY_VER(i915) >= 13) {
> + bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> + } else {
> + /* Find the nearest match in the array of known BPPs from VESA
> */
> + for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> + if (bits_per_pixel < valid_dsc_bpp[i + 1])
> + break;
> + }
> + drm_dbg_kms(>drm, "Set dsc bpp from %d to VESA %d\n",
> + bits_per_pixel, valid_dsc_bpp[i]);
> +
> + bits_per_pixel = valid_dsc_bpp[i];
> + }
> +
> + return bits_per_pixel;
> +}
> +
> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> @@ -680,7 +710,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> - int i;
>
> /*
>* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
> @@ -713,24 +742,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
>
> - /* Error out if the max bpp is less than smallest allowed valid bpp */
> - if (bits_per_pixel < valid_dsc_bpp[0]) {
> - drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> - bits_per_pixel, valid_dsc_bpp[0]);
> - return 0;
> - }
> -
> - /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> - if (DISPLAY_VER(i915) >= 13) {
> - bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> - } else {
> - /* Find the nearest match in the array of known BPPs from VESA
> */
> - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> - if (bits_per_pixel < valid_dsc_bpp[i + 1])
> - break;
> - }
> - bits_per_pixel = valid_dsc_bpp[i];
> - }
> + bits_per_pixel = intel_dp_dsc_nearest_valid_bpp(i915, bits_per_pixel,
> pipe_bpp);
>
> /*
>* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c6539a6915e9..e4faccf87370 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> }
>
> u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> +u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp,
> u
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+
On Wed, Dec 07, 2022 at 05:10:54PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 05, 2022 at 12:34:25PM -0800, Navare, Manasi wrote:
> > On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We are miscalculating both the guardband value, and the resulting
> > > vblank exit length on adl+. This means that our start of vblank
> > > (double buffered register latch point) is incorrect, and we also
> > > think that it's not where it actually is (hence vblank evasion/etc.
> > > may not work properly). Fix up the calculations to match the real
> > > hardware behaviour (as reverse engineered by intel_display_poller).
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > index 6655dd2c1684..753e7b211708 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > @@ -78,10 +78,10 @@ static int intel_vrr_vblank_exit_length(const struct
> > > intel_crtc_state *crtc_stat
> > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > >
> > > - /* The hw imposes the extra scanline before frame start */
> > > if (DISPLAY_VER(i915) >= 13)
> > > - return crtc_state->vrr.guardband + crtc_state->framestart_delay
> > > + 1;
> > > + return crtc_state->vrr.guardband;
> >
> > This makes sense since with guardband, there is no framestart delay
>
> framestart delay is still a thing. But it's not something that
> affects how the hardware interprets the guardband value.
>
> >
> > > else
> > > + /* The hw imposes the extra scanline before frame start */
> > > return crtc_state->vrr.pipeline_full +
> > > crtc_state->framestart_delay + 1;
> > > }
> > >
> > > @@ -151,7 +151,7 @@ intel_vrr_compute_config(struct intel_crtc_state
> > > *crtc_state,
> > >* number of scan lines. Assuming 0 for no DSB.
> > >*/
> > > crtc_state->vrr.guardband =
> > > - crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay;
> > > + crtc_state->vrr.vmin + 1 - adjusted_mode->crtc_vdisplay;
> >
> > Why are we adding + 1 here? The bspec says guardband should be :
> > Guardband = Vmin - Vactive - Window2 where in our case Window2 = 0
> > If we need that + 1 to get this working, then perhaps we need to update
> > Bspec?
>
> flipline is what actaully determines the start of vblank, and
> 'flipline>=vmin+1' always.
Flipline would be always >=vmin as per the bspec, have we tried with
that or if that definitely doesnt work then we need to have this changed
in the bspec.
Either way if this is the only value that works then with this change
added to bspec:
Reviewed-by: Manasi Navare
Manasi
>
> >
> > I kind of want to see if this is still breaking if we dont have that +
> > 1?
>
> Without it start of vblank happens one line later than where we want it
> to happen.
>
> >
> > Manasi
> >
> > > } else {
> > > crtc_state->vrr.pipeline_full =
> > > min(255, crtc_state->vrr.vmin -
> > > adjusted_mode->crtc_vdisplay -
> > > --
> > > 2.37.4
> > >
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 4/4] drm/i915/vrr: Be more careful with the bits in TRANS_VRR_CTL
On Fri, Dec 02, 2022 at 03:44:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On mtl (at least) clearing the guardband bits in the same write
> as the enable bit gets cleared seems to cause an immediate FIFO
> underrun. Thus is seems that we need to first clear just the
> enable bit, then wait for the VRR live status to indicate the
> transcoder has exited VRR mode (this step is documented in Bspec
> as well), and finally we can clear out the rest of the TRANS_VRR_CTL
> for good measure.
>
> I did this without any RMWs in case we want to toggle VRR on/off
> via DSB in the future, and as we know DSB can't read registers.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_vrr.c | 40 +++-
> 1 file changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 753e7b211708..5ff6aed9575e 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -161,31 +161,36 @@ intel_vrr_compute_config(struct intel_crtc_state
> *crtc_state,
> crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
> }
>
> -void intel_vrr_enable(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state)
> +static u32 trans_vrr_ctl(const struct intel_crtc_state *crtc_state)
> {
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - u32 trans_vrr_ctl;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
>
> - if (!crtc_state->vrr.enable)
> - return;
> -
> - if (DISPLAY_VER(dev_priv) >= 13)
> - trans_vrr_ctl = VRR_CTL_VRR_ENABLE |
> - VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
> + if (DISPLAY_VER(i915) >= 13)
> + return VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
> XELPD_VRR_CTL_VRR_GUARDBAND(crtc_state->vrr.guardband);
> else
> - trans_vrr_ctl = VRR_CTL_VRR_ENABLE |
> - VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
> + return VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
> VRR_CTL_PIPELINE_FULL(crtc_state->vrr.pipeline_full) |
> VRR_CTL_PIPELINE_FULL_OVERRIDE;
> +}
> +
> +void intel_vrr_enable(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> + if (!crtc_state->vrr.enable)
> + return;
>
> intel_de_write(dev_priv, TRANS_VRR_VMIN(cpu_transcoder),
> crtc_state->vrr.vmin - 1);
> intel_de_write(dev_priv, TRANS_VRR_VMAX(cpu_transcoder),
> crtc_state->vrr.vmax - 1);
> - intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), trans_vrr_ctl);
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
> trans_vrr_ctl(crtc_state));
> intel_de_write(dev_priv, TRANS_VRR_FLIPLINE(cpu_transcoder),
> crtc_state->vrr.flipline - 1);
> intel_de_write(dev_priv, TRANS_PUSH(cpu_transcoder), TRANS_PUSH_EN);
> +
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
> +VRR_CTL_VRR_ENABLE | trans_vrr_ctl(crtc_state));
> }
>
> void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
> @@ -222,8 +227,13 @@ void intel_vrr_disable(const struct intel_crtc_state
> *old_crtc_state)
> if (!old_crtc_state->vrr.enable)
> return;
>
> - intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), 0);
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
> +trans_vrr_ctl(old_crtc_state));
> + intel_de_wait_for_clear(dev_priv, TRANS_VRR_STATUS(cpu_transcoder),
> + VRR_STATUS_VRR_EN_LIVE, 1000);
> +
> intel_de_write(dev_priv, TRANS_PUSH(cpu_transcoder), 0);
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), 0);
> }
>
> void intel_vrr_get_config(struct intel_crtc *crtc,
> --
> 2.37.4
>
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vrr: Reorder transcoder vs. vrr enable/disable
On Fri, Dec 02, 2022 at 03:44:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On mtl it looks like disabling VRR after the transcoder has
> been disabled can cause the pipe/transcoder to get stuck
> when re-enabled in non-vrr mode. Reversing the order seems to
> help.
>
> Bspec is extremely confused about the VRR enable/disable sequence
> anyway, and this now more closely matches the non-modeset VRR
> sequence, whereas the full modeset sequence still claims that
> the original order is fine. But since we eventually want to toggle
> VRR without a full modeset anyway this seems like the better order
> to follow.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 5f9a2410fc4c..69595cbb2766 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2726,10 +2726,10 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
> if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> intel_crtc_vblank_off(old_crtc_state);
>
> - intel_disable_transcoder(old_crtc_state);
> -
> intel_vrr_disable(old_crtc_state);
>
> + intel_disable_transcoder(old_crtc_state);
> +
> intel_ddi_disable_transcoder_func(old_crtc_state);
>
> intel_dsc_disable(old_crtc_state);
> @@ -2946,13 +2946,13 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> intel_ddi_enable_transcoder_func(encoder, crtc_state);
>
> - intel_vrr_enable(encoder, crtc_state);
> -
> /* Enable/Disable DP2.0 SDP split config before transcoder */
> intel_audio_sdp_split_update(encoder, crtc_state);
>
> intel_enable_transcoder(crtc_state);
>
> + intel_vrr_enable(encoder, crtc_state);
> +
> intel_crtc_vblank_on(crtc_state);
>
> if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> --
> 2.37.4
>
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+
On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We are miscalculating both the guardband value, and the resulting
> vblank exit length on adl+. This means that our start of vblank
> (double buffered register latch point) is incorrect, and we also
> think that it's not where it actually is (hence vblank evasion/etc.
> may not work properly). Fix up the calculations to match the real
> hardware behaviour (as reverse engineered by intel_display_poller).
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 6655dd2c1684..753e7b211708 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -78,10 +78,10 @@ static int intel_vrr_vblank_exit_length(const struct
> intel_crtc_state *crtc_stat
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>
> - /* The hw imposes the extra scanline before frame start */
> if (DISPLAY_VER(i915) >= 13)
> - return crtc_state->vrr.guardband + crtc_state->framestart_delay
> + 1;
> + return crtc_state->vrr.guardband;
This makes sense since with guardband, there is no framestart delay
> else
> + /* The hw imposes the extra scanline before frame start */
> return crtc_state->vrr.pipeline_full +
> crtc_state->framestart_delay + 1;
> }
>
> @@ -151,7 +151,7 @@ intel_vrr_compute_config(struct intel_crtc_state
> *crtc_state,
>* number of scan lines. Assuming 0 for no DSB.
>*/
> crtc_state->vrr.guardband =
> - crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay;
> + crtc_state->vrr.vmin + 1 - adjusted_mode->crtc_vdisplay;
Why are we adding + 1 here? The bspec says guardband should be :
Guardband = Vmin - Vactive - Window2 where in our case Window2 = 0
If we need that + 1 to get this working, then perhaps we need to update
Bspec?
I kind of want to see if this is still breaking if we dont have that +
1?
Manasi
> } else {
> crtc_state->vrr.pipeline_full =
> min(255, crtc_state->vrr.vmin -
> adjusted_mode->crtc_vdisplay -
> --
> 2.37.4
>
Re: [Intel-gfx] [PATCH 1/4] drm/i915/vrr: Make registers latch in a consitent place on icl/tgl
On Fri, Dec 02, 2022 at 03:44:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Account for the framestart delay when calculating the "pipeline full"
> value for icl/tgl vrr. This puts the start of vblank (ie. where the
> double bufferd registers get latched) to a consistent place regardless
> of what framestart delay value is used. framestart delay does not
> change where start of vblank occurs in non-vrr mode and I can't see
> any reason why we'd want different behaviour in vrr mode.
>
> Currently framestart delay is always set to 1, and the hardcoded 4
> scanlines in the code means we're currently delaying the start of
> vblank by three extra lines. And with framestart delay set to 4 we'd
> have no extra delay.
>
> Signed-off-by: Ville Syrjälä
So now basically if we want to delay the vblank, then we will need to
update framestart_delay to somethin other than 1.
Currently with framestart_delay = 1, there is no vblank delay, its just
vrr.vmin - vdisplay so the vblank start right after?
Is this the correct understanding?
Anyway, if this logic is validated to work then should be fine.
Basically this will only impact display <13, so as long as we dont
regress anything on TGL then we should be good.
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_vrr.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 7b1357e82b69..6655dd2c1684 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -153,18 +153,9 @@ intel_vrr_compute_config(struct intel_crtc_state
> *crtc_state,
> crtc_state->vrr.guardband =
> crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay;
> } else {
> - /*
> - * FIXME: s/4/framestart_delay/ to get consistent
> - * earliest/latest points for register latching regardless
> - * of the framestart_delay used?
> - *
> - * FIXME: this really needs the extra scanline to provide
> consistent
> - * behaviour for all framestart_delay values. Otherwise with
> - * framestart_delay==4 we will end up extending the min vblank
> by
> - * one extra line.
> - */
> crtc_state->vrr.pipeline_full =
> - min(255, crtc_state->vrr.vmin -
> adjusted_mode->crtc_vdisplay - 4 - 1);
> + min(255, crtc_state->vrr.vmin -
> adjusted_mode->crtc_vdisplay -
> + crtc_state->framestart_delay - 1);
> }
>
> crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
> --
> 2.37.4
>
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC
Thanks Stan for the explanation, With that Reviewed-by: Manasi Navare Manasi -Original Message- From: Lisovskiy, Stanislav Sent: Tuesday, November 22, 2022 2:40 AM To: Navare, Manasi D Cc: intel-gfx@lists.freedesktop.org; Saarinen, Jani ; Nikula, Jani ; dri-de...@lists.freedesktop.org; Govindapillai, Vinod Subject: Re: [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC On Thu, Nov 10, 2022 at 02:23:53PM -0800, Navare, Manasi wrote: > On Thu, Nov 03, 2022 at 03:23:00PM +0200, Stanislav Lisovskiy wrote: > > Fix intel_dp_dsc_compute_config, previously timeslots parameter was > > used in fact not as a timeslots, but more like a ratio timeslots/64, > > which of course didn't have any effect for SST DSC, but causes now > > issues for MST DSC. > > Secondly we need to calculate pipe_bpp using > > intel_dp_dsc_compute_bpp only for SST DSC case, while for MST case > > it has been calculated earlier already with > > intel_dp_dsc_mst_compute_link_config. > > Third we also were wrongly determining sink min bpp/max bpp, those > > limites should be intersected with our limits to find common > > acceptable bpp's, plus on top of that we should align those with > > VESA bpps and only then calculate required timeslots amount. > > Some MST hubs started to work only after third change was made. > > > > v2: Make kernel test robot happy(claimed there was unitialzed use, > > while there is none) > > > > Signed-off-by: Stanislav Lisovskiy > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 69 ++--- > > drivers/gpu/drm/i915/display/intel_dp.h | 3 +- > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 69 > > + > > 3 files changed, 106 insertions(+), 35 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 8288a30dbd51..82752b696498 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -716,9 +716,14 @@ u16 intel_dp_dsc_get_output_bpp(struct > > drm_i915_private *i915, > > * for SST -> TimeSlotsPerMTP is 1, > > * for MST -> TimeSlotsPerMTP has to be calculated > > */ > > - bits_per_pixel = (link_clock * lane_count * 8) * timeslots / > > -intel_dp_mode_to_fec_clock(mode_clock); > > - drm_dbg_kms(>drm, "Max link bpp: %u\n", bits_per_pixel); > > + bits_per_pixel = DIV_ROUND_UP((link_clock * lane_count) * timeslots, > > + intel_dp_mode_to_fec_clock(mode_clock) * > > 8); > > Why did we remove the *8 in the numerator for the total bandwidth > link_clock * lane_count * 8 ? > > Other than this clarification, all changes look good > > Manasi Hi Manasi, Because previously this function was actually confusing the ratio timeslots/64, with the timeslots number. It was actually expecting a ratio timeslots/64, rather than the timeslots number. For SST it didn't matter as timeslots were always 1, but for MST case if we multiply that by number number of timeslots, this formula will return some big bogus bits_per_pixel number(checked that). Of course we can pass a ratio timeslots/64 here, but it isn't very convenient and intuitive to manipulate. So I made it to use a "timeslots" parameter as timeslots number, so that the ratio is calculated as part of the formula i.e: ((link_clock * lane_count * 8) * (timeslots / 64)) / intel_dp_mode_to_fec_clock(mode_clock); which can be simplified as ((link_clock * lane_count * timeslots) / 8) / intel_dp_mode_to_fec_clock(mode_clock); the whole formula comes from that pipe_bpp * crtc_clock should be equal to link_total_bw * (timeslots / 64), i.e timeslots/64 ratio defines, how much of the link_total_bw(link_clock * lane_count * 8) we have for those pipe_bpp * crtc_clock, which we want to accomodate there. Obviously if we just multiplied link_total_bw by timeslots, we would get a situation that the more timeslots we allocate, the more total bw we get, which is wrong and will result in some bogus huge pipe_bpp numbers. Stan > > > + > > + drm_dbg_kms(>drm, "Max link bpp is %u for %u timeslots " > > + "total bw %u pixel clock %u\n", > > + bits_per_pixel, timeslots, > > + (link_clock * lane_count * 8), > > + intel_dp_mode_to_fec_clock(mode_clock)); > > > > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */ > > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915)
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC
On Thu, Nov 03, 2022 at 03:23:00PM +0200, Stanislav Lisovskiy wrote:
> Fix intel_dp_dsc_compute_config, previously timeslots parameter
> was used in fact not as a timeslots, but more like a ratio
> timeslots/64, which of course didn't have any effect for SST DSC,
> but causes now issues for MST DSC.
> Secondly we need to calculate pipe_bpp using intel_dp_dsc_compute_bpp
> only for SST DSC case, while for MST case it has been calculated
> earlier already with intel_dp_dsc_mst_compute_link_config.
> Third we also were wrongly determining sink min bpp/max bpp, those
> limites should be intersected with our limits to find common
> acceptable bpp's, plus on top of that we should align those with
> VESA bpps and only then calculate required timeslots amount.
> Some MST hubs started to work only after third change was made.
>
> v2: Make kernel test robot happy(claimed there was unitialzed use,
> while there is none)
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 69 ++---
> drivers/gpu/drm/i915/display/intel_dp.h | 3 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 69 +
> 3 files changed, 106 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8288a30dbd51..82752b696498 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -716,9 +716,14 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
>* for SST -> TimeSlotsPerMTP is 1,
>* for MST -> TimeSlotsPerMTP has to be calculated
>*/
> - bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> - intel_dp_mode_to_fec_clock(mode_clock);
> - drm_dbg_kms(>drm, "Max link bpp: %u\n", bits_per_pixel);
> + bits_per_pixel = DIV_ROUND_UP((link_clock * lane_count) * timeslots,
> + intel_dp_mode_to_fec_clock(mode_clock) *
> 8);
Why did we remove the *8 in the numerator for the total bandwidth
link_clock * lane_count * 8 ?
Other than this clarification, all changes look good
Manasi
> +
> + drm_dbg_kms(>drm, "Max link bpp is %u for %u timeslots "
> + "total bw %u pixel clock %u\n",
> + bits_per_pixel, timeslots,
> + (link_clock * lane_count * 8),
> + intel_dp_mode_to_fec_clock(mode_clock));
>
> /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
> max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> @@ -1047,7 +1052,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> target_clock,
> mode->hdisplay,
> bigjoiner,
> - pipe_bpp, 1) >> 4;
> + pipe_bpp, 64) >> 4;
> dsc_slice_count =
> intel_dp_dsc_get_slice_count(intel_dp,
>target_clock,
> @@ -1481,7 +1486,8 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state,
> struct link_config_limits *limits,
> - int timeslots)
> + int timeslots,
> + bool compute_pipe_bpp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> @@ -1496,7 +1502,10 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> return -EINVAL;
>
> - pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> conn_state->max_requested_bpc);
> + if (compute_pipe_bpp)
> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> conn_state->max_requested_bpc);
> + else
> + pipe_bpp = pipe_config->pipe_bpp;
>
> if (intel_dp->force_dsc_bpc) {
> pipe_bpp = intel_dp->force_dsc_bpc * 3;
> @@ -1527,31 +1536,47 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
> true);
> } else {
> - u16 dsc_max_output_bpp;
> + u16 dsc_max_output_bpp = 0;
> u8 dsc_dp_slice_count;
>
> - dsc_max_output_bpp =
> - intel_dp_dsc_get_output_bpp(dev_priv,
> -
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function
On Thu, Nov 03, 2022 at 03:21:46PM +0200, Stanislav Lisovskiy wrote:
> We might to use that function separately from intel_dp_dsc_compute_config
> for DP DSC over MST case, because allocating bandwidth in that
> case can be a bit more tricky. So in order to avoid code copy-pasta
> lets extract this to separate function and reuse it for both SST
> and MST cases.
>
> v2: Removed multiple blank lines
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 50 +
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 -
> 3 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 70f4d6422795..8288a30dbd51 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -671,6 +671,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
> return 6144 * 8;
> }
>
> +u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp)
It makes sense to pull this out into a separate function.
For the function name, we have never had vesa in any of the function
names even though most of these come from vesa spec. So I think we
should remove vesa IMO, just name it as intel_dp_dsc_nearest_valid_bpp
or something?
Manasi
> +{
> + u32 bits_per_pixel = bpp;
> + int i;
> +
> + /* Error out if the max bpp is less than smallest allowed valid bpp */
> + if (bits_per_pixel < valid_dsc_bpp[0]) {
> + drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> + return 0;
> + }
> +
> + /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> + if (DISPLAY_VER(i915) >= 13) {
> + bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> + } else {
> + /* Find the nearest match in the array of known BPPs from VESA
> */
> + for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> + if (bits_per_pixel < valid_dsc_bpp[i + 1])
> + break;
> + }
> + drm_dbg_kms(>drm, "Set dsc bpp from %d to VESA %d\n",
> + bits_per_pixel, valid_dsc_bpp[i]);
> +
> + bits_per_pixel = valid_dsc_bpp[i];
> + }
> +
> + return bits_per_pixel;
> +}
> +
> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> @@ -679,7 +709,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> - int i;
>
> /*
>* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
> @@ -712,24 +741,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
>
> - /* Error out if the max bpp is less than smallest allowed valid bpp */
> - if (bits_per_pixel < valid_dsc_bpp[0]) {
> - drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> - bits_per_pixel, valid_dsc_bpp[0]);
> - return 0;
> - }
> -
> - /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> - if (DISPLAY_VER(i915) >= 13) {
> - bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> - } else {
> - /* Find the nearest match in the array of known BPPs from VESA
> */
> - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> - if (bits_per_pixel < valid_dsc_bpp[i + 1])
> - break;
> - }
> - bits_per_pixel = valid_dsc_bpp[i];
> - }
> + bits_per_pixel = intel_dp_dsc_nearest_vesa_bpp(i915, bits_per_pixel,
> pipe_bpp);
>
> /*
>* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c6539a6915e9..0fe10d93b75c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> }
>
> u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> +u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp);
>
> void intel_ddi_update_pipe(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 61b2bd504e80..8442eea27a57 100644
> ---
Re: [Intel-gfx] [PATCH] drm/i915/display: mode clock check related to max dotclk frequency
On Wed, Nov 09, 2022 at 12:36:44PM +0200, Jani Nikula wrote: > On Wed, 09 Nov 2022, Nischal Varide wrote: > > A check on mode->clock to see if is greater than i915->max_dotclk_freq > > or greater than 2 * (i915_max_dotclk_freq) in case of big-joiner and > > return an -EINVAL in both the cases > > The commit message should explain *why* the change is being done. > > > > > Signed-off-by: Nischal Varide > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 7400d6b4c587..813f4c369dda 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -995,6 +995,10 @@ intel_dp_mode_valid(struct drm_connector *_connector, > > bigjoiner = true; > > max_dotclk *= 2; > > } > > + > > + if (mode->clock > max_dotclk) > > + return -EINVAL; > > + > > The return type of this function is enum drm_mode_status, which > indicates the reason for rejecting the mode. It's not a negative error > code. > > Near the top of the function we have "target_clock = mode->clock;" > making the above identical to the check we already have below. Apart > from the incorrect return code. > > What are you trying to do? > > BR, > Jani. Yes I agree with Jani here that since target_clock is mode->clock we already have that check in place and infact returing MODE_CLOCK_HIGH makes more sense than returning just a -EINVAL What is the purpose of this change? Manasi > > > > if (target_clock > max_dotclk) > > return MODE_CLOCK_HIGH; > > > > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/dsc: Add is_dsc_supported()
On Thu, Nov 03, 2022 at 11:32:22AM +0530, Swati Sharma wrote:
> Lets use RUNTIME_INFO->has_dsc since platforms supporting dsc has this
> flag enabled.
>
> This is done based on the review comments received on
> https://patchwork.freedesktop.org/patch/509393/
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 7 ++-
> drivers/gpu/drm/i915/display/intel_vdsc.h | 2 ++
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7400d6b4c587..eb908da80f2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1012,7 +1012,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>* Output bpp is stored in 6.4 format so right shift by 4 to get the
>* integer value since we support only integer values of bpp.
>*/
> - if (DISPLAY_VER(dev_priv) >= 10 &&
> + if (is_dsc_supported(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> /*
>* TBD pass the connector BPC,
> @@ -2906,7 +2906,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> intel_dp_set_max_sink_lane_count(intel_dp);
>
> /* Read the eDP DSC DPCD registers */
> - if (DISPLAY_VER(dev_priv) >= 10)
> + if (is_dsc_supported(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> /*
> @@ -4691,7 +4691,7 @@ intel_dp_detect(struct drm_connector *connector,
> }
>
> /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
> - if (DISPLAY_VER(dev_priv) >= 11)
> + if (is_dsc_supported(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> intel_dp_configure_mst(intel_dp);
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 269f9792390d..e7c1169538da 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -338,13 +338,18 @@ static const struct rc_parameters *get_rc_params(u16
> compressed_bpp,
> return _parameters[row_index][column_index];
> }
>
> +bool is_dsc_supported(struct drm_i915_private *dev_priv)
> +{
> + return RUNTIME_INFO(dev_priv)->has_dsc;
> +}
> +
> bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
> {
> const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>
> - if (!RUNTIME_INFO(i915)->has_dsc)
> + if (!is_dsc_supported(i915))
> return false;
>
> if (DISPLAY_VER(i915) >= 12)
In Runtime info, Gen 12 should have Gen 11 runtime has dsc set, so makes
this check here redundant.
Manasi
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.h
> b/drivers/gpu/drm/i915/display/intel_vdsc.h
> index 8763f00fa7e2..049e8b95fdde 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.h
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.h
> @@ -12,7 +12,9 @@ enum transcoder;
> struct intel_crtc;
> struct intel_crtc_state;
> struct intel_encoder;
> +struct drm_i915_private;
>
> +bool is_dsc_supported(struct drm_i915_private *dev_priv);
> bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state);
> void intel_uncompressed_joiner_enable(const struct intel_crtc_state
> *crtc_state);
> void intel_dsc_enable(const struct intel_crtc_state *crtc_state);
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Ensure panel granularity aligns with DSC slice height
On Wed, Nov 02, 2022 at 07:45:43PM +0200, Jouni Högander wrote:
> Do not enable psr2 if panel ganularity is not aligned with DSC slice
> height when DSC is enabled
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
>
> Signed-off-by: Jouni Högander
This check against DSC makes sense since we have seen issues otherwise
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index e11b0592055f..57575b5c6d48 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -779,6 +779,7 @@ static bool psr2_granularity_check(struct intel_dp
> *intel_dp,
> struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + const struct drm_dsc_config *vdsc_cfg = _state->dsc.config;
> const int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> const int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> u16 y_granularity = 0;
> @@ -809,6 +810,10 @@ static bool psr2_granularity_check(struct intel_dp
> *intel_dp,
> if (y_granularity == 0 || crtc_vdisplay % y_granularity)
> return false;
>
> + if (crtc_state->dsc.compression_enable &&
> + vdsc_cfg->slice_height % y_granularity)
> + return false;
> +
> crtc_state->su_y_granularity = y_granularity;
> return true;
> }
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH] drm/edid: Parse VRR cap fields from HFVSDB block
On Tue, Oct 18, 2022 at 11:01:48AM +0530, Ankit Nautiyal wrote:
> This patch parses HFVSDB fields for VRR capabilities of an
> HDMI2.1 sink and stores the VRR caps in a new structure in
> drm_hdmi_info.
>
> Signed-off-by: Ankit Nautiyal
Makes sense to add this VRR info to drm_hdmi_info struct and not combine
with DP VRR info struct in display info since hdmi info has other HDMI
cap info stored here.
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/drm_edid.c | 26 --
> include/drm/drm_connector.h | 27 +++
> 2 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 47465b9765f1..bb1f7d899580 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5823,6 +5823,21 @@ static void drm_parse_ycbcr420_deep_color_info(struct
> drm_connector *connector,
> hdmi->y420_dc_modes = dc_mask;
> }
>
> +static void drm_parse_vrr_info(struct drm_hdmi_vrr_cap *hdmi_vrr,
> +const u8 *hf_scds)
> +{
> + if (hf_scds[8] & DRM_EDID_CNMVRR)
> + hdmi_vrr->cnm_vrr = true;
> + if (hf_scds[8] & DRM_EDID_CINEMA_VRR)
> + hdmi_vrr->cinema_vrr = true;
> + if (hf_scds[8] & DRM_EDID_MDELTA)
> + hdmi_vrr->m_delta = true;
> +
> + hdmi_vrr->vrr_min = hf_scds[9] & DRM_EDID_VRR_MIN_MASK;
> + hdmi_vrr->vrr_max = (hf_scds[9] & DRM_EDID_VRR_MAX_UPPER_MASK) << 2;
> + hdmi_vrr->vrr_max |= hf_scds[10] & DRM_EDID_VRR_MAX_LOWER_MASK;
> +}
> +
> static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
> const u8 *hf_scds)
> {
> @@ -5901,9 +5916,11 @@ static void drm_parse_hdmi_forum_scds(struct
> drm_connector *connector,
> struct drm_display_info *display = >display_info;
> struct drm_hdmi_info *hdmi = >hdmi;
> struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
> + struct drm_hdmi_vrr_cap *hdmi_vrr = >vrr_cap;
> int max_tmds_clock = 0;
> u8 max_frl_rate = 0;
> bool dsc_support = false;
> + bool vrr_support = false;
>
> display->has_hdmi_infoframe = true;
>
> @@ -5949,14 +5966,19 @@ static void drm_parse_hdmi_forum_scds(struct
> drm_connector *connector,
>
> drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
>
> + if (cea_db_payload_len(hf_scds) >= 8 && hf_scds[8]) {
> + drm_parse_vrr_info(hdmi_vrr, hf_scds);
> + vrr_support = true;
> + }
> +
> if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
> drm_parse_dsc_info(hdmi_dsc, hf_scds);
> dsc_support = true;
> }
>
> drm_dbg_kms(connector->dev,
> - "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, DSC
> 1.2 support: %s\n",
> - max_tmds_clock, str_yes_no(max_frl_rate),
> str_yes_no(dsc_support));
> + "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, VRR
> support: %s, DSC 1.2 support: %s\n",
> + max_tmds_clock, str_yes_no(max_frl_rate),
> str_yes_no(vrr_support), str_yes_no(dsc_support));
> }
>
> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b1b2df48d42c..ec6ef71ab5cd 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -219,6 +219,30 @@ struct drm_hdmi_dsc_cap {
> u8 total_chunk_kbytes;
> };
>
> +
> +/**
> + * struct drm_hdmi_vrr_cap - VRR capabilities of HDMI sink
> + * Describes the VRR support provided by HDMI 2.1 sink.
> + * The information is fetched fom additional HFVSDB blocks defined
> + * for HDMI 2.1.
> + */
> +struct drm_hdmi_vrr_cap {
> + /** @cnm_vrr: sink supports negative Mvrr values*/
> + bool cnm_vrr;
> +
> + /** @cinema_vrr: sink supports fractional and integer media rates <
> VRRmin*/
> + bool cinema_vrr;
> +
> + /** @m_delta: sink can anticipate and compensate for frame-to-frame
> variation in Mvrr */
> + bool m_delta;
> +
> + /** @vrr_min: VRRmin - lowest framerate in Hz that sink can support in
> VRR */
> + u8 vrr_min;
> +
> + /** @vrr_max: VRRmax - highest framerate in Hz that sink can support in
> VRR */
> + u16 vrr_max;
> +};
> +
> /**
> * struct drm_hdmi_info - runtime information about the connected HDMI sink
> *
> @@ -259,6 +283,9 @@ struct drm_hdmi_info {
>
> /** @dsc_cap: DSC capabilities of the sink */
> struct drm_hdmi_dsc_cap dsc_cap;
> +
> + /** @vrr_cap: VRR capabilities of the sink */
> + struct drm_hdmi_vrr_cap vrr_cap;
> };
>
> /**
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH] drm/i915/hdmi: Prune Interlaced modes for Display >= 12
On Thu, Oct 13, 2022 at 10:41:24AM +0530, Ankit Nautiyal wrote: > Defeature Display Interlace support. > Support for Interlace modes is removed from Gen 12 onwards. > For DP we do not support interlace modes (except for very old > platforms). Pruning the interlaced modes for HDMI for Display >=12. > Bspec: 50490 > > Signed-off-by: Ankit Nautiyal Looks good to me Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/i915/display/intel_hdmi.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c > b/drivers/gpu/drm/i915/display/intel_hdmi.c > index 93519fb23d9d..791bfb062c49 100644 > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > @@ -1990,6 +1990,9 @@ intel_hdmi_mode_valid(struct drm_connector *connector, > if (mode->flags & DRM_MODE_FLAG_DBLSCAN) > return MODE_NO_DBLESCAN; > > + if (DISPLAY_VER(dev_priv) >= 12 && mode->flags & > DRM_MODE_FLAG_INTERLACE) > + return MODE_NO_INTERLACE; > + > if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == > DRM_MODE_FLAG_3D_FRAME_PACKING) > clock *= 2; > > @@ -2247,6 +2250,10 @@ int intel_hdmi_compute_config(struct intel_encoder > *encoder, > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) > return -EINVAL; > > + if (DISPLAY_VER(dev_priv) >= 12 && > + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) > + return -EINVAL; > + > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; > pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi, >conn_state); > @@ -2956,7 +2963,9 @@ void intel_hdmi_init_connector(struct > intel_digital_port *dig_port, > ddc); > drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); > > - connector->interlace_allowed = true; > + if (DISPLAY_VER(dev_priv) < 12) > + connector->interlace_allowed = true; > + > connector->stereo_allowed = true; > > if (DISPLAY_VER(dev_priv) >= 10) > -- > 2.25.1 >
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk config values
On Mon, Sep 19, 2022 at 05:10:47PM -0400, Rodrigo Vivi wrote:
> On Mon, Sep 19, 2022 at 12:46:45PM -0700, Navare, Manasi wrote:
> > On Fri, Sep 16, 2022 at 05:44:04PM -0700, Anusha Srivatsa wrote:
> > > Add a helper function to get stringify values of the
> > > desired cdclk action and dump it with rest of the
> > > cdclk config values
> > >
> > > Signed-off-by: Anusha Srivatsa
> >
> > Please add Suggested-by: field to give proper credits as per our
> > discussion. This applies to other patches as well to add proper credits
> > to other folks who suggested design changes/ fixes.
> > This needs to be followed as per the upstream patch review methodology.
>
> Having the suggested by is a good way to give the proper credits when the
> whole
> big idea and design was co authored, or started by the other developer.
>
> We really need to mind about it. However it is not a very good thing for all
> of the patches we have. Many ideas come out of conversation with many folks
> and we cannot simply start adding the suggested by list with all the names
> involved.
>
> There's always a threshold there that we should mind. And the official rule
> as reference is this one:
>
> "A Suggested-by: tag indicates that the patch idea is suggested by the person
> named and ensures credit to the person for the idea. Please note that this tag
> should not be added without the reporter’s permission, especially if the idea
> was not posted in a public forum." [1]
>
> As a reference we don't keep adding official suggested-by tags for any and all
> of the suggestions we receive during reviews. The simple name version in the
> commit message is what we traditionally uses for small things.
Thanks Rodrigo for the inputs. I agree with you in terms of not having
this for all patches. But particularly this patch was a suggestion that
came up through our offline discussion.
And in cases like this it is a good idea to be mindful about and give
respectful credits. For internal folks its not a big deal, but
Just want to make sure we dont lose the credibility in the community if
this is missed for external folks. People do spend time reviewing and
suggesting and improving codebase so it is good to be respectful and add
the tags for patches that are entirely someone else's suggestion.
Manasi
>
> Looking to the history of this series here I see that this patch looks like
> an evolution of the previous series with small increment and suggestions from
> multiple folks. Not sure if it is really worthwhile to have to add the
> official
> tag and start to ping everyone to get the ack if it is okay or not to add it.
>
> [1] -
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
>
> >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 18 --
> > > 1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index bc627daade3e..12f5e4d23245 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1688,6 +1688,19 @@ static u32 cdclk_squash_waveform(struct
> > > drm_i915_private *dev_priv,
> > >
> > > return 0x;
> > > }
> >
> > Missing newline causing checkpatch error
> >
> > Manasi
> >
> > > +static const char *cdclk_sequence_to_string(enum cdclk_sequence
> > > cdclk_sequence)
> > > +{
> > > + switch (cdclk_sequence) {
> > > + case CDCLK_SQUASH_ONLY:
> > > + return "Squash only";
> > > + case CDCLK_CRAWL_ONLY:
> > > + return "Crawl only";
> > > + case CDCLK_LEGACY:
> > > + return "Legacy method";
> > > + default:
> > > + return "Not a valid cdclk sequence";
> > > + }
> > > +}
> > >
> > > static void dg2_prog_squash_ctl(struct drm_i915_private *i915, u16
> > > waveform)
> > > {
> > > @@ -2083,10 +2096,11 @@ void intel_cdclk_dump_config(struct
> > > drm_i915_private *i915,
> > >const struct intel_cdclk_config *cdclk_config,
> > >const char *context)
> > > {
> > > - drm_dbg_kms(>drm, "%s %d kHz, VCO %d kHz, ref %d kHz, bypass %d
> > > kHz, voltage level %d\n",
> > > + drm_dbg_kms(>drm, "%s %d kHz, VCO %d kHz, ref %d kHz, bypass %d
> > > kHz, voltage level %d, %s action\n",
> > > context, cdclk_config->cdclk, cdclk_config->vco,
> > > cdclk_config->ref, cdclk_config->bypass,
> > > - cdclk_config->voltage_level);
> > > + cdclk_config->voltage_level,
> > > + cdclk_sequence_to_string(cdclk_config->steps->action));
> > > }
> > >
> > > /**
> > > --
> > > 2.25.1
> > >
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
Please find the review commenst for the respective patches. Also as a general rule, please add/ copy all folks nvolved in offline discussions/ triage help in order to accelerate reviews and get feedback from all. Manasi On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > This is a prep series for the actual cdclk refactoring > that will be sent following this. Idea is to have a > struct - cdclk_step that holds the following: > - cdclk action (squash, crawl or modeset) > - cdclk frequency > which gets populated in atomic check. Driver > uses the populated values during atomic commit > to do the suitable sequence of actions like > programming squash ctl registers in case of squashing > or PLL sequence incase of modeset and so on. > > This series just addresses the initial idea. The actual plumming > in the atomic commit phase will be sent shortly. > > Cc: Ville Syrjälä > Cc: Uma Shankar > Cc: Rodrigo Vivi > > Anusha Srivatsa (6): > drm/i915/display Add dg2_prog_squash_ctl() helper > drm/i915/display: add cdclk action struct to cdclk_config > drm/i915/display: Embed the new struct steps for squashing > drm/i915/display: Embed the new struct steps for crawling > drm/i915/display: Embed the new struct steps for modeset > drm/i915/display: Dump the new cdclk config values > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 +- > drivers/gpu/drm/i915/display/intel_cdclk.h | 16 - > 2 files changed, 74 insertions(+), 19 deletions(-) > > -- > 2.25.1 >
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk config values
On Fri, Sep 16, 2022 at 05:44:04PM -0700, Anusha Srivatsa wrote:
> Add a helper function to get stringify values of the
> desired cdclk action and dump it with rest of the
> cdclk config values
>
> Signed-off-by: Anusha Srivatsa
Please add Suggested-by: field to give proper credits as per our
discussion. This applies to other patches as well to add proper credits
to other folks who suggested design changes/ fixes.
This needs to be followed as per the upstream patch review methodology.
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index bc627daade3e..12f5e4d23245 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1688,6 +1688,19 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
>
> return 0x;
> }
Missing newline causing checkpatch error
Manasi
> +static const char *cdclk_sequence_to_string(enum cdclk_sequence
> cdclk_sequence)
> +{
> + switch (cdclk_sequence) {
> + case CDCLK_SQUASH_ONLY:
> + return "Squash only";
> + case CDCLK_CRAWL_ONLY:
> + return "Crawl only";
> + case CDCLK_LEGACY:
> + return "Legacy method";
> + default:
> + return "Not a valid cdclk sequence";
> + }
> +}
>
> static void dg2_prog_squash_ctl(struct drm_i915_private *i915, u16 waveform)
> {
> @@ -2083,10 +2096,11 @@ void intel_cdclk_dump_config(struct drm_i915_private
> *i915,
>const struct intel_cdclk_config *cdclk_config,
>const char *context)
> {
> - drm_dbg_kms(>drm, "%s %d kHz, VCO %d kHz, ref %d kHz, bypass %d
> kHz, voltage level %d\n",
> + drm_dbg_kms(>drm, "%s %d kHz, VCO %d kHz, ref %d kHz, bypass %d
> kHz, voltage level %d, %s action\n",
> context, cdclk_config->cdclk, cdclk_config->vco,
> cdclk_config->ref, cdclk_config->bypass,
> - cdclk_config->voltage_level);
> + cdclk_config->voltage_level,
> + cdclk_sequence_to_string(cdclk_config->steps->action));
> }
>
> /**
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH 3/6] drm/i915/display: Embed the new struct steps for squashing
On Mon, Sep 19, 2022 at 12:27:55PM +0300, Jani Nikula wrote:
> On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> > Populate the new struct steps for squash case.
> >
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 220d32adbd12..d2e81134b6f2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1973,8 +1973,9 @@ static bool intel_cdclk_can_crawl(struct
> > drm_i915_private *dev_priv,
> >
> > static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
> >const struct intel_cdclk_config *a,
> > - const struct intel_cdclk_config *b)
> > + struct intel_cdclk_config *b)
>
> Why are you dropping const?
>
> > {
> > + struct cdclk_step *cdclk_transition = b->steps;
>
> The type name has step, the array is named steps, why is the variable
> "transition"?
Yes I agree that the name cdclk_tranistion is confusing rather having
cdclk_transition is unnecessary.
Why cant you directly access b->steps->action, b->steps->cdclk
Manasi
>
> > /*
> > * FIXME should store a bit more state in intel_cdclk_config
> > * to differentiate squasher vs. cd2x divider properly. For
> > @@ -1984,6 +1985,12 @@ static bool intel_cdclk_can_squash(struct
> > drm_i915_private *dev_priv,
> > if (!has_cdclk_squasher(dev_priv))
> > return false;
> >
> > + if (a->cdclk != b->cdclk && a->vco != 0 &&
> > + a->vco == b->vco && a->ref == b->ref) {
> > + cdclk_transition->action = CDCLK_SQUASH_ONLY;
> > + cdclk_transition->cdclk = b->cdclk;
> > + }
> > +
> > return a->cdclk != b->cdclk &&
> > a->vco != 0 &&
> > a->vco == b->vco &&
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/6] drm/i915/display: add cdclk action struct to cdclk_config
On Mon, Sep 19, 2022 at 12:26:19PM +0300, Jani Nikula wrote:
> On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> > The struct has the action to be performed - squash, crawl
> > or modeset and the corresponding cdclk which is the desired
> > cdclk. This is the structure that gets populated during
> > atomic check once it is determined what the cdclk change looks
> > like
> >
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.h | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > index c674879a84a5..3869f93e8ad2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > @@ -11,13 +11,27 @@
> > #include "intel_display.h"
> > #include "intel_global_state.h"
> >
> > +#defineMAX_CDCLK_ACTIONS 1
>
> Okay, this review is just nitpicks, but they'll need to get fixed
> eventually so here goes.
>
> No tab after #define.
>
> > +
> > struct drm_i915_private;
> > struct intel_atomic_state;
> > struct intel_crtc_state;
> >
> > +enum cdclk_sequence {
>
> Needs to be named intel_ something.
Agree here
>
> > + CDCLK_INVALID_ACTION = -1,
> > +
> > + CDCLK_SQUASH_ONLY = 0,
> > + CDCLK_CRAWL_ONLY,
> > + CDCLK_LEGACY,
> > +};
> > +
> > struct intel_cdclk_config {
> > unsigned int cdclk, vco, ref, bypass;
> > u8 voltage_level;
> > + struct cdclk_step {
>
> Needs to be named intel_ something.
>
> Since this is used independently, I'd prefer it to be defined outside of
> struct intel_cdclk_config.
I think the point of having it as part of intel_cdclk_config is that
because we already pass cdclk_config to set_cdclk where these actions
are going to get used.
Manasi
>
> > + enum cdclk_sequence action;
> > + u32 cdclk;
> > + } steps[MAX_CDCLK_ACTIONS];
> > };
> >
> > struct intel_cdclk_state {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/4] drm/i915/squash: s/intel_cdclk_can_squash/intel_cdclk_squash
On Fri, Aug 19, 2022 at 05:58:20PM -0700, Anusha Srivatsa wrote:
> Apart from checking if squashing can be performed,
> accommodate accessing in-flight cdclk state for any changes
> that are needed during commit phase.
>
> v2: Move squashing bits to switch case.(Anusha)
>
> Cc: Jani Nikula
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 62 ++
> 1 file changed, 40 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 86a22c3766e5..f98fd48fe905 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1693,12 +1693,18 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> {
> + struct intel_cdclk_state *cdclk_state =
> to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> + struct intel_atomic_state *state = cdclk_state->base.state;
> + struct intel_cdclk_state *new_cdclk_state =
> intel_atomic_get_new_cdclk_state(state);
This will not work, make cdclk steps as part of cdlck_config struct and
access that through the passed cdclk_config
This already gets passed from the calling function intel_set_cdclk()
which is getting called from intel_set_cdclk_post_plane_update() from
commit_tail()
This is the correct way of programming req HW registers from cdclk state
Manasi
> + struct cdclk_step *cdclk_steps = new_cdclk_state->steps;
> int cdclk = cdclk_config->cdclk;
> int vco = cdclk_config->vco;
> + u32 squash_ctl = 0;
> u32 val;
> u16 waveform;
> int clock;
> int ret;
> + int i;
>
> /* Inform power controller of upcoming frequency change. */
> if (DISPLAY_VER(dev_priv) >= 11)
> @@ -1742,21 +1748,27 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
>
> waveform = cdclk_squash_waveform(dev_priv, cdclk);
>
> - if (waveform)
> + if (waveform && has_cdclk_squasher(dev_priv)) {
> clock = vco / 2;
> - else
> + for (i = 0; i < MAX_CDCLK_ACTIONS; i++) {
> + switch (cdclk_steps[i].action) {
> + case INTEL_CDCLK_SQUASH:
> + waveform = cdclk_squash_waveform(dev_priv,
> cdclk_steps[i].cdclk);
> + squash_ctl = CDCLK_SQUASH_ENABLE |
> + CDCLK_SQUASH_WINDOW_SIZE(0xf) |
> waveform;
> + intel_de_write(dev_priv, CDCLK_SQUASH_CTL,
> squash_ctl);
> + break;
> + case INTEL_CDCLK_NOOP:
> + case INTEL_CDCLK_CRAWL:
> + case INTEL_CDCLK_MODESET:
> + break;
> + default:
> + break;
> + }
> + }
> + } else
> clock = cdclk;
>
> - if (has_cdclk_squasher(dev_priv)) {
> - u32 squash_ctl = 0;
> -
> - if (waveform)
> - squash_ctl = CDCLK_SQUASH_ENABLE |
> - CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
> -
> - intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
> - }
> -
> val = bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) |
> bxt_cdclk_cd2x_pipe(dev_priv, pipe) |
> skl_cdclk_decimal(cdclk);
> @@ -1966,10 +1978,11 @@ static bool intel_cdclk_can_crawl(struct
> drm_i915_private *dev_priv,
> a->ref == b->ref;
> }
>
> -static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
> -const struct intel_cdclk_config *a,
> -const struct intel_cdclk_config *b)
> +static bool intel_cdclk_squash(struct drm_i915_private *dev_priv,
> +const struct intel_cdclk_state *a,
> +struct intel_cdclk_state *b)
> {
> + struct cdclk_step *cdclk_transition = b->steps;
> /*
>* FIXME should store a bit more state in intel_cdclk_config
>* to differentiate squasher vs. cd2x divider properly. For
> @@ -1978,11 +1991,16 @@ static bool intel_cdclk_can_squash(struct
> drm_i915_private *dev_priv,
>*/
> if (!has_cdclk_squasher(dev_priv))
> return false;
> +
> + cdclk_transition[0].action = INTEL_CDCLK_SQUASH;
> + cdclk_transition[0].cdclk = b->actual.cdclk;
> + cdclk_transition[1].action = INTEL_CDCLK_NOOP;
> + cdclk_transition[1].cdclk = b->actual.cdclk;
>
> - return a->cdclk != b->cdclk &&
> - a->vco != 0 &&
> - a->vco == b->vco &&
> - a->ref == b->ref;
> + return a->actual.cdclk != b->actual.cdclk &&
> + a->actual.vco != 0
Re: [Intel-gfx] [PATCH 1/4] drm/i915/display: Add CDCLK actions to intel_cdclk_state
On Fri, Aug 19, 2022 at 05:58:19PM -0700, Anusha Srivatsa wrote:
> This is a prep patch for what the rest of the series does.
>
> Add existing actions that change cdclk - squash, crawl, modeset to
> intel_cdclk_state so we have access to the cdclk values
> that are in transition.
>
> Cc: Jani Nikula
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index b535cf6a7d9e..43835688ee02 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -15,6 +15,14 @@ struct drm_i915_private;
> struct intel_atomic_state;
> struct intel_crtc_state;
>
> +enum cdclk_actions {
> + INTEL_CDCLK_MODESET = 0,
> + INTEL_CDCLK_SQUASH,
> + INTEL_CDCLK_CRAWL,
> + INTEL_CDCLK_NOOP,
> + MAX_CDCLK_ACTIONS
> +};
> +
> struct intel_cdclk_config {
> unsigned int cdclk, vco, ref, bypass;
> u8 voltage_level;
> @@ -51,6 +59,11 @@ struct intel_cdclk_state {
>
> /* bitmask of active pipes */
> u8 active_pipes;
> +
> + struct cdclk_step {
> + enum cdclk_actions action;
> + u32 cdclk;
> + } steps[MAX_CDCLK_ACTIONS];
If this is what you need to access later in bxt_set_cdclk , you needto
add this to intel_cdclk_config which is then part of cdclk_state and
that is what will get programmed in atomic_check and it gets sent to
bxt_set_cdclk in atomic_commit_tail.
This is the way ypu can access it in bxt_set_cdclk, you cannot access
the new_cdclk_state there, you need to use cdclk_config that is already
getting passed to it
Manasi
> };
>
> int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state);
> --
> 2.25.1
>
Re: [Intel-gfx] [v2][PATCH 1/1] drm/i915/dsc: convert dsc debugfs entry from output_bpp to input_bpc
On Sat, Sep 03, 2022 at 12:36:58AM +0530, Swati Sharma wrote:
> Convert dsc debugfs entry from output_bpp to input_bpc. The rationale
> is to validate different input bpc across various platforms.
>
> v2: -improved commit message (Jani N)
> -styling fixes (Jani N)
>
> Signed-off-by: Swati Sharma
Thanks for the patch Swati.
This makes sense to test different input bpcs from IGT rather than
forcing compressed bpp so that we leave the proper compressed bpp
calculation to the driver which is the right way.
Make sure this patch and corresponding IGT change gets merged at the
same time else IGT will throw err
Reviewed-by: Manasi Navare
Manasi
> ---
> .../drm/i915/display/intel_display_debugfs.c | 27 +--
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 21 ---
> 3 files changed, 19 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 5dc364e9db49..0bd916fd9fec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2140,7 +2140,7 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> .write = i915_dsc_fec_support_write
> };
>
> -static int i915_dsc_bpp_show(struct seq_file *m, void *data)
> +static int i915_dsc_bpc_show(struct seq_file *m, void *data)
> {
> struct drm_connector *connector = m->private;
> struct drm_device *dev = connector->dev;
> @@ -2163,14 +2163,14 @@ static int i915_dsc_bpp_show(struct seq_file *m, void
> *data)
> }
>
> crtc_state = to_intel_crtc_state(crtc->state);
> - seq_printf(m, "Compressed_BPP: %d\n", crtc_state->dsc.compressed_bpp);
> + seq_printf(m, "Input_BPC: %d\n",
> crtc_state->dsc.config.bits_per_component);
>
> out: drm_modeset_unlock(>mode_config.connection_mutex);
>
> return ret;
> }
>
> -static ssize_t i915_dsc_bpp_write(struct file *file,
> +static ssize_t i915_dsc_bpc_write(struct file *file,
> const char __user *ubuf,
> size_t len, loff_t *offp)
> {
> @@ -2178,33 +2178,32 @@ static ssize_t i915_dsc_bpp_write(struct file *file,
> ((struct seq_file *)file->private_data)->private;
> struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - int dsc_bpp = 0;
> + int dsc_bpc = 0;
> int ret;
>
> - ret = kstrtoint_from_user(ubuf, len, 0, _bpp);
> + ret = kstrtoint_from_user(ubuf, len, 0, _bpc);
> if (ret < 0)
> return ret;
>
> - intel_dp->force_dsc_bpp = dsc_bpp;
> + intel_dp->force_dsc_bpc = dsc_bpc;
> *offp += len;
>
> return len;
> }
>
> -static int i915_dsc_bpp_open(struct inode *inode,
> +static int i915_dsc_bpc_open(struct inode *inode,
>struct file *file)
> {
> - return single_open(file, i915_dsc_bpp_show,
> -inode->i_private);
> + return single_open(file, i915_dsc_bpc_show, inode->i_private);
> }
>
> -static const struct file_operations i915_dsc_bpp_fops = {
> +static const struct file_operations i915_dsc_bpc_fops = {
> .owner = THIS_MODULE,
> - .open = i915_dsc_bpp_open,
> + .open = i915_dsc_bpc_open,
> .read = seq_read,
> .llseek = seq_lseek,
> .release = single_release,
> - .write = i915_dsc_bpp_write
> + .write = i915_dsc_bpc_write
> };
>
> /*
> @@ -2274,8 +2273,8 @@ void intel_connector_debugfs_add(struct intel_connector
> *intel_connector)
> debugfs_create_file("i915_dsc_fec_support", 0644, root,
> connector, _dsc_fec_support_fops);
>
> - debugfs_create_file("i915_dsc_bpp", 0644, root,
> - connector, _dsc_bpp_fops);
> + debugfs_create_file("i915_dsc_bpc", 0644, root,
> + connector, _dsc_bpc_fops);
> }
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0da9b208d56e..dbda845030bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1712,7 +1712,7 @@ struct intel_dp {
Re: [Intel-gfx] [PATCH 03/11] drm/edid: s/monitor_rage/vrr_range/
On Sat, Aug 27, 2022 at 12:34:53AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename info->monitor_range to info->vrr_range to actually
> reflect its usage.
Okay makes sense.
Reviewed-by: Manasi Navare
Manasi
>
> Cc: Manasi Navare
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 -
> drivers/gpu/drm/drm_debugfs.c | 4 +--
> drivers/gpu/drm/drm_edid.c| 26 +--
> drivers/gpu/drm/i915/display/intel_vrr.c | 6 ++---
> include/drm/drm_connector.h | 4 +--
> 5 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e702f0d72d53..928b5b6541db 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9921,8 +9921,8 @@ void amdgpu_dm_update_freesync_caps(struct
> drm_connector *connector,
> amdgpu_dm_connector->min_vfreq = 0;
> amdgpu_dm_connector->max_vfreq = 0;
> amdgpu_dm_connector->pixel_clock_mhz = 0;
> - connector->display_info.monitor_range.min_vfreq = 0;
> - connector->display_info.monitor_range.max_vfreq = 0;
> + connector->display_info.vrr_range.min_vfreq = 0;
> + connector->display_info.vrr_range.max_vfreq = 0;
> freesync_capable = false;
>
> goto update;
> @@ -9970,8 +9970,8 @@ void amdgpu_dm_update_freesync_caps(struct
> drm_connector *connector,
> amdgpu_dm_connector->pixel_clock_mhz =
> range->pixel_clock_mhz * 10;
>
> - connector->display_info.monitor_range.min_vfreq
> = range->min_vfreq;
> - connector->display_info.monitor_range.max_vfreq
> = range->max_vfreq;
> + connector->display_info.vrr_range.min_vfreq =
> range->min_vfreq;
> + connector->display_info.vrr_range.max_vfreq =
> range->max_vfreq;
>
> break;
> }
> @@ -9993,8 +9993,8 @@ void amdgpu_dm_update_freesync_caps(struct
> drm_connector *connector,
> if (amdgpu_dm_connector->max_vfreq -
> amdgpu_dm_connector->min_vfreq > 10)
> freesync_capable = true;
>
> - connector->display_info.monitor_range.min_vfreq =
> vsdb_info.min_refresh_rate_hz;
> - connector->display_info.monitor_range.max_vfreq =
> vsdb_info.max_refresh_rate_hz;
> + connector->display_info.vrr_range.min_vfreq =
> vsdb_info.min_refresh_rate_hz;
> + connector->display_info.vrr_range.max_vfreq =
> vsdb_info.max_refresh_rate_hz;
> }
> }
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 01ee3febb813..1437c798b122 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -377,8 +377,8 @@ static int vrr_range_show(struct seq_file *m, void *data)
> if (connector->status != connector_status_connected)
> return -ENODEV;
>
> - seq_printf(m, "Min: %u\n",
> connector->display_info.monitor_range.min_vfreq);
> - seq_printf(m, "Max: %u\n",
> connector->display_info.monitor_range.max_vfreq);
> + seq_printf(m, "Min: %u\n", connector->display_info.vrr_range.min_vfreq);
> + seq_printf(m, "Max: %u\n", connector->display_info.vrr_range.max_vfreq);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ac662495635c..4355d73632c3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6020,11 +6020,11 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> }
>
> static
> -void get_monitor_range(const struct detailed_timing *timing, void *c)
> +void get_vrr_range(const struct detailed_timing *timing, void *c)
> {
> struct detailed_mode_closure *closure = c;
> struct drm_display_info *info = >connector->display_info;
> - struct drm_monitor_range_info *monitor_range = >monitor_range;
> + struct drm_monitor_range_info *vrr_range = >vrr_range;
> const struct
Re: [Intel-gfx] [PATCH 02/11] drm/edid: Clarify why we only accept the "range limits only" descriptor
On Sat, Aug 27, 2022 at 12:34:52AM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > The current comment fails to clarify why we only accept > the "range limits only" variant of the range descriptor. > Reword it to make some actual sense. > Thanks Ville for adding this description for monitor_range Reviewed-by: Manasi Navare Manasi > Cc: Manasi Navare > Cc: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: amd-...@lists.freedesktop.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_edid.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 4005dab6147d..ac662495635c 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -6033,10 +6033,13 @@ void get_monitor_range(const struct detailed_timing > *timing, void *c) > return; > > /* > - * Check for flag range limits only. If flag == 1 then > - * no additional timing information provided. > - * Default GTF, GTF Secondary curve and CVT are not > - * supported > + * These limits are used to determine the VRR refresh > + * rate range. Only the "range limits only" variant > + * of the range descriptor seems to guarantee that > + * any and all timings are accepted by the sink, as > + * opposed to just timings conforming to the indicated > + * formula (GTF/GTF2/CVT). Thus other variants of the > + * range descriptor are not accepted here. >*/ > if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG) > return; > -- > 2.35.1 >
Re: [Intel-gfx] [PATCH 01/11] drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets
On Sat, Aug 27, 2022 at 12:34:51AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> EDID 1.4 introduced some extra flags in the range
> descriptor to support min/max h/vfreq >= 255. Consult them
> to correctly parse the vfreq limits.
>
> Note that some combinations of the flags are documented
> as "reserved" (as are some other values in the descriptor)
> but explicitly checking for those doesn't seem particularly
> worthwile since we end up with bogus results whether we
> decode them or not.
>
> v2: Increase the storage to u16 to make it work (Jani)
> Note the "reserved" values situation (Jani)
> v3: Document the EDID version number in the defines
> Drop some bogus (u8) casts
>
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
> Reviewed-by: Jani Nikula
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_debugfs.c | 4 ++--
> drivers/gpu/drm/drm_edid.c| 24 ++--
> include/drm/drm_connector.h | 4 ++--
> include/drm/drm_edid.h| 5 +
> 4 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 493922069c90..01ee3febb813 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -377,8 +377,8 @@ static int vrr_range_show(struct seq_file *m, void *data)
> if (connector->status != connector_status_connected)
> return -ENODEV;
>
> - seq_printf(m, "Min: %u\n",
> (u8)connector->display_info.monitor_range.min_vfreq);
> - seq_printf(m, "Max: %u\n",
> (u8)connector->display_info.monitor_range.max_vfreq);
> + seq_printf(m, "Min: %u\n",
> connector->display_info.monitor_range.min_vfreq);
> + seq_printf(m, "Max: %u\n",
> connector->display_info.monitor_range.max_vfreq);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 90a5e26eafa8..4005dab6147d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6020,12 +6020,14 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> }
>
> static
> -void get_monitor_range(const struct detailed_timing *timing,
> -void *info_monitor_range)
> +void get_monitor_range(const struct detailed_timing *timing, void *c)
> {
> - struct drm_monitor_range_info *monitor_range = info_monitor_range;
> + struct detailed_mode_closure *closure = c;
> + struct drm_display_info *info = >connector->display_info;
> + struct drm_monitor_range_info *monitor_range = >monitor_range;
> const struct detailed_non_pixel *data = >data.other_data;
> const struct detailed_data_monitor_range *range = >data.range;
> + const struct edid *edid = closure->drm_edid->edid;
>
> if (!is_display_descriptor(timing, EDID_DETAIL_MONITOR_RANGE))
> return;
> @@ -6041,18 +6043,28 @@ void get_monitor_range(const struct detailed_timing
> *timing,
>
> monitor_range->min_vfreq = range->min_vfreq;
> monitor_range->max_vfreq = range->max_vfreq;
> +
> + if (edid->revision >= 4) {
> + if (data->pad2 & DRM_EDID_RANGE_OFFSET_MIN_VFREQ)
> + monitor_range->min_vfreq += 255;
> + if (data->pad2 & DRM_EDID_RANGE_OFFSET_MAX_VFREQ)
> + monitor_range->max_vfreq += 255;
Yes this makes sense. This looks like added for supporting HRR (high
refresh rate) panels.
Do you think we should mention that in the commit message or in the
comment in the code itself?
Other than that looks good to me:
Reviewed-by: Manasi Navare
Manasi
> + }
> }
>
> static void drm_get_monitor_range(struct drm_connector *connector,
> const struct drm_edid *drm_edid)
> {
> - struct drm_display_info *info = >display_info;
> + const struct drm_display_info *info = >display_info;
> + struct detailed_mode_closure closure = {
> + .connector = connector,
> + .drm_edid = drm_edid,
> + };
>
> if (!version_greater(drm_edid, 1, 1))
> return;
>
> - drm_for_each_detailed_block(drm_edid, get_monitor_range,
> - >monitor_range);
> + drm_for_each_detailed_block(drm_edid, get_monitor_range, );
>
> DRM_DEBUG_KMS("Supported Monitor Refresh rate range is %d Hz - %d Hz\n",
> info->monitor_range.min_vfreq,
> diff --git a/include/drm/drm_connector.h b/in
Re: [Intel-gfx] [PATCH 0/2] Add DP MST DSC support to i915
On Thu, Aug 11, 2022 at 10:33:51AM +0300, Lisovskiy, Stanislav wrote: > On Wed, Aug 10, 2022 at 04:02:08PM -0400, Lyude Paul wrote: > > Btw, what's the plan for this? Figured I'd ask since I noticed this on the > > ML, > > nd I'm now finishing up getting the atomic only MST patches I've been > > working > > on merged :) > > Current plan is that I need to fix this, as current implementation doesn't > seem to work because of my wrong assumption that drm_dp_mst_find_vcpi_slots > will fail if no slots are available and then we can fallback to DSC. > > In reality that function can return whatever bogus value it wants, like > 71 slots, while you have only 63 available. The real check is done in > drm_dp_mst_atomic_check, which would of course reject that configuration, > however by that moment its going to be too late for swithcing to DSC. > > So looke like I will have to move that check at least partly to where DSC/no > DSC decision is done. However if there are multiple displays we get > another problem, lets say we have 2 displays requiring 40 vcpi slots each in > DSC > mode with certain input bpp. > We have now either option to reject the whole config or go back and try with > another bpp to check if we can reduce amount of slots. > Because by default we choose the first one which fits, however by the time > when > compute_config is called, we still don't have all config computed, which might > lead to that last crtc can either run our of vcpi slots or we will have to > go back and try recalculating with higher compression ratio. > > My other question was that DSC was supposed to be "visually" lossless, > wondering > why we are still trying with different bpps? Could have just set highest > compression ratio right away. We do want to still maintain as high pic quality as possible. So we try to find out the min compression ration that will make the mode fit into the available link BW. Manasi > > So need to sort this out first before floating new series. > > Stan > > > > > On Wed, 2022-08-10 at 11:17 +0300, Stanislav Lisovskiy wrote: > > > Currently we have only DSC support for DP SST. > > > > > > Stanislav Lisovskiy (2): > > > drm: Add missing DP DSC extended capability definitions. > > > drm/i915: Add DSC support to MST path > > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 76 +- > > > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++ > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 145 > > > include/drm/display/drm_dp.h| 10 +- > > > 4 files changed, 203 insertions(+), 45 deletions(-) > > > > > > > -- > > Cheers, > > Lyude Paul (she/her) > > Software Engineer at Red Hat > >
Re: [Intel-gfx] [RFC V3 2/2] drm/i915/vrr: Set drm crtc vrr_enabled property
On Tue, May 17, 2022 at 12:56:36PM +0530, Bhanuprakash Modem wrote: > This function sets the vrr_enabled property for crtc based > on the platform support and the request from userspace. > > V2: Check for platform support before updating the prop. > V3: Don't attach vrr_enabled prop, as it is alreay attached. > > Cc: Ville Syrjälä > Cc: Manasi Navare > Signed-off-by: Bhanuprakash Modem > --- > drivers/gpu/drm/i915/display/intel_vrr.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c > b/drivers/gpu/drm/i915/display/intel_vrr.c > index 396f2f994fa0..7263b35550de 100644 > --- a/drivers/gpu/drm/i915/display/intel_vrr.c > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c > @@ -160,6 +160,10 @@ void intel_vrr_enable(struct intel_encoder *encoder, > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; > u32 trans_vrr_ctl; > > + if (HAS_VRR(dev_priv)) > + drm_mode_crtc_set_vrr_enabled_property(crtc_state->uapi.crtc, > +crtc_state->vrr.enable); But here if userspace has accidently set the CRTC vrr enabled prop to true without cheking VRR capabile prop, this will be true and here the driver will still not reset it. If that is the purpose of adding this then we should infact set this to false if !HAS_VRR Manasi > + > if (!crtc_state->vrr.enable) > return; > > @@ -211,6 +215,10 @@ void intel_vrr_disable(const struct intel_crtc_state > *old_crtc_state) > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); > enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder; > > + if (HAS_VRR(dev_priv)) > + > drm_mode_crtc_set_vrr_enabled_property(old_crtc_state->uapi.crtc, > +false); > + > if (!old_crtc_state->vrr.enable) > return; > > -- > 2.35.1 >
Re: [Intel-gfx] [RFC V3 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc
On Tue, May 17, 2022 at 12:56:35PM +0530, Bhanuprakash Modem wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces helpers to attach and set "vrr_enabled" property
> on the crtc to allow userspace to query VRR enabled status on that crtc.
>
> Atomic drivers should attach this property to crtcs those are capable of
> driving variable refresh rates using
> drm_mode_crtc_attach_vrr_enabled_property().
We are not attaching the prop anymore, please remove this from the
commit message.
>
> The value should be updated based on driver and hardware capability
> by using drm_mode_crtc_set_vrr_enabled_property().
>
> V2: Use property flag as atomic
> V3: Drop helper to attach vrr_enabled prop, since it is already
> attached (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Nicholas Kazlauskas
> Cc: Manasi Navare
> Cc: Harry Wentland
> Signed-off-by: Bhanuprakash Modem
> ---
> drivers/gpu/drm/drm_crtc.c| 26 ++
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> include/drm/drm_crtc.h| 3 +++
> 3 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 26a77a735905..8bb8b4bf4199 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -239,6 +239,9 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc
> *crtc)
> * Driver's default scaling filter
> * Nearest Neighbor:
> * Nearest Neighbor scaling filter
> + * VRR_ENABLED:
> + * Atomic property for setting the VRR state of the CRTC.
> + * To enable the VRR on CRTC, user-space must set this property to 1.
This prop was primarily a userspace Write only and driver read only
property which would be used only by the userspace to request VRR on
that CRTC,
Are we now modifying this to be used as a bidirectional property to also
indicate the status of VRR on that CRTC which will be updated by the
driver?
We need to add this accordingly and update the DRM documentation and
also get acks from other vendors since AMD and other folks mght be using
this as a write only prop.
Manasi
> */
>
> __printf(6, 0)
> @@ -883,3 +886,26 @@ int drm_crtc_create_scaling_filter_property(struct
> drm_crtc *crtc,
> return 0;
> }
> EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
> +
> +/**
> + * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
> + * a crtc.
> + * @crtc: drm CRTC
> + * @vrr_enabled: True to enable the VRR on CRTC
> + *
> + * Should be used by atomic drivers to update the VRR enabled status on a
> CRTC
> + */
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
> + bool vrr_enabled)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_property_set_value(>base,
> + config->prop_vrr_enabled,
> + vrr_enabled);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 37b4b9f0e468..b7cde73d5586 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -323,7 +323,7 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_mode_id = prop;
>
> - prop = drm_property_create_bool(dev, 0,
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> "VRR_ENABLED");
> if (!prop)
> return -ENOMEM;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a70baea0636c..906787398f40 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1333,4 +1333,7 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev,
> int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
> unsigned int supported_filters);
>
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
> + bool vrr_enabled);
> +
> #endif /* __DRM_CRTC_H__ */
> --
> 2.35.1
>
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Add a separate crtc_enable hook for SKL+
Jani, I have cleaned up the hsw_crtc_enable now removing the unused
function calls.
Could you please take a look?
Regards
Manasi
On Thu, May 12, 2022 at 12:52:04PM -0700, Manasi Navare wrote:
> Currently we reuse hsw_crtc_enable for SKL+ platforms.
> But this has added a lot of platform checks for SKL+ platforms.
> So its time to move the code to a separate crtc_enable hook
> for SKL+ platforms.
>
> No functional changes here.
>
> v2: Cleanup hsw_crtc_enable (Jani N)
>
> Suggested-by: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 64
> 1 file changed, 52 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 806d50b302ab..70cde34aca10 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1895,13 +1895,13 @@ static void hsw_configure_cpu_transcoder(const struct
> intel_crtc_state *crtc_sta
> hsw_set_transconf(crtc_state);
> }
>
> -static void hsw_crtc_enable(struct intel_atomic_state *state,
> +static void skl_crtc_enable(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> const struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> + enum pipe pipe = crtc->pipe;
> enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> bool psl_clkgate_wa;
>
> @@ -1925,8 +1925,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> intel_uncompressed_joiner_enable(new_crtc_state);
>
> intel_set_pipe_src_size(new_crtc_state);
> - if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> - bdw_set_pipemisc(new_crtc_state);
> + bdw_set_pipemisc(new_crtc_state);
>
> if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
> !transcoder_is_dsi(cpu_transcoder))
> @@ -1940,10 +1939,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> if (psl_clkgate_wa)
> glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
>
> - if (DISPLAY_VER(dev_priv) >= 9)
> - skl_pfit_enable(new_crtc_state);
> - else
> - ilk_pfit_enable(new_crtc_state);
> + skl_pfit_enable(new_crtc_state);
>
> /*
>* On ILK+ LUT must be loaded before the pipe is running but with
> @@ -1952,9 +1948,6 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> intel_color_load_luts(new_crtc_state);
> intel_color_commit_noarm(new_crtc_state);
> intel_color_commit_arm(new_crtc_state);
> - /* update DSPCNTR to configure gamma/csc for pipe bottom color */
> - if (DISPLAY_VER(dev_priv) < 9)
> - intel_disable_primary_plane(new_crtc_state);
>
> hsw_set_linetime_wm(new_crtc_state);
>
> @@ -1972,6 +1965,53 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> intel_crtc_wait_for_next_vblank(crtc);
> glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false);
> }
> +}
> +
> +static void hsw_crtc_enable(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe hsw_workaround_pipe;
> + enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> +
> + if (drm_WARN_ON(_priv->drm, crtc->active))
> + return;
> +
> + intel_encoders_pre_pll_enable(state, crtc);
> +
> + if (new_crtc_state->shared_dpll)
> + intel_enable_shared_dpll(new_crtc_state);
> +
> + intel_encoders_pre_enable(state, crtc);
> +
> + intel_set_pipe_src_size(new_crtc_state);
> + if (IS_BROADWELL(dev_priv))
> + bdw_set_pipemisc(new_crtc_state);
> +
> + if (!transcoder_is_dsi(cpu_transcoder))
> + hsw_configure_cpu_transcoder(new_crtc_state);
> +
> + crtc->active = true;
> +
> + ilk_pfit_enable(new_crtc_state);
> +
> + /*
> + * On ILK+ LUT must be loaded before the pipe is running but with
> + * clocks enabled
> + */
> + intel_color_load_luts(new_crtc_state);
> + intel_color_commit_noarm(new_crtc_state);
> + intel_color_commit_arm(new_crtc_state);
> + /* update DSPCNTR to configure gamma/csc for pipe bottom color */
> + intel_disable_primary_plane(new_crtc_state);
> +
> + hsw_set_linetime_wm(new_crtc_state);
> +
> + intel_initial_watermarks(state, crtc);
> +
> + intel_encoders_enable(state, crtc);
>
> /* If we change the relative order
Re: [Intel-gfx] [PATCH] drm/i915/display: Add a separate crtc_enable hook for SKL+
On Thu, May 12, 2022 at 12:45:09PM +0300, Jani Nikula wrote:
> On Wed, 11 May 2022, Manasi Navare wrote:
> > Currently we reuse hsw_crtc_enable for SKL+ platforms.
> > But this has added a lot of platform checks for SKL+ platforms.
> > So its time to move the code to a separate crtc_enable hook
> > for SKL+ platforms.
>
> This leaves behind a ton of unused code paths in hsw_crtc_enable, which
> needs cleanup.
Oh yes, I can get rid of all the ?9 checks now from hsw_crtc_enable
I will clean that up and send a v2
Manasi
>
> BR,
> Jani.
>
> >
> > No functional changes here.
> >
> > Suggested-by: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 74 +++-
> > 1 file changed, 73 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 806d50b302ab..e2e228073e2e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1895,6 +1895,78 @@ static void hsw_configure_cpu_transcoder(const
> > struct intel_crtc_state *crtc_sta
> > hsw_set_transconf(crtc_state);
> > }
> >
> > +static void skl_crtc_enable(struct intel_atomic_state *state,
> > + struct intel_crtc *crtc)
> > +{
> > + const struct intel_crtc_state *new_crtc_state =
> > + intel_atomic_get_new_crtc_state(state, crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + enum pipe pipe = crtc->pipe;
> > + enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> > + bool psl_clkgate_wa;
> > +
> > + if (drm_WARN_ON(_priv->drm, crtc->active))
> > + return;
> > +
> > + if (!new_crtc_state->bigjoiner_pipes) {
> > + intel_encoders_pre_pll_enable(state, crtc);
> > +
> > + if (new_crtc_state->shared_dpll)
> > + intel_enable_shared_dpll(new_crtc_state);
> > +
> > + intel_encoders_pre_enable(state, crtc);
> > + } else {
> > + icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
> > + }
> > +
> > + intel_dsc_enable(new_crtc_state);
> > +
> > + if (DISPLAY_VER(dev_priv) >= 13)
> > + intel_uncompressed_joiner_enable(new_crtc_state);
> > +
> > + intel_set_pipe_src_size(new_crtc_state);
> > + bdw_set_pipemisc(new_crtc_state);
> > +
> > + if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
> > + !transcoder_is_dsi(cpu_transcoder))
> > + hsw_configure_cpu_transcoder(new_crtc_state);
> > +
> > + crtc->active = true;
> > +
> > + /* Display WA #1180: WaDisableScalarClockGating: glk */
> > + psl_clkgate_wa = DISPLAY_VER(dev_priv) == 10 &&
> > + new_crtc_state->pch_pfit.enabled;
> > + if (psl_clkgate_wa)
> > + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
> > +
> > + skl_pfit_enable(new_crtc_state);
> > +
> > + /*
> > +* On ILK+ LUT must be loaded before the pipe is running but with
> > +* clocks enabled
> > +*/
> > + intel_color_load_luts(new_crtc_state);
> > + intel_color_commit_noarm(new_crtc_state);
> > + intel_color_commit_arm(new_crtc_state);
> > +
> > + hsw_set_linetime_wm(new_crtc_state);
> > +
> > + if (DISPLAY_VER(dev_priv) >= 11)
> > + icl_set_pipe_chicken(new_crtc_state);
> > +
> > + intel_initial_watermarks(state, crtc);
> > +
> > + if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
> > + intel_crtc_vblank_on(new_crtc_state);
> > +
> > + intel_encoders_enable(state, crtc);
> > +
> > + if (psl_clkgate_wa) {
> > + intel_crtc_wait_for_next_vblank(crtc);
> > + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false);
> > + }
> > +}
> > +
> > static void hsw_crtc_enable(struct intel_atomic_state *state,
> > struct intel_crtc *crtc)
> > {
> > @@ -9231,7 +9303,7 @@ static const struct drm_mode_config_funcs
> > intel_mode_funcs = {
> >
> > static const struct drm_i915_display_funcs skl_display_funcs = {
> > .get_pipe_config = hsw_get_pipe_config,
> > - .crtc_enable = hsw_crtc_enable,
> > + .crtc_enable = skl_crtc_enable,
> > .crtc_disable = hsw_crtc_disable,
> > .commit_modeset_enables = skl_commit_modeset_enables,
> > .get_initial_plane_config = skl_get_initial_plane_config,
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC v2 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc
On Mon, Apr 25, 2022 at 12:16:11PM +0530, Bhanuprakash Modem wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces helpers to attach and set "vrr_enabled" property
> on the crtc to allow userspace to query VRR enabled status on that crtc.
>
> Atomic drivers should attach this property to crtcs those are capable of
> driving variable refresh rates using
> drm_mode_crtc_attach_vrr_enabled_property().
>
> The value should be updated based on driver and hardware capability
> by using drm_mode_crtc_set_vrr_enabled_property().
>
> V2: Use property flag as atomic
We already have userspace making us of the CRTC vrr_enabled property to
enable VRR for the CRTC like in case of full screen gaming.
This can already be done through:
drm_atomic_crtc_set_property call. Why do we need additonal helpers
for setting the same per CRTC property?
This is a default CRTC property so it will be created annd attached for
CRTC as per the DRM doc:
"VRR_ENABLED":
* Default _crtc boolean property that notifies the driver that the
* content on the CRTC is suitable for variable refresh rate presentation.
* The driver will take this property as a hint to enable variable
* refresh rate support if the receiver supports it, ie. if the
* "vrr_capable" property is true on the _connector object. The
* vertical front porch duration will be extended until page-flip or
* timeout when enabled.
Then we can use the atomic_crtc_set/get_property helpers to set it
Am I missing some other use case here?
Manasi
>
> Cc: Ville Syrjälä
> Cc: Nicholas Kazlauskas
> Cc: Manasi Navare
> Cc: Harry Wentland
> Signed-off-by: Bhanuprakash Modem
> ---
> drivers/gpu/drm/drm_crtc.c| 44 +++
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> include/drm/drm_crtc.h| 4 +++
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 26a77a735905..95b4a0c7ecb3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -883,3 +883,47 @@ int drm_crtc_create_scaling_filter_property(struct
> drm_crtc *crtc,
> return 0;
> }
> EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
> +
> +/**
> + * drm_mode_crtc_attach_vrr_enabled_property - attaches the vrr_enabled
> property
> + * @crtc: drm CRTC to attach the vrr_enabled property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * VRR enabled status for a crtc.
> + */
> +void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_attach_property(>base,
> +config->prop_vrr_enabled,
> +0);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_attach_vrr_enabled_property);
> +
> +/**
> + * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
> + * a crtc.
> + * @crtc: drm CRTC
> + * @vrr_enabled: True to enable the VRR on CRTC
> + *
> + * Should be used by atomic drivers to update the VRR enabled status on a
> CRTC
> + */
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
> + bool vrr_enabled)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_property_set_value(>base,
> + config->prop_vrr_enabled,
> + vrr_enabled);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 37b4b9f0e468..b7cde73d5586 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -323,7 +323,7 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_mode_id = prop;
>
> - prop = drm_property_create_bool(dev, 0,
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> "VRR_ENABLED");
> if (!prop)
> return -ENOMEM;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a70baea0636c..bde657cb0f9e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1333,4 +1333,8 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev,
> int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
> unsigned int supported_filters);
>
> +void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc);
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbc: Consult hw.crtc instead of uapi.crtc
On Wed, Apr 13, 2022 at 06:28:51PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> plane_state->uapi.crtc is not what we want to be looking at.
> If bigjoiner is used hw.crtc is what tells us what crtc the plane
> is supposedly using.
>
> Not an actual problem on current hardware as the only FBC capable
> pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc
> always here. But when we get more FBC instances this will become
> actually important.
>
> Fixes: 2e6c99f88679 ("drm/i915/fbc: Nuke lots of crap from
> intel_fbc_state_cache")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 670835318a1f..ff303c7d3a57 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1045,7 +1045,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
> struct intel_plane_state *plane_state =
> intel_atomic_get_new_plane_state(state, plane);
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> - struct intel_crtc *crtc = to_intel_crtc(plane_state->uapi.crtc);
> + struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
> const struct intel_crtc_state *crtc_state;
> struct intel_fbc *fbc = plane->fbc;
>
> --
> 2.35.1
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: s/false/0/
On Wed, Apr 13, 2022 at 06:28:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_fbc_check_plane() is supposed to an int, not a boolean.
> So replace the bogus 'return false's with the correct 'return 0's.
> These were accidental copy-paste mistakes when the code got moved
> into intel_fbc_check_plane() from somewhere else tht did return
> a boolean.
>
> No functional issue here since false==0.
>
> Signed-off-by: Ville Syrjälä
Good catch
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index ff303c7d3a57..966970d1cf0a 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1086,7 +1086,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
>*/
> if (DISPLAY_VER(i915) >= 12 && crtc_state->has_psr2) {
> plane_state->no_fbc_reason = "PSR2 enabled";
> - return false;
> + return 0;
> }
>
> if (!pixel_format_is_valid(plane_state)) {
> @@ -1112,7 +1112,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
> if (plane_state->hw.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
> fb->format->has_alpha) {
> plane_state->no_fbc_reason = "per-pixel alpha not supported";
> - return false;
> + return 0;
> }
>
> if (!intel_fbc_hw_tracking_covers_screen(plane_state)) {
> @@ -1128,7 +1128,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
> if (DISPLAY_VER(i915) >= 9 &&
> plane_state->view.color_plane[0].y & 3) {
> plane_state->no_fbc_reason = "plane start Y offset misaligned";
> - return false;
> + return 0;
> }
>
> /* Wa_22010751166: icl, ehl, tgl, dg1, rkl */
> @@ -1136,7 +1136,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
> (plane_state->view.color_plane[0].y +
>(drm_rect_height(_state->uapi.src) >> 16)) & 3) {
> plane_state->no_fbc_reason = "plane end Y offset misaligned";
> - return false;
> + return 0;
> }
>
> /* WaFbcExceedCdClockThreshold:hsw,bdw */
> --
> 2.35.1
>
Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
Hi Ville,
I was looking at your suggestion of extracting the per pipe stuff out.
Currently in hsw_crtc_enable: the Only non per pipe stuff which gets enabled
for the encoders is :
encoder specific is pre_pll_enable(), enable_shared_dpll, encoders_pre_enable
and configure_cpu_transcoder() - All of this
can be put in a function hsw_encoder_configure() or something that can still be
called from with hsw_crtc_enable
Then the remaining can go into a per pipe function that can be called for each
slave pipe
But it means still pretty much splitting the current hsw_crtc_enable into 2
separate functions
Does this refactoring make sense?
Manasi
On Thu, Mar 17, 2022 at 09:14:16PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2022 at 12:05:47PM -0700, Navare, Manasi wrote:
> > On Thu, Mar 17, 2022 at 08:52:52PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 15, 2022 at 04:38:56PM -0700, Manasi Navare wrote:
> > > > This patch abstracts pieces of hsw_crtc_enable corresponding to
> > > > different
> > > > Bspec enable sequence steps into separate functions.
> > > > This helps to call them in a specific order for bigjoiner master/slave
> > > > in a cleaner fashion.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Animesh Manna
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
> > > > 1 file changed, 66 insertions(+), 59 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index eb49973621f0..d8e6466c9fa0 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const
> > > > struct intel_crtc_state *crtc_state)
> > > > intel_de_write(dev_priv, reg, val);
> > > > }
> > > >
> > > > -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state
> > > > *state,
> > > > -const struct intel_crtc_state
> > > > *crtc_state)
> > > > -{
> > > > - struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> > > > -
> > > > - /*
> > > > -* Enable sequence steps 1-7 on bigjoiner master
> > > > -*/
> > > > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > > > - intel_encoders_pre_pll_enable(state, master_crtc);
> > > > -
> > > > - if (crtc_state->shared_dpll)
> > > > - intel_enable_shared_dpll(crtc_state);
> > > > -
> > > > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > > > - intel_encoders_pre_enable(state, master_crtc);
> > > > -}
> > > > -
> > > > static void hsw_configure_cpu_transcoder(const struct intel_crtc_state
> > > > *crtc_state)
> > > > {
> > > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > @@ -1910,70 +1892,73 @@ static void hsw_configure_cpu_transcoder(const
> > > > struct intel_crtc_state *crtc_sta
> > > > hsw_set_transconf(crtc_state);
> > > > }
> > > >
> > > > -static void hsw_crtc_enable(struct intel_atomic_state *state,
> > > > - struct intel_crtc *crtc)
> > > > +static void hsw_crtc_pre_pll_enable(struct intel_atomic_state *state,
> > > > + const struct intel_crtc_state
> > > > *crtc_state)
> > > > {
> > > > - const struct intel_crtc_state *new_crtc_state =
> > > > - intel_atomic_get_new_crtc_state(state, crtc);
> > > > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > > > - enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> > > > - bool psl_clkgate_wa;
> > > > -
> > > > - if (drm_WARN_ON(_priv->drm, crtc->active))
> > > > - return;
> > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > >
> > > > - if (!new_crtc_state->bigjoiner_pipes) {
> > > > -
Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
On Thu, Mar 17, 2022 at 08:52:52PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 15, 2022 at 04:38:56PM -0700, Manasi Navare wrote:
> > This patch abstracts pieces of hsw_crtc_enable corresponding to different
> > Bspec enable sequence steps into separate functions.
> > This helps to call them in a specific order for bigjoiner master/slave
> > in a cleaner fashion.
> >
> > Cc: Ville Syrjälä
> > Cc: Animesh Manna
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
> > 1 file changed, 66 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index eb49973621f0..d8e6466c9fa0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const struct
> > intel_crtc_state *crtc_state)
> > intel_de_write(dev_priv, reg, val);
> > }
> >
> > -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
> > -const struct intel_crtc_state
> > *crtc_state)
> > -{
> > - struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> > -
> > - /*
> > -* Enable sequence steps 1-7 on bigjoiner master
> > -*/
> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > - intel_encoders_pre_pll_enable(state, master_crtc);
> > -
> > - if (crtc_state->shared_dpll)
> > - intel_enable_shared_dpll(crtc_state);
> > -
> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > - intel_encoders_pre_enable(state, master_crtc);
> > -}
> > -
> > static void hsw_configure_cpu_transcoder(const struct intel_crtc_state
> > *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -1910,70 +1892,73 @@ static void hsw_configure_cpu_transcoder(const
> > struct intel_crtc_state *crtc_sta
> > hsw_set_transconf(crtc_state);
> > }
> >
> > -static void hsw_crtc_enable(struct intel_atomic_state *state,
> > - struct intel_crtc *crtc)
> > +static void hsw_crtc_pre_pll_enable(struct intel_atomic_state *state,
> > + const struct intel_crtc_state *crtc_state)
> > {
> > - const struct intel_crtc_state *new_crtc_state =
> > - intel_atomic_get_new_crtc_state(state, crtc);
> > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > - enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> > - bool psl_clkgate_wa;
> > -
> > - if (drm_WARN_ON(_priv->drm, crtc->active))
> > - return;
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >
> > - if (!new_crtc_state->bigjoiner_pipes) {
> > - intel_encoders_pre_pll_enable(state, crtc);
> > + /*
> > +* Enable sequence steps 1 - 7 on all pipes
> > +*/
> > + intel_encoders_pre_pll_enable(state, crtc);
> > + if (crtc_state->shared_dpll)
> > + intel_enable_shared_dpll(crtc_state);
> >
> > - if (new_crtc_state->shared_dpll)
> > - intel_enable_shared_dpll(new_crtc_state);
> > + intel_encoders_pre_enable(state, crtc);
> > +}
> >
> > - intel_encoders_pre_enable(state, crtc);
> > - } else {
> > - icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
> > - }
> > +static void hsw_crtc_post_pll_enable(struct intel_atomic_state *state,
> > +const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > + bool psl_clkgate_wa;
> >
> > - intel_dsc_enable(new_crtc_state);
> > + /*
> > +* Enable sequence step 8
> > +*/
> > + intel_dsc_enable(crtc_state);
> >
> > if (DISPLAY_VER(dev_priv) >= 13)
> > - intel_uncompressed_joiner_enable(new_crtc_state);
> > + intel_uncompressed_joiner_enable(crtc_state);
> >
> > - intel_set_pipe_src_size(new_crtc_state);
> > + intel_set_pipe_src_size(crtc_state);
> > if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> > - bdw_set_pipemisc(new_crtc_state);
> > + bdw_set_pipemisc(crtc_state);
> >
> > - if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
> > + if (!intel_crtc_is_bigjoiner_slave(crtc_state) &&
> > !transcoder_is_dsi(cpu_transcoder))
> > - hsw_configure_cpu_transcoder(new_crtc_state);
> > + hsw_configure_cpu_transcoder(crtc_state);
> >
> > crtc->active = true;
> >
> > /* Display WA #1180: WaDisableScalarClockGating: glk */
> > psl_clkgate_wa = DISPLAY_VER(dev_priv) == 10
Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
On Thu, Mar 17, 2022 at 11:28:03AM -0700, Navare, Manasi wrote:
> On Thu, Mar 17, 2022 at 05:35:43PM +0200, Jani Nikula wrote:
> > On Wed, 16 Mar 2022, "Navare, Manasi" wrote:
> > > On Wed, Mar 16, 2022 at 09:48:17AM +0200, Jani Nikula wrote:
> > >> On Tue, 15 Mar 2022, Manasi Navare wrote:
> > >> > This patch abstracts pieces of hsw_crtc_enable corresponding to
> > >> > different
> > >> > Bspec enable sequence steps into separate functions.
> > >> > This helps to call them in a specific order for bigjoiner master/slave
> > >> > in a cleaner fashion.
> > >>
> > >> So does this contain only refactoring or functional changes also? One or
> > >> the other at a time, please, not both.
> > >
> > > No this is only refactor, no functional changes here
> > >
> > >>
> > >> Also looks like hsw_crtc_* have accumulated just way too many checks for
> > >> platforms instead of having a clean break at e.g. display 9 and/or 11.
> > >
> > > These checks were already part of hsw_crtc_enable() function that I have
> > > just moved to a separate
> > > function. How do you recommend removing these checks?
> >
> > We use hsw_crtc_enable for all DDI platforms and later. We do have the
> > difference between skl_display_funcs and ddi_display_funcs, but they
> > both point to hsw_crtc_enable. Maybe it's time for them to have their
> > own functions that don't have to take so many platform differences into
> > account.
>
> Yes I could perhaps have a separate skl_crtc_enable() function which would
> then have all parts that apply to DISPLAy >=9
> everything else can stay in hsw_crtc_enable
>
> That makes sense?
Or actually we could have a separate one for >=11 starting ICL, since there are
a lot of
checks for >=11. Also bigjoiner support only from ICL, so then this bigjoiner
sequence then only becomes part
of icl_crtc_enable()
Which one of the above 2 do you recommend?
Manasi
>
> Manasi
>
> >
> > BR,
> > Jani.
> >
> >
> >
> >
> > >
> > >>
> > >> Adding references to "enable sequence step 8" is not helpful because
> > >> it's platform specific. (Yeah, I know there are existing references like
> > >> this, but they're also suspect.)
> > >
> > > Yes agree, may be I will add the comment for what actually the step 7/8
> > > does?
> > >
> > > Manasi
> > >
> > >>
> > >>
> > >> BR,
> > >> Jani.
> > >>
> > >>
> > >> >
> > >> > Cc: Ville Syrjälä
> > >> > Cc: Animesh Manna
> > >> > Signed-off-by: Manasi Navare
> > >> > ---
> > >> > drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
> > >> > 1 file changed, 66 insertions(+), 59 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > >> > b/drivers/gpu/drm/i915/display/intel_display.c
> > >> > index eb49973621f0..d8e6466c9fa0 100644
> > >> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > >> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > >> > @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const
> > >> > struct intel_crtc_state *crtc_state)
> > >> >intel_de_write(dev_priv, reg, val);
> > >> > }
> > >> >
> > >> > -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state
> > >> > *state,
> > >> > - const struct intel_crtc_state
> > >> > *crtc_state)
> > >> > -{
> > >> > - struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> > >> > -
> > >> > - /*
> > >> > - * Enable sequence steps 1-7 on bigjoiner master
> > >> > - */
> > >> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > >> > - intel_encoders_pre_pll_enable(state, master_crtc);
> > >> > -
> > >> > - if (crtc_state->shared_dpll)
> > >> > - intel_enable_shared_dpll(crtc_state);
> > >> > -
> > >> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > >> > - intel_encoders_pre_enable(state, maste
Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
On Thu, Mar 17, 2022 at 05:35:43PM +0200, Jani Nikula wrote:
> On Wed, 16 Mar 2022, "Navare, Manasi" wrote:
> > On Wed, Mar 16, 2022 at 09:48:17AM +0200, Jani Nikula wrote:
> >> On Tue, 15 Mar 2022, Manasi Navare wrote:
> >> > This patch abstracts pieces of hsw_crtc_enable corresponding to different
> >> > Bspec enable sequence steps into separate functions.
> >> > This helps to call them in a specific order for bigjoiner master/slave
> >> > in a cleaner fashion.
> >>
> >> So does this contain only refactoring or functional changes also? One or
> >> the other at a time, please, not both.
> >
> > No this is only refactor, no functional changes here
> >
> >>
> >> Also looks like hsw_crtc_* have accumulated just way too many checks for
> >> platforms instead of having a clean break at e.g. display 9 and/or 11.
> >
> > These checks were already part of hsw_crtc_enable() function that I have
> > just moved to a separate
> > function. How do you recommend removing these checks?
>
> We use hsw_crtc_enable for all DDI platforms and later. We do have the
> difference between skl_display_funcs and ddi_display_funcs, but they
> both point to hsw_crtc_enable. Maybe it's time for them to have their
> own functions that don't have to take so many platform differences into
> account.
Yes I could perhaps have a separate skl_crtc_enable() function which would then
have all parts that apply to DISPLAy >=9
everything else can stay in hsw_crtc_enable
That makes sense?
Manasi
>
> BR,
> Jani.
>
>
>
>
> >
> >>
> >> Adding references to "enable sequence step 8" is not helpful because
> >> it's platform specific. (Yeah, I know there are existing references like
> >> this, but they're also suspect.)
> >
> > Yes agree, may be I will add the comment for what actually the step 7/8
> > does?
> >
> > Manasi
> >
> >>
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> > Cc: Ville Syrjälä
> >> > Cc: Animesh Manna
> >> > Signed-off-by: Manasi Navare
> >> > ---
> >> > drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
> >> > 1 file changed, 66 insertions(+), 59 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> > b/drivers/gpu/drm/i915/display/intel_display.c
> >> > index eb49973621f0..d8e6466c9fa0 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> > @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const
> >> > struct intel_crtc_state *crtc_state)
> >> > intel_de_write(dev_priv, reg, val);
> >> > }
> >> >
> >> > -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state
> >> > *state,
> >> > - const struct intel_crtc_state
> >> > *crtc_state)
> >> > -{
> >> > -struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> >> > -
> >> > -/*
> >> > - * Enable sequence steps 1-7 on bigjoiner master
> >> > - */
> >> > -if (intel_crtc_is_bigjoiner_slave(crtc_state))
> >> > -intel_encoders_pre_pll_enable(state, master_crtc);
> >> > -
> >> > -if (crtc_state->shared_dpll)
> >> > -intel_enable_shared_dpll(crtc_state);
> >> > -
> >> > -if (intel_crtc_is_bigjoiner_slave(crtc_state))
> >> > -intel_encoders_pre_enable(state, master_crtc);
> >> > -}
> >> > -
> >> > static void hsw_configure_cpu_transcoder(const struct intel_crtc_state
> >> > *crtc_state)
> >> > {
> >> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >> > @@ -1910,70 +1892,73 @@ static void hsw_configure_cpu_transcoder(const
> >> > struct intel_crtc_state *crtc_sta
> >> > hsw_set_transconf(crtc_state);
> >> > }
> >> >
> >> > -static void hsw_crtc_enable(struct intel_atomic_state *state,
> >> > -struct intel_crtc *crtc)
> >> > +static void hsw_crtc_pre_pll_enable(struct intel_atomic_state *state,
> >> > +
Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
On Wed, Mar 16, 2022 at 09:48:17AM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2022, Manasi Navare wrote:
> > This patch abstracts pieces of hsw_crtc_enable corresponding to different
> > Bspec enable sequence steps into separate functions.
> > This helps to call them in a specific order for bigjoiner master/slave
> > in a cleaner fashion.
>
> So does this contain only refactoring or functional changes also? One or
> the other at a time, please, not both.
No this is only refactor, no functional changes here
>
> Also looks like hsw_crtc_* have accumulated just way too many checks for
> platforms instead of having a clean break at e.g. display 9 and/or 11.
These checks were already part of hsw_crtc_enable() function that I have just
moved to a separate
function. How do you recommend removing these checks?
>
> Adding references to "enable sequence step 8" is not helpful because
> it's platform specific. (Yeah, I know there are existing references like
> this, but they're also suspect.)
Yes agree, may be I will add the comment for what actually the step 7/8 does?
Manasi
>
>
> BR,
> Jani.
>
>
> >
> > Cc: Ville Syrjälä
> > Cc: Animesh Manna
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
> > 1 file changed, 66 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index eb49973621f0..d8e6466c9fa0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const struct
> > intel_crtc_state *crtc_state)
> > intel_de_write(dev_priv, reg, val);
> > }
> >
> > -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
> > -const struct intel_crtc_state
> > *crtc_state)
> > -{
> > - struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> > -
> > - /*
> > -* Enable sequence steps 1-7 on bigjoiner master
> > -*/
> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > - intel_encoders_pre_pll_enable(state, master_crtc);
> > -
> > - if (crtc_state->shared_dpll)
> > - intel_enable_shared_dpll(crtc_state);
> > -
> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > - intel_encoders_pre_enable(state, master_crtc);
> > -}
> > -
> > static void hsw_configure_cpu_transcoder(const struct intel_crtc_state
> > *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -1910,70 +1892,73 @@ static void hsw_configure_cpu_transcoder(const
> > struct intel_crtc_state *crtc_sta
> > hsw_set_transconf(crtc_state);
> > }
> >
> > -static void hsw_crtc_enable(struct intel_atomic_state *state,
> > - struct intel_crtc *crtc)
> > +static void hsw_crtc_pre_pll_enable(struct intel_atomic_state *state,
> > + const struct intel_crtc_state *crtc_state)
> > {
> > - const struct intel_crtc_state *new_crtc_state =
> > - intel_atomic_get_new_crtc_state(state, crtc);
> > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > - enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> > - bool psl_clkgate_wa;
> > -
> > - if (drm_WARN_ON(_priv->drm, crtc->active))
> > - return;
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >
> > - if (!new_crtc_state->bigjoiner_pipes) {
> > - intel_encoders_pre_pll_enable(state, crtc);
> > + /*
> > +* Enable sequence steps 1 - 7 on all pipes
> > +*/
> > + intel_encoders_pre_pll_enable(state, crtc);
> > + if (crtc_state->shared_dpll)
> > + intel_enable_shared_dpll(crtc_state);
> >
> > - if (new_crtc_state->shared_dpll)
> > - intel_enable_shared_dpll(new_crtc_state);
> > + intel_encoders_pre_enable(state, crtc);
> > +}
> >
> > - intel_encoders_pre_enable(state, crtc);
> > - } else {
> > - icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
> > - }
> > +static void hsw_crtc_post_pll_enable(struct intel_atomic_state *state,
> > +const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > + bool psl_clkgate_wa;
> >
> > - intel_dsc_enable(new_crtc_state);
> > + /*
> > +* Enable sequence step 8
> > +*/
> > + intel_dsc_enable(crtc_state);
> >
> > if (DISPLAY_VER(dev_priv) >= 13)
> > - intel_uncompressed_joiner_enable(new_crtc_state);
> > +
Re: [Intel-gfx] [PATCH 8/9] drm/i915: Deal with bigjoiner vs. DRRS
On Tue, Mar 15, 2022 at 03:27:51PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DRRS operates on transcoder level, so we should only poke at it from
> the master crtc rather than letting every joined pipe give it
> potentially conflicting input.
>
> Signed-off-by: Ville Syrjälä
Looks good
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_drrs.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 44c9af8f8b9b..9a341ab1a848 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -176,8 +176,16 @@ static void intel_drrs_schedule_work(struct intel_crtc
> *crtc)
> static unsigned int intel_drrs_frontbuffer_bits(const struct
> intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + unsigned int frontbuffer_bits;
>
> - return INTEL_FRONTBUFFER_ALL_MASK(crtc->pipe);
> + frontbuffer_bits = INTEL_FRONTBUFFER_ALL_MASK(crtc->pipe);
> +
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc,
> + crtc_state->bigjoiner_pipes)
> + frontbuffer_bits |= INTEL_FRONTBUFFER_ALL_MASK(crtc->pipe);
> +
> + return frontbuffer_bits;
> }
>
> /**
> @@ -196,6 +204,9 @@ void intel_drrs_enable(const struct intel_crtc_state
> *crtc_state)
> if (!crtc_state->hw.active)
> return;
>
> + if (intel_crtc_is_bigjoiner_slave(crtc_state))
> + return;
> +
> mutex_lock(>drrs.mutex);
>
> crtc->drrs.cpu_transcoder = crtc_state->cpu_transcoder;
> @@ -223,6 +234,9 @@ void intel_drrs_disable(const struct intel_crtc_state
> *old_crtc_state)
> if (!old_crtc_state->hw.active)
> return;
>
> + if (intel_crtc_is_bigjoiner_slave(old_crtc_state))
> + return;
> +
> mutex_lock(>drrs.mutex);
>
> if (intel_drrs_is_enabled(crtc))
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Make the PIPESC rect relative to the entire bigjoiner area
On Fri, Mar 04, 2022 at 05:10:33PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 03, 2022 at 02:41:23PM -0800, Navare, Manasi wrote:
> > On Wed, Feb 23, 2022 at 03:13:15PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > When using bigjoiner it's useful to know the offset of each
> > > individual pipe in the whole set of joined pipes. Let's include
> > > that information in our PIPESRC rectangle. With this we can make
> > > the plane clipping code blissfully unaware of bigjoiner usage, as
> > > all we have to do is remove the pipe's offset from the final plane
> > > destination coordinates.
> > >
> > > v2: Use intel_bigjoiner_num_pipes()
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > .../gpu/drm/i915/display/intel_atomic_plane.c | 7 +++---
> > > drivers/gpu/drm/i915/display/intel_cursor.c | 8 ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 21 ++
> > > drivers/gpu/drm/i915/display/intel_overlay.c | 22 +--
> > > 4 files changed, 40 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > index 3cbf66146da0..92ae4eebc62f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > @@ -824,10 +824,6 @@ int intel_atomic_plane_check_clipping(struct
> > > intel_plane_state *plane_state,
> > > return -ERANGE;
> > > }
> > >
> > > - /* right side of the image is on the slave crtc, adjust dst to match */
> > > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > > - drm_rect_translate(dst, -drm_rect_width(_state->pipe_src),
> > > 0);
> > > -
> > > /*
> > >* FIXME: This might need further adjustment for seamless scaling
> > >* with phase information, for the 2p2 and 2p1 scenarios.
> > > @@ -844,6 +840,9 @@ int intel_atomic_plane_check_clipping(struct
> > > intel_plane_state *plane_state,
> > > return -EINVAL;
> > > }
> > >
> > > + /* final plane coordinates will be relative to the plane's pipe */
> > > + drm_rect_translate(dst, -clip->x1, -clip->y1);
> > > +
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > index da6cf0515164..9279e2783e7e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > @@ -152,9 +152,11 @@ static int intel_check_cursor(struct
> > > intel_crtc_state *crtc_state,
> > > /* Use the unclipped src/dst rectangles, which we program to hw */
> > > plane_state->uapi.src = src;
> > > plane_state->uapi.dst = dst;
> > > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > > - drm_rect_translate(_state->uapi.dst,
> > > --drm_rect_width(_state->pipe_src), 0);
> > > +
> > > + /* final plane coordinates will be relative to the plane's pipe */
> > > + drm_rect_translate(_state->uapi.dst,
> > > +-crtc_state->pipe_src.x1,
> > > +-crtc_state->pipe_src.y1);
> > >
> > > ret = intel_cursor_check_surface(plane_state);
> > > if (ret)
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 7a09bb33c1eb..a9c15f27b948 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -3204,6 +3204,23 @@ static void intel_get_transcoder_timings(struct
> > > intel_crtc *crtc,
> > > }
> > > }
> > >
> > > +static void intel_bigjoiner_adjust_pipe_src(struct intel_crtc_state
> > > *crtc_state)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
> > > + enum pipe master_pipe, pipe = crtc->pipe;
> > > + int width;
> > > +
> > > + if (num_pipes < 2)
> > > + return;
> > > +
> > > + master_pipe = bigjoiner_master_pipe(crtc_state);
> > > + width =
Re: [Intel-gfx] [PATCH v7] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Thu, Mar 10, 2022 at 01:43:57AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 03, 2022 at 03:32:22PM -0800, Manasi Navare wrote:
> > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> > settings.
> > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> > MSA bit
> > in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> > the corresponding VRR Capable Connector property.
> > Hence the userspace still sees this as VRR Capable panel which is incorrect.
> >
> > Fix this by explicitly resetting the connector property.
> >
> > v2: Reset vrr capable if status == connector_disconnected
> > v3: Use i915 and use bool vrr_capable (Jani Nikula)
> > v4: Move vrr_capable to after update modes call (Jani N)
> > Remove the redundant comment (Jan N)
> > v5: Fixes the regression on older platforms by reseting the VRR
> > only if HAS_VRR
> > v6: Remove the checks from driver, add in drm core before
> > setting VRR prop (Ville)
> > v7: Move VRR set/reset to set/unset_edid (Ville)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> > property on a long hpd")
> > Signed-off-by: Manasi Navare
>
> Looks reasoanble enough to me.
> Reviewed-by: Ville Syrjälä
>
> But be careful when pushing this since I don't think
> the drm_connector_set_vrr_capable_property() change has
> percolated into drm-intel-next yet.
Okay I can wait then to push until that gets percolated from drm-misc
Manasi
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6ef33096bb6..1d0f8fc39005 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4385,13 +4385,20 @@ intel_dp_update_420(struct intel_dp *intel_dp)
> > static void
> > intel_dp_set_edid(struct intel_dp *intel_dp)
> > {
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > struct intel_connector *connector = intel_dp->attached_connector;
> > struct edid *edid;
> > + bool vrr_capable;
> >
> > intel_dp_unset_edid(intel_dp);
> > edid = intel_dp_get_edid(intel_dp);
> > connector->detect_edid = edid;
> >
> > + vrr_capable = intel_vrr_is_capable(>base);
> > + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> > + connector->base.base.id, connector->base.name,
> > str_yes_no(vrr_capable));
> > + drm_connector_set_vrr_capable_property(>base, vrr_capable);
> > +
> > intel_dp_update_dfp(intel_dp, edid);
> > intel_dp_update_420(intel_dp);
> >
> > @@ -4424,6 +4431,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> >
> > intel_dp->dfp.ycbcr_444_to_420 = false;
> > connector->base.ycbcr_420_allowed = false;
> > +
> > + drm_connector_set_vrr_capable_property(>base,
> > + false);
> > }
> >
> > static int
> > @@ -4574,14 +4584,9 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > int num_modes = 0;
> >
> > edid = intel_connector->detect_edid;
> > - if (edid) {
> > + if (edid)
> > num_modes = intel_connector_update_modes(connector, edid);
> >
> > - if (intel_vrr_is_capable(connector))
> > - drm_connector_set_vrr_capable_property(connector,
> > - true);
> > - }
> > -
> > /* Also add fixed mode, which may or may not be present in EDID */
> > if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
> > intel_connector->panel.fixed_mode) {
> > --
> > 2.19.1
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH v7] drm/i915/display/vrr: Reset VRR capable property on a long hpd
Hi Ville,
Here the VRR set/reset moved to set/unset edid like you suggested.
Anything else needed here?
Manasi
On Thu, Mar 03, 2022 at 03:32:22PM -0800, Manasi Navare wrote:
> With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> settings.
> When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> MSA bit
> in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> the corresponding VRR Capable Connector property.
> Hence the userspace still sees this as VRR Capable panel which is incorrect.
>
> Fix this by explicitly resetting the connector property.
>
> v2: Reset vrr capable if status == connector_disconnected
> v3: Use i915 and use bool vrr_capable (Jani Nikula)
> v4: Move vrr_capable to after update modes call (Jani N)
> Remove the redundant comment (Jan N)
> v5: Fixes the regression on older platforms by reseting the VRR
> only if HAS_VRR
> v6: Remove the checks from driver, add in drm core before
> setting VRR prop (Ville)
> v7: Move VRR set/reset to set/unset_edid (Ville)
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> property on a long hpd")
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6ef33096bb6..1d0f8fc39005 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4385,13 +4385,20 @@ intel_dp_update_420(struct intel_dp *intel_dp)
> static void
> intel_dp_set_edid(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_connector *connector = intel_dp->attached_connector;
> struct edid *edid;
> + bool vrr_capable;
>
> intel_dp_unset_edid(intel_dp);
> edid = intel_dp_get_edid(intel_dp);
> connector->detect_edid = edid;
>
> + vrr_capable = intel_vrr_is_capable(>base);
> + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> + connector->base.base.id, connector->base.name,
> str_yes_no(vrr_capable));
> + drm_connector_set_vrr_capable_property(>base, vrr_capable);
> +
> intel_dp_update_dfp(intel_dp, edid);
> intel_dp_update_420(intel_dp);
>
> @@ -4424,6 +4431,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>
> intel_dp->dfp.ycbcr_444_to_420 = false;
> connector->base.ycbcr_420_allowed = false;
> +
> + drm_connector_set_vrr_capable_property(>base,
> +false);
> }
>
> static int
> @@ -4574,14 +4584,9 @@ static int intel_dp_get_modes(struct drm_connector
> *connector)
> int num_modes = 0;
>
> edid = intel_connector->detect_edid;
> - if (edid) {
> + if (edid)
> num_modes = intel_connector_update_modes(connector, edid);
>
> - if (intel_vrr_is_capable(connector))
> - drm_connector_set_vrr_capable_property(connector,
> -true);
> - }
> -
> /* Also add fixed mode, which may or may not be present in EDID */
> if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
> intel_connector->panel.fixed_mode) {
> --
> 2.19.1
>
Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Make the PIPESC rect relative to the entire bigjoiner area
On Wed, Feb 23, 2022 at 03:13:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When using bigjoiner it's useful to know the offset of each
> individual pipe in the whole set of joined pipes. Let's include
> that information in our PIPESRC rectangle. With this we can make
> the plane clipping code blissfully unaware of bigjoiner usage, as
> all we have to do is remove the pipe's offset from the final plane
> destination coordinates.
>
> v2: Use intel_bigjoiner_num_pipes()
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 7 +++---
> drivers/gpu/drm/i915/display/intel_cursor.c | 8 ---
> drivers/gpu/drm/i915/display/intel_display.c | 21 ++
> drivers/gpu/drm/i915/display/intel_overlay.c | 22 +--
> 4 files changed, 40 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 3cbf66146da0..92ae4eebc62f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -824,10 +824,6 @@ int intel_atomic_plane_check_clipping(struct
> intel_plane_state *plane_state,
> return -ERANGE;
> }
>
> - /* right side of the image is on the slave crtc, adjust dst to match */
> - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - drm_rect_translate(dst, -drm_rect_width(_state->pipe_src),
> 0);
> -
> /*
>* FIXME: This might need further adjustment for seamless scaling
>* with phase information, for the 2p2 and 2p1 scenarios.
> @@ -844,6 +840,9 @@ int intel_atomic_plane_check_clipping(struct
> intel_plane_state *plane_state,
> return -EINVAL;
> }
>
> + /* final plane coordinates will be relative to the plane's pipe */
> + drm_rect_translate(dst, -clip->x1, -clip->y1);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index da6cf0515164..9279e2783e7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -152,9 +152,11 @@ static int intel_check_cursor(struct intel_crtc_state
> *crtc_state,
> /* Use the unclipped src/dst rectangles, which we program to hw */
> plane_state->uapi.src = src;
> plane_state->uapi.dst = dst;
> - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - drm_rect_translate(_state->uapi.dst,
> --drm_rect_width(_state->pipe_src), 0);
> +
> + /* final plane coordinates will be relative to the plane's pipe */
> + drm_rect_translate(_state->uapi.dst,
> +-crtc_state->pipe_src.x1,
> +-crtc_state->pipe_src.y1);
>
> ret = intel_cursor_check_surface(plane_state);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7a09bb33c1eb..a9c15f27b948 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3204,6 +3204,23 @@ static void intel_get_transcoder_timings(struct
> intel_crtc *crtc,
> }
> }
>
> +static void intel_bigjoiner_adjust_pipe_src(struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
> + enum pipe master_pipe, pipe = crtc->pipe;
> + int width;
> +
> + if (num_pipes < 2)
> + return;
> +
> + master_pipe = bigjoiner_master_pipe(crtc_state);
> + width = drm_rect_width(_state->pipe_src);
> +
> + drm_rect_translate_to(_state->pipe_src,
> + (pipe - master_pipe) * width, 0);
> +}
> +
> static void intel_get_pipe_src_size(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> @@ -3216,6 +3233,8 @@ static void intel_get_pipe_src_size(struct intel_crtc
> *crtc,
> drm_rect_init(_config->pipe_src, 0, 0,
> REG_FIELD_GET(PIPESRC_WIDTH_MASK, tmp) + 1,
> REG_FIELD_GET(PIPESRC_HEIGHT_MASK, tmp) + 1);
> +
> + intel_bigjoiner_adjust_pipe_src(pipe_config);
> }
>
> static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state)
> @@ -5853,6 +5872,8 @@ intel_modeset_pipe_config_late(struct intel_crtc_state
> *crtc_state)
> struct drm_connector *connector;
> int i;
>
> + intel_bigjoiner_adjust_pipe_src(crtc_state);
> +
> for_each_new_connector_in_state(>base, connector,
> conn_state, i) {
> struct intel_encoder *encoder =
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index 631e1f1dc5e6..ee46561b5ae8 100644
> ---
Re: [Intel-gfx] [PATCH v2 12/13] drm/i915: Use bigjoiner_pipes more
On Thu, Feb 24, 2022 at 12:35:59PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 23, 2022 at 12:00:28PM -0800, Navare, Manasi wrote:
> > On Wed, Feb 23, 2022 at 03:13:14PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Replace the hardcoded 2 pipe assumptions when we're massaging
> > > pipe_mode and the pipe_src rect to be suitable for bigjoiner.
> > > Instead we can just count the number of pipes in the bitmask.
> > >
> > > v2: Introduce intel_bigjoiner_num_pipes()
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 31 +---
> > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 9b4013ed3d98..7a09bb33c1eb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -368,6 +368,11 @@ bool intel_crtc_is_bigjoiner_master(const struct
> > > intel_crtc_state *crtc_state)
> > > crtc->pipe == bigjoiner_master_pipe(crtc_state);
> > > }
> > >
> > > +static int intel_bigjoiner_num_pipes(const struct intel_crtc_state
> > > *crtc_state)
> > > +{
> > > + return hweight8(crtc_state->bigjoiner_pipes);
> > > +}
> >
> > Okay yes makes sense. Although bigjoiner will always be between just 2
> > pipes so why not hardcode to 2 and
> > use the if (!crtc_state->bigjoiner_pipes) as the check instead of
> > num_pipes < 2.
> > When we have a joiner for 4 pipes, in that case also bigjoiner will still
> > be only between 2 pipes.
> > So in bigjoiner_pipe mask, it will always only have 2 pipes.
>
> It'll be whatever pipes we have when we have more pipes.
Okay agreed might be good from scalability pov
Reviewed-by: Manasi Navare
Manasi
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH v2 10/13] drm/i915: Start tracking PIPESRC as a drm_rect
On Wed, Feb 23, 2022 at 03:13:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of just having the pipe_src_{w,h} let's use a full
> drm_rect for it. This will be particularly useful to astract
> away some bigjoiner details.
>
> v2: No hweight() stuff yet
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 15 ++--
> drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 55 ++-
> .../drm/i915/display/intel_display_debugfs.c | 4 +-
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_overlay.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_panel.c| 70 +--
> drivers/gpu/drm/i915/display/skl_scaler.c | 12 ++--
> .../drm/i915/display/skl_universal_plane.c| 2 +-
> 9 files changed, 96 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index c53aa6a4c7a0..3cbf66146da0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -803,8 +803,8 @@ int intel_atomic_plane_check_clipping(struct
> intel_plane_state *plane_state,
> struct drm_framebuffer *fb = plane_state->hw.fb;
> struct drm_rect *src = _state->uapi.src;
> struct drm_rect *dst = _state->uapi.dst;
> + const struct drm_rect *clip = _state->pipe_src;
> unsigned int rotation = plane_state->hw.rotation;
> - struct drm_rect clip = {};
> int hscale, vscale;
>
> if (!fb) {
> @@ -824,28 +824,23 @@ int intel_atomic_plane_check_clipping(struct
> intel_plane_state *plane_state,
> return -ERANGE;
> }
>
> - if (crtc_state->hw.enable) {
> - clip.x2 = crtc_state->pipe_src_w;
> - clip.y2 = crtc_state->pipe_src_h;
> - }
> -
> /* right side of the image is on the slave crtc, adjust dst to match */
> if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - drm_rect_translate(dst, -crtc_state->pipe_src_w, 0);
> + drm_rect_translate(dst, -drm_rect_width(_state->pipe_src),
> 0);
>
> /*
>* FIXME: This might need further adjustment for seamless scaling
>* with phase information, for the 2p2 and 2p1 scenarios.
>*/
> - plane_state->uapi.visible = drm_rect_clip_scaled(src, dst, );
> + plane_state->uapi.visible = drm_rect_clip_scaled(src, dst, clip);
>
> drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
>
> if (!can_position && plane_state->uapi.visible &&
> - !drm_rect_equals(dst, )) {
> + !drm_rect_equals(dst, clip)) {
> drm_dbg_kms(>drm, "Plane must cover entire CRTC\n");
> drm_rect_debug_print("dst: ", dst, false);
> - drm_rect_debug_print("clip: ", , false);
> + drm_rect_debug_print("clip: ", clip, false);
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 3e80763aa828..1f448f4e9aaf 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -154,7 +154,7 @@ static int intel_check_cursor(struct intel_crtc_state
> *crtc_state,
> plane_state->uapi.dst = dst;
> if (intel_crtc_is_bigjoiner_slave(crtc_state))
> drm_rect_translate(_state->uapi.dst,
> --crtc_state->pipe_src_w, 0);
> +-drm_rect_width(_state->pipe_src), 0);
>
> ret = intel_cursor_check_surface(plane_state);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f0d51555617e..d3ffa62952bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2687,8 +2687,8 @@ static u32 ilk_pipe_pixel_rate(const struct
> intel_crtc_state *crtc_state)
> return pixel_rate;
>
> drm_rect_init(, 0, 0,
> - crtc_state->pipe_src_w << 16,
> - crtc_state->pipe_src_h << 16);
> + drm_rect_width(_state->pipe_src) << 16,
> + drm_rect_height(_state->pipe_src) << 16);
>
> return intel_adjusted_rate
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Tue, Mar 01, 2022 at 09:34:54PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 01, 2022 at 11:30:52AM -0800, Navare, Manasi wrote:
> > Hi Ville,
> >
> > Does it make sense to add the set prop in intel_dp_Set_edid but keep the
> > reset to false
> > in intel_dp_detect where we clear other parameters?
>
> We don't clear stuff in .detect(), or at least shouldn't. .detect() doesn't
> even get run when forcing the connector status.
Well we do clear some compliance variables there.
But okay I can move the VRR rest stuff in intel_dp_unset_edid(), just that this
will also
get called evertime we set edid, it will always clear this first.
Manasi
>
> >
> > Manasi
> >
> >
> > On Fri, Feb 25, 2022 at 05:11:02PM -0800, Navare, Manasi wrote:
> > > On Fri, Feb 25, 2022 at 11:13:35AM +0200, Ville Syrjälä wrote:
> > > > On Thu, Feb 24, 2022 at 05:30:55PM -0800, Manasi Navare wrote:
> > > > > With some VRR panels, user can turn VRR ON/OFF on the fly from the
> > > > > panel settings.
> > > > > When VRR is turned OFF ,sends a long HPD to the driver clearing the
> > > > > Ignore MSA bit
> > > > > in the DPCD. Currently the driver parses that onevery HPD but fails
> > > > > to reset
> > > > > the corresponding VRR Capable Connector property.
> > > > > Hence the userspace still sees this as VRR Capable panel which is
> > > > > incorrect.
> > > > >
> > > > > Fix this by explicitly resetting the connector property.
> > > > >
> > > > > v2: Reset vrr capable if status == connector_disconnected
> > > > > v3: Use i915 and use bool vrr_capable (Jani Nikula)
> > > > > v4: Move vrr_capable to after update modes call (Jani N)
> > > > > Remove the redundant comment (Jan N)
> > > > > v5: Fixes the regression on older platforms by reseting the VRR
> > > > > only if HAS_VRR
> > > > > v6: Remove the checks from driver, add in drm core before
> > > > > setting VRR prop (Ville)
> > > > >
> > > > > Cc: Jani Nikula
> > > > > Cc: Ville Syrjälä
> > > > > Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> > > > > property on a long hpd")
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 15 +++
> > > > > 1 file changed, 11 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 1046e7fe310a..f96123b56935 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -4455,6 +4455,10 @@ intel_dp_detect(struct drm_connector
> > > > > *connector,
> > > > > memset(_dp->compliance, 0,
> > > > > sizeof(intel_dp->compliance));
> > > > > memset(intel_dp->dsc_dpcd, 0,
> > > > > sizeof(intel_dp->dsc_dpcd));
> > > > >
> > > > > + /* Reset VRR Capable property on disconnect */
> > > > > + drm_connector_set_vrr_capable_property(connector,
> > > > > +false);
> > > > > +
> > > > > if (intel_dp->is_mst) {
> > > > > drm_dbg_kms(_priv->drm,
> > > > > "MST device may have disappeared %d
> > > > > vs %d\n",
> > > > > @@ -4569,15 +4573,18 @@ static int intel_dp_get_modes(struct
> > > > > drm_connector *connector)
> > > > > {
> > > > > struct intel_connector *intel_connector =
> > > > > to_intel_connector(connector);
> > > > > struct edid *edid;
> > > > > + struct drm_i915_private *i915 = to_i915(connector->dev);
> > > > > int num_modes = 0;
> > > > >
> > > > > edid = intel_connector->detect_edid;
> > > > > if (edid) {
> > > > > - num_modes = intel_connector_update_modes(connector,
> > > > > edid);
> > > > > + bool vrr_capable;
> > > > >
>
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/display/vrr: Reset VRR capable property on a long hpd
Hi Ville,
Does it make sense to add the set prop in intel_dp_Set_edid but keep the reset
to false
in intel_dp_detect where we clear other parameters?
Manasi
On Fri, Feb 25, 2022 at 05:11:02PM -0800, Navare, Manasi wrote:
> On Fri, Feb 25, 2022 at 11:13:35AM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 24, 2022 at 05:30:55PM -0800, Manasi Navare wrote:
> > > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> > > settings.
> > > When VRR is turned OFF ,sends a long HPD to the driver clearing the
> > > Ignore MSA bit
> > > in the DPCD. Currently the driver parses that onevery HPD but fails to
> > > reset
> > > the corresponding VRR Capable Connector property.
> > > Hence the userspace still sees this as VRR Capable panel which is
> > > incorrect.
> > >
> > > Fix this by explicitly resetting the connector property.
> > >
> > > v2: Reset vrr capable if status == connector_disconnected
> > > v3: Use i915 and use bool vrr_capable (Jani Nikula)
> > > v4: Move vrr_capable to after update modes call (Jani N)
> > > Remove the redundant comment (Jan N)
> > > v5: Fixes the regression on older platforms by reseting the VRR
> > > only if HAS_VRR
> > > v6: Remove the checks from driver, add in drm core before
> > > setting VRR prop (Ville)
> > >
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjälä
> > > Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> > > property on a long hpd")
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 15 +++
> > > 1 file changed, 11 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 1046e7fe310a..f96123b56935 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -4455,6 +4455,10 @@ intel_dp_detect(struct drm_connector *connector,
> > > memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> > > memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> > >
> > > + /* Reset VRR Capable property on disconnect */
> > > + drm_connector_set_vrr_capable_property(connector,
> > > +false);
> > > +
> > > if (intel_dp->is_mst) {
> > > drm_dbg_kms(_priv->drm,
> > > "MST device may have disappeared %d vs
> > > %d\n",
> > > @@ -4569,15 +4573,18 @@ static int intel_dp_get_modes(struct
> > > drm_connector *connector)
> > > {
> > > struct intel_connector *intel_connector = to_intel_connector(connector);
> > > struct edid *edid;
> > > + struct drm_i915_private *i915 = to_i915(connector->dev);
> > > int num_modes = 0;
> > >
> > > edid = intel_connector->detect_edid;
> > > if (edid) {
> > > - num_modes = intel_connector_update_modes(connector, edid);
> > > + bool vrr_capable;
> > >
> > > - if (intel_vrr_is_capable(connector))
> > > - drm_connector_set_vrr_capable_property(connector,
> > > -true);
> > > + num_modes = intel_connector_update_modes(connector, edid);
> > > + vrr_capable = intel_vrr_is_capable(connector);
> > > + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> > > + connector->base.id, connector->name,
> > > yesno(vrr_capable));
> > > + drm_connector_set_vrr_capable_property(connector, vrr_capable);
> >
> > As mentioned on irc I think intel_dp_(un)set_edid() would be a better
> > place for these.
>
> Yes I guess I can add the above to check for vrr_capable and set it to
> true/false in intel_dp_set_edid()
>
> But the resetting part needs to happen outside of intel_dp_unset_edid so that
> we dont always set it to false
> before set_edid. It can just stay in intel_dp_detect where we clear other
> othing on connect status == disconnected.
> Is that fine?
>
> Manasi
>
> >
> > > }
> > >
> > > /* Also add fixed mode, which may or may not be present in EDID */
> > > --
> > > 2.19.1
> >
> > --
> > Ville Syrjälä
> > Intel
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Fri, Feb 25, 2022 at 11:13:35AM +0200, Ville Syrjälä wrote:
> On Thu, Feb 24, 2022 at 05:30:55PM -0800, Manasi Navare wrote:
> > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> > settings.
> > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> > MSA bit
> > in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> > the corresponding VRR Capable Connector property.
> > Hence the userspace still sees this as VRR Capable panel which is incorrect.
> >
> > Fix this by explicitly resetting the connector property.
> >
> > v2: Reset vrr capable if status == connector_disconnected
> > v3: Use i915 and use bool vrr_capable (Jani Nikula)
> > v4: Move vrr_capable to after update modes call (Jani N)
> > Remove the redundant comment (Jan N)
> > v5: Fixes the regression on older platforms by reseting the VRR
> > only if HAS_VRR
> > v6: Remove the checks from driver, add in drm core before
> > setting VRR prop (Ville)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> > property on a long hpd")
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 1046e7fe310a..f96123b56935 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4455,6 +4455,10 @@ intel_dp_detect(struct drm_connector *connector,
> > memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> > memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> >
> > + /* Reset VRR Capable property on disconnect */
> > + drm_connector_set_vrr_capable_property(connector,
> > + false);
> > +
> > if (intel_dp->is_mst) {
> > drm_dbg_kms(_priv->drm,
> > "MST device may have disappeared %d vs
> > %d\n",
> > @@ -4569,15 +4573,18 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > {
> > struct intel_connector *intel_connector = to_intel_connector(connector);
> > struct edid *edid;
> > + struct drm_i915_private *i915 = to_i915(connector->dev);
> > int num_modes = 0;
> >
> > edid = intel_connector->detect_edid;
> > if (edid) {
> > - num_modes = intel_connector_update_modes(connector, edid);
> > + bool vrr_capable;
> >
> > - if (intel_vrr_is_capable(connector))
> > - drm_connector_set_vrr_capable_property(connector,
> > - true);
> > + num_modes = intel_connector_update_modes(connector, edid);
> > + vrr_capable = intel_vrr_is_capable(connector);
> > + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> > + connector->base.id, connector->name,
> > yesno(vrr_capable));
> > + drm_connector_set_vrr_capable_property(connector, vrr_capable);
>
> As mentioned on irc I think intel_dp_(un)set_edid() would be a better
> place for these.
Yes I guess I can add the above to check for vrr_capable and set it to
true/false in intel_dp_set_edid()
But the resetting part needs to happen outside of intel_dp_unset_edid so that
we dont always set it to false
before set_edid. It can just stay in intel_dp_detect where we clear other
othing on connect status == disconnected.
Is that fine?
Manasi
>
> > }
> >
> > /* Also add fixed mode, which may or may not be present in EDID */
> > --
> > 2.19.1
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev4)
Hi,
I fixed the regression in this patch and resent it, it still has BAT failures,
I wanted to understand if it failed to boot some of the machines again or the
errors flagged here are the known errors.
Regards
Manasi
From: Patchwork
Sent: Thursday, February 24, 2022 10:45 AM
To: Navare, Manasi D
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR capable
property on a long hpd (rev4)
Patch Details
Series:
drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev4)
URL:
https://patchwork.freedesktop.org/series/98801/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/index.html
CI Bug Log - changes from CI_DRM_11279 -> Patchwork_22394
Summary
FAILURE
Serious unknown changes coming with Patchwork_22394 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22394, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/index.html
Participating hosts (43 -> 32)
Missing (11): fi-kbl-soraka fi-cml-u2 fi-bsw-cyan fi-ilk-650 fi-apl-guc
fi-kbl-7500u fi-kbl-x1275 fi-cfl-8109u fi-bsw-kefka fi-bdw-samus fi-skl-6600u
Possible new issues
Here are the unknown changes that may have been introduced in Patchwork_22394:
IGT changes
Possible regressions
* igt@gem_exec_suspend@basic-s0@smem:
* fi-skl-6700k2:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11279/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html>
->
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html>
Known issues
Here are the changes found in Patchwork_22394 that come from known issues:
IGT changes
Issues hit
* igt@amdgpu/amd_basic@cs-multi-fence:
* fi-blb-e6850: NOTRUN ->
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-blb-e6850/igt@amdgpu/amd_ba...@cs-multi-fence.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +17 similar
issues
* igt@runner@aborted:
* fi-skl-6700k2: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-skl-6700k2/igt@run...@aborted.html>
(i915#4312<https://gitlab.freedesktop.org/drm/intel/issues/4312>)
Possible fixes
* igt@i915_selftest@live@hangcheck:
* bat-dg1-6:
DMESG-FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11279/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html>
(i915#4494<https://gitlab.freedesktop.org/drm/intel/issues/4494> /
i915#4957<https://gitlab.freedesktop.org/drm/intel/issues/4957>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html>
* igt@i915_selftest@live@requests:
* fi-blb-e6850:
DMESG-FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11279/fi-blb-e6850/igt@i915_selftest@l...@requests.html>
(i915#5026<https://gitlab.freedesktop.org/drm/intel/issues/5026>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-blb-e6850/igt@i915_selftest@l...@requests.html>
* igt@i915_selftest@live@workarounds:
* {bat-adlp-6}:
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11279/bat-adlp-6/igt@i915_selftest@l...@workarounds.html>
(i915#5068<https://gitlab.freedesktop.org/drm/intel/issues/5068>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/bat-adlp-6/igt@i915_selftest@l...@workarounds.html>
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
* {bat-adlp-6}:
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11279/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html>
(i915#3576<https://gitlab.freedesktop.org/drm/intel/issues/3576>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html>
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Build changes
* Linux: CI_DRM_11279 -> Patchwork_22394
CI-20190529: 20190529
CI_DRM_11279: 5301cc85b3cc0eaa37405a117c77a35db7f4a76d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6356: b403d8e73c6888561eaec97835688313b0763ce9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22394: 244f36e5190c176be3ec2fbc9fc18c63b8383621 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
244f36e5190c drm/i915/display/vrr: Reset VRR capable property on a long hpd
Re: [Intel-gfx] [PATCH v2 12/13] drm/i915: Use bigjoiner_pipes more
On Wed, Feb 23, 2022 at 03:13:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hardcoded 2 pipe assumptions when we're massaging
> pipe_mode and the pipe_src rect to be suitable for bigjoiner.
> Instead we can just count the number of pipes in the bitmask.
>
> v2: Introduce intel_bigjoiner_num_pipes()
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 31 +---
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 9b4013ed3d98..7a09bb33c1eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -368,6 +368,11 @@ bool intel_crtc_is_bigjoiner_master(const struct
> intel_crtc_state *crtc_state)
> crtc->pipe == bigjoiner_master_pipe(crtc_state);
> }
>
> +static int intel_bigjoiner_num_pipes(const struct intel_crtc_state
> *crtc_state)
> +{
> + return hweight8(crtc_state->bigjoiner_pipes);
> +}
Okay yes makes sense. Although bigjoiner will always be between just 2 pipes so
why not hardcode to 2 and
use the if (!crtc_state->bigjoiner_pipes) as the check instead of num_pipes <
2.
When we have a joiner for 4 pipes, in that case also bigjoiner will still be
only between 2 pipes.
So in bigjoiner_pipe mask, it will always only have 2 pipes.
Manasi
> +
> struct intel_crtc *intel_master_crtc(const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> @@ -2731,16 +2736,18 @@ static void intel_crtc_compute_pixel_rate(struct
> intel_crtc_state *crtc_state)
> static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> struct drm_display_mode *mode)
> {
> - if (!crtc_state->bigjoiner_pipes)
> + int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
> +
> + if (num_pipes < 2)
> return;
>
> - mode->crtc_clock /= 2;
> - mode->crtc_hdisplay /= 2;
> - mode->crtc_hblank_start /= 2;
> - mode->crtc_hblank_end /= 2;
> - mode->crtc_hsync_start /= 2;
> - mode->crtc_hsync_end /= 2;
> - mode->crtc_htotal /= 2;
> + mode->crtc_clock /= num_pipes;
> + mode->crtc_hdisplay /= num_pipes;
> + mode->crtc_hblank_start /= num_pipes;
> + mode->crtc_hblank_end /= num_pipes;
> + mode->crtc_hsync_start /= num_pipes;
> + mode->crtc_hsync_end /= num_pipes;
> + mode->crtc_htotal /= num_pipes;
> }
>
> static void intel_splitter_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> @@ -2792,7 +2799,8 @@ static void intel_crtc_readout_derived_state(struct
> intel_crtc_state *crtc_state
> /* Populate the "user" mode with full numbers */
> drm_mode_copy(mode, pipe_mode);
> intel_mode_from_crtc_timings(mode, mode);
> - mode->hdisplay = drm_rect_width(_state->pipe_src) <<
> !!crtc_state->bigjoiner_pipes;
> + mode->hdisplay = drm_rect_width(_state->pipe_src) *
> + (intel_bigjoiner_num_pipes(crtc_state) ?: 1);
> mode->vdisplay = drm_rect_height(_state->pipe_src);
>
> /* Derive per-pipe timings in case bigjoiner is used */
> @@ -2812,16 +2820,17 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
>
> static void intel_bigjoiner_compute_pipe_src(struct intel_crtc_state
> *crtc_state)
> {
> + int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
> int width, height;
>
> - if (!crtc_state->bigjoiner_pipes)
> + if (num_pipes < 2)
> return;
>
> width = drm_rect_width(_state->pipe_src);
> height = drm_rect_height(_state->pipe_src);
>
> drm_rect_init(_state->pipe_src, 0, 0,
> - width / 2, height);
> + width / num_pipes, height);
> }
>
> static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2 01/13] drm/i915: Avoid negative shift due to bigjoiner_pipes==0
On Wed, Feb 23, 2022 at 03:13:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> bigjoiner_pipes==0 leads bigjoiner_master_pipe() to
> do BIT(ffs(0)-1) which is undefined behaviour. The code should
> actually still work fine since the only place we provoke
> that is intel_crtc_bigjoiner_slave_pipes() and it'll bitwise
> AND the result with 0, so doesn't really matter what we get
> out of bigjoiner_master_pipe(). But best not provoke undefined
> behaviour anyway.
>
> Reported-by: kernel test robot
> Fixes: a6e7a006f5d5 ("drm/i915: Change bigjoiner state tracking to use the
> pipe bitmask")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 80b19c304c43..f3f5f11a5abf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -346,7 +346,10 @@ static enum pipe bigjoiner_master_pipe(const struct
> intel_crtc_state *crtc_state
>
> u8 intel_crtc_bigjoiner_slave_pipes(const struct intel_crtc_state
> *crtc_state)
> {
> - return crtc_state->bigjoiner_pipes &
> ~BIT(bigjoiner_master_pipe(crtc_state));
> + if (crtc_state->bigjoiner_pipes)
> + return crtc_state->bigjoiner_pipes &
> ~BIT(bigjoiner_master_pipe(crtc_state));
> + else
> + return 0;
> }
>
> bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH] Revert "drm/i915/display/vrr: Reset VRR capable property on a long hpd"
On Wed, Feb 23, 2022 at 10:29:16AM +0200, Jani Nikula wrote:
> On Wed, 23 Feb 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This reverts commit 9bc34b4d0f3cb368241684cc5e0445d435dded44.
> >
> > Just oopses on most machines.
> >
> > Cc: Manasi Navare
> > Cc: Jani Nikula
> > Signed-off-by: Ville Syrjälä
>
> Auch, "ERROR: It appears as if the changes made in Patchwork_22288
> prevented too many machines from booting." [1].
Why would it prevent machines from booting where this only sets the property to
false and we tested this
on VRR panels and it works as expected and infact is needed to turn VRR off if
disabled from
the panel and also on the connector disconnect.
Our customers already want this.
We should look at whther this prevented the machines from booting or this just
revealed some other issue.
>
> Acked-by: Jani Nikula
>
>
> [1]
> https://lore.kernel.org/r/164506400291.18053.4904919379639827...@emeril.freedesktop.org
>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 17 -
> > 1 file changed, 4 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 929e9b6febf1..1046e7fe310a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4455,12 +4455,6 @@ intel_dp_detect(struct drm_connector *connector,
> > memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> > memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> >
> > - /* Reset VRR Capable property */
> > - drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s] VRR capable:
> > FALSE\n",
> > - connector->base.id, connector->name);
> > - drm_connector_set_vrr_capable_property(connector,
> > - false);
Do we perhaps need a condition here to reset this only if it was set previously
or if it is a VRR panel?
Manasi
> > -
> > if (intel_dp->is_mst) {
> > drm_dbg_kms(_priv->drm,
> > "MST device may have disappeared %d vs
> > %d\n",
> > @@ -4575,18 +4569,15 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > {
> > struct intel_connector *intel_connector = to_intel_connector(connector);
> > struct edid *edid;
> > - struct drm_i915_private *i915 = to_i915(connector->dev);
> > int num_modes = 0;
> >
> > edid = intel_connector->detect_edid;
> > if (edid) {
> > - bool vrr_capable;
> > -
> > num_modes = intel_connector_update_modes(connector, edid);
> > - vrr_capable = intel_vrr_is_capable(connector);
> > - drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> > - connector->base.id, connector->name,
> > yesno(vrr_capable));
> > - drm_connector_set_vrr_capable_property(connector, vrr_capable);
> > +
> > + if (intel_vrr_is_capable(connector))
> > + drm_connector_set_vrr_capable_property(connector,
> > + true);
> > }
> >
> > /* Also add fixed mode, which may or may not be present in EDID */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Properly clear crtc state when disabling it fully, again
On Thu, Feb 17, 2022 at 12:32:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we just leave the old gunk lying around in the crtc
> state when userspace asks us to fully disable the crtc. That
> doesn't match what the state would be had we never even enabled
> the crtc in the first place. So let's make this consistent and
> call intel_crtc_prepare_cleared_state() for disabled crtcs as well
> (excluding bigjoiner slaves of course which have had their state
> copied from the master).
>
> I actually already did this once in commit fff13e63a141 ("drm/i915:
> Clear most of crtc state when disabling the crtc") but then
> commit 19f65a3dbf75 ("drm/i915: Try to make bigjoiner work in atomic
> check") undid it all :(
>
> Signed-off-by: Ville Syrjälä
okay agree
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 61adfcd7cf63..e160cee3240d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7627,9 +7627,8 @@ static int intel_atomic_check(struct drm_device *dev,
> continue;
> }
>
> - if (!new_crtc_state->uapi.enable) {
> - if (!intel_crtc_is_bigjoiner_slave(new_crtc_state))
> - intel_crtc_copy_uapi_to_hw_state_modeset(state,
> crtc);
> + if (intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> + drm_WARN_ON(_priv->drm,
> new_crtc_state->uapi.enable);
> continue;
> }
>
> @@ -7637,6 +7636,9 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> + if (!new_crtc_state->hw.enable)
> + continue;
> +
> ret = intel_modeset_pipe_config(state, new_crtc_state);
> if (ret)
> goto fail;
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Dump hw.enable and pipe_mode
On Thu, Feb 17, 2022 at 12:32:19PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Include hw.enable and pipe_mode in the crtc debugfs state dump. > These are fairly fundemental to the operation of the driver > so not seeing them leaves us in the dark. > > Signed-off-by: Ville Syrjälä Yup makes sense to have this debug Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/i915/display/intel_display_debugfs.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > index f1d78b1c7702..1740f24446bb 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > @@ -923,9 +923,12 @@ static void intel_crtc_info(struct seq_file *m, struct > intel_crtc *crtc) > yesno(crtc_state->uapi.active), > DRM_MODE_ARG(_state->uapi.mode)); > > - seq_printf(m, "\thw: active=%s, adjusted_mode=" DRM_MODE_FMT "\n", > -yesno(crtc_state->hw.active), > + seq_printf(m, "\thw: enable=%s, active=%s\n", > +yesno(crtc_state->hw.enable), yesno(crtc_state->hw.active)); > + seq_printf(m, "\tadjusted_mode=" DRM_MODE_FMT "\n", > DRM_MODE_ARG(_state->hw.adjusted_mode)); > + seq_printf(m, "\tpipe__mode=" DRM_MODE_FMT "\n", > +DRM_MODE_ARG(_state->hw.pipe_mode)); > > seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d\n", > crtc_state->pipe_src_w, crtc_state->pipe_src_h, > -- > 2.34.1 >
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove odd any_ms=true assignment
On Thu, Feb 17, 2022 at 12:32:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For some reason we're flagging that we need to run through the
> full modeset calculations (any_ms==true -> do cdclk/etc. checks)
> if any crtc got initially flagged for a modeset and is not
> enabled via the uapi. No idea why this is here since later on
> (after all fastset handling) we do full run through the crtcs
> and flag any_ms if anything still needs a full modeset. So let's
> just throw out this early weirdo.
>
> Signed-off-by: Ville Syrjälä
Hmm yea wonder why that got added here
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 59961621fe4a..61adfcd7cf63 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7628,10 +7628,8 @@ static int intel_atomic_check(struct drm_device *dev,
> }
>
> if (!new_crtc_state->uapi.enable) {
> - if (!intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> + if (!intel_crtc_is_bigjoiner_slave(new_crtc_state))
> intel_crtc_copy_uapi_to_hw_state_modeset(state,
> crtc);
> - any_ms = true;
> - }
> continue;
> }
>
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Dump hw.enable and pipe_mode
On Thu, Feb 17, 2022 at 12:32:19PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Include hw.enable and pipe_mode in the crtc debugfs state dump. > These are fairly fundemental to the operation of the driver > so not seeing them leaves us in the dark. > > Signed-off-by: Ville Syrjälä Okay looks good to have more debug info here Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/i915/display/intel_display_debugfs.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > index f1d78b1c7702..1740f24446bb 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > @@ -923,9 +923,12 @@ static void intel_crtc_info(struct seq_file *m, struct > intel_crtc *crtc) > yesno(crtc_state->uapi.active), > DRM_MODE_ARG(_state->uapi.mode)); > > - seq_printf(m, "\thw: active=%s, adjusted_mode=" DRM_MODE_FMT "\n", > -yesno(crtc_state->hw.active), > + seq_printf(m, "\thw: enable=%s, active=%s\n", > +yesno(crtc_state->hw.enable), yesno(crtc_state->hw.active)); > + seq_printf(m, "\tadjusted_mode=" DRM_MODE_FMT "\n", > DRM_MODE_ARG(_state->hw.adjusted_mode)); > + seq_printf(m, "\tpipe__mode=" DRM_MODE_FMT "\n", > +DRM_MODE_ARG(_state->hw.pipe_mode)); > > seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d\n", > crtc_state->pipe_src_w, crtc_state->pipe_src_h, > -- > 2.34.1 >
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Dump the crtc hw state always
On Thu, Feb 17, 2022 at 12:32:18PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's just dump the "full" hw crtc state in debugs so that we can
> see if some stale junk was left behind when the crtc is supposed
> to be entirely off.
>
> Signed-off-by: Ville Syrjälä
So basically always print the debugfs even for crtcs that are not enabled to
catch any stale state?
Reviewed-by: Manasi Navare
Manasi
> ---
> .../gpu/drm/i915/display/intel_display_debugfs.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 84be489c3399..f1d78b1c7702 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -923,17 +923,15 @@ static void intel_crtc_info(struct seq_file *m, struct
> intel_crtc *crtc)
> yesno(crtc_state->uapi.active),
> DRM_MODE_ARG(_state->uapi.mode));
>
> - if (crtc_state->hw.enable) {
> - seq_printf(m, "\thw: active=%s, adjusted_mode=" DRM_MODE_FMT
> "\n",
> -yesno(crtc_state->hw.active),
> -DRM_MODE_ARG(_state->hw.adjusted_mode));
> + seq_printf(m, "\thw: active=%s, adjusted_mode=" DRM_MODE_FMT "\n",
> +yesno(crtc_state->hw.active),
> +DRM_MODE_ARG(_state->hw.adjusted_mode));
>
> - seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d\n",
> -crtc_state->pipe_src_w, crtc_state->pipe_src_h,
> -yesno(crtc_state->dither), crtc_state->pipe_bpp);
> + seq_printf(m, "\tpipe src size=%dx%d, dither=%s, bpp=%d\n",
> +crtc_state->pipe_src_w, crtc_state->pipe_src_h,
> +yesno(crtc_state->dither), crtc_state->pipe_bpp);
>
> - intel_scaler_info(m, crtc);
> - }
> + intel_scaler_info(m, crtc);
>
> if (crtc_state->bigjoiner)
> seq_printf(m, "\tLinked to 0x%x pipes as a %s\n",
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v3] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Fri, Feb 18, 2022 at 10:36:00AM +0200, Jani Nikula wrote:
> On Thu, 17 Feb 2022, "Navare, Manasi" wrote:
> > Hi Jani,
> >
> > This addresses the review comments, could you please take a look at thsi
> > patch?
>
> Sorry for the delay,
>
> Reviewed-by: Jani Nikula
Thanks for the comments and review, pushed now to din
Regards
Manasi
>
>
> >
> > Manasi
> >
> > On Tue, Feb 15, 2022 at 12:26:01PM -0800, Manasi Navare wrote:
> >> With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> >> settings.
> >> When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> >> MSA bit
> >> in the DPCD. Currently the driver parses that onevery HPD but fails to
> >> reset
> >> the corresponding VRR Capable Connector property.
> >> Hence the userspace still sees this as VRR Capable panel which is
> >> incorrect.
> >>
> >> Fix this by explicitly resetting the connector property.
> >>
> >> v2: Reset vrr capable if status == connector_disconnected
> >> v3: Use i915 and use bool vrr_capable (Jani Nikula)
> >> v4: Move vrr_capable to after update modes call (Jani N)
> >> Remove the redundant comment (Jan N)
> >>
> >> Cc: Jani Nikula
> >> Signed-off-by: Manasi Navare
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 17 +
> >> 1 file changed, 13 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 1046e7fe310a..929e9b6febf1 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -4455,6 +4455,12 @@ intel_dp_detect(struct drm_connector *connector,
> >>memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> >>memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> >>
> >> + /* Reset VRR Capable property */
> >> + drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s] VRR capable:
> >> FALSE\n",
> >> + connector->base.id, connector->name);
> >> + drm_connector_set_vrr_capable_property(connector,
> >> + false);
> >> +
> >>if (intel_dp->is_mst) {
> >>drm_dbg_kms(_priv->drm,
> >>"MST device may have disappeared %d vs
> >> %d\n",
> >> @@ -4569,15 +4575,18 @@ static int intel_dp_get_modes(struct drm_connector
> >> *connector)
> >> {
> >>struct intel_connector *intel_connector = to_intel_connector(connector);
> >>struct edid *edid;
> >> + struct drm_i915_private *i915 = to_i915(connector->dev);
> >>int num_modes = 0;
> >>
> >>edid = intel_connector->detect_edid;
> >>if (edid) {
> >> - num_modes = intel_connector_update_modes(connector, edid);
> >> + bool vrr_capable;
> >>
> >> - if (intel_vrr_is_capable(connector))
> >> - drm_connector_set_vrr_capable_property(connector,
> >> - true);
> >> + num_modes = intel_connector_update_modes(connector, edid);
> >> + vrr_capable = intel_vrr_is_capable(connector);
> >> + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> >> + connector->base.id, connector->name,
> >> yesno(vrr_capable));
> >> + drm_connector_set_vrr_capable_property(connector, vrr_capable);
> >>}
> >>
> >>/* Also add fixed mode, which may or may not be present in EDID */
> >> --
> >> 2.19.1
> >>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3] drm/i915/display/vrr: Reset VRR capable property on a long hpd
Hi Jani,
This addresses the review comments, could you please take a look at thsi patch?
Manasi
On Tue, Feb 15, 2022 at 12:26:01PM -0800, Manasi Navare wrote:
> With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> settings.
> When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> MSA bit
> in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> the corresponding VRR Capable Connector property.
> Hence the userspace still sees this as VRR Capable panel which is incorrect.
>
> Fix this by explicitly resetting the connector property.
>
> v2: Reset vrr capable if status == connector_disconnected
> v3: Use i915 and use bool vrr_capable (Jani Nikula)
> v4: Move vrr_capable to after update modes call (Jani N)
> Remove the redundant comment (Jan N)
>
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1046e7fe310a..929e9b6febf1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4455,6 +4455,12 @@ intel_dp_detect(struct drm_connector *connector,
> memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
>
> + /* Reset VRR Capable property */
> + drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s] VRR capable:
> FALSE\n",
> + connector->base.id, connector->name);
> + drm_connector_set_vrr_capable_property(connector,
> +false);
> +
> if (intel_dp->is_mst) {
> drm_dbg_kms(_priv->drm,
> "MST device may have disappeared %d vs
> %d\n",
> @@ -4569,15 +4575,18 @@ static int intel_dp_get_modes(struct drm_connector
> *connector)
> {
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct edid *edid;
> + struct drm_i915_private *i915 = to_i915(connector->dev);
> int num_modes = 0;
>
> edid = intel_connector->detect_edid;
> if (edid) {
> - num_modes = intel_connector_update_modes(connector, edid);
> + bool vrr_capable;
>
> - if (intel_vrr_is_capable(connector))
> - drm_connector_set_vrr_capable_property(connector,
> -true);
> + num_modes = intel_connector_update_modes(connector, edid);
> + vrr_capable = intel_vrr_is_capable(connector);
> + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> + connector->base.id, connector->name,
> yesno(vrr_capable));
> + drm_connector_set_vrr_capable_property(connector, vrr_capable);
> }
>
> /* Also add fixed mode, which may or may not be present in EDID */
> --
> 2.19.1
>
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Use bigjoiner_pipes more
On Tue, Feb 15, 2022 at 08:32:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hardcoded 2 pipe assumptions when we're massaging
> pipe_mode and the pipe_src rect to be suitable for bigjoiner.
> Instead we can just count the number of pipes in the bitmask.
>
> Signed-off-by: Ville Syrjälä
Patch looks good, perhaps can be squashed with Patch 10 ?
But either ways
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 23 +++-
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 192474163edb..0690470eab97 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2727,16 +2727,18 @@ static void intel_crtc_compute_pixel_rate(struct
> intel_crtc_state *crtc_state)
> static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> struct drm_display_mode *mode)
> {
> - if (!crtc_state->bigjoiner_pipes)
> + int num_pipes = hweight8(crtc_state->bigjoiner_pipes);
> +
> + if (num_pipes < 2)
> return;
>
> - mode->crtc_clock /= 2;
> - mode->crtc_hdisplay /= 2;
> - mode->crtc_hblank_start /= 2;
> - mode->crtc_hblank_end /= 2;
> - mode->crtc_hsync_start /= 2;
> - mode->crtc_hsync_end /= 2;
> - mode->crtc_htotal /= 2;
> + mode->crtc_clock /= num_pipes;
> + mode->crtc_hdisplay /= num_pipes;
> + mode->crtc_hblank_start /= num_pipes;
> + mode->crtc_hblank_end /= num_pipes;
> + mode->crtc_hsync_start /= num_pipes;
> + mode->crtc_hsync_end /= num_pipes;
> + mode->crtc_htotal /= num_pipes;
> }
>
> static void intel_splitter_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> @@ -2809,16 +2811,17 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
>
> static void intel_bigjoiner_compute_pipe_src(struct intel_crtc_state
> *crtc_state)
> {
> + int num_pipes = hweight8(crtc_state->bigjoiner_pipes);
> int width, height;
>
> - if (!crtc_state->bigjoiner_pipes)
> + if (num_pipes < 2)
> return;
>
> width = drm_rect_width(_state->pipe_src);
> height = drm_rect_height(_state->pipe_src);
>
> drm_rect_init(_state->pipe_src, 0, 0,
> - width / 2, height);
> + width / num_pipes, height);
> }
>
> static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Eliminate bigjoiner boolean
enable);
> @@ -7535,32 +7539,26 @@ static int intel_atomic_check_bigjoiner(struct
> intel_atomic_state *state,
> struct intel_crtc_state *master_crtc_state =
> intel_atomic_get_new_crtc_state(state, master_crtc);
> struct intel_crtc *slave_crtc;
> - u8 slave_pipes;
>
> - /*
> - * TODO: encoder.compute_config() may be the best
> - * place to populate the bitmask for the master crtc.
> - * For now encoder.compute_config() just flags things
> - * as needing bigjoiner and we populate the bitmask
> - * here.
> - */
> - WARN_ON(master_crtc_state->bigjoiner_pipes);
> -
> - if (!master_crtc_state->bigjoiner)
> + if (!master_crtc_state->bigjoiner_pipes)
> return 0;
>
> - slave_pipes = BIT(master_crtc->pipe + 1);
> + /* sanity check */
> + if (drm_WARN_ON(>drm,
> + master_crtc->pipe !=
> bigjoiner_master_pipe(master_crtc_state)))
> + return -EINVAL;
>
> - if (slave_pipes & ~bigjoiner_pipes(i915)) {
> + if (master_crtc_state->bigjoiner_pipes & ~bigjoiner_pipes(i915)) {
So here we are making sure that in compute_config if master pipe = D and we
blidly set
genmask to have slave pipe = D + 1 = E then here this will catch it and fail
the atomic check
Is that undestanding correct?
With this and the concern that Ankit brought, but then we have that check in
enabled_bigjoiner_pipes()
Eeverything else makes sense
Reviewed-by: Manasi Navare
Manasi
> drm_dbg_kms(>drm,
> "[CRTC:%d:%s] Cannot act as big joiner master "
> - "(need 0x%x as slave pipes, only 0x%x possible)\n",
> + "(need 0x%x as pipes, only 0x%x possible)\n",
> master_crtc->base.base.id, master_crtc->base.name,
> - slave_pipes, bigjoiner_pipes(i915));
> + master_crtc_state->bigjoiner_pipes,
> bigjoiner_pipes(i915));
> return -EINVAL;
> }
>
> - for_each_intel_crtc_in_pipe_mask(>drm, slave_crtc, slave_pipes) {
> + for_each_intel_crtc_in_pipe_mask(>drm, slave_crtc,
> +
> intel_crtc_bigjoiner_slave_pipes(master_crtc_state)) {
> struct intel_crtc_state *slave_crtc_state;
> int ret;
>
> @@ -7594,10 +7592,8 @@ static int intel_atomic_check_bigjoiner(struct
> intel_atomic_state *state,
> slave_crtc->base.base.id, slave_crtc->base.name,
> master_crtc->base.base.id, master_crtc->base.name);
>
> - master_crtc_state->bigjoiner_pipes =
> - BIT(master_crtc->pipe) | BIT(slave_crtc->pipe);
> slave_crtc_state->bigjoiner_pipes =
> - BIT(master_crtc->pipe) | BIT(slave_crtc->pipe);
> + master_crtc_state->bigjoiner_pipes;
>
> ret = copy_bigjoiner_crtc_state_modeset(state, slave_crtc);
> if (ret)
> @@ -7620,13 +7616,11 @@ static void kill_bigjoiner_slave(struct
> intel_atomic_state *state,
> struct intel_crtc_state *slave_crtc_state =
> intel_atomic_get_new_crtc_state(state, slave_crtc);
>
> - slave_crtc_state->bigjoiner = false;
> slave_crtc_state->bigjoiner_pipes = 0;
>
> intel_crtc_copy_uapi_to_hw_state_modeset(state, slave_crtc);
> }
>
> - master_crtc_state->bigjoiner = false;
> master_crtc_state->bigjoiner_pipes = 0;
> }
>
> @@ -7936,7 +7930,7 @@ static int intel_atomic_check(struct drm_device *dev,
> }
> }
>
> - if (new_crtc_state->bigjoiner) {
> + if (new_crtc_state->bigjoiner_pipes) {
> if (intel_pipes_need_modeset(state,
> new_crtc_state->bigjoiner_pipes)) {
> new_crtc_state->uapi.mode_changed = true;
> new_crtc_state->update_pipe = false;
> @@ -10338,7 +10332,7 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
> intel_encoder_get_config(encoder, crtc_state);
>
> /* read out to slave crtc as well for bigjoiner */
> - if (crtc_state->bigjoiner) {
> + if (crtc_state->bigjoiner_pipes) {
> struct intel_crtc *slave_crtc;
>
> /* encoder should read be linked to bigjoiner
> master */
Re: [Intel-gfx] [PATCH 08/12] drm/i915: Fix MSO vs. bigjoiner timings confusion
On Tue, Feb 15, 2022 at 08:32:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When calculating pipe_mode and when doing readout we need
> to order our steps correctly.
>
> 1. We start with adjusted_mode crtc timings being populated
>with the transcoder timings (either via readout or
>compute_config(). These will be per-segment for MSO.
> 2. For all other uses we want the full crtc timings so
>we ask intel_splitter_adjust_timings() to expand
>the per-segment numbers to their full glory
> 3. If bigjoiner is used we the divide the full numbers
>down to per-pipe numbers using intel_bigjoiner_adjust_timings()
>
> During readout we also have to reconstruct the adjusted_mode
> normal timings (ie. not the crtc_ stuff). These are supposed
> to reflect the full timings of the display. So we grab these
> between steps 2 and 3.
>
> The "user" mode readout (mainly done for fastboot purposes)
> should be whatever mode the user would have used had they
> asked us to do a modeset. We want the full timings for this
> as the per-segment timings are not suppoesed to be user visible.
> Also the user mode normal timings hdisplay/vdisplay need to
> match PIPESRC (that is where we get our PIPESRC size
> we doing a modeset with a user supplied mode).
>
> And we end up with
> - adjusted_mode normal timigns == full timings
> - adjusted_mode crtc timings == transcoder timings
> (per-segment timings for MSO, full timings otherwise)
> - pipe_mode normal/crtc timings == pipe timings
> (full timings divided by the number of bigjoiner pipes, if any)
> - user mode normal timings == full timings with
> hdisplay/vdisplay replaced with PIPESRC size
> - user mode crtc timings == full timings
>
> Yes, that is a lot of timings. One day we'll try to remove
> some of the ones we don't actually need to keep around...
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 50 +---
> 1 file changed, 32 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6ff58164929c..131be3bb8026 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2769,25 +2769,33 @@ static void intel_crtc_readout_derived_state(struct
> intel_crtc_state *crtc_state
> struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
> struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
>
> + /*
> + * Start with the adjusted_mode crtc timings, which
> + * have been filled with the transcoder timings.
> + */
> drm_mode_copy(pipe_mode, adjusted_mode);
>
> - intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
> -
> - if (crtc_state->splitter.enable) {
> - intel_splitter_adjust_timings(crtc_state, pipe_mode);
> -
> - intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
> - intel_mode_from_crtc_timings(adjusted_mode, pipe_mode);
> - } else {
> - intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
> - intel_mode_from_crtc_timings(adjusted_mode, adjusted_mode);
> - }
> -
> - intel_crtc_compute_pixel_rate(crtc_state);
> -
> - drm_mode_copy(mode, adjusted_mode);
> + /* Expand MSO per-segment transcoder timings to full */
> + intel_splitter_adjust_timings(crtc_state, pipe_mode);
> +
> + /*
> + * We want the full numbers in adjusted_mode normal timings,
> + * adjusted_mode crtc timings are left with the raw transcoder
> + * timings.
> + */
> + intel_mode_from_crtc_timings(adjusted_mode, pipe_mode);
> +
> + /* Populate the "user" mode with full numbers */
> + drm_mode_copy(mode, pipe_mode);
> + intel_mode_from_crtc_timings(mode, mode);
> mode->hdisplay = crtc_state->pipe_src_w << crtc_state->bigjoiner;
> mode->vdisplay = crtc_state->pipe_src_h;
> +
> + /* Derive per-pipe timings in case bigjoiner is used */
> + intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
> + intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
> +
> + intel_crtc_compute_pixel_rate(crtc_state);
> }
>
> static void intel_encoder_get_config(struct intel_encoder *encoder,
> @@ -2836,15 +2844,21 @@ static int intel_crtc_compute_pipe_mode(struct
> intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct drm_display_mode *a
Re: [Intel-gfx] [PATCH 07/12] drm/i915: Extract intel_crtc_compute_pipe_mode()
On Tue, Feb 15, 2022 at 08:32:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull intel_crtc_compute_pipe_mode() out from
> intel_crtc_compute_config(). Since it's semi related
> we'll suck in the max dotclock/double wide checks in
> as well.
>
> And we'll pimp the debugs while at it.
>
> Signed-off-by: Ville Syrjälä
Yup looks lot more organized
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 28 ++--
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3d3fddd3f452..6ff58164929c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2832,17 +2832,12 @@ static int intel_crtc_compute_pipe_src(struct
> intel_crtc_state *crtc_state)
> return 0;
> }
>
> -static int intel_crtc_compute_config(struct intel_crtc *crtc,
> - struct intel_crtc_state *crtc_state)
> +static int intel_crtc_compute_pipe_mode(struct intel_crtc_state *crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
> int clock_limit = i915->max_dotclk_freq;
> - int ret;
> -
> - ret = intel_crtc_compute_pipe_src(crtc_state);
> - if (ret)
> - return ret;
>
> drm_mode_copy(pipe_mode, _state->hw.adjusted_mode);
>
> @@ -2868,12 +2863,29 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
>
> if (pipe_mode->crtc_clock > clock_limit) {
> drm_dbg_kms(>drm,
> - "requested pixel clock (%d kHz) too high (max: %d
> kHz, double wide: %s)\n",
> + "[CRTC:%d:%s] requested pixel clock (%d kHz) too
> high (max: %d kHz, double wide: %s)\n",
> + crtc->base.base.id, crtc->base.name,
> pipe_mode->crtc_clock, clock_limit,
> yesno(crtc_state->double_wide));
> return -EINVAL;
> }
>
> + return 0;
> +}
> +
> +static int intel_crtc_compute_config(struct intel_crtc *crtc,
> + struct intel_crtc_state *crtc_state)
> +{
> + int ret;
> +
> + ret = intel_crtc_compute_pipe_src(crtc_state);
> + if (ret)
> + return ret;
> +
> + ret = intel_crtc_compute_pipe_mode(crtc_state);
> + if (ret)
> + return ret;
> +
> intel_crtc_compute_pixel_rate(crtc_state);
>
> if (crtc_state->has_pch_encoder)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Extract intel_crtc_compute_pipe_src()
On Tue, Feb 15, 2022 at 08:32:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_crtc_compute_config() doesn't really tell a unified story.
> Let's chunk it up into pieces. We'll start with
> intel_crtc_compute_pipe_src().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
with just one clarification below
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 62
> 1 file changed, 39 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 19417ff975c6..3d3fddd3f452 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2798,18 +2798,55 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
> intel_crtc_readout_derived_state(crtc_state);
> }
>
> +static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> +
> + if (crtc_state->bigjoiner)
> + crtc_state->pipe_src_w /= 2;
> +
> + /*
> + * Pipe horizontal size must be even in:
> + * - DVO ganged mode
> + * - LVDS dual channel mode
> + * - Double wide pipe
> + */
> + if (crtc_state->pipe_src_w & 1) {
> + if (crtc_state->double_wide) {
> + drm_dbg_kms(>drm,
> + "[CRTC:%d:%s] Odd pipe source width not
> supported with double wide pipe\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> +
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> + intel_is_dual_link_lvds(i915)) {
> + drm_dbg_kms(>drm,
> + "[CRTC:%d:%s] Odd pipe source width not
> supported with dual link LVDS\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> static int intel_crtc_compute_config(struct intel_crtc *crtc,
>struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
> int clock_limit = i915->max_dotclk_freq;
> + int ret;
> +
> + ret = intel_crtc_compute_pipe_src(crtc_state);
Here crtc_state->pipe_src_w would already have been populated right?
Just wanted to double check since we are moving this earlier in the function
Manasi
> + if (ret)
> + return ret;
>
> drm_mode_copy(pipe_mode, _state->hw.adjusted_mode);
>
> intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
> - if (crtc_state->bigjoiner)
> - crtc_state->pipe_src_w /= 2;
>
> intel_splitter_adjust_timings(crtc_state, pipe_mode);
>
> @@ -2837,27 +2874,6 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> return -EINVAL;
> }
>
> - /*
> - * Pipe horizontal size must be even in:
> - * - DVO ganged mode
> - * - LVDS dual channel mode
> - * - Double wide pipe
> - */
> - if (crtc_state->pipe_src_w & 1) {
> - if (crtc_state->double_wide) {
> - drm_dbg_kms(>drm,
> - "Odd pipe source width not supported with
> double wide pipe\n");
> - return -EINVAL;
> - }
> -
> - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> - intel_is_dual_link_lvds(i915)) {
> - drm_dbg_kms(>drm,
> - "Odd pipe source width not supported with
> dual link LVDS\n");
> - return -EINVAL;
> - }
> - }
> -
> intel_crtc_compute_pixel_rate(crtc_state);
>
> if (crtc_state->has_pch_encoder)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Extract intel_bigjoiner_adjust_timings()
On Tue, Feb 15, 2022 at 08:32:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deduplicate the code to convert the full timings to
> per-pipe timings for bigjoiner usage.
>
> Signed-off-by: Ville Syrjälä
Makes sense to have a helper to do this:
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 41 +---
> 1 file changed, 18 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 70017526fa81..19417ff975c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2724,6 +2724,21 @@ static void intel_crtc_compute_pixel_rate(struct
> intel_crtc_state *crtc_state)
> ilk_pipe_pixel_rate(crtc_state);
> }
>
> +static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> +struct drm_display_mode *mode)
> +{
> + if (!crtc_state->bigjoiner)
> + return;
> +
> + mode->crtc_clock /= 2;
> + mode->crtc_hdisplay /= 2;
> + mode->crtc_hblank_start /= 2;
> + mode->crtc_hblank_end /= 2;
> + mode->crtc_hsync_start /= 2;
> + mode->crtc_hsync_end /= 2;
> + mode->crtc_htotal /= 2;
> +}
> +
> static void intel_splitter_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> struct drm_display_mode *mode)
> {
> @@ -2756,19 +2771,7 @@ static void intel_crtc_readout_derived_state(struct
> intel_crtc_state *crtc_state
>
> drm_mode_copy(pipe_mode, adjusted_mode);
>
> - if (crtc_state->bigjoiner) {
> - /*
> - * transcoder is programmed to the full mode,
> - * but pipe timings are half of the transcoder mode
> - */
> - pipe_mode->crtc_hdisplay /= 2;
> - pipe_mode->crtc_hblank_start /= 2;
> - pipe_mode->crtc_hblank_end /= 2;
> - pipe_mode->crtc_hsync_start /= 2;
> - pipe_mode->crtc_hsync_end /= 2;
> - pipe_mode->crtc_htotal /= 2;
> - pipe_mode->crtc_clock /= 2;
> - }
> + intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
>
> if (crtc_state->splitter.enable) {
> intel_splitter_adjust_timings(crtc_state, pipe_mode);
> @@ -2804,17 +2807,9 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
>
> drm_mode_copy(pipe_mode, _state->hw.adjusted_mode);
>
> - /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
> - if (crtc_state->bigjoiner) {
> - pipe_mode->crtc_clock /= 2;
> - pipe_mode->crtc_hdisplay /= 2;
> - pipe_mode->crtc_hblank_start /= 2;
> - pipe_mode->crtc_hblank_end /= 2;
> - pipe_mode->crtc_hsync_start /= 2;
> - pipe_mode->crtc_hsync_end /= 2;
> - pipe_mode->crtc_htotal /= 2;
> + intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
> + if (crtc_state->bigjoiner)
> crtc_state->pipe_src_w /= 2;
> - }
>
> intel_splitter_adjust_timings(crtc_state, pipe_mode);
>
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Rename variables in intel_crtc_compute_config()
On Tue, Feb 15, 2022 at 08:31:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Do the s/dev_priv/i915/ and s/pipe_config/crtc_state/ renames
> to intel_crtc_compute_config(). I want to start splitting this
> up a bit and doing the renames now avoids spreading these old
> nameing conventions elsewhere.
>
> Signed-off-by: Ville Syrjälä
Yes the name cleanup looks good, would be good to call out "No functional
changes" in the
commit message.
With that
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 50 ++--
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 49ca13abd108..5da8db3dda8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2787,16 +2787,16 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
> }
>
> static int intel_crtc_compute_config(struct intel_crtc *crtc,
> - struct intel_crtc_state *pipe_config)
> + struct intel_crtc_state *crtc_state)
> {
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct drm_display_mode *pipe_mode = _config->hw.pipe_mode;
> - int clock_limit = dev_priv->max_dotclk_freq;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
> + int clock_limit = i915->max_dotclk_freq;
>
> - drm_mode_copy(pipe_mode, _config->hw.adjusted_mode);
> + drm_mode_copy(pipe_mode, _state->hw.adjusted_mode);
>
> /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
> - if (pipe_config->bigjoiner) {
> + if (crtc_state->bigjoiner) {
> pipe_mode->crtc_clock /= 2;
> pipe_mode->crtc_hdisplay /= 2;
> pipe_mode->crtc_hblank_start /= 2;
> @@ -2804,12 +2804,12 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
> pipe_mode->crtc_hsync_start /= 2;
> pipe_mode->crtc_hsync_end /= 2;
> pipe_mode->crtc_htotal /= 2;
> - pipe_config->pipe_src_w /= 2;
> + crtc_state->pipe_src_w /= 2;
> }
>
> - if (pipe_config->splitter.enable) {
> - int n = pipe_config->splitter.link_count;
> - int overlap = pipe_config->splitter.pixel_overlap;
> + if (crtc_state->splitter.enable) {
> + int n = crtc_state->splitter.link_count;
> + int overlap = crtc_state->splitter.pixel_overlap;
>
> pipe_mode->crtc_hdisplay = (pipe_mode->crtc_hdisplay - overlap)
> * n;
> pipe_mode->crtc_hblank_start = (pipe_mode->crtc_hblank_start -
> overlap) * n;
> @@ -2822,8 +2822,8 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
>
> intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
>
> - if (DISPLAY_VER(dev_priv) < 4) {
> - clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
> + if (DISPLAY_VER(i915) < 4) {
> + clock_limit = i915->max_cdclk_freq * 9 / 10;
>
> /*
>* Enable double wide mode when the dot clock
> @@ -2831,16 +2831,16 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
>*/
> if (intel_crtc_supports_double_wide(crtc) &&
> pipe_mode->crtc_clock > clock_limit) {
> - clock_limit = dev_priv->max_dotclk_freq;
> - pipe_config->double_wide = true;
> + clock_limit = i915->max_dotclk_freq;
> + crtc_state->double_wide = true;
> }
> }
>
> if (pipe_mode->crtc_clock > clock_limit) {
> - drm_dbg_kms(_priv->drm,
> + drm_dbg_kms(>drm,
> "requested pixel clock (%d kHz) too high (max: %d
> kHz, double wide: %s)\n",
> pipe_mode->crtc_clock, clock_limit,
> - yesno(pipe_config->double_wide));
> + yesno(crtc_state->double_wide));
> return -EINVAL;
> }
>
> @@ -2850,25 +2850,25 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
>* - LVDS dual channel mode
>* - Double wide pipe
>*/
> - if (pipe_config->pipe_src
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix cursor coordinates on bigjoiner slave
On Wed, Feb 16, 2022 at 10:39:56AM +0200, Ville Syrjälä wrote: > On Tue, Feb 15, 2022 at 07:25:36PM -0800, Navare, Manasi wrote: > > On Tue, Feb 15, 2022 at 08:31:57PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Adjust the cursor dst coordinates appripriately when it's on > > > the bigjoiner slave pipe. intel_atomic_plane_check_clipping() > > > already did this but with the cursor we discard those results > > > (apart from uapi.visible and error checks) since the hardware > > > will be doing the clipping for us. > > > > > > v2: Rebase due to bigjoiner bitmask usage > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/display/intel_cursor.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c > > > b/drivers/gpu/drm/i915/display/intel_cursor.c > > > index 2ade8fdd9bdd..3e80763aa828 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c > > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c > > > @@ -152,6 +152,9 @@ static int intel_check_cursor(struct intel_crtc_state > > > *crtc_state, > > > /* Use the unclipped src/dst rectangles, which we program to hw */ > > > plane_state->uapi.src = src; > > > plane_state->uapi.dst = dst; > > > + if (intel_crtc_is_bigjoiner_slave(crtc_state)) > > > + drm_rect_translate(_state->uapi.dst, > > > +-crtc_state->pipe_src_w, 0); > > > > So this is basically to offset the cursor position from say 3860 to 0, 3861 > > to 1 7680 to 3860 for the right half > > of the screen right? > > And without this, it will just keep it at first rectangle? > > Yes. The original rectangle came from userspace and is thus > relative to the whole area covered by all the joined pipes. > But the plane coordinates we hand to the hardware must be > relative to their respective pipe. > > It's a bit ugly as is but works for now. The last patch make > this much nicer by removing all the assumptions here about > the relative positions of the pipes. Okay yes makes sens, Reviewed-by: Manasi Navare Manasi > > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix cursor coordinates on bigjoiner slave
On Tue, Feb 15, 2022 at 08:31:57PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Adjust the cursor dst coordinates appripriately when it's on > the bigjoiner slave pipe. intel_atomic_plane_check_clipping() > already did this but with the cursor we discard those results > (apart from uapi.visible and error checks) since the hardware > will be doing the clipping for us. > > v2: Rebase due to bigjoiner bitmask usage > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_cursor.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c > b/drivers/gpu/drm/i915/display/intel_cursor.c > index 2ade8fdd9bdd..3e80763aa828 100644 > --- a/drivers/gpu/drm/i915/display/intel_cursor.c > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c > @@ -152,6 +152,9 @@ static int intel_check_cursor(struct intel_crtc_state > *crtc_state, > /* Use the unclipped src/dst rectangles, which we program to hw */ > plane_state->uapi.src = src; > plane_state->uapi.dst = dst; > + if (intel_crtc_is_bigjoiner_slave(crtc_state)) > + drm_rect_translate(_state->uapi.dst, > +-crtc_state->pipe_src_w, 0); So this is basically to offset the cursor position from say 3860 to 0, 3861 to 1 7680 to 3860 for the right half of the screen right? And without this, it will just keep it at first rectangle? Manasi > > ret = intel_cursor_check_surface(plane_state); > if (ret) > -- > 2.34.1 >
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/dgfx: Get VBT from rvda
On Tue, Feb 15, 2022 at 07:07:27PM +0530, Anshuman Gupta wrote:
> Since OpRegion ver 2.1 MBOX3 RVDA field is Relative address of Raw
> VBT data from OpRegion Base.
> Populate the opreion->rvda accordingly.
> As Intel DGFX cards supports OpRegion version 2.2 or greater,
> RVDA as an absolute VBT physical address (Ver 2.0) doesn't applicable
> to DGFX cards.
>
> v2:
> - Add kzalloc NULL check for opreg_rvda pointer.
>
> Cc: Jani Nikula
> Cc: Uma Shankar
> Cc: Rodrigo Vivi
> Reviewed-by: Uma Shankar
> Reviewed-by: Badal Nilawar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 22 ++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 8af3a92582cb..9907dae8f3cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -1625,11 +1625,31 @@ static void *intel_dgfx_alloc_opregion(struct
> drm_i915_private *i915)
>
> static void *intel_dgfx_alloc_rvda(struct drm_i915_private *i915)
> {
> - return ERR_PTR(-EOPNOTSUPP);
> + struct intel_opregion *opregion = >opregion;
> + void *opreg_rvda;
> +
> + if (!opregion->dgfx_oprom_opreg)
> + return ERR_PTR(-EINVAL);
> +
> + opreg_rvda = kzalloc(opregion->asle->rvds, GFP_KERNEL);
> + if (!opreg_rvda)
> + return ERR_PTR(-ENOMEM);
> +
> + memcpy(opreg_rvda, opregion->dgfx_oprom_opreg + opregion->asle->rvda,
> opregion->asle->rvds);
The suggestion here by Chris Wilson was to replace kzalloc + memcpy with kmemdup
Please add that and give necessary credits for changes done by me in DII and
suggested by Chris Wilson
Manasi
> +
> + /* We got RVDA, OPROM opregion + vbt image not nedded anymore */
> + kfree(opregion->dgfx_oprom_opreg);
> + opregion->dgfx_oprom_opreg = NULL;
> +
> + return opreg_rvda;
> }
>
> static void intel_dgfx_free_rvda(struct drm_i915_private *i915)
> {
> + struct intel_opregion *opregion = >opregion;
> +
> + kfree(opregion->rvda);
> + opregion->rvda = NULL;
> }
>
> static void intel_dgfx_free_opregion(struct drm_i915_private *i915)
> --
> 2.26.2
>
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/opregion: Abstract opregion function
On Tue, Feb 15, 2022 at 07:07:23PM +0530, Anshuman Gupta wrote:
> Abstract opregion operations like get opregion base, get rvda and
> opregion cleanup in form of i915_opregion_ops.
> This will be required to converge igfx and dgfx opregion.
>
> v2:
> - Keep only function pointer abstraction stuff. [Jani]
> - Add alloc_rvda error handling.
Please add the version changelog from the error handling that I have added in
DII
Since it uses that error handling, please give necessary credits as well.
Manasi
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Badal Nilawar
> Cc: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 179 +-
> drivers/gpu/drm/i915/display/intel_opregion.h | 3 +
> 2 files changed, 134 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 9b56064ddb5d..94eb7c23fcb4 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -138,6 +138,13 @@ struct opregion_asle_ext {
> u8 rsvd[764];
> } __packed;
>
> +struct i915_opregion_func {
> + void *(*alloc_opregion)(struct drm_i915_private *i915);
> + void *(*alloc_rvda)(struct drm_i915_private *i915);
> + void (*free_rvda)(struct drm_i915_private *i915);
> + void (*free_opregion)(struct drm_i915_private *i915);
> +};
> +
> /* Driver readiness indicator */
> #define ASLE_ARDY_READY (1 << 0)
> #define ASLE_ARDY_NOT_READY (0 << 0)
> @@ -876,10 +883,7 @@ static int intel_load_vbt_firmware(struct
> drm_i915_private *dev_priv)
> static int intel_opregion_setup(struct drm_i915_private *dev_priv)
> {
> struct intel_opregion *opregion = _priv->opregion;
> - struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> - u32 asls, mboxes;
> - char buf[sizeof(OPREGION_SIGNATURE)];
> - int err = 0;
> + u32 mboxes;
> void *base;
> const void *vbt;
> u32 vbt_size;
> @@ -890,27 +894,12 @@ static int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> BUILD_BUG_ON(sizeof(struct opregion_asle) != 0x100);
> BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
>
> - pci_read_config_dword(pdev, ASLS, );
> - drm_dbg(_priv->drm, "graphic opregion physical addr: 0x%x\n",
> - asls);
> - if (asls == 0) {
> - drm_dbg(_priv->drm, "ACPI OpRegion not supported!\n");
> - return -ENOTSUPP;
> - }
> -
> INIT_WORK(>asle_work, asle_work);
>
> - base = memremap(asls, OPREGION_SIZE, MEMREMAP_WB);
> - if (!base)
> - return -ENOMEM;
> + base = opregion->opregion_func->alloc_opregion(dev_priv);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>
> - memcpy(buf, base, sizeof(buf));
> -
> - if (memcmp(buf, OPREGION_SIGNATURE, 16)) {
> - drm_dbg(_priv->drm, "opregion signature mismatch\n");
> - err = -EINVAL;
> - goto err_out;
> - }
> opregion->header = base;
> opregion->lid_state = base + ACPI_CLID;
>
> @@ -970,23 +959,10 @@ static int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
>
> if (opregion->header->over.major >= 2 && opregion->asle &&
> opregion->asle->rvda && opregion->asle->rvds) {
> - resource_size_t rvda = opregion->asle->rvda;
> -
> - /*
> - * opregion 2.0: rvda is the physical VBT address.
> - *
> - * opregion 2.1+: rvda is unsigned, relative offset from
> - * opregion base, and should never point within opregion.
> - */
> - if (opregion->header->over.major > 2 ||
> - opregion->header->over.minor >= 1) {
> - drm_WARN_ON(_priv->drm, rvda < OPREGION_SIZE);
> -
> - rvda += asls;
> - }
>
> - opregion->rvda = memremap(rvda, opregion->asle->rvds,
> - MEMREMAP_WB);
> + opregion->rvda = opregion->opregion_func->alloc_rvda(dev_priv);
> + if (IS_ERR(opregion->rvda))
> + goto mbox4_vbt;
>
> vbt = opregion->rvda;
> vbt_size = opregion->asle->rvds;
> @@ -999,11 +975,12 @@ static int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> } else {
> drm_dbg_kms(_priv->drm,
> "Invalid VBT in ACPI OpRegion (RVDA)\n");
> - memunmap(opregion->rvda);
> - opregion->rvda = NULL;
> + opregion->opregion_func->free_rvda(dev_priv);
> }
> }
>
> +mbox4_vbt:
> +
> vbt = base + OPREGION_VBT_OFFSET;
> /*
>* The VBT specification says that if the ASLE ext mailbox is not used
> @@ -1028,9 +1005,6 @@ static int
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/dgfx: OPROM OpRegion Setup
On Tue, Feb 15, 2022 at 07:07:26PM +0530, Anshuman Gupta wrote:
> On igfx cards ACPI OpRegion retrieve through ASLS.
> System BIOS writes ASLS address to pci config space(0xFC) but
> on discrete cards OpRegion is part of PCI Option ROM(OPROM) along
> with other firmware images, i915 is interested only in
> Code Signature System(CSS) and OpRegion + VBT image.
>
> DGFX Cards has it dedicated flash, where OPROM reside.
> DGFX card provides SPI controller interface to read the OPROM.
> Read OPROM through SPI MMIO because PCI ROM mapping may does not
> work on some platforms due to the BIOS not leaving the OPROM mapped.
>
> In order to setup OpRegion and retrieve VBT from OpRegion,
> it is required to do OPROM sanity check.
>
> OPROM Sanity checks involves below steps.
>
> Verify OPROM images Signature as Documented in PCI firmware Specs 3.2.
> Verify Intel CSS image signature.
> Verify the Intel CSS image code type.
> Authenticate OPROM RSA Signature. (TODO)
> Verify OpRegion image Signature.
>
> After successful sanity check, driver will consume the OPROM
> config data to get opreg and vbt accordingly.
>
> v2:
> - Add kzalloc NULL check for oprom_opreg pointer.
> - Fixed memory leak in intel_spi_get_oprom_opreg().
>
> PCI Firmware Spec: ID:12886
> https://pcisig.com/specifications
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Uma Shankar
> Cc: Badal Nilawar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 343 +-
> drivers/gpu/drm/i915/display/intel_opregion.h | 1 +
> 2 files changed, 327 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 562161a929d6..8af3a92582cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -31,6 +31,7 @@
> #include
>
> #include "i915_drv.h"
> +#include "i915_reg.h"
> #include "intel_acpi.h"
> #include "intel_backlight.h"
> #include "intel_display_types.h"
> @@ -145,6 +146,34 @@ struct i915_opregion_func {
> void (*free_opregion)(struct drm_i915_private *i915);
> };
>
> +/* Refer 8_PCI_Firmware_v3.2_01-26-2015_ts_clean_Firmware_Final Page 77 */
> +struct expansion_rom_header {
> + u16 signature; /* Offset[0x0]: Header 0x55 0xAA */
> + u8 resvd[0x16];
> + u16 pcistructoffset;/* Offset[0x18]: Contains pointer PCI Data
> Structure */
> + u16 img_base; /* Offset[0x1A]: Offset to Oprom Image Base
> start */
> +} __packed;
> +
> +struct pci_data_structure {
> + u32 signature;
> + u8 resvd[12];
> + u16 img_len;
> + u8 resvd1[2];
> + u8 code_type;
> + u8 last_img;
> + u8 resvd2[6];
> +} __packed;
> +
> +/* PCI Firmware Spec specific Macro */
> +#define LAST_IMG_INDICATOR 0x80
> +#define OPROM_IMAGE_MAGIC0xAA55 /* Little Endian */
> +#define OPROM_IMAGE_PCIR_MAGIC 0x52494350 /* "PCIR" */
> +#define OPROM_BYTE_BOUNDARY 512 /* OPROM image sizes are
> in 512 byte */
> +
> +#define INTEL_CSS_SIGNATURE "$CPD" /* Code Signature System
> Signature */
> +#define NUM_CSS_BYTES4
> +#define INTEL_OPROM_CSS_CODE_TYPE0xF0
> +
> /* Driver readiness indicator */
> #define ASLE_ARDY_READY (1 << 0)
> #define ASLE_ARDY_NOT_READY (0 << 0)
> @@ -880,6 +909,196 @@ static int intel_load_vbt_firmware(struct
> drm_i915_private *dev_priv)
> return ret;
> }
>
> +/* Refer PCI Firmware Spec Chapter 5 */
> +static int
> +pci_exp_rom_check_signature(struct drm_i915_private *i915,
> + struct expansion_rom_header *exprom_hdr,
> + struct pci_data_structure *exprom_pci_data)
> +{
> + if (exprom_hdr->signature != OPROM_IMAGE_MAGIC) {
> + drm_err(>drm, "Invalid PCI ROM header signature.\n");
> + return -EINVAL;
> + }
> +
> + if (exprom_pci_data->signature != OPROM_IMAGE_PCIR_MAGIC) {
> + drm_err(>drm, "Invalid PCI ROM data signature.\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static u32 intel_spi_oprom_offset(struct drm_i915_private *i915)
> +{
> + u32 static_region, offset;
> +
> + /* initialize SPI to read the OPROM */
> + static_region = intel_uncore_read(>uncore, SPI_STATIC_REGIONS);
> + static_region &= OPTIONROM_SPI_REGIONID_MASK;
> + intel_uncore_write(>uncore, PRIMARY_SPI_REGIONID, static_region);
> +
> + /* read OPROM offset in SPI flash */
> + offset = intel_uncore_read(>uncore, OROM_OFFSET);
> +
> + return offset;
> +}
> +
> +static void intel_spi_read_oprom(struct drm_i915_private *i915,
> + u32 offset, size_t len, void *buf)
> +{
> + u32 count, data;
> + u32 *word = buf;
> +
> + drm_WARN_ON(>drm, !IS_ALIGNED(len, 4));
> +
> + for (count = 0; count < len;
Re: [Intel-gfx] [PATCH 09/10] drm/i915: Return both master and slave pipes from enabled_bigjoiner_pipes()
On Thu, Feb 03, 2022 at 08:38:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Return both the master and slave pipe bitmasks from
> enabled_bigjoiner_pipes(). We'll have use for both during
> readout soon.
>
> Signed-off-by: Ville Syrjälä
This looks good, can this be just combined with the patch that would use the
slave and mastr pipes
in the readout ?
Either way,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 25 +++-
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6df498fc720a..34b6b4ab3a1b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4064,11 +4064,14 @@ static bool transcoder_ddi_func_is_enabled(struct
> drm_i915_private *dev_priv,
> return tmp & TRANS_DDI_FUNC_ENABLE;
> }
>
> -static u8 enabled_bigjoiner_pipes(struct drm_i915_private *dev_priv)
> +static void enabled_bigjoiner_pipes(struct drm_i915_private *dev_priv,
> + u8 *master_pipes, u8 *slave_pipes)
> {
> - u8 master_pipes = 0, slave_pipes = 0;
> struct intel_crtc *crtc;
>
> + *master_pipes = 0;
> + *slave_pipes = 0;
> +
> for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc,
>bigjoiner_pipes(dev_priv)) {
> enum intel_display_power_domain power_domain;
> @@ -4083,9 +4086,9 @@ static u8 enabled_bigjoiner_pipes(struct
> drm_i915_private *dev_priv)
> continue;
>
> if (tmp & MASTER_BIG_JOINER_ENABLE)
> - master_pipes |= BIT(pipe);
> + *master_pipes |= BIT(pipe);
> else
> - slave_pipes |= BIT(pipe);
> + *slave_pipes |= BIT(pipe);
> }
>
> if (DISPLAY_VER(dev_priv) < 13)
> @@ -4096,18 +4099,16 @@ static u8 enabled_bigjoiner_pipes(struct
> drm_i915_private *dev_priv)
> u32 tmp = intel_de_read(dev_priv,
> ICL_PIPE_DSS_CTL1(pipe));
>
> if (tmp & UNCOMPRESSED_JOINER_MASTER)
> - master_pipes |= BIT(pipe);
> + *master_pipes |= BIT(pipe);
> if (tmp & UNCOMPRESSED_JOINER_SLAVE)
> - slave_pipes |= BIT(pipe);
> + *slave_pipes |= BIT(pipe);
> }
> }
>
> /* Bigjoiner pipes should always be consecutive master and slave */
> - drm_WARN(_priv->drm, slave_pipes != master_pipes << 1,
> + drm_WARN(_priv->drm, *slave_pipes != *master_pipes << 1,
>"Bigjoiner misconfigured (master pipes 0x%x, slave pipes
> 0x%x)\n",
> - master_pipes, slave_pipes);
> -
> - return slave_pipes;
> + *master_pipes, *slave_pipes);
> }
>
> static u8 hsw_panel_transcoders(struct drm_i915_private *i915)
> @@ -4126,6 +4127,7 @@ static u8 hsw_enabled_transcoders(struct intel_crtc
> *crtc)
> struct drm_i915_private *dev_priv = to_i915(dev);
> u8 panel_transcoder_mask = hsw_panel_transcoders(dev_priv);
> enum transcoder cpu_transcoder;
> + u8 master_pipes, slave_pipes;
> u8 enabled_transcoders = 0;
>
> /*
> @@ -4177,7 +4179,8 @@ static u8 hsw_enabled_transcoders(struct intel_crtc
> *crtc)
> enabled_transcoders |= BIT(cpu_transcoder);
>
> /* bigjoiner slave -> consider the master pipe's transcoder as well */
> - if (enabled_bigjoiner_pipes(dev_priv) & BIT(crtc->pipe)) {
> + enabled_bigjoiner_pipes(dev_priv, _pipes, _pipes);
> + if (slave_pipes & BIT(crtc->pipe)) {
> cpu_transcoder = (enum transcoder) crtc->pipe - 1;
> if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
> enabled_transcoders |= BIT(cpu_transcoder);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Use for_each_intel_crtc_in_pipe_mask() more
On Thu, Feb 03, 2022 at 08:38:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Convert a few hand roller for_each_intel_crtc_in_pipe_mask()
> to the real thing.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 9a7f40d17b79..6df498fc720a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4069,14 +4069,12 @@ static u8 enabled_bigjoiner_pipes(struct
> drm_i915_private *dev_priv)
> u8 master_pipes = 0, slave_pipes = 0;
> struct intel_crtc *crtc;
>
> - for_each_intel_crtc(_priv->drm, crtc) {
> + for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc,
> + bigjoiner_pipes(dev_priv)) {
> enum intel_display_power_domain power_domain;
> enum pipe pipe = crtc->pipe;
> intel_wakeref_t wakeref;
>
> - if ((bigjoiner_pipes(dev_priv) & BIT(pipe)) == 0)
> - continue;
> -
> power_domain = intel_dsc_power_domain(crtc, (enum transcoder)
> pipe);
> with_intel_display_power_if_enabled(dev_priv, power_domain,
> wakeref) {
> u32 tmp = intel_de_read(dev_priv,
> ICL_PIPE_DSS_CTL1(pipe));
> @@ -8993,10 +8991,8 @@ static u32 intel_encoder_possible_crtcs(struct
> intel_encoder *encoder)
> struct intel_crtc *crtc;
> u32 possible_crtcs = 0;
>
> - for_each_intel_crtc(dev, crtc) {
> - if (encoder->pipe_mask & BIT(crtc->pipe))
> - possible_crtcs |= drm_crtc_mask(>base);
> - }
> + for_each_intel_crtc_in_pipe_mask(dev, crtc, encoder->pipe_mask)
> + possible_crtcs |= drm_crtc_mask(>base);
>
> return possible_crtcs;
> }
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 07/10] drm/i915: Convert for_each_intel_crtc_mask() to take a pipe mask instead
On Thu, Feb 03, 2022 at 08:38:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Often using pipes is more convenient than crtc indices.
> Convert the current for_each_intel_crtc_mask() to take a
> pipe mask instead of a crtc index mask, and rename it to
> for_each_intel_crtc_in_pipe_mask() to make it clear what
> it does.
>
> The current users of for_each_intel_crtc_mask() don't really
> care which kind of mask we use, but for other uses a pipe
> mask if better.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 4 +--
> drivers/gpu/drm/i915/display/intel_dp.c | 34 ++--
> 2 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 22e5f0d6e171..fe9eb3acee65 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -430,11 +430,11 @@ enum hpd_pin {
> &(dev)->mode_config.crtc_list, \
> base.head)
>
> -#define for_each_intel_crtc_mask(dev, intel_crtc, crtc_mask) \
> +#define for_each_intel_crtc_in_pipe_mask(dev, intel_crtc, pipe_mask) \
> list_for_each_entry(intel_crtc, \
> &(dev)->mode_config.crtc_list, \
> base.head) \
> - for_each_if((crtc_mask) & drm_crtc_mask(_crtc->base))
> + for_each_if((pipe_mask) & BIT(intel_crtc->pipe))
>
> #define for_each_intel_encoder(dev, intel_encoder) \
> list_for_each_entry(intel_encoder, \
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 146b83916005..3fb9f643ebb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3810,14 +3810,14 @@ static bool intel_dp_has_connector(struct intel_dp
> *intel_dp,
>
> static int intel_dp_prep_link_retrain(struct intel_dp *intel_dp,
> struct drm_modeset_acquire_ctx *ctx,
> - u32 *crtc_mask)
> + u8 *pipe_mask)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct drm_connector_list_iter conn_iter;
> struct intel_connector *connector;
> int ret = 0;
>
> - *crtc_mask = 0;
> + *pipe_mask = 0;
>
> if (!intel_dp_needs_link_retrain(intel_dp))
> return 0;
> @@ -3851,12 +3851,12 @@ static int intel_dp_prep_link_retrain(struct intel_dp
> *intel_dp,
> !try_wait_for_completion(_state->commit->hw_done))
> continue;
>
> - *crtc_mask |= drm_crtc_mask(>base);
> + *pipe_mask |= BIT(crtc->pipe);
> }
> drm_connector_list_iter_end(_iter);
>
> if (!intel_dp_needs_link_retrain(intel_dp))
> - *crtc_mask = 0;
> + *pipe_mask = 0;
>
> return ret;
> }
> @@ -3875,7 +3875,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> struct intel_crtc *crtc;
> - u32 crtc_mask;
> + u8 pipe_mask;
> int ret;
>
> if (!intel_dp_is_connected(intel_dp))
> @@ -3886,17 +3886,17 @@ int intel_dp_retrain_link(struct intel_encoder
> *encoder,
> if (ret)
> return ret;
>
> - ret = intel_dp_prep_link_retrain(intel_dp, ctx, _mask);
> + ret = intel_dp_prep_link_retrain(intel_dp, ctx, _mask);
> if (ret)
> return ret;
>
> - if (crtc_mask == 0)
> + if (pipe_mask == 0)
> return 0;
>
> drm_dbg_kms(_priv->drm, "[ENCODER:%d:%s] retraining link\n",
> encoder->base.base.id, encoder->base.name);
>
> - for_each_intel_crtc_mask(_priv->drm, crtc, crtc_mask) {
> + for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc, pipe_mask) {
> const struct intel_crtc_state *crtc_state =
> to_intel_crtc_state(crtc->base.state);
>
> @@ -3907,7 +3907,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
>
> intel_crtc_pch_transcoder(crtc), false);
> }
>
> - for_each_int
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Change bigjoiner state tracking to use the pipe bitmask
On Mon, Feb 07, 2022 at 09:31:19AM +0200, Ville Syrjälä wrote:
> On Fri, Feb 04, 2022 at 03:58:29PM -0800, Navare, Manasi wrote:
> > On Thu, Feb 03, 2022 at 08:38:23PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Get rid of the inflexible bigjoiner_linked_crtc pointer thing
> > > and just track things as a bitmask of pipes instead. We can
> > > also nuke the bigjoiner_slave boolean as the role of the pipe
> > > can be determined from its position in the bitmask.
> > >
> > > It might be possible to nuke the bigjoiner boolean as well
> > > if we make encoder.compute_config() do the bitmask assignment
> > > directly for the master pipe. But for now I left that alone so
> > > that encoer.compute_config() will just flag the state as needing
> > > bigjoiner, and the intel_atomic_check_bigjoiner() is still
> > > responsible for determining the bitmask. But that may have to change
> > > as the encoder may be in the best position to determine how
> > > exactly we should populate the bitmask.
> > >
> > > Most places that just looked at the single bigjoiner_linked_crtc
> > > now iterate over the whole bitmask, eliminating the singular
> > > slave pipe assumption.
> >
> > Okay so trying to understand the design here:
> > For Pipe A + B Bigjoiner and C + D bigjoiner for example,
> > bitmasks will be as below:
> >
> > A : 0011
> > B: 0011
> >
> > C: 1100
> > D: 1100
> >
> > Is this correct understanding? Because we would mark both the master pipe
> > and slave pipe in a bitmask right?
>
> Yes.
>
> >
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > .../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
> > > drivers/gpu/drm/i915/display/intel_display.c | 305 --
> > > drivers/gpu/drm/i915/display/intel_display.h | 2 +
> > > .../drm/i915/display/intel_display_debugfs.c | 5 +-
> > > .../drm/i915/display/intel_display_types.h| 7 +-
> > > .../drm/i915/display/intel_plane_initial.c| 7 -
> > > drivers/gpu/drm/i915/display/intel_vdsc.c | 43 ---
> > > drivers/gpu/drm/i915/display/intel_vdsc.h | 1 -
> > > 9 files changed, 227 insertions(+), 160 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > index 41d52889dfce..0e15fe908855 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > @@ -404,9 +404,10 @@ int intel_plane_atomic_check(struct
> > > intel_atomic_state *state,
> > > intel_atomic_get_new_crtc_state(state, crtc);
> > >
> > > if (new_crtc_state && intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> > > + struct intel_crtc *master_crtc =
> > > + intel_master_crtc(new_crtc_state);
> > > struct intel_plane *master_plane =
> > > -
> > > intel_crtc_get_plane(new_crtc_state->bigjoiner_linked_crtc,
> > > - plane->id);
> > > + intel_crtc_get_plane(master_crtc, plane->id);
> > >
> > > new_master_plane_state =
> > > intel_atomic_get_new_plane_state(state, master_plane);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 3f0e1e127595..9dee12986991 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -2703,6 +2703,7 @@ static void intel_ddi_post_disable(struct
> > > intel_atomic_state *state,
> > > struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > > enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > > bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
> > > + struct intel_crtc *slave_crtc;
> > >
> > > if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> > > intel_crtc_vblank_off(old_crtc_state);
> > > @@ -2721,9 +2722,8 @@ static void intel_ddi_post_disable(struct
> > > intel_atomic_state *state,
> > > ilk_pfit_disable(old_crtc_state);
> > > }
> > >
> > > - if
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Change bigjoiner state tracking to use the pipe bitmask
On Thu, Feb 03, 2022 at 08:38:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of the inflexible bigjoiner_linked_crtc pointer thing
> and just track things as a bitmask of pipes instead. We can
> also nuke the bigjoiner_slave boolean as the role of the pipe
> can be determined from its position in the bitmask.
>
> It might be possible to nuke the bigjoiner boolean as well
> if we make encoder.compute_config() do the bitmask assignment
> directly for the master pipe. But for now I left that alone so
> that encoer.compute_config() will just flag the state as needing
> bigjoiner, and the intel_atomic_check_bigjoiner() is still
> responsible for determining the bitmask. But that may have to change
> as the encoder may be in the best position to determine how
> exactly we should populate the bitmask.
>
> Most places that just looked at the single bigjoiner_linked_crtc
> now iterate over the whole bitmask, eliminating the singular
> slave pipe assumption.
Okay so trying to understand the design here:
For Pipe A + B Bigjoiner and C + D bigjoiner for example,
bitmasks will be as below:
A : 0011
B: 0011
C: 1100
D: 1100
Is this correct understanding? Because we would mark both the master pipe and
slave pipe in a bitmask right?
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
> drivers/gpu/drm/i915/display/intel_display.c | 305 --
> drivers/gpu/drm/i915/display/intel_display.h | 2 +
> .../drm/i915/display/intel_display_debugfs.c | 5 +-
> .../drm/i915/display/intel_display_types.h| 7 +-
> .../drm/i915/display/intel_plane_initial.c| 7 -
> drivers/gpu/drm/i915/display/intel_vdsc.c | 43 ---
> drivers/gpu/drm/i915/display/intel_vdsc.h | 1 -
> 9 files changed, 227 insertions(+), 160 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 41d52889dfce..0e15fe908855 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -404,9 +404,10 @@ int intel_plane_atomic_check(struct intel_atomic_state
> *state,
> intel_atomic_get_new_crtc_state(state, crtc);
>
> if (new_crtc_state && intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> + struct intel_crtc *master_crtc =
> + intel_master_crtc(new_crtc_state);
> struct intel_plane *master_plane =
> -
> intel_crtc_get_plane(new_crtc_state->bigjoiner_linked_crtc,
> - plane->id);
> + intel_crtc_get_plane(master_crtc, plane->id);
>
> new_master_plane_state =
> intel_atomic_get_new_plane_state(state, master_plane);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3f0e1e127595..9dee12986991 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2703,6 +2703,7 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
> + struct intel_crtc *slave_crtc;
>
> if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> intel_crtc_vblank_off(old_crtc_state);
> @@ -2721,9 +2722,8 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
> ilk_pfit_disable(old_crtc_state);
> }
>
> - if (old_crtc_state->bigjoiner_linked_crtc) {
> - struct intel_crtc *slave_crtc =
> - old_crtc_state->bigjoiner_linked_crtc;
> + for_each_intel_crtc_in_pipe_mask(_priv->drm, slave_crtc,
> +
> intel_crtc_bigjoiner_slave_pipes(old_crtc_state)) {
> const struct intel_crtc_state *old_slave_crtc_state =
> intel_atomic_get_old_crtc_state(state, slave_crtc);
>
> @@ -3041,6 +3041,7 @@ intel_ddi_update_prepare(struct intel_atomic_state
> *state,
>struct intel_encoder *encoder,
>struct intel_crtc *crtc)
> {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> struct intel_crtc_state *crtc_state =
> crtc ? intel_atomic_get_new_crtc_state(state, crtc) : NULL;
> int required_lanes = crtc_state ? crtc_state->lane_count : 1;
> @@ -3050,11 +3051,12 @@ intel_ddi_update_prepare(struct intel_atomic_state
> *state,
> intel_tc_port_get_link(enc_to_dig_port(encoder),
> required_lanes);
> if (crtc_state && crtc_state->hw.active) {
> - struct intel_crtc
Re: [Intel-gfx] [PATCH 06/10] drm/i915: Introduce intel_crtc_is_bigjoiner_{slave, master}()
On Thu, Feb 03, 2022 at 08:38:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Introduce helpers to query whether the crtc is the slave/master
> for bigjoiner. This decouples most places from the exact
> state layout we use to track this relationship, allowing us
> to change and extend it more easily.
So even with the bitmask approach, we still plan to have bools for
bigjoiner_slave?
>
> Performed with cocci:
> @@
> expression S, E;
> @@
> (
> S->bigjoiner_slave = E;
> |
> - S->bigjoiner_slave
> + intel_crtc_is_bigjoiner_slave(S)
> )
>
> @@
> expression S, E;
> @@
> (
> - E && S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S)
> + E && intel_crtc_is_bigjoiner_master(S)
> |
> - S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S)
> + intel_crtc_is_bigjoiner_master(S)
> )
>
> @@
> expression S;
> @@
> - (intel_crtc_is_bigjoiner_master(S))
> + intel_crtc_is_bigjoiner_master(S)
>
> @@
> expression S, E1, E2, E3;
> @@
> - intel_crtc_is_bigjoiner_slave(S) ? E1 : S->bigjoiner ? E2 : E3
> + intel_crtc_is_bigjoiner_slave(S) ? E1 : intel_crtc_is_bigjoiner_master(S) ?
> E2 : E3
>
> @@
> typedef bool;
> @@
> + bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state
> *crtc_state)
> + {
> + return crtc_state->bigjoiner_slave;
> + }
> +
> intel_master_crtc(...) {...}
>
> @@
> typedef bool;
> @@
> + bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state
> *crtc_state)
> + {
> + return crtc_state->bigjoiner && !crtc_state->bigjoiner_slave;
> + }
> +
> intel_master_crtc(...) {...}
>
> @@
> typedef bool;
> identifier S;
> @@
> - bool is_trans_port_sync_mode(const struct intel_crtc_state *S);
> + bool is_trans_port_sync_mode(const struct intel_crtc_state *state);
> + bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state
> *crtc_state);
> + bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state
> *crtc_state);
Is all of the above part of the commit message? Dont understand why its
changing is_trans_port_sync_mode() ?
Manasi
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 51 +++
> drivers/gpu/drm/i915/display/intel_display.h | 2 +
> .../drm/i915/display/intel_display_debugfs.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-
> 6 files changed, 39 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index bec02333bdeb..41d52889dfce 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -403,7 +403,7 @@ int intel_plane_atomic_check(struct intel_atomic_state
> *state,
> struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
>
> - if (new_crtc_state && new_crtc_state->bigjoiner_slave) {
> + if (new_crtc_state && intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> struct intel_plane *master_plane =
>
> intel_crtc_get_plane(new_crtc_state->bigjoiner_linked_crtc,
>plane->id);
> @@ -633,7 +633,7 @@ int intel_atomic_plane_check_clipping(struct
> intel_plane_state *plane_state,
> }
>
> /* right side of the image is on the slave crtc, adjust dst to match */
> - if (crtc_state->bigjoiner_slave)
> + if (intel_crtc_is_bigjoiner_slave(crtc_state))
> drm_rect_translate(dst, -crtc_state->pipe_src_w, 0);
>
> /*
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 354b08d6f81d..3f0e1e127595 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2926,7 +2926,7 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
> {
> drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
>
> - if (!crtc_state->bigjoiner_slave)
> + if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> intel_ddi_enable_transcoder_func(encoder, crtc_state);
>
> intel_vrr_enable(encoder, crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d5dc2c25c1f6..9a7f40d17b79 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -337,9 +337,19 @@ is_trans_port_sync_mode(const struct intel_crtc_state
> *crtc_state)
> is_trans_port_sync_slave(crtc_state);
> }
>
> +bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state)
> +{
> + return crtc_state->bigjoiner_slave;
> +}
> +
> +bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state
> *crtc_state)
> +{
> + return crtc_state->bigjoiner &&
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Nuke some dead code
On Thu, Feb 03, 2022 at 08:38:18PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove all the dead code from icl_ddi_bigjoiner_pre_enable().
>
> Signed-off-by: Ville Syrjälä
Yup good catch here and thank you for cleaning up the dead code
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 18 +-
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 48869478efc2..d5dc2c25c1f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1974,23 +1974,7 @@ static void hsw_set_frame_start_delay(const struct
> intel_crtc_state *crtc_state)
> static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
>const struct intel_crtc_state
> *crtc_state)
> {
> - struct intel_crtc_state *master_crtc_state;
> - struct intel_crtc *master_crtc;
> - struct drm_connector_state *conn_state;
> - struct drm_connector *conn;
> - struct intel_encoder *encoder = NULL;
> - int i;
> -
> - master_crtc = intel_master_crtc(crtc_state);
> - master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
> -
> - for_each_new_connector_in_state(>base, conn, conn_state, i) {
> - if (conn_state->crtc != _crtc->base)
> - continue;
> -
> - encoder = to_intel_encoder(conn_state->best_encoder);
> - break;
> - }
> + struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
>
> /*
>* Enable sequence steps 1-7 on bigjoiner master
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2 02/10] drm/i915: Fix bigjoiner state copy fails
On Fri, Feb 04, 2022 at 09:20:09AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We seem to be missing a few things from the bigjoiner state copy.
> Namely hw.mode isn't getting copied (which probably causes PIPESRC
> to be misconfigured), CTM/LUTs aren't getting copied (which could
> cause the pipe to produced incorrect output), and we also forgot
> to copy over the color_mgmt_changed flag so potentially we fail
> to do the actual CTM/LUT programming (assuming we aren't doing
> a full modeset or fastset). Fix it all.
>
> v2: Fix uapi.ctm vs. hw.ctm copy-paste fail
>
> Signed-off-by: Ville Syrjälä
Yup looks good
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 85dce8a093d4..4f5f023417a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5827,8 +5827,10 @@ intel_crtc_copy_uapi_to_hw_state_nomodeset(struct
> intel_atomic_state *state,
> master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
>
> /* No need to copy state if the master state is unchanged */
> - if (master_crtc_state)
> + if (master_crtc_state) {
> + crtc_state->uapi.color_mgmt_changed =
> master_crtc_state->uapi.color_mgmt_changed;
> intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
> + }
> }
>
> static void
> @@ -5890,13 +5892,23 @@ copy_bigjoiner_crtc_state(struct intel_crtc_state
> *crtc_state,
> memset(_state->hw, 0, sizeof(saved_state->hw));
> crtc_state->hw.enable = from_crtc_state->hw.enable;
> crtc_state->hw.active = from_crtc_state->hw.active;
> + crtc_state->hw.mode = from_crtc_state->hw.mode;
> crtc_state->hw.pipe_mode = from_crtc_state->hw.pipe_mode;
> crtc_state->hw.adjusted_mode = from_crtc_state->hw.adjusted_mode;
> + crtc_state->hw.scaling_filter = from_crtc_state->hw.scaling_filter;
> +
> + drm_property_replace_blob(_state->hw.degamma_lut,
> + from_crtc_state->hw.degamma_lut);
> + drm_property_replace_blob(_state->hw.gamma_lut,
> + from_crtc_state->hw.gamma_lut);
> + drm_property_replace_blob(_state->hw.ctm,
> + from_crtc_state->hw.ctm);
>
> /* Some fixups */
> crtc_state->uapi.mode_changed = from_crtc_state->uapi.mode_changed;
> crtc_state->uapi.connectors_changed =
> from_crtc_state->uapi.connectors_changed;
> crtc_state->uapi.active_changed = from_crtc_state->uapi.active_changed;
> + crtc_state->uapi.color_mgmt_changed =
> from_crtc_state->uapi.color_mgmt_changed;
> crtc_state->nv12_planes = crtc_state->c8_planes =
> crtc_state->update_planes = 0;
> crtc_state->bigjoiner_linked_crtc =
> to_intel_crtc(from_crtc_state->uapi.crtc);
> crtc_state->bigjoiner_slave = true;
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2 04/10] drm/i915: Clean up the bigjoiner state copy logic
On Fri, Feb 04, 2022 at 09:20:49AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently the bigjoiner state copy logic is kind of
> a byzantine mess.
>
> Clean it up to operate in the following manner during a full
> modeset:
> 1) master uapi -> hw state copy
> 2) master hw -> slave hw state copy
>
> And during a non-modeset update we do:
> 1) master uapi -> hw state light copy
> 2) master hw -> slave hw state light copy
>
> I think that is now easier to reason about since we never do
> any kind of master uapi -> slave hw state copy short circuit
> that could happen previously.
>
> Obviously this does now depend on the master uapi->hw copy
> always happening before the master hw -> slave hw copy, but
> that is guaranteed by the fact that we always add both crtcs
> to the state early, the crtcs are registered in pipe
> order (so the compute_config loop happens in pipe order),
> and the hardware requires the master pipe has to be lower
> than the slave pipe as well. And for good measure we shall
> add a check+WARN for this before doing the bigjoiner crtc
> assignment.
>
> v2: Fix uapi.ctm vs. hw.ctm copy-paste fail
>
> Signed-off-by: Ville Syrjälä
Looks good to me, jus one question on how we decide what state from orginal
slave crtc state to preserve.
But in either case
Reviewed-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 11 --
> drivers/gpu/drm/i915/display/intel_atomic.h | 2 -
> drivers/gpu/drm/i915/display/intel_display.c | 170 ---
> 3 files changed, 108 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 093904065112..e0667d163266 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -281,17 +281,6 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
> *crtc_state)
> intel_crtc_put_color_blobs(crtc_state);
> }
>
> -void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
> - const struct intel_crtc_state *from_crtc_state)
> -{
> - drm_property_replace_blob(_state->hw.degamma_lut,
> - from_crtc_state->uapi.degamma_lut);
> - drm_property_replace_blob(_state->hw.gamma_lut,
> - from_crtc_state->uapi.gamma_lut);
> - drm_property_replace_blob(_state->hw.ctm,
> - from_crtc_state->uapi.ctm);
> -}
> -
> /**
> * intel_crtc_destroy_state - destroy crtc state
> * @crtc: drm crtc
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
> b/drivers/gpu/drm/i915/display/intel_atomic.h
> index d2700c74c9da..1dc439983dd9 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> @@ -44,8 +44,6 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
> drm_crtc *crtc);
> void intel_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
> -void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
> - const struct intel_crtc_state
> *from_crtc_state);
> struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
> void intel_atomic_state_free(struct drm_atomic_state *state);
> void intel_atomic_state_clear(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 349cc3807e8b..b391cb98b12f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5818,32 +5818,37 @@ static bool check_digital_port_conflicts(struct
> intel_atomic_state *state)
>
> static void
> intel_crtc_copy_uapi_to_hw_state_nomodeset(struct intel_atomic_state *state,
> -struct intel_crtc_state *crtc_state)
> +struct intel_crtc *crtc)
> {
> - const struct intel_crtc_state *master_crtc_state;
> - struct intel_crtc *master_crtc;
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
>
> - master_crtc = intel_master_crtc(crtc_state);
> - master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
> + WARN_ON(crtc_state->bigjoiner_slave);
>
> - /* No need to copy state if the master state is unchanged */
> - if (master_crtc_state) {
> - crtc_state->uapi.color_mgmt_changed =
> master_crtc_state->uapi.color_mgmt_changed;
> - intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
> - }
> + drm_property_replace_blob(_state->hw.degamma_lut,
> + crtc_state->uapi.degamma_lut);
> + drm_property_replace_blob(_state->hw.gamma_lut,
> +
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Remove weird code from intel_atomic_check_bigjoiner()
On Thu, Feb 03, 2022 at 08:38:16PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There's some weird junk in intel_atomic_check_bigjoiner()
> that's trying to look at the old crtc state's bigjoiner
> usage for some reason. That code is totally unnecessary,
> and maybe even actively harmful. Not entirely sure which
> since it's such a mess that I can't actually wrap my brain
> around what it ends up doing.
>
> Either way, thanks to intel_bigjoiner_add_affected_crtcs()
> all of the old bigjoiner crtcs are guaranteed to be in the
> state already if any one of them is in the state. Also if
> any one of those crtcs got flagged for a modeset, then all
> of them will have been flagged, and the bigjoiner links
> will have been detached via kill_bigjoiner_slave().
>
> So there is no need to look examing any old bigjoiner
> usage in intel_atomic_check_bigjoiner(). All we have to care
> about is whether bigjoiner is needed for the new state,
> and whether we can get the slave crtc we need.
>
> Signed-off-by: Ville Syrjälä
Completely agree with this cleanup, makes it so much easier to add new future
code
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 33 +++-
> 1 file changed, 11 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2006eec6e166..b5701ca57889 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7584,38 +7584,28 @@ static bool intel_cpu_transcoders_need_modeset(struct
> intel_atomic_state *state,
> }
>
> static int intel_atomic_check_bigjoiner(struct intel_atomic_state *state,
> - struct intel_crtc *crtc,
> - struct intel_crtc_state *old_crtc_state,
> - struct intel_crtc_state *new_crtc_state)
> + struct intel_crtc *master_crtc)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> - struct intel_crtc_state *slave_crtc_state, *master_crtc_state;
> - struct intel_crtc *slave_crtc, *master_crtc;
> + struct intel_crtc_state *master_crtc_state =
> + intel_atomic_get_new_crtc_state(state, master_crtc);
> + struct intel_crtc_state *slave_crtc_state;
> + struct intel_crtc *slave_crtc;
>
> - /* slave being enabled, is master is still claiming this crtc? */
> - if (old_crtc_state->bigjoiner_slave) {
> - slave_crtc = crtc;
> - master_crtc = old_crtc_state->bigjoiner_linked_crtc;
> - master_crtc_state = intel_atomic_get_new_crtc_state(state,
> master_crtc);
> - if (!master_crtc_state ||
> !intel_crtc_needs_modeset(master_crtc_state))
> - goto claimed;
> - }
> -
> - if (!new_crtc_state->bigjoiner)
> + if (!master_crtc_state->bigjoiner)
> return 0;
>
> - slave_crtc = intel_dsc_get_bigjoiner_secondary(crtc);
> + slave_crtc = intel_dsc_get_bigjoiner_secondary(master_crtc);
> if (!slave_crtc) {
> drm_dbg_kms(>drm,
> "[CRTC:%d:%s] Big joiner configuration requires "
> "CRTC + 1 to be used, doesn't exist\n",
> - crtc->base.base.id, crtc->base.name);
> + master_crtc->base.base.id, master_crtc->base.name);
> return -EINVAL;
> }
>
> - new_crtc_state->bigjoiner_linked_crtc = slave_crtc;
> + master_crtc_state->bigjoiner_linked_crtc = slave_crtc;
> slave_crtc_state = intel_atomic_get_crtc_state(>base,
> slave_crtc);
> - master_crtc = crtc;
> if (IS_ERR(slave_crtc_state))
> return PTR_ERR(slave_crtc_state);
>
> @@ -7627,7 +7617,7 @@ static int intel_atomic_check_bigjoiner(struct
> intel_atomic_state *state,
> "[CRTC:%d:%s] Used as slave for big joiner\n",
> slave_crtc->base.base.id, slave_crtc->base.name);
>
> - return copy_bigjoiner_crtc_state(slave_crtc_state, new_crtc_state);
> + return copy_bigjoiner_crtc_state(slave_crtc_state, master_crtc_state);
>
> claimed:
> drm_dbg_kms(>drm,
> @@ -7899,8 +7889,7 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - ret = intel_atomic_check_bigjoiner(state, crtc, old_crtc_state,
> -new_crtc_state);
> + ret = intel_atomic_check_bigjoiner(state, crtc);
> if (ret)
> goto fail;
> }
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix bigjoiner state copy fails
On Thu, Feb 03, 2022 at 08:38:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We seem to be missing a few things from the bigjoiner state copy.
> Namely hw.mode isn't getting copied (which probably causes PIPESRC
> to be misconfigured), CTM/LUTs aren't getting copied (which could
> cause the pipe to produced incorrect output), and we also forgot
> to copy over the color_mgmt_changed flag so potentially we fail
> to do the actual CTM/LUT programming (assuming we aren't doing
> a full modeset or fastset). Fix it all.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 85dce8a093d4..2006eec6e166 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5827,8 +5827,10 @@ intel_crtc_copy_uapi_to_hw_state_nomodeset(struct
> intel_atomic_state *state,
> master_crtc_state = intel_atomic_get_new_crtc_state(state, master_crtc);
>
> /* No need to copy state if the master state is unchanged */
> - if (master_crtc_state)
> + if (master_crtc_state) {
> + crtc_state->uapi.color_mgmt_changed =
> master_crtc_state->uapi.color_mgmt_changed;
Since in this function we are copying from uapi_to_hw_state, is this the right
function to copy to uapi state ?
> intel_crtc_copy_color_blobs(crtc_state, master_crtc_state);
> + }
> }
>
> static void
> @@ -5890,13 +5892,23 @@ copy_bigjoiner_crtc_state(struct intel_crtc_state
> *crtc_state,
> memset(_state->hw, 0, sizeof(saved_state->hw));
> crtc_state->hw.enable = from_crtc_state->hw.enable;
> crtc_state->hw.active = from_crtc_state->hw.active;
> + crtc_state->hw.mode = from_crtc_state->hw.mode;
> crtc_state->hw.pipe_mode = from_crtc_state->hw.pipe_mode;
> crtc_state->hw.adjusted_mode = from_crtc_state->hw.adjusted_mode;
> + crtc_state->hw.scaling_filter = from_crtc_state->hw.scaling_filter;
> +
> + drm_property_replace_blob(_state->hw.degamma_lut,
> + from_crtc_state->hw.degamma_lut);
> + drm_property_replace_blob(_state->hw.gamma_lut,
> + from_crtc_state->hw.gamma_lut);
> + drm_property_replace_blob(_state->uapi.ctm,
> + from_crtc_state->hw.ctm);
>
> /* Some fixups */
> crtc_state->uapi.mode_changed = from_crtc_state->uapi.mode_changed;
> crtc_state->uapi.connectors_changed =
> from_crtc_state->uapi.connectors_changed;
> crtc_state->uapi.active_changed = from_crtc_state->uapi.active_changed;
> + crtc_state->uapi.color_mgmt_changed =
> from_crtc_state->uapi.color_mgmt_changed;
> crtc_state->nv12_planes = crtc_state->c8_planes =
> crtc_state->update_planes = 0;
> crtc_state->bigjoiner_linked_crtc =
> to_intel_crtc(from_crtc_state->uapi.crtc);
> crtc_state->bigjoiner_slave = true;
This looks good
Manasi
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Flag crtc scaling_filter changes as modeset
On Thu, Feb 03, 2022 at 08:38:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The core doesn't flag scaling_filter prop changes as needing
> a modeset. That doesn't work for us since we only reprogram the
> pipe scaler during full modesets and fastsets. So we need to
> flag the prop change as a modeset ourselves. Assuming nothing else
> has changed the operation will get promoted (demoted?) to a fastset
> later.
>
> Signed-off-by: Ville Syrjälä
Makes sense, although not sure why this was sent as part of bigjoiner bitmask
series
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index df347329d90e..85dce8a093d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7846,6 +7846,10 @@ static int intel_atomic_check(struct drm_device *dev,
> new_crtc_state, i) {
> if (new_crtc_state->inherited != old_crtc_state->inherited)
> new_crtc_state->uapi.mode_changed = true;
> +
> + if (new_crtc_state->uapi.scaling_filter !=
> + old_crtc_state->uapi.scaling_filter)
> + new_crtc_state->uapi.mode_changed = true;
> }
>
> intel_vrr_check_modeset(state);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Mon, Jan 31, 2022 at 02:28:04PM +0200, Jani Nikula wrote:
> On Wed, 26 Jan 2022, Manasi Navare wrote:
> > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> > settings.
> > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> > MSA bit
> > in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> > the corresponding VRR Capable Connector property.
> > Hence the userspace still sees this as VRR Capable panel which is incorrect.
> >
> > Fix this by explicitly resetting the connector property.
> >
> > v2: Reset vrr capable if status == connector_disconnected
> > v3: Use i915 and use bool vrr_capable (Jani Nikula)
> > Cc: Jani Nikula
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4d4579a301f6..687cb37bb22a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4446,6 +4446,12 @@ intel_dp_detect(struct drm_connector *connector,
> > memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> > memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> >
> > + /* Reset VRR Capable property */
> > + drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s] VRR capable:
> > FALSE\n",
> > + connector->base.id, connector->name);
>
> Both the comment and the logging here seem excessive.
Okay will remove the comment, it is indeed redundant now
>
> > + drm_connector_set_vrr_capable_property(connector,
> > + false);
> > +
>
> Fits on one line.
Sure will change that
>
> > if (intel_dp->is_mst) {
> > drm_dbg_kms(_priv->drm,
> > "MST device may have disappeared %d vs
> > %d\n",
> > @@ -4560,15 +4566,17 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > {
> > struct intel_connector *intel_connector = to_intel_connector(connector);
> > struct edid *edid;
> > + struct drm_i915_private *i915 = to_i915(connector->dev);
> > int num_modes = 0;
> >
> > edid = intel_connector->detect_edid;
> > if (edid) {
> > - num_modes = intel_connector_update_modes(connector, edid);
> > + bool vrr_capable = intel_vrr_is_capable(connector);
> >
> > - if (intel_vrr_is_capable(connector))
> > - drm_connector_set_vrr_capable_property(connector,
> > - true);
> > + num_modes = intel_connector_update_modes(connector, edid);
>
> intel_vrr_is_capable() probably needs to happen after
> intel_connector_update_modes(), right?
Thanks Jani yes that is correct, will move this after num_modes =
intel_connector_update_modes(connector, edid);
Manasi
>
> BR,
> Jani.
>
> > + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> > + connector->base.id, connector->name,
> > yesno(vrr_capable));
> > + drm_connector_set_vrr_capable_property(connector, vrr_capable);
> > }
> >
> > /* Also add fixed mode, which may or may not be present in EDID */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] drm/i915/display/vrr: Reset VRR capable property on a long hpd
Hi Jani,
I have addressed your review comments, could you take a look at this patch,
this is needed by one of our customers.
Manasi
On Wed, Jan 26, 2022 at 11:53:04AM -0800, Manasi Navare wrote:
> With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> settings.
> When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> MSA bit
> in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> the corresponding VRR Capable Connector property.
> Hence the userspace still sees this as VRR Capable panel which is incorrect.
>
> Fix this by explicitly resetting the connector property.
>
> v2: Reset vrr capable if status == connector_disconnected
> v3: Use i915 and use bool vrr_capable (Jani Nikula)
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4d4579a301f6..687cb37bb22a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4446,6 +4446,12 @@ intel_dp_detect(struct drm_connector *connector,
> memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
>
> + /* Reset VRR Capable property */
> + drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s] VRR capable:
> FALSE\n",
> + connector->base.id, connector->name);
> + drm_connector_set_vrr_capable_property(connector,
> +false);
> +
> if (intel_dp->is_mst) {
> drm_dbg_kms(_priv->drm,
> "MST device may have disappeared %d vs
> %d\n",
> @@ -4560,15 +4566,17 @@ static int intel_dp_get_modes(struct drm_connector
> *connector)
> {
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct edid *edid;
> + struct drm_i915_private *i915 = to_i915(connector->dev);
> int num_modes = 0;
>
> edid = intel_connector->detect_edid;
> if (edid) {
> - num_modes = intel_connector_update_modes(connector, edid);
> + bool vrr_capable = intel_vrr_is_capable(connector);
>
> - if (intel_vrr_is_capable(connector))
> - drm_connector_set_vrr_capable_property(connector,
> -true);
> + num_modes = intel_connector_update_modes(connector, edid);
> + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> + connector->base.id, connector->name,
> yesno(vrr_capable));
> + drm_connector_set_vrr_capable_property(connector, vrr_capable);
> }
>
> /* Also add fixed mode, which may or may not be present in EDID */
> --
> 2.19.1
>
Re: [Intel-gfx] [PATCH] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Fri, Jan 14, 2022 at 02:33:29PM +0200, Jani Nikula wrote:
> On Wed, 12 Jan 2022, Manasi Navare wrote:
> > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> > settings.
> > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> > MSA bit
> > in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> > the corresponding VRR Capable Connector property.
> > Hence the userspace still sees this as VRR Capable panel which is incorrect.
> >
> > Fix this by explicitly resetting the connector property.
> >
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index df2a7d86aef0..4f1418f02b76 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4539,15 +4539,24 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > {
> > struct intel_connector *intel_connector = to_intel_connector(connector);
> > struct edid *edid;
> > + struct drm_i915_private *dev_priv = to_i915(connector->dev);
>
> Please call it "i915" for new stuff.
Okay yes will change this to i915
>
> > int num_modes = 0;
> >
> > edid = intel_connector->detect_edid;
> > if (edid) {
> > num_modes = intel_connector_update_modes(connector, edid);
> >
> > - if (intel_vrr_is_capable(connector))
> > + if (intel_vrr_is_capable(connector)) {
> > + drm_dbg_kms(_priv->drm, "VRR capable = TRUE for
> > [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > drm_connector_set_vrr_capable_property(connector,
> >true);
> > + } else {
> > + drm_dbg_kms(_priv->drm, "VRR capable = false for
> > [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + drm_connector_set_vrr_capable_property(connector,
> > + false);
> > + }
>
> Please don't repeat yourself! Also, prefer having [CONNECTOR:%d:%s] at
> the beginning.
>
> bool capable = intel_vrr_is_capable(connector);
>
> drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> connector->base.id, connector->name,
> yesno(capable));
> drm_connector_set_vrr_capable_property(connector, capable);
Okay agree, thanks for the suggestion, will change in the v2 and resend
Regards
Manasi
>
> BR,
> Jani.
>
>
> > }
> >
> > /* Also add fixed mode, which may or may not be present in EDID */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Nuke dg2_ddi_pre_enable_dp()
On Wed, Jan 19, 2022 at 05:17:05PM +0200, Jani Nikula wrote:
> On Wed, 19 Jan 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate
> > it.
> >
> > The one thing that tgl_ddi_pre_enable_dp() is missing that we
> > need is intel_ddi_config_transcoder_dp2(). So we'll bring that
> > over.
> >
> > tgl_ddi_pre_enable_dp() does also have a few things that
> > dg2_ddi_pre_enable_dp() didn't have:
> > - icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2
> > - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on
> > DG2
> > - intel_ddi_mso_configure() -> only matters for MSO panels
> >
> > Another slight difference is that dg2_ddi_pre_enable_dp() was
> > missing a bigjoiner check around intel_dsc_enable(), which
> > tgl_ddi_pre_enable_dp() does have.
Thanks Ville for this patch, I was just comparing differences between
dg2_pre_enable_dp and tgl_pre_enable_dp
in regards to a bug and there is totally no need for two functions with the
checks you have here.
For the bigjoiner check aroind intel_dsc_enable(), I think the function
intel_dsc_dp_pps_write(encoder, crtc_state);
also needs to be moved into that check.
And then this functions needs to be called from icl_ddi_bigjoiner_pre_enable()
where we call intel_dsc_enable
With that:
Reviewed-by: Manasi Navare
Manasi
>
> Reviewed-by: Jani Nikula
>
> The modeset step bspec references could use a cleanup too. If they
> aren't stable number combos for *one* platform, let alone many,
> we should probably just remove them.
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 117 +--
> > 1 file changed, 4 insertions(+), 113 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4e93eac926a5..2f20abc5122d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -2289,116 +2289,6 @@ static void intel_ddi_mso_configure(const struct
> > intel_crtc_state *crtc_state)
> > OVERLAP_PIXELS_MASK, dss1);
> > }
> >
> > -static void dg2_ddi_pre_enable_dp(struct intel_atomic_state *state,
> > - struct intel_encoder *encoder,
> > - const struct intel_crtc_state *crtc_state,
> > - const struct drm_connector_state *conn_state)
> > -{
> > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > - struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > - bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> > -
> > - intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > -crtc_state->lane_count);
> > -
> > - /*
> > -* We only configure what the register value will be here. Actual
> > -* enabling happens during link training farther down.
> > -*/
> > - intel_ddi_init_dp_buf_reg(encoder, crtc_state);
> > -
> > - /*
> > -* 1. Enable Power Wells
> > -*
> > -* This was handled at the beginning of intel_atomic_commit_tail(),
> > -* before we called down into this function.
> > -*/
> > -
> > - /* 2. Enable Panel Power if PPS is required */
> > - intel_pps_on(intel_dp);
> > -
> > - /*
> > -* 3. Enable the port PLL.
> > -*/
> > - intel_ddi_enable_clock(encoder, crtc_state);
> > -
> > - /* 4. Enable IO power */
> > - if (!intel_tc_port_in_tbt_alt_mode(dig_port))
> > - dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
> > -
> > dig_port->ddi_io_power_domain);
> > -
> > - /*
> > -* 5. The rest of the below are substeps under the bspec's "Enable and
> > -* Train Display Port" step. Note that steps that are specific to
> > -* MST will be handled by intel_mst_pre_enable_dp() before/after it
> > -* calls into this function. Also intel_mst_pre_enable_dp() only calls
> > -* us when active_mst_links==0, so any steps designated for "single
> > -* stream or multi-stream master transcoder" can just be performed
> > -* unconditionally here.
> > -*/
> > -
> > - /*
> > -* 5.a Conf
Re: [Intel-gfx] [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Tue, Jan 18, 2022 at 06:34:20PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote:
> >
> > Hi Ville,
> >
> > Could you take a look at this, this addresses teh review comments from prev
> > version
>
> I don't think I ever got an answer to my question as to whether this
> was tested with all the interesting scenarios:
> 1) just with the master crtc added by userspace into the commit
> 2) just with the slave crtc added by userspace into the commit
> 3) both crtcs added by userspace into the commit
>
> I guess 1) has been tested since that happens all the time, but the other
> two scanarios would likely need to be done with a synthetic test to make
> sure we're actually hitting them.
>
> I think it *should* work, but I'd like to have real proof of that.
> Reviewed-by: Ville Syrjälä
Thank you for your review here Ville.
I have triggered a separate email thread to understand all the above testing
scenarios and get them tested with bigjoiner IGT.
Manasi
>
> >
> > Manasi
> >
> > On Mon, Oct 04, 2021 at 04:59:13AM -0700, Manasi Navare wrote:
> > > In case of a modeset where a mode gets split across mutiple CRTCs
> > > in the driver specific implementation (bigjoiner in i915) we wrongly count
> > > the affected CRTCs based on the drm_crtc_mask and indicate the stolen
> > > CRTC as
> > > an affected CRTC in atomic_check_only().
> > > This triggers a warning since affected CRTCs doent match requested CRTC.
> > >
> > > To fix this in such bigjoiner configurations, we should only
> > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > if it is just used internally in the driver to split the mode.
> > >
> > > v3: Add the same uapi crtc_state->enable check in requested
> > > crtc calc (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Simon Ser
> > > Cc: Pekka Paalanen
> > > Cc: Daniel Stone
> > > Cc: Daniel Vetter
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 12
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index ff1416cd609a..a1e4c7905ebb 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > > *state)
> > >
> > > DRM_DEBUG_ATOMIC("checking %p\n", state);
> > >
> > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > - requested_crtc |= drm_crtc_mask(crtc);
> > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->enable)
> > > + requested_crtc |= drm_crtc_mask(crtc);
> > > + }
> > >
> > > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > > new_plane_state, i) {
> > > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > > @@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > > *state)
> > > }
> > > }
> > >
> > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > - affected_crtc |= drm_crtc_mask(crtc);
> > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->enable)
> > > + affected_crtc |= drm_crtc_mask(crtc);
> > > + }
> > >
> > > /*
> > >* For commits that allow modesets drivers can add other CRTCs to the
> > > --
> > > 2.19.1
> > >
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
On Mon, Jan 10, 2022 at 08:24:54PM -0800, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Navare, Manasi D
> > Sent: Tuesday, January 11, 2022 1:07 AM
> > To: Kulkarni, Vandita
> > Cc: Nikula, Jani ; Lisovskiy, Stanislav
> > ; Ville Syrjälä
> > ;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > engine for higher moderates
> >
> > Thankf for revisiting this thread. The use of max_cdclk is currently in 2
> > places
> > in DSC code 1. . if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq)
> > {
> > if (pipe_config->dsc.slice_count > 1) {
> > pipe_config->dsc.dsc_split = true; 2. if
> > (bigjoiner) {
> > u32 max_bpp_bigjoiner =
> > i915->max_cdclk_freq * 48 /
> > intel_dp_mode_to_fec_clock(mode_clock);
> >
> > DRM_DEBUG_KMS("Max big joiner bpp: %u\n",
> > max_bpp_bigjoiner);
> > bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> > }
> >
> > In both these places, using max_cdclk can cause problems, like for
> > compressed bpp it can give a higher bpp based on max_cdclk and we might
> > actually end up chosing lower cdclk at what point this will cause underruns.
> >
> > So when I was discussing with Ville on this, my first thought was also to
> > use
> > the cdclk_state->actual_cdclk but like Ville mentioned later in the review
> > comments the challenge there was that actual cdclk does get computed
> > much later than dsc_compute_config.
> >
> > So I think as suggested in one of the reviews we just to check if DSC is
> > enabled then we dont allow lowering the cdclk which would also prevent
> > underruns caused by possibly setting up higher bpp based on max cdclk.
>
> Thanks for the review.
> This is taken care now, in case if we cannot split, then we already are using
> max_cdclk.
> Regarding the bigjoiner_bpp, you may need to make the change if you need it
> to be set to max cdclk.
> As we all of us here agree that we do not have computed cd clk at that time.
>
So the resolution was to keep it at max_cdclock when we set the dsc.split and
decide to use 2 VDSC engines? Is this change merged upstream now?
For bpp calculation, that was pointed out by Srikanth that they were seeing
underruns and was a bug they had found in their code.
And infact there we dont want to set it to max_cdclk because if we lower the
cdclk later then that bpp will cause underuns.
One of the comments in here was to then check if DSC enabled in function that
tries to lower the cdclk and not allow if DSC enabled.
Are you already working on that change or do I need to follow up on that with
Ville/ Jani?
Manasi
> >
> > @Ville @Jani does this sound like a good approach. Then @Vandita we can
> > pursue that change.
> >
> > Regards
> > Manasi
> >
> > On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> > > Revisiting this thread after update from the bspec.
> > >
> > > > -Original Message-
> > > > From: Nikula, Jani
> > > > Sent: Tuesday, September 14, 2021 8:40 PM
> > > > To: Kulkarni, Vandita ; Lisovskiy,
> > > > Stanislav
> > > > Cc: Ville Syrjälä ; intel-
> > > > g...@lists.freedesktop.org; Navare, Manasi D
> > > >
> > > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > > VDSC engine for higher moderates
> > > >
> > > > On Tue, 14 Sep 2021, "Kulkarni, Vandita"
> > > >
> > > > wrote:
> > > > >> -Original Message-
> > > > >> From: Nikula, Jani
> > > > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > > > >> To: Lisovskiy, Stanislav
> > > > >> Cc: Ville Syrjälä ; Kulkarni,
> > > > >> Vandita ;
> > > > >> intel-gfx@lists.freedesktop.org; Navare, Manasi D
> > > > >>
> > > > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > > >> VDSC engine for higher moderates
> > > > >>
> > > > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > > >>
> > > > >> wrote:
> > > > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav
> > > > >> &g
Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
Thankf for revisiting this thread. The use of max_cdclk is currently in 2
places in DSC code
1. . if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) {
if (pipe_config->dsc.slice_count > 1) {
pipe_config->dsc.dsc_split = true;
2. if (bigjoiner) {
u32 max_bpp_bigjoiner =
i915->max_cdclk_freq * 48 /
intel_dp_mode_to_fec_clock(mode_clock);
DRM_DEBUG_KMS("Max big joiner bpp: %u\n", max_bpp_bigjoiner);
bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
}
In both these places, using max_cdclk can cause problems, like for compressed
bpp it can give a higher bpp based
on max_cdclk and we might actually end up chosing lower cdclk at what point
this will cause underruns.
So when I was discussing with Ville on this, my first thought was also to use
the cdclk_state->actual_cdclk but like
Ville mentioned later in the review comments the challenge there was that
actual cdclk does get computed
much later than dsc_compute_config.
So I think as suggested in one of the reviews we just to check if DSC is
enabled then we dont allow lowering the cdclk
which would also prevent underruns caused by possibly setting up higher bpp
based on max cdclk.
@Ville @Jani does this sound like a good approach. Then @Vandita we can pursue
that change.
Regards
Manasi
On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> Revisiting this thread after update from the bspec.
>
> > -Original Message-
> > From: Nikula, Jani
> > Sent: Tuesday, September 14, 2021 8:40 PM
> > To: Kulkarni, Vandita ; Lisovskiy, Stanislav
> >
> > Cc: Ville Syrjälä ; intel-
> > g...@lists.freedesktop.org; Navare, Manasi D
> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > engine for higher moderates
> >
> > On Tue, 14 Sep 2021, "Kulkarni, Vandita"
> > wrote:
> > >> -Original Message-
> > >> From: Nikula, Jani
> > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > >> To: Lisovskiy, Stanislav
> > >> Cc: Ville Syrjälä ; Kulkarni, Vandita
> > >> ; intel-gfx@lists.freedesktop.org;
> > >> Navare, Manasi D
> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > >> engine for higher moderates
> > >>
> > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > >>
> > >> wrote:
> > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> > >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > >> wrote:
> > >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita
> > wrote:
> > >> >> > >> > > -Original Message-
> > >> >> > >> > > From: Ville Syrjälä
> > >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > >> >> > >> > > To: Kulkarni, Vandita
> > >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > >> >> > >> > > ; Navare, Manasi D
> > >> >> > >> > >
> > >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> > >> >> > >> > > second VDSC engine for higher moderates
> > >> >> > >> > >
> > >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> > >> >> > >> > > Kulkarni
> > >> wrote:
> > >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable
> > >> >> > >> > > > the second VDSC engine when moderate is higher that the
> > >> >> > >> > > > current
> > >> cdclk.
> > >> >> > >> > > >
> > >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> > >> >> > >> > > >
> > >> >> > >> > > > ---
> > >> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12
> > >> >> > >> > > > ++--
> > >> >> > >> >
Re: [Intel-gfx] [PATCH] drm/i915/display/dsc: Clamp the max DSC input BPP to connector's max bpp
@Jani , @Ville, can you take a look at this, this was how the original DSC
patches
clamped the max bpp, but with latest DSC changes looks like this is not
obeyed anymore and needs to be fixed.
Manasi
On Thu, Nov 11, 2021 at 03:09:49PM -0800, Manasi Navare wrote:
> Pipe_bpp limits are decided by connectors max bpp as computed in
> compute_sink_pipe_bpp() before computing link and DSC config.
> Currently dsc_compute_config() sets the max input bpp only based
> on DSC Input BPPs supported and max bpc requested for the connector
> but does not clamp it based on connector's max bpp.
> This patch fixes that.
>
> Cc: Jani Nikula
> Cc: Vandita Kulkarni
> Cc: Ville Syrjälä
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 45373c213d9e..82209d995969 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1400,6 +1400,7 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> return -EINVAL;
>
> pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> conn_state->max_requested_bpc);
> + pipe_bpp = min(pipe_bpp, limits->max_bpp);
>
> /* Min Input BPC for ICL+ is 8 */
> if (pipe_bpp < 8 * 3) {
> --
> 2.19.1
>
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent
On Wed, Nov 17, 2021 at 03:09:45PM -0800, Navare, Manasi wrote:
> On Wed, Nov 17, 2021 at 11:04:05PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> > > On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Let's adjust the vblank evasion to account for the case where
> > > > a push has already been sent. In that case the vblank exit will start
> > > > at vmin vblank start (as opposed to vmax vblank start when no push
> > > > has been sent).
> > > >
> > > > This should minimize the effects of the tiny race between sampling
> > > > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > > > This will also be required if we want to do mailbox style updates with
> > > > vrr since then we'd definitely do multiple commits per frame. Currently
> > > > mailbox updates are only used by the legacy cursor, but we don't do
> > > > vrr push for those.
> > > >
> > > > Cc: Manasi Navare
> > > > Signed-off-by: Ville Syrjälä
I still want to see if PUSH send can be cleared if its coming after Vmax
because then that
will affect the next frame that will always just terminate at Vmin. But we can
continue that
discussion later. For this patch
Reviewed-by: Manasi Navare
Manasi
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
> > > > drivers/gpu/drm/i915/display/intel_vrr.c | 12
> > > > drivers/gpu/drm/i915/display/intel_vrr.h | 1 +
> > > > 3 files changed, 20 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > index cf403be7736c..eb5444f90e77 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct
> > > > intel_crtc_state *new_crtc_state)
> > > > if (intel_crtc_needs_vblank_work(new_crtc_state))
> > > > intel_crtc_vblank_work_init(new_crtc_state);
> > > >
> > > > - if (new_crtc_state->vrr.enable)
> > > > - vblank_start =
> > > > intel_vrr_vmax_vblank_start(new_crtc_state);
> > > > - else
> > > > + if (new_crtc_state->vrr.enable) {
> > > > + if (intel_vrr_is_push_sent(new_crtc_state))
> > > > + vblank_start =
> > > > intel_vrr_vmin_vblank_start(new_crtc_state);
> > >
> > > Actually if Push is sent then the vblank gets terminated at that point
> > > which falls between vmin and vmax so
> > > not necessarily at Vmin but at anytime between vmin and vmax. Is it
> > > correct to calculate it based on vmin?
> >
> > If you do a push between vmin and vmax then the vblank terminates
> > immediately and the PUSH_SEND bit gets cleared. The only way the bit
> > stays set is you set it after vmax/before vmin.
> >
>
> The scenario where PUSH comes in during the active so that its before Vmin,
> then it will stay on until we hit vmin to
> terminate the vblank.
> But when we reach Vmax, the HW will terminate the vblank anyways, should we
> actually alter the code to not
> allow any PUSH after Vmax?
>
> Manasi
>
> > >
> > > > + else
> > > > + vblank_start =
> > > > intel_vrr_vmax_vblank_start(new_crtc_state);
> > > > + } else {
> > > > vblank_start = intel_mode_vblank_start(adjusted_mode);
> > > > + }
> > > >
> > > > /* FIXME needs to be calibrated sensibly */
> > > > min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > index c335b1dbafcf..db1c3902fc2d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct
> > > > intel_crtc_state *crtc_state)
> > > >TRANS_PUSH_EN | TRANS_PUSH_SEND);
> > > > }
> > > >
> > > > +bool i
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent
On Wed, Nov 17, 2021 at 11:04:05PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> > On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Let's adjust the vblank evasion to account for the case where
> > > a push has already been sent. In that case the vblank exit will start
> > > at vmin vblank start (as opposed to vmax vblank start when no push
> > > has been sent).
> > >
> > > This should minimize the effects of the tiny race between sampling
> > > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > > This will also be required if we want to do mailbox style updates with
> > > vrr since then we'd definitely do multiple commits per frame. Currently
> > > mailbox updates are only used by the legacy cursor, but we don't do
> > > vrr push for those.
> > >
> > > Cc: Manasi Navare
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
> > > drivers/gpu/drm/i915/display/intel_vrr.c | 12
> > > drivers/gpu/drm/i915/display/intel_vrr.h | 1 +
> > > 3 files changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index cf403be7736c..eb5444f90e77 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct
> > > intel_crtc_state *new_crtc_state)
> > > if (intel_crtc_needs_vblank_work(new_crtc_state))
> > > intel_crtc_vblank_work_init(new_crtc_state);
> > >
> > > - if (new_crtc_state->vrr.enable)
> > > - vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > > - else
> > > + if (new_crtc_state->vrr.enable) {
> > > + if (intel_vrr_is_push_sent(new_crtc_state))
> > > + vblank_start =
> > > intel_vrr_vmin_vblank_start(new_crtc_state);
> >
> > Actually if Push is sent then the vblank gets terminated at that point
> > which falls between vmin and vmax so
> > not necessarily at Vmin but at anytime between vmin and vmax. Is it correct
> > to calculate it based on vmin?
>
> If you do a push between vmin and vmax then the vblank terminates
> immediately and the PUSH_SEND bit gets cleared. The only way the bit
> stays set is you set it after vmax/before vmin.
>
The scenario where PUSH comes in during the active so that its before Vmin,
then it will stay on until we hit vmin to
terminate the vblank.
But when we reach Vmax, the HW will terminate the vblank anyways, should we
actually alter the code to not
allow any PUSH after Vmax?
Manasi
> >
> > > + else
> > > + vblank_start =
> > > intel_vrr_vmax_vblank_start(new_crtc_state);
> > > + } else {
> > > vblank_start = intel_mode_vblank_start(adjusted_mode);
> > > + }
> > >
> > > /* FIXME needs to be calibrated sensibly */
> > > min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > index c335b1dbafcf..db1c3902fc2d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct
> > > intel_crtc_state *crtc_state)
> > > TRANS_PUSH_EN | TRANS_PUSH_SEND);
> > > }
> > >
> > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > +
> > > + if (!crtc_state->vrr.enable)
> > > + return false;
> > > +
> > > + return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) &
> > > TRANS_PUSH_SEND;
> >
> > But HW clears this bit after double buffer update. Is this a good
> > inidcation to check the PUSH_SEND bit?
> >
> > Manasi
> >
> > > +}
> > > +
> > > void intel_vrr_disable(const struct intel_crtc_state *old_c
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix framestart_delay commens in VRR code
On Wed, Nov 17, 2021 at 08:31:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since I originally wrote these comments we decided to change our
> definition of framestart_delay from 0-3 to 1-4. Adjust the comments
> to match that new convention. The actual code was adjusted already.
>
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index db1c3902fc2d..139e8936edc5 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -60,7 +60,7 @@ intel_vrr_check_modeset(struct intel_atomic_state *state)
> * Between those two points the vblank exit starts (and hence registers get
> * latched) ASAP after a push is sent.
> *
> - * framestart_delay is programmable 0-3.
> + * framestart_delay is programmable 1-4.
> */
> static int intel_vrr_vblank_exit_length(const struct intel_crtc_state
> *crtc_state)
> {
> @@ -138,13 +138,13 @@ intel_vrr_compute_config(struct intel_crtc_state
> *crtc_state,
> i915->window2_delay;
> else
> /*
> - * FIXME: s/4/framestart_delay+1/ to get consistent
> + * FIXME: s/4/framestart_delay/ to get consistent
>* earliest/latest points for register latching regardless
>* of the framestart_delay used?
>*
>* FIXME: this really needs the extra scanline to provide
> consistent
>* behaviour for all framestart_delay values. Otherwise with
> - * framestart_delay==3 we will end up extending the min vblank
> by
> + * framestart_delay==4 we will end up extending the min vblank
> by
>* one extra line.
>*/
> crtc_state->vrr.pipeline_full =
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent
On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's adjust the vblank evasion to account for the case where
> a push has already been sent. In that case the vblank exit will start
> at vmin vblank start (as opposed to vmax vblank start when no push
> has been sent).
>
> This should minimize the effects of the tiny race between sampling
> the frame counter vs. intel_vrr_send_push() during the previous frame.
> This will also be required if we want to do mailbox style updates with
> vrr since then we'd definitely do multiple commits per frame. Currently
> mailbox updates are only used by the legacy cursor, but we don't do
> vrr push for those.
>
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
> drivers/gpu/drm/i915/display/intel_vrr.c | 12
> drivers/gpu/drm/i915/display/intel_vrr.h | 1 +
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index cf403be7736c..eb5444f90e77 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state
> *new_crtc_state)
> if (intel_crtc_needs_vblank_work(new_crtc_state))
> intel_crtc_vblank_work_init(new_crtc_state);
>
> - if (new_crtc_state->vrr.enable)
> - vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> - else
> + if (new_crtc_state->vrr.enable) {
> + if (intel_vrr_is_push_sent(new_crtc_state))
> + vblank_start =
> intel_vrr_vmin_vblank_start(new_crtc_state);
Actually if Push is sent then the vblank gets terminated at that point which
falls between vmin and vmax so
not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to
calculate it based on vmin?
> + else
> + vblank_start =
> intel_vrr_vmax_vblank_start(new_crtc_state);
> + } else {
> vblank_start = intel_mode_vblank_start(adjusted_mode);
> + }
>
> /* FIXME needs to be calibrated sensibly */
> min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index c335b1dbafcf..db1c3902fc2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state
> *crtc_state)
> TRANS_PUSH_EN | TRANS_PUSH_SEND);
> }
>
> +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> + if (!crtc_state->vrr.enable)
> + return false;
> +
> + return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) &
> TRANS_PUSH_SEND;
But HW clears this bit after double buffer update. Is this a good inidcation to
check the PUSH_SEND bit?
Manasi
> +}
> +
> void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h
> b/drivers/gpu/drm/i915/display/intel_vrr.h
> index 96f9c9c27ab9..1c2da572693d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state
> *crtc_state,
> void intel_vrr_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state);
> void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
> void intel_vrr_get_config(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state);
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again
On Wed, Nov 17, 2021 at 08:31:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Moving the vrr push to happen before sampling the frame counter
> was wrong. If we are already in vblank when the push is sent
> the vblank exit will start immediately which causes the sampled
> frame counter to correspond to the next frame instead of the current
> frame.
>
> So put things back into the original order (except we should
> keep the vrr push within the irq disable section to avoid
> pointless irq related delays here).
>
> We'll just have to accept the tiny race that exists between
> sampling the frame counter vs. vrr push. And let's at least
> document said race properly in a comment.
>
> I suppose we could try to minimize the race by sampling the frame
> counter just before sending the push, but that would require
> changing drm_crtc_arm_vblank_event() to accept a caller provided
> vblank counter value, so leave it be for now. Another thing we
> could do is change the vblank evasion to account for the case
> where a push was already sent. That would anyway be required
> for mailbox style updates. Currently mailbox updates are only
> used by the legacy cursor, but we don't do a vrr push for those.
>
> Cc: Manasi Navare
> Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame
> counter")
> Signed-off-by: Ville Syrjälä
The original order was to send push after enabling IRQs but I think it makes
sense to send push just before enabling IRQs so avoid the vblank
termination getting delayed due to IRQs
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index f09df2cf052b..cf403be7736c 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -610,9 +610,6 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
>
> trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
>
> - /* Send VRR Push to terminate Vblank */
> - intel_vrr_send_push(new_crtc_state);
> -
> /*
>* Incase of mipi dsi command mode, we need to set frame update
>* request for every commit.
> @@ -641,6 +638,22 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
> new_crtc_state->uapi.event = NULL;
> }
>
> + /*
> + * Send VRR Push to terminate Vblank. If we are already in vblank
> + * this has to be done _after_ sampling the frame counter, as
> + * otherwise the push would immediately terminate the vblank and
> + * the sampled frame counter would correspond to the next frame
> + * instead of the current frame.
> + *
> + * There is a tiny race here (iff vblank evasion failed us) where
> + * we might sample the frame counter just before vmax vblank start
> + * but the push would be sent just after it. That would cause the
> + * push to affect the next frame instead of the current frame,
> + * which would cause the next frame to terminate already at vmin
> + * vblank start instead of vmax vblank start.
> + */
> + intel_vrr_send_push(new_crtc_state);
> +
> local_irq_enable();
>
> if (intel_vgpu_active(dev_priv))
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH] drm/i915/display/tgl: Implement Wa_14013120569
On Mon, Nov 01, 2021 at 12:25:21PM +0200, Jani Nikula wrote:
> On Mon, 28 Jun 2021, Madhumitha Tolakanahalli Pradeep
> wrote:
> > PCH display HPD IRQ is not detected with default filter value.
> > So, PP_CONTROL is manually reprogrammed.
>
> Returning to this workaround.
>
> You're not supposed to enable the workaround when there's eDP
> connected. This is also crucial in avoiding issues with eDP PPS.
>
> The workaround is specific to Tiger Lake PCH, so you need to check
> against the PCH, not the GPU.
>
> Also see comments inline.
>
> >
> > Signed-off-by: Madhumitha Tolakanahalli Pradeep
> >
> > ---
> > .../gpu/drm/i915/display/intel_display_power.c | 8
> > drivers/gpu/drm/i915/display/intel_hotplug.c | 16
> > 2 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 285380079aab..e44323cc76f5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -6385,8 +6385,16 @@ static void intel_power_domains_verify_state(struct
> > drm_i915_private *i915)
> >
> > void intel_display_power_suspend_late(struct drm_i915_private *i915)
> > {
> > +struct drm_i915_private *dev_priv = i915;
> > +u32 val;
> > if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
> > IS_BROXTON(i915)) {
> > + val = intel_de_read(dev_priv, PP_CONTROL(0));
> > + /* Wa_14013120569:tgl */
> > + if (IS_TIGERLAKE(i915)) {
> > + val &= ~PANEL_POWER_ON;
> > + intel_de_write(dev_priv, PP_CONTROL(0), val);
> > + }
>
> As José said, how do you enable the workaround after resume if external
> displays are still connected?
>
> > bxt_enable_dc9(i915);
> > /* Tweaked Wa_14010685332:icp,jsp,mcc */
> > if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
> > PCH_MCC)
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > index 47c85ac97c87..8e3f84100daf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > @@ -26,6 +26,7 @@
> > #include "i915_drv.h"
> > #include "intel_display_types.h"
> > #include "intel_hotplug.h"
> > +#include "intel_de.h"
> >
> > /**
> > * DOC: Hotplug
> > @@ -266,7 +267,9 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> > struct intel_connector *connector)
> > {
> > struct drm_device *dev = connector->base.dev;
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > enum drm_connector_status old_status;
> > + u32 val;
> > u64 old_epoch_counter;
> > bool ret = false;
> >
> > @@ -288,6 +291,19 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> >
> > drm_get_connector_status_name(connector->base.status),
> > old_epoch_counter,
> > connector->base.epoch_counter);
> > +
> > + /* Wa_14013120569:tgl */
> > + if (IS_TIGERLAKE(dev_priv)) {
> > + val = intel_de_read(dev_priv, PP_CONTROL(0));
> > + if (connector->base.status ==
> > connector_status_connected) {
> > + val |= PANEL_POWER_ON;
> > + intel_de_write(dev_priv, PP_CONTROL(0), val);
> > + }
> > + else if (connector->base.status ==
> > connector_status_disconnected) {
> > + val &= ~PANEL_POWER_ON;
> > + intel_de_write(dev_priv, PP_CONTROL(0), val);
> > + }
> > + }
>
> First off, usually if you have a clean, generic, high level function,
> it's a hint you shouldn't stick low level register access there.
>
> If you plug in two external displays and then unplug one of them, you
> end up disabling the workaround, while it's supposed to remain enabled
> if there's an external display connected. This is likely the most
> annoying part about the workaround.
>
> This does not seem like a trivial workaround to implement.
>
Yes I agree, not a trivial W/A to implement. I think few main things to figure
out:
- Right place to enable/disable the W/A at connect/disconnect and for the
connectors already connected on boot - Probably in hdmi_init_connector() and
dp_init_connector() for the connected conns
on boot and then intel_encoder_hptplug() at the time of ext display
hotplug/unplug
@Jani having this W/A in above 2 places you think is good?
- The other thing like Jani pointed out is that we should enable/disable only
if !edp - so add this check for init_connector functions before setting/
clearing the W/A
- Third thing is the wrapper function to be defined in intel_pps.c something
like below:
intel_pps_wa_enable(struct
Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
On Mon, Nov 01, 2021 at 09:35:32PM -0700, Kulkarni, Vandita wrote: > > -Original Message- > > From: Navare, Manasi D > > Sent: Tuesday, November 2, 2021 10:11 AM > > To: Kulkarni, Vandita > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani > > Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp > > > > On Mon, Nov 01, 2021 at 09:45:23AM -0700, Kulkarni, Vandita wrote: > > > > -Original Message- > > > > From: Navare, Manasi D > > > > Sent: Saturday, October 30, 2021 4:43 AM > > > > To: Kulkarni, Vandita > > > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani > > > > > > > > Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp > > > > > > > > On Wed, Oct 27, 2021 at 09:37:10PM -0700, Kulkarni, Vandita wrote: > > > > > > -Original Message- > > > > > > From: Navare, Manasi D > > > > > > Sent: Thursday, October 28, 2021 12:57 AM > > > > > > To: Kulkarni, Vandita > > > > > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani > > > > > > > > > > > > Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed > > > > > > bpp > > > > > > > > > > > > On Wed, Oct 27, 2021 at 03:23:16PM +0530, Vandita Kulkarni wrote: > > > > > > > DP 1.4 spec limits max compression bpp to uncompressed bpp -1, > > > > > > > which is supported from XELPD onwards. > > > > > > > Instead of uncompressed bpp, max dsc input bpp was being used > > > > > > > to limit the max compression bpp. > > > > > > > > > > > > So the input Pipe BPP which is the uncompressed bpp is decided > > > > > > by the input bpc and when this was initially written, we had > > > > > > designed it to respect the max_req_bpc by the user. > > > > > > So that is what we use to decide the input bpc and hence the > > > > > > pipe_bpp This input pipe_bpp decides the compressed bpp that we > > > > > > calculate based on all the supported output bpps which are > > > > > > supported all the way upto uncompressed_output_bpp - 1. > > > > > > > > > > > > So I dont see the need to change the logic here. Moreover I dont > > > > > > see any change in the dsc_compute_bpp function So I dont > > > > > > understand the purpose of introducing the new max_dsc_pipe_bpp > > > > > > variable here > > > > > > > > > > Thanks for the comments, I had few more opens around this along > > > > > with > > > > this patch. > > > > > > > > > > AFAIU about max_requested_bpc it is to limit the max_bpc > > > > > "drm: Add connector property to limit max bpc" > > > > > And the driver is supposed to program the default bpc as per the > > > > > connector > > > > limitation. > > > > > Which is 12 as per the current driver implementation. > > > > > > > > > > I had few queries around this design: > > > > > So it means that max_dsc_input_bpp would be set to 36 if supported > > > > > by the > > > > sink and the platform. > > > > > And now we make this as our pipe_bpp, 1. Does this mean that we > > > > > are assuming 12bpc as i/p always? > > > > > 2. What happens to those with formats 8bpc, 10 bpc? > > > > > > > > > > > > > Yes so this driver policy was decided based on some feedback that I > > > > had got from the community as well as internal feedback from Ville > > > > that the decision of input_bpc should be based on max_bpc requested > > > > by the user through the connector property and max_bpc supported by > > the platform. > > > > Here we take the min of the two so that we dont violate either of > > > > the max constrains. > > > > This was primarily suggested by Ville since he said that we should > > > > always respect what user has set as the upper limit in the bpc > > > > because this could be for example driven by the fact that OEM's > > > > panel has a limitation or issues with higher bpcs or a display > > > > requirement > > for certain use case. > > > > Hence while we want to support as high bpc as supported by the > &g
