Re: [RFC v2 0/5] Common Display Framework

On 2012-12-17 16:36, Laurent Pinchart wrote:

Hi Tomi,

I finally have time to work on a v3 :-)

On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:

quoted

On 2012-11-22 23:45, Laurent Pinchart wrote:

quoted

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Hi everybody,

Here's the second RFC of what was previously known as the Generic Panel
Framework.

Nice work! Thanks for working on this.

I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:

In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.

I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:

soc-base.dtsi:

dss {
	dpi0: dpi {
	};
};

board.dts:

&dpi0 {
	panel = &dpi-panel;
};

/ {
	dpi-panel: dpi-panel {
		...panel data...;
	};
};

Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).

Hotplug definitely needs to be supported, as the common display framework also 
targets HDMI and DP. The notification mechanism was actually designed to 
support hotplug.

HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a
cable hotplug, handled inside a driver, which doesn't have any effect on
the linux devices.

If we do implement HDMI and DP monitors with real linux drivers, then
yes, we could use real hotplug. But we could as well have the monitor
driver always registered, and just have a driver internal cable-hotplug
system.

To be honest, I'm not sure if implementing real hotplug is easily
possible, as we don't have real, probable (probe-able =) busses. So even
if we'd get a hotplug event of a new display device, what kind of device
would the bus master register? It has no way to know that.

How do you see the proposal preventing hotplug ?

Well, probably it doesn't prevent. But it doesn't feel right to me.

Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be
probed. In the probe function it should somehow register itself to the
cdf, or perhaps the previous entity in the chain.

This sounds to me that the link is from the panel to the previous
entity, not the other way around as you describe, and also the previous
entity doesn't know of the panel entities.

quoted

Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.

I don't see any way around that. The panel is not a standalone entity that can 
only receive calls (as it needs to control video streams, per your request 
:-)) or only emit calls (as something needs to control it, userspace doesn't 
control the panel directly).

Right, but as I see it, the destination of the panel's calls, and the
source of the calls to panel are different things. The destination is
the bus layer, dealing with the video signal being transferred. The
source is a bit higher level thing, something that's controlling the
display in general.

quoted

Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.

I don't think we should handle pure sources, pure sinks (displays) and mixed 
entities (transceivers) differently. I prefer having abstract entities that 
can have a source and a sink, and expose the corresponding operations. That 
would make pipeline handling much easier, as the code will only need to deal 
with a single type of object. Implementing support for entities with multiple 
sinks and/or sources would also be possible.

Ok. I think having pure sources is simpler model, but it's true that if
we need to iterate and study the pipeline during runtime, it's probably
better to have single entities with multiple sources/sinks.

quoted

Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.

What is missing in your proposal is an explanation of how the panel is 
controlled. What does your register_display() function register the display 
with, and what then calls the display operations ?

In my particular case, the omapfb calls the display operations, which is
the higher level "manager" for the whole display. So omapfb does calls
both to the DSS side and to the panel side of the pipeline.

I agree that making calls to both ends is a bit silly, but then again, I
think it also happens in your model, it's just hidden there.

 Tomi