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