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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
