[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Andrzej Hajda]

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.

On the other side I agree graph bindings are bloated and it should be
possible to simplify them to single phandle if we do not need extra
parameters.

Regards
Andrzej

> 
>>>> 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
> 
> 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>