| Message ID | 1476969615-4421-5-git-send-email-deathsimple@vodafone.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Christian, 2016-10-20 Christian König <deathsimple@vodafone.de>: > From: Christian König <christian.koenig@amd.com> > > This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9. > > Otherwise signaling might never be activated on the fences. This can > result in infinite waiting with hardware which has unreliable interrupts. > > v2: still return one when the timeout is zero and we don't have any fences. > > Signed-off-by: Christian König <christian.koenig@amd.com> > Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) > --- > drivers/dma-buf/reservation.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Gustavo
On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan <gustavo@padovan.org> wrote: > Hi Christian, > > 2016-10-20 Christian König <deathsimple@vodafone.de>: > >> From: Christian König <christian.koenig@amd.com> >> >> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9. >> >> Otherwise signaling might never be activated on the fences. This can >> result in infinite waiting with hardware which has unreliable interrupts. >> >> v2: still return one when the timeout is zero and we don't have any fences. >> >> Signed-off-by: Christian König <christian.koenig@amd.com> >> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) >> --- >> drivers/dma-buf/reservation.c | 5 +---- >> 1 file changed, 1 insertion(+), 4 deletions(-) > > Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> I've rebased these patches based on the fence renaming in drm-next. Should I pull these in through my tree or should they go in through drm-misc or the dma-buf tree? If the later, I'll send out the rebased patches. Alex
On Mon, Nov 07, 2016 at 12:55:30PM -0500, Alex Deucher wrote: > On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan <gustavo@padovan.org> wrote: > > Hi Christian, > > > > 2016-10-20 Christian König <deathsimple@vodafone.de>: > > > >> From: Christian König <christian.koenig@amd.com> > >> > >> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9. > >> > >> Otherwise signaling might never be activated on the fences. This can > >> result in infinite waiting with hardware which has unreliable interrupts. > >> > >> v2: still return one when the timeout is zero and we don't have any fences. > >> > >> Signed-off-by: Christian König <christian.koenig@amd.com> > >> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) > >> --- > >> drivers/dma-buf/reservation.c | 5 +---- > >> 1 file changed, 1 insertion(+), 4 deletions(-) > > > > Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > I've rebased these patches based on the fence renaming in drm-next. > Should I pull these in through my tree or should they go in through > drm-misc or the dma-buf tree? If the later, I'll send out the rebased > patches. If there's no amdgpu deps I think best to merge through drm-misc (which now also contains dma-buf stuff, maintainers patch should go out as soon as the new drm-misc.git is live). -Daniel
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 9566a62..debb91d 100644 --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -379,10 +379,7 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj, { struct fence *fence; unsigned seq, shared_count, i = 0; - long ret = timeout; - - if (!timeout) - return reservation_object_test_signaled_rcu(obj, wait_all); + long ret = timeout ? timeout : 1; retry: fence = NULL;