Displaying 19 results from an estimated 19 matches for "radeon_fence_wait_ani".
Did you mean:
radeon_fence_wait_any
2014 Jun 02
1
[RFC PATCH v1.3 08/16 1/2] drm/radeon: add timeout argument to radeon_fence_wait_seq
Am 02.06.2014 15:14, schrieb Maarten Lankhorst:
> This makes it possible to wait for a specific amount of time,
> rather than wait until infinity.
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
> ---
> Splitted out version, I've noticed that I forgot to convert
> radeon_fence_wait_empty to long r, fixed.
>
2014 Jun 02
0
[RFC PATCH v1.3 08/16 1/2] drm/radeon: add timeout argument to radeon_fence_wait_seq
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
Splitted out version, I've noticed that I forgot to convert radeon_fence_wait_empty to long r, fixed.
drivers/gpu/drm/radeon/radeon_fence.c | 60 +++++++++++++++++++++++------------
1 file changed, 40 insertions(+),
2014 May 15
2
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
> op 15-05-14 11:21, Christian K?nig schreef:
>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
>>> op 14-05-14 17:29, Christian K?nig schreef:
>>>>> + /* did fence get signaled after we enabled the sw irq? */
>>>>> + if
>>>>>
2014 Jun 02
3
[RFC PATCH v1.2 08/16] drm/radeon: use common fence implementation for fences
Am 02.06.2014 12:09, schrieb Maarten Lankhorst:
> Changes since v1:
> - Fixed interaction with reset handling.
> + Use exclusive_lock, either with trylock or blocking.
> + Bump sw irq refcount in the recovery function to prevent fiddling
> with irq registers during gpu recovery.
> - Add radeon lockup detection to the default fence wait function.
First of all please
2014 May 15
0
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
op 15-05-14 11:42, Christian K?nig schreef:
> Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
>> op 15-05-14 11:21, Christian K?nig schreef:
>>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
>>>> op 14-05-14 17:29, Christian K?nig schreef:
>>>>>> + /* did fence get signaled after we enabled the sw irq? */
>>>>>> + if
2014 May 19
2
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
Am 19.05.2014 15:35, schrieb Maarten Lankhorst:
> op 19-05-14 14:30, Christian K?nig schreef:
>> Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
>>> op 19-05-14 10:27, Christian K?nig schreef:
>>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
>>>> [SNIP]
>>>> The problem here is that the whole approach collides with the way
>>>>
2014 Jun 02
0
[RFC PATCH v1.2 08/16] drm/radeon: use common fence implementation for fences
Changes since v1:
- Fixed interaction with reset handling.
+ Use exclusive_lock, either with trylock or blocking.
+ Bump sw irq refcount in the recovery function to prevent fiddling
with irq registers during gpu recovery.
- Add radeon lockup detection to the default fence wait function.
---
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index
2014 May 15
2
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
> op 15-05-14 11:42, Christian K?nig schreef:
>> Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
>>> op 15-05-14 11:21, Christian K?nig schreef:
>>>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
>>>>> op 14-05-14 17:29, Christian K?nig schreef:
>>>>>>> + /* did fence get signaled
2014 May 19
2
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
> op 15-05-14 18:13, Christian K?nig schreef:
>> Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
>>> op 15-05-14 17:48, Christian K?nig schreef:
>>>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
>>>>> op 15-05-14 15:19, Christian K?nig schreef:
>>>>>> Am 15.05.2014 15:04, schrieb
2014 May 19
0
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
op 19-05-14 10:27, Christian K?nig schreef:
> Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
>> op 15-05-14 18:13, Christian K?nig schreef:
>>> Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
>>>> op 15-05-14 17:48, Christian K?nig schreef:
>>>>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
>>>>>> op 15-05-14 15:19, Christian K?nig
2014 May 19
2
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
> op 19-05-14 10:27, Christian K?nig schreef:
>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
>> [SNIP]
>> The problem here is that the whole approach collides with the way we
>> do reset handling from a conceptual point of view. Every IOCTL or
>> other call chain into the driver is protected by the read side of
2014 Jul 09
2
[PATCH 09/17] drm/radeon: use common fence implementation for fences
> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
> Sent: Wednesday, July 09, 2014 8:30 AM
> To: airlied at linux.ie
> Cc: thellstrom at vmware.com; nouveau at lists.freedesktop.org; linux-
> kernel at vger.kernel.org; dri-devel at lists.freedesktop.org;
> bskeggs at redhat.com; Deucher, Alexander; Koenig, Christian
>
2014 May 14
0
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
drivers/gpu/drm/radeon/radeon.h | 15 +--
drivers/gpu/drm/radeon/radeon_device.c | 1
drivers/gpu/drm/radeon/radeon_fence.c | 189 +++++++++++++++++++++++++-------
3 files changed, 153 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index
2014 Jul 09
0
[PATCH 09/17] drm/radeon: use common fence implementation for fences
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
drivers/gpu/drm/radeon/radeon.h | 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 ++++++++-
drivers/gpu/drm/radeon/radeon_fence.c | 223 ++++++++++++++++++++++++++------
3 files changed, 248 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
2014 Jul 09
0
[PATCH v2 09/17] drm/radeon: use common fence implementation for fences
op 09-07-14 14:57, Deucher, Alexander schreef:
>> <snip>
>> +static const char *radeon_fence_get_timeline_name(struct fence *f)
>> +{
>> + struct radeon_fence *fence = to_radeon_fence(f);
>> + switch (fence->ring) {
>> + case RADEON_RING_TYPE_GFX_INDEX: return "radeon.gfx";
>> + case CAYMAN_RING_TYPE_CP1_INDEX: return
2014 May 14
2
[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences
> + /* did fence get signaled after we enabled the sw irq? */
> + if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >= fence->seq) {
> + radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring);
> + return false;
> + }
> +
> + fence->fence_wake.flags = 0;
> + fence->fence_wake.private = NULL;
> + fence->fence_wake.func =
2014 Jul 09
22
[PATCH 00/17] Convert TTM to the new fence interface.
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with fence_obj.
After flipping the switch RCU becomes available instead, and
the extra reservations can be dropped again. :-)
I've done at least basic
2014 Jul 31
19
[PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
include/linux/fence.h | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
index d174585b874b..c1a4519ba2f5 100644
---
2014 May 14
17
[RFC PATCH v1 00/16] Convert all ttm drivers to use the new reservation interface
This series depends on the previously posted reservation api patches.
2 of them are not yet in for-next-fences branch of
git://git.linaro.org/people/sumit.semwal/linux-3.x.git
The missing patches are still in my vmwgfx_wip branch at
git://people.freedesktop.org/~mlankhorst/linux
All ttm drivers are converted to the fence api, fence_lock is removed
and rcu is used in its place.
qxl is the first