[Intel-gfx] [PATCH v4] drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier
Jani Nikula
jani.nikula at linux.intel.com
Wed Nov 8 17:42:17 UTC 2023
On Wed, 08 Nov 2023, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Wed, Nov 08, 2023 at 06:59:18PM +0200, Ville Syrjälä wrote:
>> On Mon, Nov 06, 2023 at 01:42:28PM +0200, Mika Kahola wrote:
>> > Display driver shall read DPCD 00071h[3:1] during configuration
>> > to get PSR setup time. This register provides the setup time
>> > requirement on the VSC SDP entry packet. If setup time cannot be
>> > met with the current timings
>> > (e.g., PSR setup time + other blanking requirements > blanking time),
>> > driver should enable sending VSC SDP one frame earlier before sending
>> > the capture frame.
>> >
>> > BSpec: 69895 (PSR Entry Setup Frames 17:16)
>> >
>> > v2: Write frames before su entry to correct register (Ville, Jouni)
>> > Move frames before su entry calculation to it's
>> > own function (Ville, Jouni)
>> > Rename PSR Entry Setup Frames register to indicate
>> > Lunarlake specificity (Jouni)
>> > v3: Modify setup entry frames calculation function to
>> > return the actual frames (Ville)
>> > Match comment with actual implementation (Jouni)
>> > v4: Drop "set" from function naming (Jouni, Ville)
>> > Use i915 instead of dev_priv (Jouni)
>> >
>> > Signed-off-by: Mika Kahola <mika.kahola at intel.com>
>> > ---
>> > .../drm/i915/display/intel_display_types.h | 1 +
>> > drivers/gpu/drm/i915/display/intel_psr.c | 82 +++++++++++++++----
>> > drivers/gpu/drm/i915/display/intel_psr_regs.h | 2 +
>> > 3 files changed, 71 insertions(+), 14 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
>> > index 047fe3f8905a..92f06d67fd1e 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
>> > @@ -1708,6 +1708,7 @@ struct intel_psr {
>> > u32 dc3co_exitline;
>> > u32 dc3co_exit_delay;
>> > struct delayed_work dc3co_work;
>> > + u8 entry_setup_frames;
>> > };
>> >
>> > struct intel_dp {
>> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
>> > index 920f77336163..fc242916349b 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>> > @@ -593,6 +593,9 @@ static void intel_psr_enable_sink(struct intel_dp *intel_dp)
>> > if (intel_dp->psr.req_psr2_sdp_prior_scanline)
>> > dpcd_val |= DP_PSR_SU_REGION_SCANLINE_CAPTURE;
>> >
>> > + if (intel_dp->psr.entry_setup_frames > 0)
>> > + dpcd_val |= DP_PSR_FRAME_CAPTURE;
>> > +
>> > drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val);
>> >
>> > drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
>> > @@ -691,6 +694,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
>> > if (DISPLAY_VER(dev_priv) >= 8)
>> > val |= EDP_PSR_CRC_ENABLE;
>> >
>> > + if (DISPLAY_VER(dev_priv) >= 20)
>> > + val |= LNL_EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp->psr.entry_setup_frames);
>> > +
>> > intel_de_rmw(dev_priv, psr_ctl_reg(dev_priv, cpu_transcoder),
>> > ~EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK, val);
>> > }
>> > @@ -728,11 +734,27 @@ static int psr2_block_count(struct intel_dp *intel_dp)
>> > return psr2_block_count_lines(intel_dp) / 4;
>> > }
>> >
>> > +static u8 frames_before_su_entry(struct intel_dp *intel_dp)
>> ^^
>>
>> That vs -ETIME broke my tgl.
>>
>> > +static u8 intel_psr_entry_setup_frames(struct intel_dp *intel_dp,
> ^^
> No, actually that ...
*sigh*
I eyeballed the patch and the u8 and thought about giving my standard
issue "please use ints unless you have specific reasons to use something
else" comment. But didn't.
It's a "code smell". It's suspicious even if it isn't broken.
BR,
Jani.
>
>> > + const struct drm_display_mode *adjusted_mode)
>> > +{
>> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> > + int psr_setup_time = drm_dp_psr_setup_time(intel_dp->psr_dpcd);
>> > + u8 entry_setup_frames = 0;
> ^^
> ... and that.
--
Jani Nikula, Intel
More information about the Intel-gfx
mailing list