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. >> 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). >> If you now create ps8622 bindings that do not >> support those graphs, the no one else using ps8622 can use >> ports/endpoint graphs either. > > That's not true. The binding can easily be extended in a backwards- > compatible way later on (should it really prove necessary). I hope you are right =). As I said in my earlier mail, my experience so far has been different. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature