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

[Kim Kyuwon <chammoru@gmail.com>]

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