On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote: > On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote: > >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: > > [...] > >> > I believe this is a huge step backwards from current kernel design > >> > standards, which prefer modularity. > >> > >> But it makes things behave in the way that userspace expects, which is > >> more important. > > > > Why would userspace care about the modularity of kernel drivers? The > > only thing that userspace should care about is whether there's a DRM > > device or not. How the kernel makes that happen should be completely > > irrelevant to userspace. > > What I was referring to was userspace not expecting parts of the drm > (crtcs/encoders/connectors) driver to show up incrementally. You can > avoid that, but it is more of a hassle currently (ie. most drivers > that need to do this, including a few that I've written, end up > needing some form of > stuff-devices-in-global-variables-that-main-driver-checks-for). I must have misunderstood then. I don't think adding hotplug of DRM subdevices is something we would want. And I don't think there's a requirement for that, either. Embedded devices usually have well-defined use-cases, so the configuration is rather static at runtime. As for the global variables, you can do it properly. Granted, it might be more work than global variables, but keeping drivers separated does have advantages. Especially when the devices have completely separated register ranges or clocks or other resources, it's very natural to use one driver per device and glue them together with a composite device construct. Thierry
Attachment:
pgpopIv9BSpLF.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
