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

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

[-- Attachment #1: Type: text/plain, Size: 4132 bytes --]

Hi,

On 2013-12-12 02:39, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
>> 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.

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



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