[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uHda2bsSG4Rsjb+=McYo50J0sS4vGqJ0R==ajc9HbqV7Q@mail.gmail.com>
Date: Tue, 22 Jul 2014 18:43:07 +0200
From: Daniel Vetter <daniel.vetter@...ll.ch>
To: Christian König <deathsimple@...afone.de>
Cc: Christian König <christian.koenig@....com>,
Thomas Hellstrom <thellstrom@...are.com>,
nouveau <nouveau@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
"Deucher, Alexander" <alexander.deucher@....com>,
Ben Skeggs <bskeggs@...hat.com>
Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence
implementation for fences
On Tue, Jul 22, 2014 at 6:21 PM, Daniel Vetter <daniel.vetter@...ll.ch> wrote:
> But like I've said fence->signaled is optional so you don't need this
> necessarily, as long as radeon eventually calls fence_signaled once
> the fence has completed.
Actually I've chatted a bit with Maarten about the different ways we
could restrict both the calling context and the implementations for
fence callbacks to avoid surprises. One is certainyl that we need
WARN_ON(in_interrupt) around the wait, enable_singaling and add
callback stuff.
But we also talked about ensure that the ->signaled callback never
sleeps by wrapping it in a preempt_enable/disable section. Currently
sleeping is allowed in ->signaled, which the radeon implementation
here does. I think it would be reasonable to forbid this and drop
__radeon_fence_signaled.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists