Proposal for a low-level Linux display framework

[Tomi Valkeinen]

On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 
> > 2) panel drivers, handles panel specific things. Each panel may support
> > custom commands and features, for which we need a dedicated driver. And
> > this driver is not platform specific, but should work with any platform
> > which has the output used with the panel.
> 
> Right, we've got DDC ports (which are just i2c) and DisplayPort aux
> channel stuff.
> 
> The DDC stuff is abstracted out and shared across the drivers, but the
> DisplayPort aux channel code is not -- it's duplicated in every output
> driver. 

I feel that you are still talking about the output driver, not the
panel. DDC and DP aux are part of the connector-entity in DRM, right?
But there's no separate display-entity behind the connector, which would
handle the peculiarities for a particular panel/display, say DSI panel
model L33T from AcmeCorp.

So, as I see it, DDC and DP aux are on the output driver, and the panel
driver uses those to do whatever is needed for a particular panel.

> > DSI bus is a half-duplex serial bus, and while it's designed for
> > displays you could use it easily for any communication between the SoC
> > and the peripheral.
> 
> Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world.

But that is still more or less standard HDMI stuff, isn't it? So you
implement it once for HDMI, and then it works with all HDMI monitors?

Or is there some way to implement custom behavior for one particular
HDMI monitor? Is this custom behavior in a kernel driver or handled in
userspace?

> > The point is that we cannot have standard "MIPI DSI command mode panel
> > driver" which would work for all DSI cmd mode panels, but we need (in
> > the worst case) separate driver for each panel.
> 
> It sounds like we do want to share code for those bits, much like we
> have DDC split out now. And, we should do something about the
> DisplayPort aux channel stuff to avoid duplicating it everywhere.

Yep. What I had in mind for DSI with my low-level fmwk would be a
mipi_dsi component that offers services to use the DSI bus. Each
platform which supports DSI would implement the DSI support for their
HW. Then the DSI panel driver could do things like:

dsi->write(dev, virtual_channel_id, buf, len);

dsi->set_max_return_packet_size(dev, 10);
dsi->read(dev, virtual_channel_id, read_cmd, recv_buf, len);

An example DSI command mode panel driver can be found from
drivers/video/omap2/displays/panel-taal.c, which uses omapdss' dsi
functions directly but could quite easily use a common DSI interface and
thus be platform independent.

> I'm not sure a common interface to all of these different
> channels makes sense, but surely a DSI library and an aux channel
> library would fit nicely alongside the existing DDC library.

What do you mean with "channel"? Any video or command bus going to the
display? Yes, I think they are quite different and I don't see a point
in trying to make a common interface for them. 

DSI is in many ways a real bus. You can connect multiple peripherals to
one DSI bus (but it needs a DSI hub), and communicate with them by using
their virtual channel ID. And quite often there are DSI chips that
transform the DSI packets to some other form. Some real example
configurations:

Plain DSI panel:

[SoC] ---DSI--- [DSI panel]

DSI-2-DisplayPort converter chip:

[SoC] ---DSI--- [DSI chip] ---DP--- [DP monitor]

DSI buffer chip supporting to DSI panels:

[SoC] ---DSI--- [DSI chip] +--DSI--- [DSI panel 1]
                           |--DSI--- [DSI panel 2]

It would be nice to be able to model this somehow neatly with device
drivers. For example, the DSI panel from the first example could be used
in the two-panel configuration, and if (and when) the panel requires
custom configuration, the same panel driver could be used in both cases.
In the first case the panel driver would use DSI support from the Soc,
in the third case the panel driver would use the DSI support from the
DSI chip (which would, in turn, use DSI support from the SoC).

 Tomi