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.
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
