From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Subject: Re: [PATCH 2/3] OMAP3630: PM: implement Foward Body-Bias for OPP1G Date: Thu, 22 Apr 2010 08:56:53 -0500 Message-ID: <4BD055A5.1050206@ti.com> References: <1271453603-21929-1-git-send-email-mturquette@ti.com> <1271453603-21929-3-git-send-email-mturquette@ti.com> <20100419074636.GC5325@besouro.research.nokia.com> <4BCF6C6F.3030406@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from bear.ext.ti.com ([192.94.94.41]:52816 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754926Ab0DVN5B (ORCPT ); Thu, 22 Apr 2010 09:57:01 -0400 In-Reply-To: <4BCF6C6F.3030406@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Turquette, Mike" Cc: "eduardo.valentin@nokia.com" , ext Mike Turquette , "linux-omap@vger.kernel.org" , "Sripathy, Vishwanath" , "Gopinath, Thara" , "Gulati, Shweta" , Kevin Hilman Turquette, Mike had written, on 04/21/2010 04:21 PM, the following: [...] >>> >>> /** >>> + * voltscale_adaptive_body_bias - controls ABB ldo during voltage scaling >>> + * @target_volt: target voltage determines if ABB ldo is active or bypassed >>> + * >>> + * Adaptive Body-Bias is a technique in all OMAP silicon that uses the 45nm >>> + * process. ABB can boost voltage in high OPPs for silicon with weak >>> + * characteristics (forward Body-Bias) as well as lower voltage in low OPPs >>> + * for silicon with strong characteristics (Reverse Body-Bias). >>> + * >>> + * Only Foward Body-Bias for operating at high OPPs is implemented below, per >>> + * recommendations from silicon team. >>> + * Reverse Body-Bias for saving power in active cases and sleep cases is not >>> + * yet implemented. >>> + * OMAP4 hardward also supports ABB ldo, but no recommendations have been made >>> + * to implement it yet. >>> + */ >>> +int voltscale_adaptive_body_bias(unsigned long target_volt) >>> +{ >>> + u32 sr2en_enabled; >>> + int timeout; >>> + int sr2_wtcnt_value; >>> + >>> + /* calculate SR2_WTCNT_VALUE settling time */ >>> + sr2_wtcnt_value = (ABB_MAX_SETTLING_TIME * >>> + (clk_get_rate("sys_ck") / 1000000) / 8); >>> + >>> + /* has SR2EN been enabled previously? */ >>> + sr2en_enabled = (prm_read_mod_reg(OMAP3430_GR_MOD, >>> + OMAP3_PRM_LDO_ABB_CTRL_OFFSET) & >>> + OMAP3630_SR2EN); >>> + >>> + /* select fast, nominal or slow OPP for ABB ldo */ >>> + /* FIXME: include OMAP4 once recommendations are complete */ >>> + if (cpu_is_omap3630() && (target_volt >= 1350000)) { >> You are creating two steps to decide if you apply or not FBB. >> Here and also bellow (omap voltage scale). Would it make sense to bind it >> per opp? I mean just a flag on opp dat then you apply or not based on that flag. >> Same for RBB. > > Eduardo, > > Thanks for reviewing. > > There has been some offline discussion about the best way to handle the > the relationship between FBB enable flags and OPPs: > > 1) extend OPP table > 2) piggyback on Thara's SR hwmod structures > This probably won't work given Paul's review comments > 3) other wacky stuff > > After some discussion about the best way to do this I will definitely > lose the duplicate checks and replace with some nice table look-up. > > Extending the OPP table is gross for OMAP2 and OMAP3430. Piggybacking > on SR stuff is just a hack and there is no real relationship between ABB > ldo and SR. The crux of the issue is how to relate FBB enable flags to > OPP table. hwmod? Ideas on this are very welcome. > might be a good idea for using I vote for 2) omap_volt_data in voltage.c and using the flag there. 1) is a bad idea as ABB is not present in older silicon and opp table should ideally be independent of silicon and contain only common data.. [...] -- Regards, Nishanth Menon