From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751104Ab1AVFay (ORCPT ); Sat, 22 Jan 2011 00:30:54 -0500 Received: from mail-bw0-f46.google.com ([209.85.214.46]:52220 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750875Ab1AVFax convert rfc822-to-8bit (ORCPT ); Sat, 22 Jan 2011 00:30:53 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AHV+z8aO0VDZGJ7KLRycfEK7doBEYDJmwqL/ltVI1n4WHWTzy2NppGoVp3UbR3cV2b SNaCEL8RrMFGqAbuIsrPJ4fBM0JbU2ub7ysjpBTUO9hi8jn347fHvOkGdAWJVNsTSvbJ cpvwg09EOKwVzpucfK9smnvkkOuhY0H5MU+mo= MIME-Version: 1.0 In-Reply-To: <20110122040757.GA2094@richard-laptop> References: <201101111016.42819.jeremy.kerr@canonical.com> <20110111091607.GI12552@n2100.arm.linux.org.uk> <201101111744.59712.jeremy.kerr@canonical.com> <20110111103929.GN24920@pengutronix.de> <4D386ABF.9060908@fluff.org> <20110120190822.GK6335@n2100.arm.linux.org.uk> <20110122040757.GA2094@richard-laptop> Date: Sat, 22 Jan 2011 14:30:51 +0900 Message-ID: Subject: Re: Locking in the clk API From: Jassi Brar To: Richard Zhao Cc: Russell King - ARM Linux , Ben Dooks , Lorenzo Pieralisi , Vincent Guittot , linux-sh , Ben Herrenschmidt , Sascha Hauer , linux-kernel , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Jeremy Kerr , linux-arm-kernel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 22, 2011 at 1:08 PM, Richard Zhao wrote: > On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote: >> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar wrote: >> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux >> > wrote: >> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote: >> >>> If you want to make it so that each low-power mode has to work >> >>> out what PLLs need to be disabled and then re-enabled makes me >> >>> want to be sick. Hiding this stuff behind specific implementations >> >>> is a recipe for disaster. >> >> >> >> Why should systems which don't suffer from such problems be prevented >> >> from gaining power saving from turning off their clocks when devices >> >> are not being used (eg, the console serial port.) >> >> >> >> One solution to your root PLL issue would be to have a separate set of >> >> enable/disable API calls which get called at setup/release time (or >> >> whatever you'd like to call it) which can only be called from non-atomic >> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions >> >> should perform whatever is necessary to ensure that the clock source >> >> is available for use atomically when clk_enable() is called. >> >> >> >> So, in your case, clk_prepare() ensures that the root PLL is enabled, >> >> clk_unprepare() allows it to be turned off. >> >> >> >> In the case of a console driver, clk_prepare() can be called when we >> >> know the port will be used as a console.  clk_enable() is then called >> >> before writing out the string, and clk_disable() after we've completely >> >> sent the last character. >> >> >> >> This allows the best of both worlds.  We now have a clk_enable() which >> >> can be used to turn the clocks off through the clock tree up to the first >> >> non-atomic clock, and we also have a way to deal with those which need >> >> to sleep.  So not only do "sleeping clock" implementations become possible >> >> but these "sleeping clock" implementations also get the opportunity to >> >> shutdown some of their clock tree with minimal latency for doing so. >> > >> > This is exactly what I suggested in my last post, except the console example. >> > Only to be a part of common clock api because it's not very safe to assume >> > future SoCs will have the same simple clock topologies that they have today. >> > >> > Not to mean to teach, but I hope you realize with more and more >> > device controller being crammed into ever shrinking SoCs, >> > clock would eventually have to be flexible in functionality >> > and complicated in hierarchy. Ben already gave examples >> > of Audio, MFC and Video controllers of latest Samsung SoCs. >> >> plus >> >> a) If only Samsung bsp implements the api, it would be impossible to >> share drivers, those that can be, with other platforms without nasty ifdef's. >> b) If the task of unification starts with only a particular platform made to >> implement a new api, the attempt kills its own purpose. > I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare? > If its clock tree has many plls and device clock is not far away from plls and > may sleep, we may use prepare/unprepare to do actually clock enable/disable. I am not against clk_prepare/unprepare. I rather suggest make it part of common clock API. Please read my last two posts again.