> -----Original Message----- > From: Menon, Nishanth > Sent: Friday, May 28, 2010 7:03 PM > To: Koen Kooi > Cc: Premi, Sanjeev; linux-omap@xxxxxxxxxxxxxxx; > eduardo.valentin@xxxxxxxxx; Kevin Hilman > Subject: Re: omap3 pm: dependency between opp layer and cpufreq > > 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. Nishanth, When setting via mpurate, we need to get the appropriate voltage corresponding to the mpurate so that right combination can be done. This is where the mapping between freq and voltage needs to be queried. And OPP layer is best placed to provide the info... without duplication. The mechanism of changing the voltage itself can vary on the PMIC. BTW, I am getting ready to submit an updated patch for mpurate. Just waiting for an early resolution to this discussion. ~sanjeev > > 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
