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

[Marcus Lorentzon]

Hi Greg,
at FOSDEM we had a session on CDF (Common Display Framework). You can 
read more details about this in the posts from Laurent Pinchart on dridevel:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
http://lists.freedesktop.org/archives/dri-devel/2013-February/034576.html
Adding Arnd in CC since he has guided me in the device driver model before.

One design issue came up and Rob/Daniel proposed asking you for 
guidance. Here is some background to the issue.

In CDF we are trying to get some common code between all the embedded 
panels (and maybe also some eDP/DVI/HDMI encoders). Target user is KMS 
encoder/connector "drivers" in DRM on ARM, Intel, SuperH (or others). 
CDF consist of two major APIs (dev ops). One API for display controller 
to use for controlling the display and one API for display driver to use 
to access the data/video/control bus master/host. Much like any device 
hooked into some kernel framework. Here is a small overview of the parts 
and APIs.

KMS API: display controller drv access --->
CDF API: Display/Encoder/Panel drv access --->
Data/Control bus API: bus drv (often the same drv as display controller 
- panel bus host)

The issue is related to the latter bus API. The bus is a combination of 
I2C/SPI/DBI/DSI/DPI busses. I2C and SPI I guess you know.
DBI and a command version of DSI are MIPI standard command mode 
interfaces (DBI - Display Bus Interface, DSI - Display Serial 
Interface), which means they are combined control and data busses (much 
like I2C).
Then there is DPI (Display Parallel Interface) and DSI video mode 
version which are MIPI standard video mode data busses. They are used to 
send pixel data to the display. DPI is a pure one directional data bus, 
but DSI can be used to send commands as well so it can be used as a 
control interface, even during video data streaming (it is a packet 
protocol).

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

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)


2) Another solution discussed at FOSDEM is to make full use of the 
device driver model. This would include adding the MIPI DBI/DSI bus 
types to the kernel. Add a full featured DSI/DBI API for devices 
attached on those busses (functionally the same APIs as for video 
source, but split into the actual bus types). Have display 
controller/host implement DBI/DSI bus ops. And finally register display 
as DBI/DSI device on the respective bus. For displays of type g) this 
could mean having two devices, one I2C device and one DSI device (this 
is the major objection to using the device driver model).

Pros: Device driver model is well understood which will make it easier 
to understand for new CDF developers. Only g) type of panels will 
diverge from driver model (multi parents)
Cons: Two struct device for g) type displays (one per bus), slightly 
more code to create the busses than a simple video source


3) Daniel V hinted that multiple parents (or multiple busses) is 
something that has been discussed as a limitation of device driver model 
before. And that maybe now was the time to fix that or at least sort out 
how to handle it.

Pros: If possible to solve, probably the way to go, since it will 
eliminate the need of 1) and 2) that where created to work around the 
driver model limitation with multi parent
Cons: Out of scope for CDF project, needs device driver model resources 
to fix


4) A combination of 1) and 2). Use video source solution for type g) 
devices and device driver model for the rest.

Pros: See above, each CDF driver can choose the model that fits that 
driver the best
Cons: See above, similar displays might have CDF drivers that look very 
different, still forces hosts to implement video source API

So, what option do you prefer if any?
Any comment on 3) and what has been said so far on multiple bus HW designs?

/BR
/Marcus