On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: >> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: >> >> If I understand stuff correctly you have a main driver plus a bunch of >> >> encoder/crtc modules and you expect that everything gets loaded and then >> >> only when the kms driver is first opened. The current drm core just >> >> doesn't support hotplugging of encoder/crtc objects after driver init has >> >> completed. If you try to do that it'll go down in flames due to all the >> >> races involved. >> >> >> > You know the logic you broke here was just a moderately sane approach to >> > get around the monolithic DRM driver nonsense, while not having to use >> > real hotplug in DRM. >> > >> > The thing is we don't know if we will ever have all submodules loaded, >> > as this driver is mostly used on embedded devices where people randomly >> > decide to exclude things from their kernel config, because they don't >> > use the feature on their board. The current logic is under the premise >> > that there are no early DRM clients in something like Plymouth, which is >> > a bit flaky, but worked very well for the targeted use-cases. >> >> Imo the imxdrm->references logic is broken already and simply removing >> those checks would be the right course of action - pretending to have >> fixed races but not actually having fixed much is imo much worse than >> openly admitting that the code is racy and needs work. >> >> Wrt embedded guys shaving off a few kb by not loading a bunch of >> modules I think you should simply make that compile-time options >> instead of modules. More hassle but at least it should work. > > It's not about the few kb. The problem is that our devices are not > monolithic, but instead we have multiple devices in and around the SoC > which form a DRM device. right, but the cores on the SoC, and even any external encoder chips, are not actually hot-pluggable. I have a similar scenario w/ msm drm, where there is the core display controller (for ex, 'mdp4'), plus hdmi/dsi/etc blocks around that (with their own irq, io/register region, etc). It would be nice if the kernel provided a better mechanism for composite drivers, but what I do is just register the platform drivers for those other blocks first (in the init code, before calling 'platform_driver_register(&msm_platform_driver)'. This way, if the device is actually present, I know before drm dev_load. I do not attempt to build hdmi/dsi/etc as separate modules. I could if I wanted to include/exclude them at compile time, but separate modules seems like a bad idea. BR, -R > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
