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

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

[Kim Kyuwon]

Hi Kevin, Rajendra, and other OMAP experts,

Lately I'm digging up OMAP3430-DVFS and I found 4 problems on top of PM branch.

1. Setting CPUFreq Governor to 'ondemand' turns off display system.
I think the following codes in set_opp() of rescource34xx.c makes this problem.

		/*
		 * For VDD1 OPP3 and above, make sure the interconnect
		 * is at 100Mhz or above.
		 * throughput in KiB/s for 100 Mhz = 100 * 1000 * 4.
		 */
		if (target_level >= 3)
			resource_request("vdd2_opp", &vdd2_dev, 400000);
		else
			resource_release("vdd2_opp", &vdd2_dev);

I'm not sure this is the root cause. However, if I remove the above
sentences, display system doesn't turn off.

2. [Trivial] Setting CPUFreq Governor to 'ondemand' makes warning
message as below.

    SR1: VDD autocomp is not active
    SR2: VDD autocomp is not active

These warning messages are removed, if I set sr_vdd1_autocomp and
sr_vdd2_autocomp to 1. However, is these warning messages really
needed?

3. OP(Operating Point) transition time is set to 10seconds in
cpu-omap.c as follows:

	/* FIXME: what's the actual transition time? */
	policy->cpuinfo.transition_latency = 10 * 1000 * 1000;

The default sampling rate of CPUFreq is set to transition_latency, so
it becomes 10 seconds! It's really too long for DVFS. I measured
transition latency by myself using oscilloscope and it's about 150 ~
200m seconds. I think TI engineers may know more accurate figure. I
wish we could update transition latency as soon as possible.

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.

In OMAP PM, there are a lot of part that only experts in TI or people
with experience can handle. So I'm afraid to send new patch or fix
previous PM codes.
I hope we can discuss above issues a lot!

Thank you.
Kyuwon (규원)
--
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

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

[Paul Walmsley]

Hello Richard,

On Thu, 23 Apr 2009, Kim Kyuwon wrote:

> 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?

- Paul

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

[Woodruff, Richard]

> 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.

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.

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

[Kim Kyuwon]

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.
> 

RE: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Kim Kyuwon
> Sent: Thursday, April 23, 2009 12:00 AM

> 3. OP(Operating Point) transition time is set to 10seconds in
> cpu-omap.c as follows:

> The default sampling rate of CPUFreq is set to transition_latency, so
> it becomes 10 seconds! It's really too long for DVFS. I measured
> transition latency by myself using oscilloscope and it's about 150 ~
> 200m seconds. I think TI engineers may know more accurate figure. I
> wish we could update transition latency as soon as possible.

That time sounds long.  What points did you measure from and what was your system speeds?

One thing to watch our for wait_clk_stable delay.  PM branch needs some tweaks here.  The value of 0x800 will result in a delay which can result in your display fifo under flowing. For an 800MHz Cortex a value of 0x18 will suffice.  This value can be tuned to processor frequency if you like.

When SDRC is disabled just above all traffic will be pended.  You want to be past this as quick as possible.

Regards,
Richard W.