[Intel-gfx] [v1 6/6] drm/i915/display: Reduce blanking to support 4k60 at 10bpp for LSPCON

[Ville Syrjälä]

On Wed, Oct 16, 2019 at 01:46:24PM +0000, Shankar, Uma wrote:
> 
> 
> >-----Original Message-----
> >From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >Sent: Wednesday, October 16, 2019 6:44 PM
> >To: Shankar, Uma <uma.shankar at intel.com>
> >Cc: intel-gfx at lists.freedesktop.org; Mun, Gwan-gyeong <gwan-
> >gyeong.mun at intel.com>; Sharma, Shashank <shashank.sharma at intel.com>
> >Subject: Re: [v1 6/6] drm/i915/display: Reduce blanking to support 4k60 at 10bpp for
> >LSPCON
> >
> >On Wed, Oct 16, 2019 at 04:02:49PM +0530, Uma Shankar wrote:
> >> Blanking needs to be reduced to incorporate DP and HDMI timing/link
> >> bandwidth limitations for CEA modes (4k at 60 at 10 bpp). DP can drive
> >> 17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
> >> This will cause mode to blank out. Reduced Htotal by shortening the
> >> back porch and front porch within permissible limits.
> >>
> >> Signed-off-by: Uma Shankar <uma.shankar at intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_dp.c | 17 +++++++++++++++++
> >>  1 file changed, 17 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index d92777bd3bed..a12b6916023d 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -597,8 +597,10 @@ intel_dp_mode_valid(struct drm_connector
> >> *connector,  {
> >>  	struct intel_dp *intel_dp = intel_attached_dp(connector);
> >>  	struct intel_connector *intel_connector =
> >> to_intel_connector(connector);
> >> +	struct intel_encoder *intel_encoder =
> >> +intel_attached_encoder(connector);
> >>  	struct drm_display_mode *fixed_mode = intel_connector-
> >>panel.fixed_mode;
> >>  	struct drm_i915_private *dev_priv = to_i915(connector->dev);
> >> +	struct intel_lspcon *lspcon =
> >> +enc_to_intel_lspcon(&intel_encoder->base);
> >>  	int target_clock = mode->clock;
> >>  	int max_rate, mode_rate, max_lanes, max_link_clock;
> >>  	int max_dotclk;
> >> @@ -620,6 +622,21 @@ intel_dp_mode_valid(struct drm_connector *connector,
> >>  		target_clock = fixed_mode->clock;
> >>  	}
> >>
> >> +	/*
> >> +	 * Reducing Blanking to incorporate DP and HDMI timing/link bandwidth
> >> +	 * limitations for CEA modes (4k at 60 at 10 bpp). DP can drive 17.28Gbs
> >> +	 * while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps. This will
> >> +	 * cause mode to blank out. Reduced Htotal by shortening the back porch
> >> +	 * and front porch within permissible limits.
> >> +	 */
> >> +	if (lspcon->active && lspcon->hdr_supported &&
> >> +	    mode->clock > 570000) {
> >> +		mode->clock = 570000;
> >> +		mode->htotal -= 180;
> >> +		mode->hsync_start -= 72;
> >> +		mode->hsync_end -= 72;
> >> +	}
> >
> >I don't think we want these kind of hacks. Either the mode works or it doesn't.
> 
> Hi Ville,
> Yeah this is not ideal. But in order to enable HDR which is mostly 10bit content on Lspcon based
> Gen9 devices there are limitations on bandwidth side on DP. So with that limit, we cannot drive
> 10bit content at 4k at 60. But practically we can get this working and able to drive the sink without
> any real issues with above timing adjustments. This gets enabled if firmware advertise HDR capabilities,
>  so in case a vendor doesn't want this, it can be disabled in the LSPCON firmware.
> 
> I tested on HDMI analyzer and multiple sinks and also data from other OS teams suggest that this
> configuration works and is enabled in some of the products as well.
> 
> Definitely not ideal, but at least we get HDR working on Gen9 devices with this, with an option
> of disabling if not required. This can be more of quirk kind of thing.
> 
> What do you suggest.

If user wants HDR user overrides the mode manually.

-- 
Ville Syrjälä
Intel