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.
~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
