* cpufreq on ARM broken
@ 2004-05-29 16:01 Russell King
2004-06-01 17:11 ` Dave Jones
0 siblings, 1 reply; 6+ messages in thread
From: Russell King @ 2004-05-29 16:01 UTC (permalink / raw)
To: cpufreq
Hi,
cpufreq doesn't appear to initialise on ARM - cpufreq_register_driver()
fails with -ENODEV.
This appears to be because we register cpus at subsys_initcall() time,
and cpufreq drivers at arch_initcall() time. We need cpufreq up and
running before any drivers are initialised since their timings depend
on the CPU clock rate.
The following patch appears to fix these problems.
--- linux-tolinus/arch/arm/mach-sa1100/cpu-sa1100.c Fri May 21 00:05:46 2004
+++ linux/arch/arm/mach-sa1100/cpu-sa1100.c Sat May 29 16:19:51 2004
@@ -230,8 +230,9 @@
}
static struct cpufreq_driver sa1100_driver = {
- .flags = (CPUFREQ_PANIC_OUTOFSYNC |
- CPUFREQ_PANIC_RESUME_OUTOFSYNC),
+ .flags = CPUFREQ_STICKY |
+ CPUFREQ_PANIC_OUTOFSYNC |
+ CPUFREQ_PANIC_RESUME_OUTOFSYNC,
.verify = sa11x0_verify_speed,
.target = sa1100_target,
.get = sa11x0_getspeed,
--- linux-tolinus/arch/arm/mach-sa1100/cpu-sa1110.c Fri May 21 00:05:46 2004
+++ linux/arch/arm/mach-sa1100/cpu-sa1110.c Sat May 29 16:19:35 2004
@@ -329,8 +329,9 @@
}
static struct cpufreq_driver sa1110_driver = {
- .flags = (CPUFREQ_PANIC_OUTOFSYNC |
- CPUFREQ_PANIC_RESUME_OUTOFSYNC),
+ .flags = CPUFREQ_STICKY |
+ CPUFREQ_PANIC_OUTOFSYNC |
+ CPUFREQ_PANIC_RESUME_OUTOFSYNC,
.verify = sa11x0_verify_speed,
.target = sa1110_target,
.get = sa11x0_getspeed,
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: cpufreq on ARM broken
2004-05-29 16:01 cpufreq on ARM broken Russell King
@ 2004-06-01 17:11 ` Dave Jones
2004-06-02 12:21 ` Dominik Brodowski
0 siblings, 1 reply; 6+ messages in thread
From: Dave Jones @ 2004-06-01 17:11 UTC (permalink / raw)
To: linux; +Cc: cpufreq
Thoughts ?
I've forgotten why we introduced this flag, it appears that this
would be the first thing in the tree to actually use it,
which makes me sceptical.
Dave
On Sat, 2004-05-29 at 17:01, Russell King wrote:
> cpufreq doesn't appear to initialise on ARM - cpufreq_register_driver()
> fails with -ENODEV.
>
> This appears to be because we register cpus at subsys_initcall() time,
> and cpufreq drivers at arch_initcall() time. We need cpufreq up and
> running before any drivers are initialised since their timings depend
> on the CPU clock rate.
>
> The following patch appears to fix these problems.
>
> --- linux-tolinus/arch/arm/mach-sa1100/cpu-sa1100.c Fri May 21 00:05:46 2004
> +++ linux/arch/arm/mach-sa1100/cpu-sa1100.c Sat May 29 16:19:51 2004
> @@ -230,8 +230,9 @@
> }
>
> static struct cpufreq_driver sa1100_driver = {
> - .flags = (CPUFREQ_PANIC_OUTOFSYNC |
> - CPUFREQ_PANIC_RESUME_OUTOFSYNC),
> + .flags = CPUFREQ_STICKY |
> + CPUFREQ_PANIC_OUTOFSYNC |
> + CPUFREQ_PANIC_RESUME_OUTOFSYNC,
> .verify = sa11x0_verify_speed,
> .target = sa1100_target,
> .get = sa11x0_getspeed,
> --- linux-tolinus/arch/arm/mach-sa1100/cpu-sa1110.c Fri May 21 00:05:46 2004
> +++ linux/arch/arm/mach-sa1100/cpu-sa1110.c Sat May 29 16:19:35 2004
> @@ -329,8 +329,9 @@
> }
>
> static struct cpufreq_driver sa1110_driver = {
> - .flags = (CPUFREQ_PANIC_OUTOFSYNC |
> - CPUFREQ_PANIC_RESUME_OUTOFSYNC),
> + .flags = CPUFREQ_STICKY |
> + CPUFREQ_PANIC_OUTOFSYNC |
> + CPUFREQ_PANIC_RESUME_OUTOFSYNC,
> .verify = sa11x0_verify_speed,
> .target = sa1110_target,
> .get = sa11x0_getspeed,
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: cpufreq on ARM broken
2004-06-01 17:11 ` Dave Jones
@ 2004-06-02 12:21 ` Dominik Brodowski
2004-06-02 12:59 ` Dave Jones
2004-06-02 21:36 ` Russell King
0 siblings, 2 replies; 6+ messages in thread
From: Dominik Brodowski @ 2004-06-02 12:21 UTC (permalink / raw)
To: Dave Jones; +Cc: cpufreq
On Tue, Jun 01, 2004 at 06:11:34PM +0100, Dave Jones wrote:
> Thoughts ?
> I've forgotten why we introduced this flag, it appears that this
> would be the first thing in the tree to actually use it,
> which makes me sceptical.
This flag was introduced when I added the "fail if no proper CPU found"
feature, which is helpful for the ACPI P-States driver and some other x86
drivers which only check whether they can run on _any_ CPU in the
cpu-specific initialization call. To assert backwards-compatibility, this
flag avoids "automatic unregistration" -- I wasn't aware some drivers do
need this backwards compatibility, but obviously ARM needs it. So Russell's
patch looks to be what's needed, from my perspective.
Dominik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq on ARM broken
2004-06-02 12:21 ` Dominik Brodowski
@ 2004-06-02 12:59 ` Dave Jones
2004-06-02 13:08 ` Dominik Brodowski
2004-06-02 21:36 ` Russell King
1 sibling, 1 reply; 6+ messages in thread
From: Dave Jones @ 2004-06-02 12:59 UTC (permalink / raw)
To: cpufreq
On Wed, Jun 02, 2004 at 02:21:53PM +0200, Dominik Brodowski wrote:
> On Tue, Jun 01, 2004 at 06:11:34PM +0100, Dave Jones wrote:
> > Thoughts ?
> > I've forgotten why we introduced this flag, it appears that this
> > would be the first thing in the tree to actually use it,
> > which makes me sceptical.
>
> This flag was introduced when I added the "fail if no proper CPU found"
> feature, which is helpful for the ACPI P-States driver and some other x86
> drivers which only check whether they can run on _any_ CPU in the
> cpu-specific initialization call.
So how come grepping for STICKY in arch/i386/kernel/cpu/cpufreq didn't
turn anything up?
> To assert backwards-compatibility, this
> flag avoids "automatic unregistration" -- I wasn't aware some drivers do
> need this backwards compatibility, but obviously ARM needs it. So Russell's
> patch looks to be what's needed, from my perspective.
Ok, I've no real objection either way. It just seemed odd to have
this functionality around, that no-one was using, which just happened
to be the right fix.
I'll roll this in later, right now there's some corruption in the cpufreq
bk tree which the bitmover folks are looking into.
Dave
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq on ARM broken
2004-06-02 12:59 ` Dave Jones
@ 2004-06-02 13:08 ` Dominik Brodowski
0 siblings, 0 replies; 6+ messages in thread
From: Dominik Brodowski @ 2004-06-02 13:08 UTC (permalink / raw)
To: Dave Jones; +Cc: cpufreq
On Wed, Jun 02, 2004 at 01:59:08PM +0100, Dave Jones wrote:
> On Wed, Jun 02, 2004 at 02:21:53PM +0200, Dominik Brodowski wrote:
> > On Tue, Jun 01, 2004 at 06:11:34PM +0100, Dave Jones wrote:
> > > Thoughts ?
> > > I've forgotten why we introduced this flag, it appears that this
> > > would be the first thing in the tree to actually use it,
> > > which makes me sceptical.
> >
> > This flag was introduced when I added the "fail if no proper CPU found"
> > feature, which is helpful for the ACPI P-States driver and some other x86
> > drivers which only check whether they can run on _any_ CPU in the
> > cpu-specific initialization call.
>
> So how come grepping for STICKY in arch/i386/kernel/cpu/cpufreq didn't
> turn anything up?
'cause it is not needed on x86: these drivers shouldn't be sticky. The
cpufreq drivers are only loaded way after the CPU sys devices are
registered. So, if the cpufreq driver's init() function fails on _all_ CPUs,
there's no sense keeping the driver registered. Only if it's unregistered,
other cpufreq drivers can register...
> > To assert backwards-compatibility, this
> > flag avoids "automatic unregistration" -- I wasn't aware some drivers do
> > need this backwards compatibility, but obviously ARM needs it. So Russell's
> > patch looks to be what's needed, from my perspective.
>
> Ok, I've no real objection either way. It just seemed odd to have
> this functionality around, that no-one was using, which just happened
> to be the right fix.
'cause I missed ARM needed it, so nobody was using it...
> I'll roll this in later, right now there's some corruption in the cpufreq
> bk tree which the bitmover folks are looking into.
Thanks,
Dominik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq on ARM broken
2004-06-02 12:21 ` Dominik Brodowski
2004-06-02 12:59 ` Dave Jones
@ 2004-06-02 21:36 ` Russell King
1 sibling, 0 replies; 6+ messages in thread
From: Russell King @ 2004-06-02 21:36 UTC (permalink / raw)
To: Dave Jones, cpufreq
On Wed, Jun 02, 2004 at 02:21:53PM +0200, Dominik Brodowski wrote:
> On Tue, Jun 01, 2004 at 06:11:34PM +0100, Dave Jones wrote:
> > Thoughts ?
> > I've forgotten why we introduced this flag, it appears that this
> > would be the first thing in the tree to actually use it,
> > which makes me sceptical.
>
> This flag was introduced when I added the "fail if no proper CPU found"
> feature, which is helpful for the ACPI P-States driver and some other x86
> drivers which only check whether they can run on _any_ CPU in the
> cpu-specific initialization call. To assert backwards-compatibility, this
> flag avoids "automatic unregistration" -- I wasn't aware some drivers do
> need this backwards compatibility, but obviously ARM needs it. So Russell's
> patch looks to be what's needed, from my perspective.
It isn't back-compat. It's caused by a side effect of how the order of
initialisation.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-06-02 21:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-29 16:01 cpufreq on ARM broken Russell King
2004-06-01 17:11 ` Dave Jones
2004-06-02 12:21 ` Dominik Brodowski
2004-06-02 12:59 ` Dave Jones
2004-06-02 13:08 ` Dominik Brodowski
2004-06-02 21:36 ` Russell King
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.