On Mon, Oct 21, 2013 at 10:57:57AM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 21, 2013 at 11:27:30AM +0200, Sascha Hauer wrote: > > If you have a better vision how imx-drm can be implemented without > > getting crazy I'd love to hear about it. Please also think about the two > > IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI > > displays, LVDS displays, VGA encoder on i.MX53, external I2C slave > > encoders,... > > Well, the multi-driver solution is just too fragile: the problem > with it is you can never be sure when all the drivers have definitely > finished initialising. This problem is made much worse should one of > them use deferred probing. > > To put it another way - with a multi-driver solution, there is no > definite point you can say "okay, we got everything". > > So, as long as a subsystem contains something that needs to be done > once everything is known (such as initialising the fb_helper), there > is a fundamental disconnect between a multi-driver solution and the > subsystem. To put it another way, a multi-driver solution should > not be used. Multi-driver with DRM has worked pretty well for Tegra. Essentially what I created was a sort of abstraction layer between DRM and the individual drivers so that each driver can register itself with that layer. Once it has been determined that all drivers have been probed, that glue layer can load the DRM driver and call back into the sub-drivers to register their respective components with DRM. That even works fairly nicely with deferred probing. Note that the code currently in Linus' tree has some issues, but I've reworked it since in linux-next and the final result isn't all that bad. I've even attempted to make it somewhat generic so that it could potentially be reused by other drivers. It's not reusable as-is, but perhaps it can be further improved. I agree that hotpluggability within DRM might have made things easier, but it would likely also have made the core more complex. Furthermore there simply was no need for DRM to provide that kind of flexibility, simple because no driver has had that need so far. Quite a few ARM SoC drivers have appeared lately, and hopefully that'll provide more of an incentive to evolve DRM as needed, but I don't think we can hold it against anyone that they haven't provided us with the ideal subsystem. Thierry
Attachment:
pgpF3iZWvBSCv.pgp
Description: PGP signature
