[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Daniel Vetter]

On Mon, Nov 04, 2013 at 01:52:33PM +0100, Thierry Reding wrote:
> 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 at gmail.com> 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 at gmail.com> 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.

I'm pretty short of ripping out all the midlayer disasters in the drm
driver load path. As soon as that's done drivers can defer probing and do
all kinds of trick until everything is set up, and then as the very last
step register the drm device. Current wip stuff is at

http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup

Leftover todo items:
- rip out bus->set_busid and block the setversion ioctl from doing stupid
  things on kms drivers. That's the last nail on the drm_bus coffin.
- Convert udl over to embedding drm_device and driver-controlled setup
  sequence and rip out drm_dev->usbdevice as a proof of concept. That
  should be the death-spell to drm_usb.c

I'll let you arm guys figure out how to the same for drm_platform.c ;-) On
a quick look there's only very few drivers that use
drm_dev->platform_device, which is the last piece to kill really.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch