On Mon, May 21, 2012 at 5:09 PM, Adam Jackson <ajax@xxxxxxxxxx> wrote: > On Mon, 2012-05-21 at 16:35 -0400, Alex Deucher wrote: >> On Mon, May 21, 2012 at 4:11 PM, Adam Jackson <ajax@xxxxxxxxxx> wrote: >> > I had been considering MST to be multiple CRTCs and some quasi-virtual >> > connectors. Does that not match the hardware? >> >> That's the basic idea. At the hw level you have multiple crtcs and >> digital encoders feeding a single digital phy which is wired to a >> connector on the board. The phy takes care of muxing the source >> streams. MST works by enclosing multiple video streams (plus optional >> secondary streams like audio) into VC (virtual channel) packets. The >> VC packets are scheduled into timeslots in the main link timing. >> Setup is via aux. The DP bus starts to look more like a network. > > Right, my question was more whether there'd be an issue with using CRTCs > and connectors as we already have them, or whether it's something new > we'd need to teach userspace about. Certainly it might be ugly to have > DP-0.0 through DP-0.16, but functionally it doesn't seem like a big > deal. Exposing DP-0.0 to DP-0.x would probably be the easiest, but it's certainly ugly. I suppose ideally we'd make monitors a top level object and allow a one to many abstraction between connectors and monitors. Or expose some sort of connector bus that would just have one endpoint on legacy connectors, but support advanced topologies on DP 1.2. It could get a little tricky teaching the current driver how to do an MST modeset since right now the drm encoders generally represent both the digital encoder and phy hardware. Ideally we'd have some extra level of abstraction, but that could be kept internal to the drivers. > >> Additionally, you can tunnel other things like USB. Should be "fun." > > Yeah, ethernet too if the marketing material is to be believed. > Definitely going to need a more sophisticated bandwidth calculator at > minimum. How complete is the USB support? Like, do isochronous > transfers have to work? They already don't work very well on real USB, > I can't imagine it working better on a contended link. I don't know. All I know was gleaned from snippets that I read in marketing and internal docs. I'm sure our display team knows the finer points. This seems like a place were we could share some common kernel infrastructure across drivers. Alex > > - ajax _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel