On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote: > Hi Russell, > > On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote: > > In any case, I don't agree with converting it to a DRM bridge - that will > > mean that we have to split the driver into two pieces, the bridge part > > handling the mode set specifics, and a connector/encoder part which > > handles the detection/edid stuff. > > > > We might as well keep the whole thing as the classical connector/encoder > > rather than introducing this additional layer of complexity. > > We have different ways to instantiate external HDMI encoders, and that's not > good. I believe everybody agrees that drm encoder slave has to go, so that's > already one problem solved (or rather solvable, it still requires someone to > do the work). We will then be left with two different methods, drm bridge and > non-bridge component-based instantiation. We need to somehow merge the two, > and I'm open to discussions on how the end result should look like. I think you're idea really doesn't work - and I think your idea that component-based is somehow separate from other methods is wrong. Look at iMX for example - even converting all the code that could be a bridge to be a bridge will not get rid of its use of the component instantiation, because you still have other components that need to come from elsewhere. The same is true of armada as well. Moreover, as I've already said, converting tda998x to a DRM bridge will not get rid of the encoder/connector part, because it _is_ a connector in the DRM sense - it provides the detection and EDID reading. So, what would we achieve by splitting the driver into a DRM bridge and DRM encoder/connector? We would still need the component helper to manage the binding of the connector part, which would also then have to register a DRM bridge in addition to a DRM encoder and providing the DRM connector as we can't have two device drivers bound to the same i2c device. What we get is more complexity in the driver. We can see this with what happened to the DW-HDMI driver - that still needs the component helper, and it provides a DRM bridge, DRM encoder and DRM connector parts. The only reason it made sense to split the DW-HDMI driver was due to the differences between the Rockchip and Freescale implementations. Such differences do not exist for TDA998x. So even here, your idea that "DRM bridge" vs "non-DRM bridge component based" doesn't work - we have "DRM bridge component based" because of the problem that I'm illustrating here. So, again, I ask: what's the point of needlessly splitting the code between an encoder/connector and a bridge? You seem to be forcing the DRM bridge model onto drivers with no regard for its appropriateness for those drivers. If it pushes more complexity into drivers, the model is wrong. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
