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

[Tomi Valkeinen]

On 23/09/14 17:45, Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote:
>> On 23/09/14 12:39, Thierry Reding wrote:
>>
>>> 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.
>>
>> The bridge should not care what kind of device is there on the other
>> end. The bridge just has an output, going to another video component.
> 
> You'll need to know at some point that one of the devices in a panel,
> otherwise you can't treat it like a panel.

The bridge doesn't need to treat it like a panel. Someone else might,
though. But the panel driver knows it is a panel, and can thus register
needed services, or mark itself as a panel.

>>>> 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
>>
>> Yes, that's one use case, cloning. But I was not talking about that.
>>
>>> 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".
>>
>> I was talking about the case where you have two totally different
>> devices, let's say panels, connected to the same output. One could take
>> a 16-bit parallel RGB signal, the other 24-bit. Only one of them can  be
>> enabled at a time (from HW perspective both can be enabled at the same
>> time, but then the other one shows garbage).
> 
> So we're essentially back to a mux, albeit maybe a virtual one.

Yes. Are you suggesting to model virtual hardware in .dts? I got the
impression that you wanted to model only the real hardware in .dts =).

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.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/3ae43015/attachment.sig>