From patchwork Tue Jul 31 04:20:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shawn Guo X-Patchwork-Id: 1257071 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 998F0DFAF2 for ; Tue, 31 Jul 2012 04:24:13 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Sw3xD-0007HL-GI; Tue, 31 Jul 2012 04:21:07 +0000 Received: from db3ehsobe006.messaging.microsoft.com ([213.199.154.144] helo=db3outboundpool.messaging.microsoft.com) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1Sw3x4-0007Gn-JM for linux-arm-kernel@lists.infradead.org; Tue, 31 Jul 2012 04:20:58 +0000 Received: from mail84-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 04:20:50 +0000 Received: from mail84-db3 (localhost [127.0.0.1]) by mail84-db3-R.bigfish.com (Postfix) with ESMTP id EEAED3A01A3; Tue, 31 Jul 2012 04:20:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: 11 X-BigFish: VS11(z1039oz98dI225amzz1202hzzz2dh87h2a8h668h839h944hd25he96hf0ah107ah) X-FB-DOMAIN-IP-MATCH: fail Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3 (MessageSwitch) id 1343708447784226_5245; Tue, 31 Jul 2012 04:20:47 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.248]) by mail84-db3.bigfish.com (Postfix) with ESMTP id BC1FAE0063; Tue, 31 Jul 2012 04:20:47 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 04:20:47 +0000 Received: from az84smr01.freescale.net (10.64.34.197) by 039-SN1MMR1-003.039d.mgd.msft.net (10.84.1.16) with Microsoft SMTP Server (TLS) id 14.2.298.5; Mon, 30 Jul 2012 23:20:45 -0500 Received: from S2101-09.ap.freescale.net ([10.192.185.28]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id q6V4KbGT027875; Mon, 30 Jul 2012 21:20:38 -0700 Date: Tue, 31 Jul 2012 12:20:52 +0800 From: Shawn Guo To: Mark Brown Subject: Re: [PATCH 3/3] cpufreq: Add a generic cpufreq-cpu0 driver Message-ID: <20120731042050.GF762@S2101-09.ap.freescale.net> References: <1342713281-31114-1-git-send-email-shawn.guo@linaro.org> <1342713281-31114-4-git-send-email-shawn.guo@linaro.org> <20120726131121.GB7306@sirena.org.uk> <20120730065218.GB31509@S2101-09.ap.freescale.net> <20120730185344.GT4468@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120730185344.GT4468@opensource.wolfsonmicro.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginatorOrg: sigmatel.com X-Spam-Note: CRM114 invocation failed X-Spam-Note: SpamAssassin invocation failed Cc: Kevin Hilman , Nishanth Menon , Mike Turquette , linux-pm@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, cpufreq@vger.kernel.org, "Rafael J. Wysocki" , Richard Zhao , Russell King - ARM Linux , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Mon, Jul 30, 2012 at 07:53:45PM +0100, Mark Brown wrote: > Quite honestly this seems totally unrealistic for the majority of users, I doubt that. Searching drivers/cpufreq folder, I can see there are several cpufreq drivers scaling voltage with regulator API, but none of them is calling regulator_set_voltage_time to find voltage latency. That said, all these users are specify transition latency on their own. > especially given the very poor documentation for this stuff which SoC > vendors typically provide. It's a reasonable amount of work to go back > and figure this stuff out (especially given that it should be varying > depending on the transition in question), and it's going to give us a > bunch of magic numbers in people's bindings. > There will be only one magic number, and it can easily become "magic" with some comments put there. > No, add a new API. > Is the following patch what you are ordering here? diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index da339fd..bfd3cfb 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -352,4 +352,11 @@ static inline void regulator_set_drvdata(struct regulator *regulator, #endif +static inline int regulator_set_voltage_tolerance(struct regulator *regulator, + int new_uV, int tol_uV) +{ + return regulator_set_voltage(regulator, + new_uV - tol_uV, new_uV + tol_uV); +} + #endif