[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

Daniel Vetter daniel at ffwll.ch
Wed Dec 5 04:08:43 PST 2012


On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström <tbergstrom at nvidia.com> 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


More information about the dri-devel mailing list