On Tue, Sep 23, 2014 at 11:54:27AM +0300, Tomi Valkeinen wrote:
> On 23/09/14 09:04, Thierry Reding wrote:
>
> > 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.
>
> I don't see a need for such properties. Do you have examples where they
> would be needed?
>
> The driver for the respective device does know if it's a bridge or a
> panel, so that information is there as soon as the driver has loaded.
These are used for chaining not identifying the device. For example:
bridge0: ... {
...
bridge = <&bridge1>;
...
};
bridge1: ... {
...
panel = <&panel>;
...
};
panel: ... {
...
};
> > 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 don't see why the graphs and such metadata are connected in any way.
> They are separate issues. If we need such metadata, it needs to be added
> in any case. That is not related to the graphs.
My point is that if you use plain phandles you usually have the
meta-data already. Referring to the above example, bridge0 knows that it
should look for a bridge with phandle &bridge1, whereas bridge1 knows
that the device it is connected to is a panel.
> >> 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.
>
> Well, I can't say about this particular bridge, but afaik you can
> connect a parallel RGB signal to multiple panels just like that, without
> any muxing.
Right, but in that case you're not reconfiguring the signal in any way
for each of the panels. You send one single signal to all of them. For
all intents and purposes there is only one panel. Well, I guess you
could have separate backlights for the panels. In that case though it
seems better to represent it at least as a virtual mux or bridge, or
perhaps a "mux panel".
Thierry
Attachment:
pgp2bx5LwHapV.pgp
Description: PGP signature
