On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
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:
> > >
> 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.
Ok, looking at previous debug output logs shows that those extended caps are not present on the systems, ie. that extended caps bit is not set. So dpcd[0x1] == 0xa.
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)?
True, it's Apple which likes to "Think different..." :/
Will do. But is there a proper/better way to do the /dev/drm_dp_aux0 dump? I used cat /dev/drm_dp_aux0 > dump, and that hangs, but if i interrupt it after a few seconds, i get a dump file of 512k size, which seems excessive? On AMD DC atm., in case that matters.
However, the file shows DPCD_REV 1.1, maximum 0xa and no extended caps (DP_TRAINING_AUX_RD_INTERVAL aka [0xe] == 0x00).
-mario
--
Ville Syrjälä
Intel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
