Re: my dothan didn't work with cpufreq...

[Jeremy Fitzhardinge <jeremy@goop.org>]

On Thu, 2004-07-22 at 11:31 +0200, Dominik Brodowski wrote:
> > The hacky way to work it out would be to read
> > back the MSR and see what freq/voltage pair you have (which would only
> > work at max speed).
> ... but as many systems boot at a lower speed on battery power, I wouldn't
> want to do this.

Oh, no, I wasn't even considering suggesting it.  It's too nasty.

> However, as "enhanced SpeedStep" is going to be introduced on
> desktop CPUs, the problem will increase: the MSR will likely have a
> different encoding. See Venkatesh's patches for details. Also, I fear that
> as more CPUs support enhanced SpeedStep, the larger
> speedstep-centrino.{o,ko} will become.

The tables are not very big, and I was thinking about generating the
model names from a template rather than explicitly enumerating them all
as we do now.

But you're right, it looks like the simple table approach will be hard
or impossible to maintain.

> > +static const struct cpu_id cpu_ids[] = {
> > +	[CPU_BANIAS]	= { X86_VENDOR_INTEL,	6,  9, 5 },
> > +	[CPU_DOTHAN_A1]	= { X86_VENDOR_INTEL,	6, 13, 1 },
> > +	[CPU_DOTHAN_B0]	= { X86_VENDOR_INTEL,	6, 13, 6 },
> 
> Hm, I'm unsure whether this is proper CodingStyle... IIRC, much effort was
> spent in converting such { }s to include the respective "fields", like
> 	{ .x86_vendor = X86_VENDOR_INTEL, x86_family = 6 ... 
> and so on.

For a tiny little structure like this, which is defined immediately
above, this is fine. (CodingStyle makes no mention of structure
initialization.)

	J