[RFC 0/2] Add AUX device entries for DP MST devices

[Ville Syrjälä]

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