Re: omap3 pm: dependency between opp layer and cpufreq

[Nishanth Menon <nm@ti.com>]

On 05/28/2010 10:56 AM, Koen Kooi wrote:
>
> Op 28 mei 2010, om 09:39 heeft Menon, Nishanth het volgende geschreven:
>
>>> -----Original Message-----
>>> From: Premi, Sanjeev
>>> Sent: Thursday, May 27, 2010 10:30 PM
>>
>> [...]
>>
>>>>
>>>> 3) Was there any specific need to tie the functions "opp_get_voltage"
>>> and others to cpufreq only?
>>>
>>> yes, because without cpufreq there is no transitions in the system :)
>>>
>>> [sp] I does - via bootarg - mpurate!
>>>
>>> When kernel boots, volatge must be set properly.
>>> We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz
>>> on OMAP3530 would fail at nominal 1.2V set by u-boot.
>>
>> I agree, but mpurate does not seem to use the cpufreq interfaces - so is
>> kinda a question how it interfaces back ->  but note, mpurate tells us what
>> the start freq is for the system - it still does no *dynamic* transitions -
>> just a static startup frequency. But I agree, it assumes that if you provide
>> mpurate, the system supposedly is operating at that frequency, aka all
>> setups have been done for that operational frequency(including voltage)
>
> There's also a funny bug in the current (PSP) mpurate/cpufreq code. The mpurate code has a
 > check for 720MHz on 35xx silicon, but cpufreq doesnt. So I can do:
>
> setenv bootargs '<foo>  mpurate=720'
>
> And the kernel will say "unsupported" and not switch to 720MHz during boot. But if I do this after boot:
>
> cpufreq-set -f 720
>
> it *will* switch to 720MHz, even if the mpurate code explicitly forbids it. I tested on all the
 >OMAP3 silicon I have and it will run at 720MHz fine, even if it's out 
of spec, so I'm happy with this bug :)

:) on mainline, if you dont have the frequency in opp definitions and 
your board has not done an explicit opp_add, cpufreq will only set u to 
the nearest available freq - easy for mainline fix if someone would like 
to send a patch adding the OPPs and the detection logic involved for 
enabling them.

Now, thinking aloud, the voltage setting by SR will probably occur in 
late_init, if mpurate is setting the clock earlier in the boot process, 
we might have a potential conflict in the mpurate expecting the system 
to be set in a certain voltage based on Sanjeev's argument, but not 
actually there.. we expect ondemand+cpufreq to do the job on runtime 
anyways.

Regards,
Nishanth Menon