From patchwork Tue Apr 16 12:40:44 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Tseglytskyi X-Patchwork-Id: 2449321 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 02BD3DF230 for ; Tue, 16 Apr 2013 12:40:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754226Ab3DPMks (ORCPT ); Tue, 16 Apr 2013 08:40:48 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:46530 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753010Ab3DPMkr (ORCPT ); Tue, 16 Apr 2013 08:40:47 -0400 Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id r3GCekIw016651; Tue, 16 Apr 2013 07:40:46 -0500 Received: from DNCE70.ent.ti.com (dnce70.ent.ti.com [137.167.131.19]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id r3GCejUF014211; Tue, 16 Apr 2013 07:40:45 -0500 Received: from [10.167.145.64] (10.167.145.64) by DNCE70.ent.ti.com (137.167.131.19) with Microsoft SMTP Server id 14.1.323.3; Tue, 16 Apr 2013 14:40:45 +0200 Message-ID: <516D46CC.3080705@ti.com> Date: Tue, 16 Apr 2013 15:40:44 +0300 From: Andrii Tseglytskyi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kevin Hilman CC: , =?ISO-8859-1?Q?Beno=EEt_Cousson?= , Tero Kristo , Mike Turquette Subject: Re: [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver References: <1366032491-4162-1-git-send-email-andrii.tseglytskyi@ti.com> <87sj2rbguv.fsf@linaro.org> In-Reply-To: <87sj2rbguv.fsf@linaro.org> X-Originating-IP: [10.167.145.64] X-EXCLAIMER-MD-CONFIG: f9c360f5-3d1e-4c3c-8703-f45bf52eff6b Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org Hi Kevin, On 04/16/2013 12:53 AM, Kevin Hilman wrote: > Andrii Tseglytskyi writes: > >> From: "Andrii.Tseglytskyi" >> >> Following patch series introduces the Adaptive Body-Bias >> LDO driver, which handles LDOs voltage during OPP change routine. >> Current implementation is based on patch series from >> Mike Turquette: >> >> http://marc.info/?l=linux-omap&m=134931341818379&w=2 >> >> ABB transition is a part of OPP changing sequence. >> ABB can operate in the following modes: >> - Bypass mode: Activated when ABB is not required >> - FBB mode: Fast Body Bias mode, used on fast OPPs > Fast? I thought the 'F' was for Forward? You are right. Should be 'Forward' here. >> - RBB mode: Reverse Body Bias mode, used on slow OPPs >> >> In current implementation ABB is converted to regulator. >> Standalone OPP table is used to store ABB mode, it is defined >> in device tree for each ABB regulator. It has the following format: >> >> operating-points = < >> /* uV ABB (0 - Bypass, 1 - FBB, 2 - RBB) */ >> 880000 0 >> 1060000 1 >> 1250000 1 >> 1260000 1 >>> ; >> ABB regulator is linked to regulator chain > In addition to Mike's comments (which I completely agree with), it would > be very helfpul to see how this is actually used. e.g, how the > regulators are chained together, how the proper ordering is managed, > etc. etc. We would like to handle voltage scaling in the following way: cpufreq_cpu0 clk_set_rate(cpu0) | |-->set_voltage(ABB regulator) /* all ABB related stuff will be handled here */ | |-->set_voltage(smps123 regulator) /* actual voltage scaling */ This simple model will be extended to handle AVS as a part of the chain. smps123 regulator may be changed to VP/VC regulator. Following example is from integration branch, which already has smps123 regulator. It demonstrates an example of linkage to chain. ABB regulator is linked with smps123 and cpu0 inside device tree. cpu0 calls set_voltage() function for ABB, and then ABB calls set_voltage() function for smps123 to do actual voltage scaling. This RFC patch series is verified together with: https://patchwork.kernel.org/patch/2445091/ Kevin, what do you think about this model in general? Does it fit to regulator framework? Thank you. Regards, Andrii --- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index bb5ee70..c8cbbee 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -36,7 +36,7 @@ cpus { cpu@0 { compatible = "arm,cortex-a15"; - cpu0-supply = <&smps123_reg>; + cpu0-supply = <&abb_mpu>; operating-points = < /* kHz uV */ /* Only for Nominal Samples */ @@ -94,6 +94,7 @@ reg = <0x4ae07cdc 0x8>, <0x4ae06014 0x4>; ti,tranxdone_status_mask = <0x80>; + avs-supply = <&smps123_reg>; operating-points = < /* uV ABB */ 880000 0