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@xxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxx> > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
