Re: [PATCH 2/3] OMAP3630: PM: implement Foward Body-Bias for OPP1G

[Nishanth Menon <nm@ti.com>]

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