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. Like I said, this seems to be the latest response to DT ABI stability requirement. Add as much data to a DT node as possible so that it has higher chances of being complete. The result is often overly complex DT content that doesn't add any real value. > 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 doubt that graphs will become so complex that walking it would become a performance bottleneck. In fact if we're constantly walking the graph we're already doing something wrong. It should only be necessary when the pipeline configuration changes, which should hopefully not be very often (i.e. not several times per second). Thierry
Attachment:
pgp8OarpMRcNk.pgp
Description: PGP signature
