[PATCH 0/5] Initial DisplayPort OUI probing

[Alex Deucher]

On Mon, May 21, 2012 at 5:09 PM, Adam Jackson <ajax at redhat.com> 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 at redhat.com> 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