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

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6746 bytes --]

On 2013-02-12 19:06, Marcus Lorentzon wrote:

> 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

DBI supports two devices and DSI supports four, if I recall right. But
for DSI you need an external hub anyway, so one could argue that it's
still a point to point bus.

Anyway, I have not seen a board that uses those features. Do you have those?

> probe for devices. So I don't think they are that far off Linux busses.

Hmm, you can probe similarly with DBI also, can't you? In neither case
the bus itself supports probing, but you just have to send read-id
messages, and handle the possible errors. This is what you mean, wasn't it?

I'm not sure if DSI probing gives meaningful values for all cases,
though, at least as a generic probing (versus board specific probing of
a few pre-defined devices). Some devices respond to multiple DSI-IDs,
each of which handle different parts of the device (like, one goes to
framebuffer management, other core control, etc.).

Probing over those busses is also something I have not seen used. Have you?

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

Well, I guess you can turn any one-to-one bus to a one-to-many if you
hack enough =).

Anyway, DPI is not a control bus (ok, you _could_ send control messages
embedded in the video data, but again, hacking), so there shouldn't be a
DPI bus in any of the approaches we're thinking about. Or are you
suggesting having linux busses for plain one way data busses also?

> 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

Yes, the PM is an issue. But isn't it an issue with multiple busses
also? Who says the DPI would be turned off first?

My view to this has been that the control bus side is in control (yay!).
So, for example, DPI never turns off except if turned off explicitly by
the display device driver, most likely via some kind of disable call
from the higher level driver which manages the whole display chain.

In many cases we need to do the disabling of the device in a controlled
manner, using both control and video busses. Say, first send a message
via control bus to blank the panel. Then turn off the video bus. Then
turn off the control bus.

But yes, there's still the issue to get the order right, so PM needs
thinking.

> 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

Ok, I see you're thinking DPI as a linux bus also. Having linux busses
for plain video data busses also would make things coherent, but it
would mean that almost all display devices would need to be on multiple
busses, right?

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

In my approach the video source (the host you mention above, I guess)
doesn't need to know anything about the video sink (client, I guess). So
I didn't need to store any references on the video source.

In the future we possibly do need that, so I imagine there would be
something like video_pipe, which has references to both ends.

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

So when you add a new board, which uses display devices that already
have ready drivers in the kernel, you still need to create a new, board
specific bridge driver that describes how the sub-devices are used and
connected? I'm not very fond of that idea.

>> 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 ;).

Do you mean I2C+DSI as a control bus? Or I2C as control and DSI as data?

I wonder if the dual control bus case is something we should even target
at? It sounds to me rather case specific optimization, not something
that's really needed (at least for the v1). I have boards that have
devices that can be controlled via I2C or DSI, but I've just used either
one.

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

I think I2C or SPI is quite common way to control DPI panels. I've
encountered many.

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

Ok, interesting =).

Anyway, note that I'm not trying to say that the full-bus approach
doesn't work. My "brain just doesn't accept it" as you said above, which
could be because I'm so accustomed to a certain way of seeing this whole
display bus thing. So please continue with this approach, and prove my
worries wrong =).

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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