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
Attachment:
pgpGvrvZuMJrB.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
