On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä <ville.syrj...@linux.intel.com> 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.syrj...@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.syrj...@linux.intel.com> > > > > 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 <https://elixir.bootlin.com/linux/v5.5-rc5/ident/DP_TRAINING_AUX_RD_INTERVAL> aka [0xe] == 0x00). -mario -- > Ville Syrjälä > Intel >
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
