From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 04/37] drm/i915: rework locking for intel_dpio|sbi_read|write Date: Wed, 12 Dec 2012 23:00:34 +0100 Message-ID: <20121212220032.GA5690@phenom.ffwll.local> References: <1355317637-16742-1-git-send-email-daniel.vetter@ffwll.ch> <1355317637-16742-5-git-send-email-daniel.vetter@ffwll.ch> <20121212125447.728e791a@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20121212125447.728e791a@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes Cc: Daniel Vetter , Intel Graphics Development , Radeon Dev , DRI Development , Nouveau Dev List-Id: nouveau.vger.kernel.org On Wed, Dec 12, 2012 at 12:54:47PM -0800, Jesse Barnes wrote: > On Wed, 12 Dec 2012 14:06:44 +0100 > Daniel Vetter wrote: > > > Spinning for up to 200 us with interrupts locked out is not good. So > > let's just spin (and even that seems to be excessive). > > > > And we don't call these functions from interrupt context, so this is > > not required. Besides that doing anything in interrupt contexts which > > might take a few hundred us is a no-go. So just convert the entire > > thing to a mutex. Also move the mutex-grabbing out of the read/write > > functions (add a WARN_ON(!is_locked)) instead) since all callers are > > nicely grouped together. > > > > Finally the real motivation for this change: Dont grab the modeset > > mutex in the dpio debugfs file, we don't need that consistency. And > > correctness of the dpio interface is ensured with the dpio_lock. > > > > Signed-off-by: Daniel Vetter > > Looks fine, I guess you could convert the wait_for_atomic_us to the > non-atomic variant now that you have a mutex. Either way: I like that _us purely to document the correct timeout ... > Reviewed-by: Jesse Barnes Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch