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

[Andrzej Hajda]

On 09/23/2014 04:41 PM, Thierry Reding wrote:
> 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.
But it is also true on HW level in case of display subsystem components -
If some device have output format X it means it can be connected to any
device
having input format X, whatever it is: panel, bridge, image enhancer...

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

But I have asked about their input interface, RGB panel and RGB/???
bridge have the
same input interface.
In other words if instead of creating frameworks for each device type we
try to create framework
for functions/interfaces these device provides we should end up with
fewer frameworks and more clean code.

Regards
Andrzej

>
> Thierry