Thread (7 messages) 7 messages, 4 authors, 2018-04-24

[PATCH 1/2 v3] drm/pl111: Support the Versatile Express

flat view

From: Linus Walleij <hidden>
Date: 2018-04-23 07:18:33
Also in: dri-devel

On Wed, Apr 18, 2018 at 2:48 PM, Robin Murphy [off-list ref] wrote:
On 18/04/18 09:52, Linus Walleij wrote:
quoted
The Versatile Express uses a special configuration controller
deeply embedded in the system motherboard FPGA to multiplex the
two to three (!) display controller instances out to the single
SiI9022 bridge.

Set up an extra file with the logic to probe to the FPGA mux
register on the system controller bus, then parse the device
tree to see if there is a CLCD or HDLCD instance on the core
tile (also known as the daughterboard) by looking in the
root of the device tree for compatible nodes.

- If there is a HDLCD on the core tile, and there is a driver
   for it, we exit probe and deactivate the motherboard CLCD.
   We do not touch the DVI mux in this case, to make sure we
   don't break HDLCD.

- If there is a CLCD on both the motherboard and the core tile
   (only the CA9 has this) the core tile CLCD takes precedence
   and get muxed to the DVI connector.

- Only if there is no working graphics on the core tile, the
   motherboard CLCD is probed and muxed to the DVI connector.

This approach seems reasonable (modulo a couple of nits below), and almost
certainly sufficient for most realistic uses, but I can't help wondering
whether it might be feasible to model the mux with its own separate
connector/bridge driver which could handle prioritisation of multiple inputs
itself (I'm pondering things like RK3288/RK3399 where the two VOPs feeding
into the single HDMI block looks a fair bit like the V2P-CA9 situation if
you squint at it).
I did look and make a brief attempt at that approach using a bridge
device for the mux. The problem is that the scenario of daisy-chained
brigdges isn't really there, I would have to invent the world for this,
I added timings to the dumb VGA bridges and now what would be
needed (as decribed by Laurent) is a timings daisy-chaining API
so that the driver can ask the whole chain of bridges to accumulate
timing effects and present the resulting timings.

It can be done, but it would sadly also break some implicit
assumptions in the existing DT bindings.

I would say it is a separate task that can be looked into once we
are migrated over to DRM.

Yours,
Linus Walleij
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help