commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Lucas Stach]

Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach <l.stach at pengutronix.de> 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.
> 
I don't see how this is overly racy. We are doing delayed DRM device
setup not delayed HW setup. We simply look around which modules are
there and what DRM we can build up from them.

With some small work we would even be able to make the Plymouth +
modules in initrd case work. The only case that would not really be
solvable without full hotplug is the Plymouth in initrd + modules on the
late rootfs.

> 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.
> 
This would be really moving in the wrong direction. We want to get more
modular, not less. We have a lot different on- and off-chip encoders and
other stuff where we want distinct drivers and not some cludged together
thing.

> And if we ever see the need to hotplug crtcs I think the right way is
> to hotplug an entire drm driver. Connector/encoder hotplugging might
> eventually be required for real to support stuff like multi-stream DP,
> but until that happens I really don't see a need for funny games,
> especially on SoC boards where everything is soldered on and can't
> possibly be hotplugged. 

Regards,
Lucas
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |