On 05/28/2010 03:42 PM, Premi, Sanjeev wrote:
-----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.
aye, I am aware of the concept here, just questioning what does it mean
by setting mpurate to the kernel - it could mean two things:
a) mean this is mpurate that the system was working on (aka) - now setup
the required stuff to continue to function at that rate.
b) go to this rate and forget where you were running at.
the job of ondemand and other governors is to adjust to an optimal OPP
using cpufreq which would conflict IMHO with (b), which kinda questions
if you dont use cpufreq, does mpurate mean actually (a)?
anyways for cpufreq to work at 720Mhz, you need to add that frequency
and corresponding voltage to the opptable, neither exists, further
mpurate should work with opp table as well, else clockframework has no
direct mechanism to verify the valid OPPs on a runtime system. that was
the intent of opp layer - to provide the rest of the users with a
mechanism to verify, query and use opps without functional knowledge of
the silicon it works on..
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
