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
Attachment:
pgpChtO2411P8.pgp
Description: PGP signature
