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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Tomi,

On Tuesday 07 October 2014 10:06:10 Tomi Valkeinen wrote:
> 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?

No, I mean the bridge driver should call the API provided by the panel objects 
to get information about the panels, and compute its configuration parameters 
from those. I'm not sure if that's possible though, it depends on whether the 
bridge parameters can be computed from information provided by the panel.

-- 
Regards,

Laurent Pinchart