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 :) regards, Koen-- 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
