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