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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
