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

Thierry Reding thierry.reding at gmail.com
Tue Sep 23 07:45:10 PDT 2014


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.

> >> 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.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/c6d6149e/attachment.sig>


More information about the dri-devel mailing list