<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 2:32 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 09:19:07PM +0100, Mario Kleiner wrote:<br>
> On Thu, Jan 9, 2020 at 7:24 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 06:57:14PM +0100, Mario Kleiner wrote:<br>
> > > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <<br>
> > <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:30:05PM +0100, Mario Kleiner wrote:<br>
> > > > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <<br>
> > > > <a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>><br>
> > > > > wrote:<br>
> > > > ><br>
> ><br>
> <br>
> > wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC<br>
> > > identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only<br>
> > > part of DP 1.3+ if i understand the comments in<br>
> > > intel_dp_extended_receiver_capabilities() correctly.<br>
> ><br>
> ><br>
> Ok, looking at previous debug output logs shows that those extended caps<br>
> are not present on the systems, ie. that extended caps bit is not set. So<br>
> dpcd[0x1] == 0xa.<br>
> <br>
> <br>
> > Yeah, but you never know how creative they've been with the DPCD in<br>
> > such a propritary machine. A full DPCD dump from /dev/drm_dp_aux* would<br>
> > be nice. Can you file a bug an attach the DPCD dump there so we have a<br>
> > good reference on what we're talking about (also for future if/when<br>
> > someone eventually starts to wonder why we have such hacks in the<br>
> > code)?<br>
> ><br>
> ><br>
> True, it's Apple which likes to "Think different..." :/<br>
> <br>
> Will do. But is there a proper/better way to do the /dev/drm_dp_aux0 dump?<br>
> I used cat /dev/drm_dp_aux0 > dump, and that hangs, but if i interrupt it<br>
> after a few seconds, i get a dump file of 512k size, which seems excessive?<br>
> On AMD DC atm., in case that matters.<br>
<br>
It can take a while to dump the whole thing. If there are errors in some<br>
parts (against the spec but some devices simply don't care about the<br>
spec) you may need to use ddrescue/etc. to dump everything that can be<br>
dumped.<br>
<br></blockquote><div>Ok, it is Mozilla bug 206157:</div><div><br></div><div><a href="https://bugzilla.kernel.org/show_bug.cgi?id=206157">https://bugzilla.kernel.org/show_bug.cgi?id=206157</a></div><div><br></div><div>I attached the first ~ 5000 Bytes of DPCD dump, as there is a 5k file size limit. The total dump is 512 kB, mostly zeros.</div><div><br></div><div>-mario</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Ville Syrjälä<br>
Intel<br>
</blockquote></div></div>