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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to