Re: PM: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)

[Kim Kyuwon <q1.kim@samsung.com>]

Hi Kevin, Tony, Paul and other experts.

Woodruff, Richard wrote:
>> From: Paul Walmsley [mailto:paul@pwsan.com] Sent: Thursday, April
>> 23, 2009 3:53 AM To: Woodruff, Richard
> 
>>> 4. Current PM code didn't enable the maximum clock (i.e. CPU:
>>> 600Mhz) according to the comment as below:
>>> 
>>> /* Avoid registering the 120% Overdrive with CPUFreq */ prcm =
>>> mpu_opps + MAX_VDD1_OPP - 1;
>>> 
>>> But in some cases, we should use 600Mhz for multimedia
>>> application. And, even thought we enable the maximum clock, CPU
>>> frequency seldom goes into maximum clock. I think we don't have
>>> to avoid registering the max OPP.
>> Do you know if this restriction can be lifted now, i.e., can the
>> silicon run at VDD1 OPP1 100% of the time and meet the device
>> lifespan targets?
> 
> So, there have been some characterization changes which give more
> leeway for software usage off overdrive.
> 
> What you found before was guarantees against typical mobile usage for
> a few classes of devices. This was done using a mix of OPPs with the
> majority of active time in lower OPPs and inactive time in low idles
> (optimal usage for mix of typical operations, this is the way you
> would want to run ideally). Against this and many more variables,
> reliability data was validated and published.
> 
> Recently there was some change to also measure active time at max
> overdrive for same usage mix. This resulted in still meeting lifetime
> goals for typical usage.
> 
> This can translate to a smart phone maker of being able to use
> overdrive as they see fit and still have long life (assuming they can
> supply adequate power and still dissipate what ever additional heat
> there is). This is still not 100% of the time in active mode.

What do you think of enabling to register the 120% Overdrive with CPUFreq
in l-o tree?.

Regard,
Kyuwon

> I suspect TI will continue to create parts for certain markets when
> the need is there. The part might be nearly identical but the way
> it's rated (with chip binning and other tricks) will allow different
> guarantees. This fits well with mobile business customer needs.
> 
> As an open source individual owner of a device, you might do things
> in a non-typical way. You are free to do this. Depending on which
> base chip variant you are using, its life may have some impact (or
> not). Your chip likely will still last many years. The phone or other
> device might die first.
> 
> All that said, today personally, I feel much more comfortable
> exposing overdrives in the reference code. Mobile users and their
> devices which actually sleep at night should be pretty safe.
> 
> Watch data sheets for details :)
> 
> Regards, Richard W.
>