On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström <tbergstrom@xxxxxxxxxx> wrote: >> You're right in that binding to a sub-device is not a nice way. DRM >> framework just needs a "struct device" to bind to. exynos seems to solve >> this by introducing a virtual device and bind to that. I'm not sure if >> this is the best way, but worth considering? > > Note that I'm not too happy about the fact that drm wants a struct > device to register a drm device. This all made a lot of sense back in > the days when drm drivers this this fancy shadow attaching to allow > drm to use a driver for rendering cooperatively with a fbdev driver. > Today there's not much reason for that anymore imo, and I'd welcome > patches to allow drivers to simply register a drm device (and remove > all the newer registration functions for usb/platform/whatever > drivers, moving the device handling into drivers). Note that it's a > bit work, since not-really-required abstraction (which was useful back > when the drm drivers have been shared with *BSD, but pointless now) > like the drm irq support needs to be moved away to a pci-dev legacy > thing only - it doesn't really buy a kms driver anything above&beyond > calling request_irq() itself. > > So feel free to burn this down, I'll be happy to carry wood to the > pyre in the from of reviews (not much time for more right now ...). Part of the reasons I haven't tackled this is that for drm/i915 we can't use this alone (since we still need to support the shadow attach for old ums), but I regard it as a smaller part of the general midlayer/inversion of control problem in the drm driver setup/teardown sequence. Which all results in ridiculous amounts of races between the interfaces regsiter in the drm core (dev node, sysfs files, debugfs files) and the driver itself. Especially module unload is totally broken. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
