On Tue, Apr 16, 2019 at 03:28:24PM +0000, Li, Sun peng (Leo) wrote: > >> Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through > >> the spec didn't provide any solid explanations either :( However eg. > >> "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration" > >> in the DP 1.4 spec does appear to show kind of virtual DPCD thing behind > >> a logical port. But I'm not really sure what than means. > > > > Good point, I'm gonna dig more into that. It sounds like we should be > > able to access that with the relative addressing as defined by the spec > > (2.11.5). I'll have to see why that's currently getting nacked though. > > > > It looks like DPCD reads on logical ports work on some devices, and not > others... I swapped my MST display out with a different one, and it read > just fine. > > More specifically - in a daisy chain setup with 2 MST displays - with > the one that works at the end: > > # auxrw.py read /dev/drm_dp_aux4_mst\:0-1-8 0x30-0x3f -> ACK > # auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK > (The GUIDs returned are identical) > > With the one that doesn't at the end: > > # auxrw.py read /dev/drm_dp_aux4_mst\:0-1-8 0x30-0x3f -> *NAK* > # auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK > > So it seems there's some device dependent behavior here. I'm not sure if > there's a better way of handling this besides exposing all the > downstream ports: If it works, great. If not, just don't use it? Yeah, I think that's fine. It's really meant for debugging anyway so doesn't really matter if we expose something that's not guaranteed to work. -- Ville Syrjälä Intel _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
