search for: radeon_fence_wait_next

...q(rdev, seq, intr); > - if (r) { > + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, > MAX_SCHEDULE_TIMEOUT); > + if (r < 0) { > return r; > } > return 0; > @@ -475,6 +491,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, > int radeon_fence_wait_next(struct radeon_device *rdev, int ring) > { > uint64_t seq[RADEON_NUM_RINGS] = {}; > + long r; > > seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; > if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { > @@ -482,7 +499,10 @@...

...g out of the reset code? > What cases did I miss then? > > I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc. The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore. Christian.

...m_rings == 0) return -ENOENT; - r = radeon_fence_wait_seq(rdev, seq, intr); - if (r) { + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, MAX_SCHEDULE_TIMEOUT); + if (r < 0) { return r; } return 0; @@ -475,6 +491,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, int radeon_fence_wait_next(struct radeon_device *rdev, int ring) { uint64_t seq[RADEON_NUM_RINGS] = {}; + long r; seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { @@ -482,7 +499,10 @@ int radeon_fence_wait_next(struct radeon...

...>>> What cases did I miss then? >>> >>> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc. >> The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore. > I'm not sure about that, what do you want to do if the ring tests fail? Do you have to retake the exclusive lock? Just...

...q(rdev, seq, intr); > - if (r) { > + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, > MAX_SCHEDULE_TIMEOUT); > + if (r < 0) { > return r; > } > return 0; > @@ -475,6 +586,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, > int radeon_fence_wait_next(struct radeon_device *rdev, int ring) > { > uint64_t seq[RADEON_NUM_RINGS] = {}; > + long r; > > seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; > if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { > @@ -482,7 +594,10 @@...

...at cases did I miss then? >>>>> >>>>> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc. >>>> The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore. >>> I'm not sure about that, what do you want to do if the ring tests fail? Do you have to retake the exclus...

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 >>>>>

> It'a pain to deal with gpu reset. Yeah, well that's nothing new. > I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup. > But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called

...m_rings == 0) return -ENOENT; - r = radeon_fence_wait_seq(rdev, seq, intr); - if (r) { + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, MAX_SCHEDULE_TIMEOUT); + if (r < 0) { return r; } return 0; @@ -551,6 +566,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, int radeon_fence_wait_next(struct radeon_device *rdev, int ring) { uint64_t seq[RADEON_NUM_RINGS] = {}; + long r; seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { @@ -558,7 +574,10 @@ int radeon_fence_wait_next(struct radeon...

...e fence waiting out of the reset code? What cases did I miss then? I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc.

...reset code? >> What cases did I miss then? >> >> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc. > > The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore. I'm not sure about that, what do you want to do if the ring tests fail? Do you have to retake the exclusive lock? ~Maarten

...;> What cases did I miss then? >>>> >>>> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc. >>> The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore. >> I'm not sure about that, what do you want to do if the ring tests fail? Do you have to retake the exclusive lock...

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 >>>>

...m_rings == 0) return -ENOENT; - r = radeon_fence_wait_seq(rdev, seq, intr); - if (r) { + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, MAX_SCHEDULE_TIMEOUT); + if (r < 0) { return r; } return 0; @@ -475,6 +586,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, int radeon_fence_wait_next(struct radeon_device *rdev, int ring) { uint64_t seq[RADEON_NUM_RINGS] = {}; + long r; seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { @@ -482,7 +594,10 @@ int radeon_fence_wait_next(struct radeon...

...q(rdev, seq, intr); > - if (r) { > + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, > MAX_SCHEDULE_TIMEOUT); > + if (r < 0) { > return r; > } > return 0; > @@ -551,6 +566,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, > int radeon_fence_wait_next(struct radeon_device *rdev, int ring) > { > uint64_t seq[RADEON_NUM_RINGS] = {}; > + long r; > > seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; > if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { > @@ -558,7 +574,10 @@...

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

...m_rings == 0) return -ENOENT; - r = radeon_fence_wait_seq(rdev, seq, intr); - if (r) { + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, MAX_SCHEDULE_TIMEOUT); + if (r < 0) { return r; } return 0; @@ -475,6 +586,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, int radeon_fence_wait_next(struct radeon_device *rdev, int ring) { uint64_t seq[RADEON_NUM_RINGS] = {}; + long r; seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { @@ -482,7 +594,10 @@ int radeon_fence_wait_next(struct radeon...

...q(rdev, seq, intr); > - if (r) { > + r = radeon_fence_wait_seq_timeout(rdev, seq, intr, > MAX_SCHEDULE_TIMEOUT); > + if (r < 0) { > return r; > } > return 0; > @@ -475,6 +586,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev, > int radeon_fence_wait_next(struct radeon_device *rdev, int ring) > { > uint64_t seq[RADEON_NUM_RINGS] = {}; > + long r; > > seq[ring] = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; > if (seq[ring] >= rdev->fence_drv[ring].sync_seq[ring]) { > @@ -482,7 +594,10 @@...

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 ---

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