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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
