On Tue, Sep 23, 2014 at 09:24:12AM +0200, Andrzej Hajda wrote:
> Hi Thierry, Tomi,
> 
> On 09/23/2014 08:04 AM, Thierry Reding wrote:
> > On Mon, Sep 22, 2014 at 05:23:25PM +0300, Tomi Valkeinen wrote:
> >> On 22/09/14 11:06, Thierry Reding wrote:
> >>
> >>>>> Why do we need a complex graph when it can be handled using a simple phandle?
> >>>>
> >>>> Maybe in your case you can handle it with simple phandle. Can you
> >>>> guarantee that it's enough for everyone, on all platforms?
> >>>
> >>> Nobody can guarantee that. An interesting effect that DT ABI stability
> >>> has had is that people now try to come up with overly generic concepts
> >>> to describe devices in an attempt to make them more future-proof. I
> >>> don't think we're doing ourselves a favour with that approach.
> >>
> >> I kind of agree. However, there are boards that need a more complex
> >> approach than just a simple phandle. They are nothing new.
> >>
> >> So while it may be true that this specific encoder has never been used
> >> in such a complex way, and there's a chance that it never will, my
> >> comments are not really about this particular encoder.
> >>
> >> What I want is a standard way to describe the video components. If we
> >> have a standard complex one (video graphs) and a standard simple one
> >> (simple phandles), it's ok for me.
> > 
> > I certainly agree that it's useful to have standard ways to describe at
> > least various aspects. For example I think it would be useful to add
> > standard properties for a bridge's connections, such as "bridge" or
> > "panel" to allow bridge chaining and attaching them to panels.
> > 
> > But I think that should be the end of it. Mandating anything other than
> > that will just complicate things and limit what people can do in the
> > binding.
> > 
> > One of the disadvantages of the video graph bindings is that they are
> > overly vague in that they don't carry information about what type a
> > device is. Bindings then have to require additional meta-data, at which
> > point it's become far easier to describe things with a custom property
> > that already provides context.
> 
> I think it is opposite, graph bindings should describe only the link and
> certainly not what type of device is behind the endpoint. The fact we
> may need that information is a disadvantage of Linux frameworks and
> should be corrected in Linux, not by adding Linux specific properties to
> DT. For example display controller should not care where its output goes
> to: panel, encoder, bridge, whatever. It should care only if the
> parameters of the link are agreed with the receiver.

Well, a display controller is never going to attach to a panel directly.
But I agree that it would be nice to unify bridges and encoders more. It
should be possible to make encoder always a bridge (or perhaps even
replace encoders with bridges altogether). Then once you're out of the
DRM device everything would be a bridge until you get to a panel.

I think we discussed this a while back in the context of bridge
chaining.

Thierry