_______________________________________ From: Kevin Hilman [khilman@xxxxxxxxxxxxxxxxxxx] Sent: Friday, May 28, 2010 11:27 PM To: Nishanth menon Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux-omap@xxxxxxxxxxxxxxx; eduardo.valentin@xxxxxxxxx Subject: Re: omap3 pm: dependency between opp layer and cpufreq Nishanth menon <menon.nishanth@xxxxxxxxx> writes: [...] >> 'mpurate' is usually used when cpufreq is not required. It >> means - set me up for the specified freq and forget it. There >> is no further change needed/ possible. > > That opens up the question - why not use cpufreq with userspace > governor instead? Esp if u dont want a change in freq, ok i get the > part where u'd like a single freq for the system to function at, but > u also mention, mpurate is for systems that dont care abt any other > dependencies. So, bit of a contradiction if it depends on scaling > voltage to the right level aka u are selecting an freq from opp > table. > > This in my mind means u shud modify mpurate to use opp layer aka > another user beyond cpufreq. >> >> You could always argue that it can be done in u-boot; but this >> bootarg helps people choose target freq keeping the u-boot same. > > Errr..... Makes me feel that u shud really be using cpufreq instead! Either way > i am not completely convinced u shud be doing voltage scaling when using > mpurate given ur description- if u are trying to write a new cpufreq layer, why > not fix why cpufreq doesn't work for u and help the rest of us as well ;) Personally, I'm not opposed to supporting mpurate= (with CPUfreq disabled) as this would also have the benefit of allowing a smaller kernel if you really don't want DVFS. After getting he right voltage from the OPP layer, what interface are you planning to use to actually scale the voltage? SR? new voltage layer directly? [sp] I plan to use the existing infra only. SR is again a config option. In the current internal implementation SR is being used. But this leads to an "ugly" hack where actual setting of mpurate is delayed until SR is initialized. In other mail (in response to Nishanth) I suggested that dependency between OPP layer and PMIC needs to be broken. If done sooner, i would try to avoid using SR (as preference). I haven't yet looked at new SR layer good enough to make clear yes/no response. ~sanjeev Kevin -- 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
