On Tue, Mar 25, 2014 at 10:40:45AM +0100, David Herrmann wrote: > Hi > > On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > Besides the issue at hand though I think drivers need to make sure > > that the device they use for attaching does outlive the dma-buf. Which > > for real hotpluggin probably means that drivers need to drop all > > attachment on unplug (the dma mapping is useless anyway) and just keep > > all their imported gem objects alive with just a reference to the > > dma-buf object itself. > > Drivers should never touch other drivers or even look at them. There > is no reason i915 is responsible of keeping udl alive. That gets > really messy and may introduce circular dependencies. > > I'd like to see exported dma-bufs reference their drm-device owner. > This way, the drm-device stays around until the dma-buf is removed. To > avoid lazy device destruction, a driver can (during unplug) simply > detach all dma-bufs if, and only if, they first made the dma-buf > somehow stand-alone. > > For example: udl can just move the allocated pages into the dma-buf, > mark it as dead and detach it. The udl-device can get destructed and > whenever i915 releases the dma-buf, the udl-dma-buf ops see it's dead > and just deref it / release dma-buf resources. But this is all not > needed if the exported dma-bufs just reference "drm_device", which is > imho the easiest fix. The issue at hand is the other way round, i.e. i915 exporting, udl importing. The i915/dma-buf falls over because the device struct referenced in the attachment disappeared. Dave fixed it by grabbing a reference, I think the better fix would be to simply not attach (since udl doesn't need it anyway). Either works. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
