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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |