On Saturday 17 December 2011 16:00:03 Richard Zhao wrote:
> On Fri, Dec 16, 2011 at 08:32:35AM -0600, Rob Herring wrote:
> > On 12/16/2011 04:30 AM, Richard Zhao wrote:
> > > It support single core and multi-core ARM SoCs. But it assume
> > > all cores share the same frequency and voltage.
> > >
> > > Signed-off-by: Richard Zhao <richard.zhao@xxxxxxxxxx>
> > > ---
> > > drivers/cpufreq/Kconfig.arm | 8 ++
> > > drivers/cpufreq/Makefile | 1 +
> > > drivers/cpufreq/arm-cpufreq.c | 269 +++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 278 insertions(+), 0 deletions(-)
> > > create mode 100644 drivers/cpufreq/arm-cpufreq.c
> > >
> >
> > What makes this specific to ARM and not a generic DT + clk api +
> > regulator api driver?
>
> smp loops_per_jiffy update needs arm header <asm/cpu.h>.
I would suggest to instead change the definition of adjust_jiffies in the
core so it can be overridden by the architecture, like this
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 987a165..174584d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -189,6 +189,7 @@ EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
* systems as each CPU might be scaled differently. So, use the arch
* per-CPU loops_per_jiffy value wherever possible.
*/
+#ifndef adjust_jiffies
#ifndef CONFIG_SMP
static unsigned long l_p_j_ref;
static unsigned int l_p_j_ref_freq;
@@ -218,7 +219,8 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
{
return;
}
-#endif
+#endif /* CONFIG_SMP */
+#endif /* adjust_jiffies */
/**
Then ARM (and any others that want the driver) can provide their own
implementation and set
#define adjust_jiffies(val, ci) adjust_jiffies((val), (ci))
to let the core use that instead of the generic UP version.
While we're there, we should probably try to fix drivers that use loops_per_jiffy,
because that is not what they think it is on SMP.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
