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

[Andrzej Hajda <a.hajda@samsung.com>]

On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
>> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
>>> 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).
>> I do not see why performance may drop significantly?
>> If the link is one-way it should probably work as below:
>> - the destination registers itself in some framework,
>> - the source looks for the destination in this framework using phandle,
>> - the source starts to communicate with the destination - since now full
>> two way link can be established dynamically.
>>
>> Where do you see here big performance penalty?
> The performance-related problems arise when you need to locate the remote 
> device in the direction opposite to the phandle link direction. Traversing a 
> link forward just involves a phandle lookup, but traversing it backwards isn't 
> possible the same way.
>
But you do not need to traverse backwards. You just wait when the source
start
to communicate with the destination, at this moment destination can
build back-link
dynamically.

Regards
Andrzej