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