Re: [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: "Emma Anholt" <emma@anholt.net>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"David Airlie" <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	amd-gfx@lists.freedesktop.org,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Tim Gover" <tim.gover@raspberrypi.com>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	intel-gfx@lists.freedesktop.org,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"Dom Cobley" <dom@raspberrypi.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate
Date: Thu, 4 Nov 2021 17:41:13 +0200	[thread overview]
Message-ID: <YYP/GWqbcvVFIrAj@intel.com> (raw)
In-Reply-To: <20211104084841.mjnennxgelacleaj@gilmour>

On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote:
> Hi Ville,
> 
> On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> > > >  		u32 max_tmds_clock = hf_vsdb[5] * 5000;
> > > >  		struct drm_scdc *scdc = &hdmi->scdc;
> > > >  
> > > > -		if (max_tmds_clock > 340000) {
> > > > +		if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) {
> > > >  			display->max_tmds_clock = max_tmds_clock;
> > > >  			DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> > > >  				display->max_tmds_clock);
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > index d2e61f6c6e08..0666203d52b7 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
> > > >  		if (scdc->scrambling.low_rates)
> > > >  			pipe_config->hdmi_scrambling = true;
> > > >  
> > > > -		if (pipe_config->port_clock > 340000) {
> > > > +		if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) {
> > > >  			pipe_config->hdmi_scrambling = true;
> > > >  			pipe_config->hdmi_high_tmds_clock_ratio = true;
> > > >  		}
> > > 
> > > All of that is HDMI 2.0 stuff. So this just makes it all super
> > > confusing IMO. Nak.
> > 
> > So reading throgh HDMI 1.4 again it does specify 340 MHz as some kind
> > of upper limit for the physical cable. But nowhere else is that number
> > really mentioned AFAICS. HDMI 2.0 does talk quite a bit about the 340
> > Mcsc limit in various places.
> > 
> > I wonder what people would think of a couple of helpers like:
> > - drm_hdmi_{can,must}_use_scrambling()
> > - drm_hdmi_is_high_tmds_clock_ratio()
> > or something along those lines? At least with those the code would
> > read decently and I wouldn't have to wonder what this HDMI 1.4 TMDS
> > clock limit really is.
> 
> Patch 2 introduces something along those lines.
> 
> It doesn't cover everything though, we're using this define in vc4 to
> limit the available modes in mode_valid on HDMI controllers not
> 4k-capable

I wouldn't want to use this kind of define for those kinds of checks
anyway. If the hardware has specific limits in what kind of clocks it
can generate (or what it was validated for) IMO you should spell
those out explicitly instead of assuming they happen to match
some standard defined max value.

-- 
Ville Syrjälä
Intel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel