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

[Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>]

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

On 23/09/14 12:53, Thierry Reding wrote:

>> Yes, but in this case we know of existing boards that have complex
>> setups. It's not theoretical.
> 
> Complex setups involving /this particular/ bridge and binding are
> theoretical at this point, however.

Right, but this discussion, at least from my part, has not so much been
about this particular bridge, but bridges in general.

So I don't have any requirements for this bridge driver/bindings to
support complex use cases at the time being.

But I do want us to have an option to use the bridge in the future in
such complex case. And yes, we can't guarantee that we'd hit the
bindings right whatever we do, but we should think about it and at least
try.

>>> 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.
> 
> Why? It seems much more natural to describe this using the natural flow
> of data. The device furthest away from the CPU should be the target of
> the phandle. That way the DT can be used to trace the flow of data down
> the pipeline.

Because I see video components "using" their video sources. A panel uses
an encoder to produce video data for the panel. An encoder uses its
video source to produce video data. A bit like a device uses a gpio, or
a pwm.

Especially with more complex encoders/panels having the panel/encoder in
control of its video source is often the easiest (only?) way to manage
the job. This has worked well on OMAP, whereas the earlier model where
the video source controlled the video sink was full of problems. Not
that that exactly proves anything, but that's my experience, and I
didn't find any easy solutions when the video source was in control.

So while the video data flows from SoC to the panel, the control goes
the other way. Whether the DT links should model the video data or
control, I don't know. Both feel natural to me.

But if a panel driver controls its video source, it makes sense for the
panel driver to get its video source in its probe, and that happens
easiest if the panel has a link to the video source.

 Tomi



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