[Intel-gfx] [PATCH 6/6] drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports

[Ville Syrjälä]

On Wed, Dec 22, 2021 at 11:47:03AM +0200, Jani Nikula wrote:
> On Fri, 17 Dec 2021, Ville Syrjala <ville.syrjala at linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > Lots of machines these days seem to have a crappy type1 DP dual
> > mode adaptor chip slapped onto the motherboard. Based on the
> > DP dual mode spec we currently limit those to 165MHz max TMDS
> > clock.
> >
> > Windows OTOH ignores DP dual mode adaptors when the VBT
> > indicates that the port is not actually DP++, so we can
> > perhaps assume that the vendors did intend that the 165MHz
> > clock limit doesn't apply here. Though it would be much
> > nicer if they actually declared an explicit limit through
> > VBT, but that doesn't seem to be happening either.
> >
> > So in order to match Windows behaviour let's ignore the
> > DP dual mode adaptor's TMDS clock limit for ports that
> > don't look like DP++ in VBT.
> >
> > Unfortunately many older VBTs misdelcare their DP++ ports
> > as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB
> > Lenovo ThinkPad X220). So we can't really do this universally
> > without risking black screens. I suppose a sensible cutoff
> > is HSW+ since that's when 4k became a thing and one might
> > assume that the machines have been tested to work with higher
> > TMDS clock rates.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Out of curiousity, on the machines where we are currently too strict on
> the limitation, do we actually read and get a valid limit from the
> adaptor in drm_dp_dual_mode_max_tmds_clock(), or is it the fallback 165
> MHz that's too strict? If the latter, should the fallback policy be
> moved out of drm_dp_dual_mode_max_tmds_clock() instead?

We've seen two types of cases:
1) Can't identify a DP dual mode adaptor (ie. can't succesfully read
   any register from the adaptor), so we use
   intel_bios_is_port_dp_dual_mode() to check for native HDMI vs.
   DP++ port. If it looks like DP++ then we assume a type1 DVI adaptor
   and so we limit to 165MHz.
2) We actually detect a type1 HDMI adaptor (ie. we manage to read the
   magic ID string from its registers). Still type1 so we limit to
   165MHz as well.

The third type of case of detecting a type2 adaptor (which will actually
report its max TMDS clock limit) on what looks like a native HDMI port
I don't think we've seen yet.

Anyways, I think with this extra check we more or less match Windows
behaviour. The only difference is that Windows doesn't even probe the
DP dual mode adaptor for native HDMI ports. I think I still want to
do the probe so that the logs will at least show that the chip is there,
even if we ignore it. Just generally better to have as much information
about the system in the logs as possible.

Another slight diffrence in behaviour is that Windows seems to
limit DVI ports (as per VBT) to 165MHz as well. We do not.

To answer the original question, I don't think there's anything we
can relly do differenrely in drm_dp_dual_mode_max_tmds_clock().

> 
> Anyway, seems that currently we're erring too far to lower limits to
> avoid black screens, so seems okay to relax this a bit. ISTR we've had
> quite a few bug reports about this.

It's a tough balance. The big problem is that we have no really
nice way for the user to override any of this safely (apart from
the manual modeline which isn't so nice). So we try to play
it a bit safe to avoid the black screens. Unfortunately quite
a few recent machines don't seem to play well with that idea.

-- 
Ville Syrjälä
Intel