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/incl...
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