Displaying 3 results from an estimated 3 matches for "51b646b9c8bb".
2014 Jul 23
1
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...g.
> I managed to do it without needing it to be part of the interface? I'm not sure whether radeon_fence_driver_recheck needs exclusive_lock, but if so it's a small change..
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 7fbfd41479f1..51b646b9c8bb 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -345,6 +345,9 @@ struct radeon_fence_driver {
> uint64_t sync_seq[RADEON_NUM_RINGS];
> atomic64_t last_seq;
> bool initialized;
> + struct delayed_work work;
> + struct...
2014 Jul 23
3
[PATCH 09/17] drm/radeon: use common fence implementation for fences
Am 23.07.2014 12:52, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
> <christian.koenig at amd.com> wrote:
>>> And the dma-buf would still have fences belonging to both drivers, and it
>>> would still call from outside the driver.
>>
>> Calling from outside the driver is fine as long as the driver can do
>> everything
2014 Jul 23
0
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...sary lockup handling.
I managed to do it without needing it to be part of the interface? I'm not sure whether radeon_fence_driver_recheck needs exclusive_lock, but if so it's a small change..
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7fbfd41479f1..51b646b9c8bb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -345,6 +345,9 @@ struct radeon_fence_driver {
uint64_t sync_seq[RADEON_NUM_RINGS];
atomic64_t last_seq;
bool initialized;
+ struct delayed_work work;
+ struct radeon_device *rdev;
+ unsigned ring;
}...