Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

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

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

On 23/09/14 09:21, Thierry Reding wrote:

>> Well, I can write almost any kind of bindings, and then evidently my
>> device would work. For me, on my board.
> 
> Well, that's the whole problem with DT. For many devices we only have a
> single setup to test against. And even when we have several they often
> are derived from each other. But the alternative would be to defer
> (possibly indefinitely) merging support for a device until a second,
> wildly different setup shows up. That's completely unreasonable and we
> need to start somewhere.

Yes, but in this case we know of existing boards that have complex
setups. It's not theoretical.

I'm not saying we should stop everything until we have a 100% solution
for the rare complex cases. But we should keep them in mind and, when
possible, solve problems in a way that will work for the complex cases also.

>> I guess non-video devices haven't had need for those. I have had lots of
>> boards with video setup that cannot be represented with simple phandles.
>> I'm not sure if I have just been unlucky or what, but my understand is
>> that other people have encountered such boards also. Usually the
>> problems encountered there have been circumvented with some hacky video
>> driver for that specific board, or maybe a static configuration handled
>> by the boot loader.
> 
> I have yet to encounter such a setup. Can you point me at a DTS for one
> such setup? I do remember a couple of hypothetical cases being discussed
> at one time or another, but I haven't seen any actual DTS content where
> this was needed.

No, I can't point to them as they are not in the mainline (at least the
ones I've been working on), for obvious reasons.

With a quick glance, I have the following devices in my cabinet that
have more complex setups: OMAP 4430 SDP, BeagleBoneBlack + LCD, AM43xx
EVM. Many Nokia devices used to have such setups, usually so that the
LCD and tv-out were connected to the same video source.

>> Do we have a standard way of representing the video pipeline with simple
>> phandles? Or does everyone just do their own version? If there's no
>> standard way, it sounds it'll be a mess to support in the future.
> 
> It doesn't matter all that much whether the representation is standard.

Again, I disagree.

> phandles should simply point to the next element in the pipeline and the
> OS abstractions should be good enough to handle the details about how to
> chain the elements.

I, on the other hand, would rather see the links the other way around.
Panel having a link to the video source, etc.

The video graphs have two-way links, which of course is the safest
options, but also more verbose and redundant.

When this was discussed earlier, it was unclear which way the links
should be. It's true that only links to one direction are strictly
needed, but the question raised was that if in the drivers we end up
always going the links the other way, the performance penalty may be
somewhat big. (If I recall right).

 Tomi



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