On Friday 29 of November 2013 09:13:19 Rob Clark wrote: > On Fri, Nov 29, 2013 at 4:10 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: > > I would mostly agree with you if we were discussing SoC-internal > > components here. Mostly, because the ARM world is more complex and you > > can see the same IP across completely different SoCs from different > > vendors. > > > > However, the topic here is about external devices, outside the SoC, such > > as different kind of bridges, like the PTN3460 eDP to LVDS bridge, which > > are likely to be reused across different platforms. Similar thing is with > > using different bridges on different boards using the same SoC platform. > > I don't think having an abstraction here would be any overabstraction at > > all. Anything less would be a huge "underabstraction" in fact. > > > I think no one is arguing that we don't eventually need some better > abstraction. But as long as it is one-bridge and one-user, if the > patches otherwise have merit, add functionality that was missing > before and don't regress, then lack of infrastructure to match up > bridge and driver isn't something I will care about too much yet. > Things are allowed to be in-progress. A missing abstraction for a 1:1 > relationship is fine. This is not just one-bridge, one-user. This is about users of Exynos DRM we already have in-tree, such as Trats, Trats2 or Arndale, that the DRM bridge infrastructure could be used on and finally allowing to have display support on them. Of course you could merge this as is and then let someone else completely rewrite it (most likely in the same release cycle), but since it's not really much more work, I don't think there is any sense. Moreover, let's stick to modern kernel driver coding standards. I don't think that "I want this patchset merged so badly" is really a good excuse to get around it. After all, there would be no GKH's staging tree, if nobody cared about quality in mainline. Best regards, Tomasz _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
