summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/mgag200/mgag200_ttm.c
diff options
context:
space:
mode:
authorDave Airlie <airlied@redhat.com>2013-05-02 08:52:01 +0400
committerDave Airlie <airlied@redhat.com>2013-05-02 06:46:39 +0400
commit641719599528d806e00de8ae8c8453361266a312 (patch)
tree1c21aa2aee3380f34cfa8f2802b7c07bb22d0640 /drivers/gpu/drm/mgag200/mgag200_ttm.c
parentb11b88ef0e07a1ea9a3df6666ba8e15833facc67 (diff)
downloadlinux-641719599528d806e00de8ae8c8453361266a312.tar.xz
drm/mgag200: deal with bo reserve fail in dirty update path
On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'drivers/gpu/drm/mgag200/mgag200_ttm.c')
-rw-r--r--drivers/gpu/drm/mgag200/mgag200_ttm.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 8fc9d9201945..401c9891d3a8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -315,8 +315,8 @@ int mgag200_bo_reserve(struct mgag200_bo *bo, bool no_wait)
ret = ttm_bo_reserve(&bo->bo, true, no_wait, false, 0);
if (ret) {
- if (ret != -ERESTARTSYS)
- DRM_ERROR("reserve failed %p\n", bo);
+ if (ret != -ERESTARTSYS && ret != -EBUSY)
+ DRM_ERROR("reserve failed %p %d\n", bo, ret);
return ret;
}
return 0;