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

[Thierry Reding]

On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote:
> On 09/23/2014 12:10 PM, Thierry Reding wrote:
> > On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
> >> On 09/23/2014 10:35 AM, Thierry Reding wrote:
> > [...]
> >>> But I agree that it would be nice to unify bridges and encoders more. It
> >>> should be possible to make encoder always a bridge (or perhaps even
> >>> replace encoders with bridges altogether). Then once you're out of the
> >>> DRM device everything would be a bridge until you get to a panel.
> >> I agree that some sort of unification of bridges, (slave) encoders is a good
> >> thing, this way we stay only with bridges and panels as receivers.
> >> But we will still have to deal with the code like:
> >>     if (on the other end of the link is panel)
> >>         do panel framework specific things
> >>     else
> >>         do bridge framework specific things
> >>
> >> The code in both branches usually does similar things but due to framework
> >> differences it is difficult to merge.
> > That's because they are inherently different entities. You can perform
> > operations on a panel that don't make sense for a bridge and vice-versa.
> >
> >> Ideally it would be best to get rid of such constructs. For example by
> >> trying to
> >> make frameworks per interface type exposed by device (eg. video_sink) and
> >> not by device type (drm_bridge, drm_panel).
> > But then you loose all information about the real type of device.
> Driver knows type of its device anyway. Why should it know device
> type of devices it is connected to? It is enough it knows how to talk to
> other device.
> Like in real world, why desktop PC should know it is connected to DVI
> monitor or to
> DVI/HDMI converter which is connected to TV?

TVs are much more standardized. There are things like DDC/CI which can
be used to control the device. Or there's additional circuitry or
control paths to change things like brightness. The same isn't true of
panels.

> >  Or you
> > have to create a common base class. And then you're still back to
> > dealing with the two specific cases in many places, so the gain seems
> > rather minimal.
> 
> For example RGB panel and RGB/??? bridge have the same hardware input
> interface.
> Why shall they have different representation in kernel?

Because panels have different requirements than bridges. Panels for
example require the backlight to be adjustable, bridges don't.

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/38663124/attachment.sig>