[BUG] cpufreq on SMP with CPUs present but not online

[BUG] cpufreq on SMP with CPUs present but not online

[Russell King]

... causes the cpufreq driver init method to be called for each CPU.
However, this causes something of a dilema on ARM/SMP - if the CPU
is not online (because we failed to bring it up via __cpu_up which
correctly returned an error), we can't read the current clock rate
settings, so we can't initialise policy->{cur,min,max} fields.

Returning an error from the cpufreq driver init method means that
cpufreq completely forgets about this particular CPU, which also
isn't desirable.

Ideas?

-- 
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

Re: [BUG] cpufreq on SMP with CPUs present but not online

[Dominik Brodowski]

On Mon, Jan 17, 2005 at 10:38:27PM +0000, Russell King wrote:
> ... causes the cpufreq driver init method to be called for each CPU.
> However, this causes something of a dilema on ARM/SMP - if the CPU
> is not online (because we failed to bring it up via __cpu_up which
> correctly returned an error), we can't read the current clock rate
> settings, so we can't initialise policy->{cur,min,max} fields.

Do I understand you correctly that this CPU will be brought up later?

> Returning an error from the cpufreq driver init method means that
> cpufreq completely forgets about this particular CPU, which also
> isn't desirable.
> 
> Ideas?

Yes. I had tried to integrate cpufreq better with the CPU hotplug core a few
months ago, but got delayed because of other hotplug-related issues which
hopefully will be sorted out very soon. Stay tuned.

	Dominik

PS: should we all use cpufreq@zenII.linux.org.uk or @lists.linux.org.uk?

Re: [BUG] cpufreq on SMP with CPUs present but not online

[Russell King]

On Tue, Jan 18, 2005 at 07:06:30PM +0100, Dominik Brodowski wrote:
> On Mon, Jan 17, 2005 at 10:38:27PM +0000, Russell King wrote:
> > ... causes the cpufreq driver init method to be called for each CPU.
> > However, this causes something of a dilema on ARM/SMP - if the CPU
> > is not online (because we failed to bring it up via __cpu_up which
> > correctly returned an error), we can't read the current clock rate
> > settings, so we can't initialise policy->{cur,min,max} fields.
> 
> Do I understand you correctly that this CPU will be brought up later?

Possibly - though I'm wondering whether it's really correct to register
the struct cpu for not-currently-online but possible CPUs.  I think this
may make sense, but I'd want to get it confirmed by some SMP folk first.

> > Returning an error from the cpufreq driver init method means that
> > cpufreq completely forgets about this particular CPU, which also
> > isn't desirable.
> > 
> > Ideas?
> 
> Yes. I had tried to integrate cpufreq better with the CPU hotplug core a few
> months ago, but got delayed because of other hotplug-related issues which
> hopefully will be sorted out very soon. Stay tuned.
> 
> 	Dominik
> 
> PS: should we all use cpufreq@zenII.linux.org.uk or @lists.linux.org.uk?

lists.linux.org.uk please.  Unfortunately, when mailservers see the
CNAME for lists.linux.org.uk, they rewrite all addresses to the result
of the CNAME.  Alan - can you change CNAME into:

lists		IN	A	195.92.249.252
		IN	AAAA	2002:c35c:f9fc::1

please?  Thanks.

-- 
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