On 01.08.2014 19:12, Maarten Lankhorst wrote:
Hey,
On 01-08-14 10:27, Michel Dänzer wrote:
On 01.08.2014 00:34, Maarten Lankhorst wrote:
@@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, struct drm_radeon_gem_wait_idle *args = data; struct drm_gem_object *gobj; struct radeon_bo *robj;
- int r;
int r = 0;
long ret;
gobj = drm_gem_object_lookup(dev, filp, args->handle); if (gobj == NULL) { return -ENOENT; } robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, NULL, false);
- ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 30 * HZ);
- if (ret == 0)
r = -EBUSY;- else if (ret < 0)
r = ret;- /* callback hw specific functions if any */ if (rdev->asic->ioctl_wait_idle) robj->rdev->asic->ioctl_wait_idle(rdev, robj);
Heads up, this conflicts with http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html which passes a non-NULL second argument to radeon_bo_wait() to get the BO's current domain.
Ok, I will fix it up and resend it later.
Does it matter if I grab the current domain without grabbing the lock here? Because it doesn't matter if it sees the old or new domain, it could have been changed after returning too.
It should be the domain where the BO is located when the fence we are waiting for here signals.