[Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <ville.syrjala at linux.intel.com>
> wrote:
> 
> > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> > ville.syrjala at linux.intel.com>
> > > wrote:
> > >
> > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > > > > firmware chooses link settings at boot which support enough
> > > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > > >
> > > > Does it actually or do we just ignore the fact that it reports
> > 3.24Gbps?
> > > >
> > > > If it really reports 3.24 then we should be able to just add that to
> > > > dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> > > >
> > > > Although we'd likely want to skip 3.24 unless it really is reported
> > > > as the max so as to not use that non-standard rate on other displays.
> > > > So would require a bit fancier logic for that.
> > > >
> > > >
> > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7
> > Gbps
> > > as maximum.
> >
> > So dpcd[0x1] == 0xa ?
> >
> >
> Yes. [*]
> 
> 
> > What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?
> > Hmm. I guess we should already be reading that via
> > intel_dp_extended_receiver_capabilities().
> >
> 
> Yes, you do.
> 
> [*] Well, i have to recheck on the machine. I started this work on the AMD
> side and checked what AMD DC gave me, haven't rechecked stuff under i915
> that i already knew from AMD. Comparing the implementations, there's some
> peculiar differences that may matter:
> 
> intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's
> retrieve_link_cap() function in deciding if the extended receiver caps are
> valid. Intels implementation copies only the first 6 Bytes of extended
> receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure
> about the differences, but one of you may wanna check why this is, and if
> it matters somehow.
> 
> Btw. your proposed
> 
> /* blah */
> if (max_rate > ...)
> 
> wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC
> identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only
> part of DP 1.3+ if i understand the comments in
> intel_dp_extended_receiver_capabilities() correctly.

Yeah, but you never know how creative they've been with the DPCD in
such a propritary machine. A full DPCD dump from /dev/drm_dp_aux* would
be nice. Can you file a bug an attach the DPCD dump there so we have a
good reference on what we're talking about (also for future if/when
someone eventually starts to wonder why we have such hacks in the
code)?

-- 
Ville Syrjälä
Intel