On Tue, Sep 23, 2014 at 02:12:52PM +0300, Laurent Pinchart wrote: > On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote: > > On Tue, Sep 23, 2014 at 12:30:20PM +0300, 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. > > > > Complex setups involving /this particular/ bridge and binding are > > theoretical at this point, however. > > > > > > 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. > > > > > The video graphs have two-way links, which of course is the safest > > > options, but also more verbose and redundant. > > > > Right. If we take that line of thinking to the extreme we end up listing > > individual registers in DT so that we can safely assume that we can > > control all possible aspects of the device. > > And the other extreme would be to have a single DT node for the logical video > device with all information pertaining to it stored in C code. Extremes are > never good, we need to find a reasonable middle-ground here. I believe OF > graph fulfills that requirement, it might be slightly more verbose than a > single phandle, but it's also much more versatile. Oh well, yet another one of these things where we'll never reach an agreement I guess. Thierry
Attachment:
pgpG2JxPK3prq.pgp
Description: PGP signature
