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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/12/2013 04:53 PM, Tomi Valkeinen wrote:
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.

You are right that any display where control bus is different from data bus have the same issue of two parents/busses.

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.

Maybe in most cases, like a modern mobile phone. But for DBI and DSI you can have many devices or endpoints on the same bus. On DSI you can even probe for devices. So I don't think they are that far off Linux busses. Agreed that DPI is not one of those, but even that can be used for multiple panels with a scanline buffered panel and scanline interleaving (think interlaced). But the latter DPI is not a use case I think we should target, it could be simulated as two point to point connections. In all cases I would like to use normal pm, enumeration etc, but then we need a way to describe multiple parents so I2C is not turned off before DPI etc. Not all platforms have dedicated I2C master under graphics sub system control. And even point-to-point will have a parent. A DPI bus could be extremely simple, the bus type struct, the dispc as bus device (display parent), and some DPI ops for the device, not the parent device. I assume video sources is a point to point reference (maybe video pipe is more correct), that is, it encapsulates both the host and the client in one object, since there is no reference to the actual device you operate on in the video source ops.
- 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.
Agreed, 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.

Agreed, but that doesn't mean we need to bake them all into one. There is very little overlap between the different bus APIs.
- 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).

The idea is to keep things simple. If you have video bridge chips, you can create a "bridge-CDF" driver that aggregate the next device in the chain. That way we never expose the complexity in those special cases with chains of encoders. This would also be easy to describe using the dev->parent relationship.
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.

For MIPI type interfaces yes. But not for I2C+DSI for example. I think it is this idea to handle some interfaces differently from others that my pattern matching brain don't accept ;).
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.


That depends on what ops we put in the bus. If we put both data and control ops as bus ops, we don't need that. The only thing I don't like with the full bus solutions is the idea of having two struct device for one physical device. But that is only for displays with multiple busses, which are kind of rare compared to the main target embedded panels which normally only use DSI/DBI bus for both data and control. Of course there are some DPI panels which would need dual busses. But most DPI panels I have used in products (if not all) never use I2C at all, only power on/off regulator and nothing more.

BTW. It should be noted that my own SoC driver use a design similar to "video source" currently :). Except it is called port in driver and formatter in dispc HW.

/BR
/Marcus

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux