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. > >> The point of the ports/endpoint graph is to also support more > >> complicated scenarios. > > > > But the scenario will always remain the same for this bridge. There will > > always be an input signal and a translation to some output signal along > > with some parameters to control how that translation happens. More > > complicated scenarios will likely need to be represented differently at > > a higher level than the bridge. > > Yes, there's always one active input and one output for this bridge. > What the video graphs would bring is to have the possibility to have > multiple inputs and outputs, of which a single ones could be active at a > time. The different inputs and outputs could even have different > settings required (say, first output requires this bit set, but when > using second output that bit must be cleared). As discussed elsewhere this should be handled at a different level then. DT should describe the hardware and this particular bridge device simply doesn't have a means to connect more than a single input or more than a single output. Thierry
Attachment:
pgpDDN57c5BqN.pgp
Description: PGP signature
