search for: radeon_fence_wait_ani

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