Multiple parents in device driver model and Common Display Framework (CDF)

[Tomi Valkeinen]

Hi Marcus,

On 2013-02-12 17:04, Marcus Lorentzon wrote:

> Now we have some different types of panels which are attached on a
> combination of busses:
> 
> a) control:DBI, data:DBI
> b) control:I2C/SPI, data:I2C/SPI
> c) control:static setup, data:DPI
> d) control:I2C/SPI, data:DPI
> e) control:DSI, data:DSI
> f) control:I2C, data:DSI
> g) control:DSI+I2C, data:DSI
> 
> As you could guess, g) is our issue. We have a device family that has
> two control bus attachments and one data bus. The kernel device/driver
> model only supports a single parent device which is normally the bus
> device.
> 
> We will write drivers for all device types a-g implementing the CDF API.
> Those with only I2C/SPI bus attachemnt will of course be I2C drivers
> registered to CDF, same probably goes for DBI and DSI panels if we
> create a new bus type for them (if not - platform devices). But the CDF
> drivers still need some way to access the bus/host operations. So we
> will have to create an API for the exposed operations possible for the
> MIPI type busses (DBI/DSI/DPI), some control and some data bus related.
> For this problem we have discussed a few solutions, which is where we
> need your guidance:
> 
> 1) Due to the fact there is no support for multiple parents in the
> device driver model and the fact that there are no DSI/DBI busses in the
> kernel, Tomi has come up with a sort of logical parent device for
> displays (see video source section, top section is "CDF API"):
> http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/include/video/display.h

When I made that, I didn't even have in mind the case g).

I made it because I think we have issues with case f) also (and, well,
in some sense we have issues with all cases. see below). If we have a
full linux bus for DSI and DBI, I don't quite understand how we should
manage f), because we have both I2C and DSI busses to which the display
device should belong.

I also had these points in my mind why I chose the video_source approach
in my version:

- The display busses are very specialized, point-to-point busses, so a
real linux bus doesn't give very much, I think.

- You never have a video bus used only for control, for example, a panel
controlled via DSI but video data sent via DPI. Yes, possible in theory,
but that would be rather insane.

- We anyway need some kind of non-bus approach for simple video data
busses like DPI. And if we have that, the slightly more complex video
busses like DSI fit quite easily in.

- We need something to represent all the data busses (see below).

> Pros: Simple, easy to implement, merging all bus types into one logical
> bus (simplicity)
> Cons: Diverging from device driver model, merging all bus types into one
> logical bus (scalability, maintainability), has to make a copy of many
> things already in device driver model (pm, enumeration, registration,
> relations, ...), solution only really needed for one special type (g)

It's not only for g). We need something similar for all cases. We need
to represent the chain of display devices with something, which is based
on the data busses. The control bus plays no role in this chain (except
when the data and control busses happen to be the same).

My video_source really represents the data bus, but offers some extended
features so that it also offers control bus operations for those video
busses that have control and data in the same bus.

If we go for a full DSI/DBI linux bus, we still need something to
represent the video bus. Then we'll have two separate entities for DSI
control (the real bus) and for DSI data (video_source or similar), which
in the end go via the same physical DSI bus.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130212/12f58e3d/attachment-0001.pgp>