Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)

Hi,

On 2013-12-12 02:39, Laurent Pinchart wrote:

Hi Tomi,

On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:

quoted

Hi,

Here's a new version for DT support to OMAP Display Subsystem. See
http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
the previous version, which contains thoughts about the related problems.

The major change in this version is the use of V4L2 and CDF style
port/endpoint style in the DT data.

That's great, and I fully support that. This also calls for refactoring the 
V4L2 DT bindings and support code to share them with display devices. A 
bikeshedding question is where to put the common code.

Thanks very much for review!

I know drivers/video is in practice "fbdev", but drivers/video (the
words) sound like the best place for things related to video.

We should establish a committee to ponder this important question.

Btw, I don't know if you noticed (or did I mention it somewhere): I use
a bit shortened form of the V4L2 bindings. If there's just one endpoint,
I omit the port node. I think that's always unambiguous (compared to
also omitting the endpoint node, and having the properties in the main
node, as was mentioned in some other thread).

I also don't supply the same data for both endpoints, when the data is
about the link. E.g. I think the V4L2 binding doc suggests to supply
things like bus-width for both endpoints. I only supply the data for the
endpoint that uses that data. With some encoders/panels the same data
could be needed on both ends, but not in these patches.

quoted

However, note that even if the DT data contains proper port & endpoint data,
the drivers only use the first endpoint. This is to simplify the patches, as
adding full support for the ports and endpoints to the drivers will be a big
task.

That's perfectly fine, there's no need to implement unused features just for 
the sake of it, as long as the bindings are forward-compatible in that 
respect.

quoted

This approach still works with more or less all the boards, as the only
cases where the simpler model is an issue are the boards with multiple
display devices connected to a single output.

Laurent, I'd appreciate if you could have a look at the .dts changes, to see
if there's anything that's clearly not CDF compatible.

I've quickly reviewed the patch set, concentrating on the .dts changes. 
Overall it looks good to me, but I suspect that we will need quite some time 
to finalize standard bindings as there's lots of small details that need to be 
taken care of.

Yes. I want to get this forward as it's becoming too much pain to manage
things without DSS DT support, when the rest of the OMAP platform code
is using DT.

The most important thing in the DSS DT bindings for now is that they
should contain enough information so that any future DT bindings changes
can be handled with a boot-time conversion code.

Actually, even the endpoint/port stuff is extra, as that could be
deduced even from the "video-source" method I used in earlier DT versions.

The major point that bothers we, as explained in my reply to one of the 
patches, is that I feel like the multi-device model (virtual DSS core + DSS 
modules) might not accurately represent the hardware. Departing from it 
probably sounds scary but might not be such a large change.

There are actually two separate things here. One is the multi-device
model, having separate device for each DSS submodule. The other is
having the 'omapdss' "virtual" platform device.

Note that the "dss_core" device is a real HW block, and depicted as the
"dss" node in DT data, whereas "omapdss" device is not present in the DT
data, and is created dynamically at boot time.

The omapdss device is a legacy thing, but nowadays it is mainly used to
pass platform data. Removing omapdss device is not easy, but the only
questions around that is how to implement the required platform-data
functionalities, and it doesn't affect the DT data.

 Tomi