diff options
| author | Dave Airlie <airlied@redhat.com> | 2021-12-29 14:02:10 +1000 |
|---|---|---|
| committer | Dave Airlie <airlied@redhat.com> | 2021-12-29 14:02:44 +1000 |
| commit | 2b534e90a1e31c7fc9536b512b72274cc3575f4c (patch) | |
| tree | f98205ccbc118d7f4e3811b1bbc11ff0eeedf80d /drivers/gpu/drm/msm/msm_fbdev.c | |
| parent | 040bf2a9446f6ba267225d34dc4a9b14d11e5092 (diff) | |
| parent | 6ed95285382d6f90a3c3a11d5806a5eb7db715c3 (diff) | |
Merge tag 'drm-msm-next-2021-12-26' of ssh://gitlab.freedesktop.org/drm/msm into drm-next
* dpu plane state cleanup in prep for multirect
* dpu debugfs cleanup (and moving things to atomic_print_state) in prep
for multirect
* dp support for sc7280
* struct_mutex removal
* include more GMU state in gpu devcore dumps
* add support for a506
* remove old eDP sub-driver (never was used in any upstream supported
devices and modern things with eDP will use DP sub-driver instead)
* debugfs to disable hw gpu hang detect for (igt tests)
* debugfs for dumping display hw state
* and the usual assortment of cleanup and bug fixes
There still seems to be a timing issue with dpu, showing up on sc7180
devices, after the bridge probe-order change. Ie. things work great if
loglevel is high enough (or enough debug options are enabled, etc).
We'll continue to debug this in the new year.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGs+vwr0nkwgYzuYAsCoHtypWpWav+yVvLZGsEJy8tJ56A@mail.gmail.com
Diffstat (limited to 'drivers/gpu/drm/msm/msm_fbdev.c')
| -rw-r--r-- | drivers/gpu/drm/msm/msm_fbdev.c | 13 |
1 files changed, 4 insertions, 9 deletions
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c index 0daaeb54ff6f..4c39ef9dd75d 100644 --- a/drivers/gpu/drm/msm/msm_fbdev.c +++ b/drivers/gpu/drm/msm/msm_fbdev.c @@ -81,8 +81,6 @@ static int msm_fbdev_create(struct drm_fb_helper *helper, bo = msm_framebuffer_bo(fb, 0); - mutex_lock(&dev->struct_mutex); - /* * NOTE: if we can be guaranteed to be able to map buffer * in panic (ie. lock-safe, etc) we could avoid pinning the @@ -91,14 +89,14 @@ static int msm_fbdev_create(struct drm_fb_helper *helper, ret = msm_gem_get_and_pin_iova(bo, priv->kms->aspace, &paddr); if (ret) { DRM_DEV_ERROR(dev->dev, "failed to get buffer obj iova: %d\n", ret); - goto fail_unlock; + goto fail; } fbi = drm_fb_helper_alloc_fbi(helper); if (IS_ERR(fbi)) { DRM_DEV_ERROR(dev->dev, "failed to allocate fb info\n"); ret = PTR_ERR(fbi); - goto fail_unlock; + goto fail; } DBG("fbi=%p, dev=%p", fbi, dev); @@ -115,7 +113,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper, fbi->screen_base = msm_gem_get_vaddr(bo); if (IS_ERR(fbi->screen_base)) { ret = PTR_ERR(fbi->screen_base); - goto fail_unlock; + goto fail; } fbi->screen_size = bo->size; fbi->fix.smem_start = paddr; @@ -124,12 +122,9 @@ static int msm_fbdev_create(struct drm_fb_helper *helper, DBG("par=%p, %dx%d", fbi->par, fbi->var.xres, fbi->var.yres); DBG("allocated %dx%d fb", fbdev->fb->width, fbdev->fb->height); - mutex_unlock(&dev->struct_mutex); - return 0; -fail_unlock: - mutex_unlock(&dev->struct_mutex); +fail: drm_framebuffer_remove(fb); return ret; } |