On Tue, Sep 23, 2014 at 03:00:31PM +0300, Tomi Valkeinen wrote: > 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. That's an orthogonal problem. You speak about the link in software here, whereas the phandles only represent the link in the description of hardware. Now DT describes hardware from the perspective of the CPU, so it's sort of like a cave that you're trying to explore. You start at the top with the address bus, from where a couple of tunnels lead to the various peripherals on the address bus. A display controller might have another tunnel to a panel, etc. If you go the other way around, how do you detect how things connect? Where do you get the information about the panel so you can trace back to the origin? Thierry
Attachment:
pgpYPRs2LyIAz.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
