From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752412Ab1AQB1y (ORCPT ); Sun, 16 Jan 2011 20:27:54 -0500 Received: from adelie.canonical.com ([91.189.90.139]:36926 "EHLO adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752143Ab1AQB1x (ORCPT ); Sun, 16 Jan 2011 20:27:53 -0500 To: linux-arm-kernel@lists.infradead.org Subject: Re: Locking in the clk API Cc: linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Herrenschmidt , Sascha Hauer , Lorenzo Pieralisi , Vincent Guittot , "Uwe =?iso-8859-1?q?Kleine-K=F6nig?=" From: Jeremy Kerr Date: Mon, 17 Jan 2011 09:27:43 +0800 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101170927.44239.jeremy.kerr@canonical.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Based on the discussion from this thread, my plan is to: * Change the 'common struct clk' patches to only use a spinlock for locking. This means that clk_{en,dis}able will acquire a per-clk spinlock (for enable counts), and be callable from atomic contexts. * Rework the initial docs (posted in the first mail of this thread) to illustrate the new locking requirements. * Request input from the platforms that require clk_enable (etc) to sleep, about how we can merge the two implementations. Russell - is this OK? Cheers, Jeremy