| Message ID | 1390486503-1504-9-git-send-email-dh.herrmann@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 43245b3..ceb875a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -838,6 +838,12 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) driver.driver_features &= ~(DRIVER_USE_AGP); + /* We cannot call remove_conflicting_framebuffers() here as we cannot + * easily figure out the apertures here. So lets just remove all + * system-framebuffers early so we don't deadlock later when calling it + * with drm_global_mutex held. */ + sysfb_claim(NULL, SYSFB_CLAIM_ALL); + return drm_get_pci_dev(pdev, ent, &driver); }
Once we allow DRM drivers for system-framebuffers, we need to evict such devices *before* probing the real driver. A simple call to sysfb_claim() does this and remove_conflicting_framebuffers() implicitly calls this. However, it causes the sysfb device to be unloaded and thus locks drm_global_mutex. remove_conflicting_framebuffers() must be called from outside any ->load() callback to avoid a dead-lock. All other DRM drivers call this right before probing the pci-device, which is fine. For i915 we need to figure out the apertures before we can evict fw-framebuffers, though. This turns out to be not as easy as you might think, so lets just evict all sysfbs for now before loading i915. A proper fix would be to make DRM code allow parallel device probing. That's not going to happen soon, so be safe and make i915 evict all sysfbs. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> --- drivers/gpu/drm/i915/i915_drv.c | 6 ++++++ 1 file changed, 6 insertions(+)