On 06/10/14 17:40, Laurent Pinchart wrote:
>> But seriously speaking, I was thinking about this. I'd really like to
>> have a generic video-mux node, that would still somehow allow us to have
>> device specific configurations for the video sources and sinks (which
>> the endpoints provide us), without endpoints.
>>
>> The reason endpoints don't feel right in this case is that it makes
>> sense that the mux has a single input and two outputs, but with
>> endpoints we need two endpoints from the bridge (which is still ok), but
>> we also need two endpoitns in the mux's input side, which doesn't feel
>> right.
>>
>> I came up with the following. It's quite ugly, though. I hope someone
>> has ideas how it could be done in a neater way:
>>
>> bridge1234 {
>> bridge1234-cfg1: config1 {
>> high-voltage;
>> };
>>
>> bridge1234-cfg2: config2 {
>> low-voltage;
>> };
>>
>> output = <&mux>;
>> };
>>
>> mux: video-gpio-mux {
>> gpio = <123>;
>>
>> outputs = <&panel1 &panel2>;
>> input-configs = <&bridge1234-cfg1 &bridge1234-cfg2>;
>> };
>>
>> panel1: panel-foo {
>>
>> };
>>
>> panel2: panel-foo {
>>
>> };
>>
>> So the bridge node has configuration sets. These might be compared to
>> pinmux nodes. And the mux has a list of input-configs. When panel1 is to
>> be enabled, "bridge1234-cfg1" config becomes active, and the bridge is
>> given this configuration.
>>
>> I have to say the endpoint system feels cleaner than the above, but
>> perhaps it's possible to improve the method above somehow.
>
> Isn't it possible for the bridge to compute its configuration at runtime by
> querying properties of the downstream video entities ? That would solve the
> problem neatly.
You mean the bridge driver would somehow take a peek into panel1 and
panel2 nodes, looking for bridge specific properties? Sounds somewhat
fragile to me... How would the bridge driver know a property is for the
bridge?
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
