Searched hist:"1937 f5b9" (Results 1 – 3 of 3) sorted by relevance
| /openbmc/linux/arch/arm/mach-sa1100/ |
| H A D | Kconfig | 1937f5b9 Sat Dec 12 10:20:57 CST 2009 Russell King <rmk+kernel@arm.linux.org.uk> ARM: fix sa1100 build
Fix:
arch/arm/mach-sa1100/generic.c:117: error: redefinition of 'cpufreq_get'
include/linux/cpufreq.h:299: error: previous definition of 'cpufreq_get' was here
cpufreq_get() is used on these platforms to tell drivers what the CPU
frequency is, and therefore the bus frequency - which is critical for
setting the PCMCIA and LCD timings. Adding ifdefs to these drivers to
select cpufreq_get() or some other interface adds confusion. Making
these drivers use some other interface for the normal paths and cpufreq
stuff for the cpufreq notifier is insane as well.
(Why x86 can't provide a version of cpufreq_get() which returns the
CPU frequency when CPUFREQ is disabled is beyond me, rather than
requiring a dummy zero-returning cpufreq_get(). Especially as they
do:
unsigned long khz = cpufreq_get(cpu);
if (!khz)
khz = tsc_khz;
In other words, if CPUFREQ is disabled, get it from tsc_khz - why
not provide a dummy cpufreq_get() which returns tsc_khz?)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1937f5b9 Sat Dec 12 10:20:57 CST 2009 Russell King <rmk+kernel@arm.linux.org.uk> ARM: fix sa1100 build
Fix:
arch/arm/mach-sa1100/generic.c:117: error: redefinition of 'cpufreq_get'
include/linux/cpufreq.h:299: error: previous definition of 'cpufreq_get' was here
cpufreq_get() is used on these platforms to tell drivers what the CPU
frequency is, and therefore the bus frequency - which is critical for
setting the PCMCIA and LCD timings. Adding ifdefs to these drivers to
select cpufreq_get() or some other interface adds confusion. Making
these drivers use some other interface for the normal paths and cpufreq
stuff for the cpufreq notifier is insane as well.
(Why x86 can't provide a version of cpufreq_get() which returns the
CPU frequency when CPUFREQ is disabled is beyond me, rather than
requiring a dummy zero-returning cpufreq_get(). Especially as they
do:
unsigned long khz = cpufreq_get(cpu);
if (!khz)
khz = tsc_khz;
In other words, if CPUFREQ is disabled, get it from tsc_khz - why
not provide a dummy cpufreq_get() which returns tsc_khz?)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| H A D | generic.c | 1937f5b9 Sat Dec 12 10:20:57 CST 2009 Russell King <rmk+kernel@arm.linux.org.uk> ARM: fix sa1100 build
Fix:
arch/arm/mach-sa1100/generic.c:117: error: redefinition of 'cpufreq_get'
include/linux/cpufreq.h:299: error: previous definition of 'cpufreq_get' was here
cpufreq_get() is used on these platforms to tell drivers what the CPU
frequency is, and therefore the bus frequency - which is critical for
setting the PCMCIA and LCD timings. Adding ifdefs to these drivers to
select cpufreq_get() or some other interface adds confusion. Making
these drivers use some other interface for the normal paths and cpufreq
stuff for the cpufreq notifier is insane as well.
(Why x86 can't provide a version of cpufreq_get() which returns the
CPU frequency when CPUFREQ is disabled is beyond me, rather than
requiring a dummy zero-returning cpufreq_get(). Especially as they
do:
unsigned long khz = cpufreq_get(cpu);
if (!khz)
khz = tsc_khz;
In other words, if CPUFREQ is disabled, get it from tsc_khz - why
not provide a dummy cpufreq_get() which returns tsc_khz?)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1937f5b9 Sat Dec 12 10:20:57 CST 2009 Russell King <rmk+kernel@arm.linux.org.uk> ARM: fix sa1100 build
Fix:
arch/arm/mach-sa1100/generic.c:117: error: redefinition of 'cpufreq_get'
include/linux/cpufreq.h:299: error: previous definition of 'cpufreq_get' was here
cpufreq_get() is used on these platforms to tell drivers what the CPU
frequency is, and therefore the bus frequency - which is critical for
setting the PCMCIA and LCD timings. Adding ifdefs to these drivers to
select cpufreq_get() or some other interface adds confusion. Making
these drivers use some other interface for the normal paths and cpufreq
stuff for the cpufreq notifier is insane as well.
(Why x86 can't provide a version of cpufreq_get() which returns the
CPU frequency when CPUFREQ is disabled is beyond me, rather than
requiring a dummy zero-returning cpufreq_get(). Especially as they
do:
unsigned long khz = cpufreq_get(cpu);
if (!khz)
khz = tsc_khz;
In other words, if CPUFREQ is disabled, get it from tsc_khz - why
not provide a dummy cpufreq_get() which returns tsc_khz?)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| /openbmc/linux/arch/arm/ |
| H A D | Kconfig | 1937f5b9 Sat Dec 12 10:20:57 CST 2009 Russell King <rmk+kernel@arm.linux.org.uk> ARM: fix sa1100 build
Fix:
arch/arm/mach-sa1100/generic.c:117: error: redefinition of 'cpufreq_get'
include/linux/cpufreq.h:299: error: previous definition of 'cpufreq_get' was here
cpufreq_get() is used on these platforms to tell drivers what the CPU
frequency is, and therefore the bus frequency - which is critical for
setting the PCMCIA and LCD timings. Adding ifdefs to these drivers to
select cpufreq_get() or some other interface adds confusion. Making
these drivers use some other interface for the normal paths and cpufreq
stuff for the cpufreq notifier is insane as well.
(Why x86 can't provide a version of cpufreq_get() which returns the
CPU frequency when CPUFREQ is disabled is beyond me, rather than
requiring a dummy zero-returning cpufreq_get(). Especially as they
do:
unsigned long khz = cpufreq_get(cpu);
if (!khz)
khz = tsc_khz;
In other words, if CPUFREQ is disabled, get it from tsc_khz - why
not provide a dummy cpufreq_get() which returns tsc_khz?)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1937f5b9 Sat Dec 12 10:20:57 CST 2009 Russell King <rmk+kernel@arm.linux.org.uk> ARM: fix sa1100 build
Fix:
arch/arm/mach-sa1100/generic.c:117: error: redefinition of 'cpufreq_get'
include/linux/cpufreq.h:299: error: previous definition of 'cpufreq_get' was here
cpufreq_get() is used on these platforms to tell drivers what the CPU
frequency is, and therefore the bus frequency - which is critical for
setting the PCMCIA and LCD timings. Adding ifdefs to these drivers to
select cpufreq_get() or some other interface adds confusion. Making
these drivers use some other interface for the normal paths and cpufreq
stuff for the cpufreq notifier is insane as well.
(Why x86 can't provide a version of cpufreq_get() which returns the
CPU frequency when CPUFREQ is disabled is beyond me, rather than
requiring a dummy zero-returning cpufreq_get(). Especially as they
do:
unsigned long khz = cpufreq_get(cpu);
if (!khz)
khz = tsc_khz;
In other words, if CPUFREQ is disabled, get it from tsc_khz - why
not provide a dummy cpufreq_get() which returns tsc_khz?)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|