<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:<br>
> On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>><br>
> wrote:<br>
> <br>
> > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:<br>
> > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:<br>
> > > > The panel reports 10 bpc color depth in its EDID, and the UEFI<br>
> > > > firmware chooses link settings at boot which support enough<br>
> > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the<br>
> > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,<br>
> ><br>
> > Does it actually or do we just ignore the fact that it reports 3.24Gbps?<br>
> ><br>
> > If it really reports 3.24 then we should be able to just add that to<br>
> > dp_rates[] in intel_dp_set_sink_rates() and be done with it.<br>
> ><br>
> > Although we'd likely want to skip 3.24 unless it really is reported<br>
> > as the max so as to not use that non-standard rate on other displays.<br>
> > So would require a bit fancier logic for that.<br>
> ><br>
> ><br>
> Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 Gbps<br>
> as maximum.<br>
<br>
So dpcd[0x1] == 0xa ?<br>
<br></blockquote><div><br></div><div>Yes. [*]<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?<br>
Hmm. I guess we should already be reading that via<br>
intel_dp_extended_receiver_capabilities().<br></blockquote><div><br></div><div>Yes, you do.</div><div><br></div><div>[*] 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:</div><div><br></div><div>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.</div><div><br> </div><div>Btw. your proposed <br></div><div><br></div><div>/* blah */</div><div>if (max_rate > ...)</div><div><br></div><div>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.</div><div><br></div><div>-mario</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Ville Syrjälä<br>
Intel<br>
</blockquote></div></div>