_______________________________________
From: Kevin Hilman [khil...@deeprootsystems.com]
Sent: Friday, May 28, 2010 11:27 PM
To: Nishanth menon
Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux-omap@vger.kernel.org; 
eduardo.valen...@nokia.com
Subject: Re: omap3 pm: dependency between opp layer and cpufreq

Nishanth menon <menon.nisha...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to