[PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Dominik Brodowski]

Export an array of supported frequencies in sysfs [scaling_available_frequencies]

 arch/i386/kernel/cpu/cpufreq/acpi.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletion(-)

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c linux/arch/i386/kernel/cpu/cpufreq/acpi.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c	2004-02-18 10:22:09.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/acpi.c	2004-02-18 22:29:03.112571968 +0100
@@ -306,7 +306,7 @@
 			data->freq_table[i].frequency = CPUFREQ_TABLE_END;
 	}
 
-	result = cpufreq_frequency_table_cpuinfo(policy, &data->freq_table[0]);
+	result = cpufreq_frequency_table_cpuinfo(policy, data->freq_table);
 	if (result) {
 		goto err_freqfree;
 	}
@@ -321,6 +321,7 @@
 			(u32) data->acpi_data.states[i].power,
 			(u32) data->acpi_data.states[i].transition_latency);
 
+	cpufreq_frequency_table_get_attr(data->freq_table, policy->cpu);
 	return_VALUE(result);
 
  err_freqfree:
@@ -345,6 +346,7 @@
 	ACPI_FUNCTION_TRACE("acpi_cpufreq_cpu_exit");
 
 	if (data) {
+		cpufreq_frequency_table_put_attr(policy->cpu);
 		acpi_io_data[policy->cpu] = NULL;
 		acpi_processor_unregister_performance(&data->acpi_data, policy->cpu);
 		kfree(data);
@@ -354,6 +356,11 @@
 }
 
 
+static struct freq_attr* acpi_cpufreq_attr[] = {
+	&cpufreq_freq_attr_scaling_available_freqs,
+	NULL,
+};
+
 static struct cpufreq_driver acpi_cpufreq_driver = {
 	.verify 	= acpi_cpufreq_verify,
 	.target 	= acpi_cpufreq_target,
@@ -361,6 +368,7 @@
 	.exit		= acpi_cpufreq_cpu_exit,
 	.name		= "acpi-cpufreq",
 	.owner		= THIS_MODULE,
+	.attr           = acpi_cpufreq_attr,
 };

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Pavel Machek]

Hi!

> Export an array of supported frequencies in sysfs
> [scaling_available_frequencies]

Would it be possible to export [frequency/voltage] pairs, and allow
user to change it?
								Pavel



-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 469 bytes --]

On Tue, Feb 24, 2004 at 01:56:28PM +0100, Pavel Machek wrote:
> Hi!
> 
> > Export an array of supported frequencies in sysfs
> > [scaling_available_frequencies]
> 
> Would it be possible to export [frequency/voltage] pairs, and allow
> user to change it?

IMO, NO! While this might be a necessity for powernow-k7, the generic acpi-io
driver should stay clean of such overrides et al. If you need to modify the
ACPI tables, there are other ways.

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Pavel Machek]

Hi!

> > > Export an array of supported frequencies in sysfs
> > > [scaling_available_frequencies]
> > 
> > Would it be possible to export [frequency/voltage] pairs, and allow
> > user to change it?
> 
> IMO, NO! While this might be a necessity for powernow-k7, the generic acpi-io
> driver should stay clean of such overrides et al. If you need to modify the
> ACPI tables, there are other ways.

Well, I know k7 machines that apparently needed override, and I know
k8 machines that definitely need one. Buggy bioses seem to be quite
common...

I do not know how buggy tables on intel machines are, but it seems to
me that overrides should be generic.

[Otoh... that would need tables to contain voltages in some known
units, probably milivolts. Again that would be good for printouts...]

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Tomasz Ciolek]

 have a loook at the "userpace frequency governer" under 2.6.x 

 TMC

On Tue, Feb 24, 2004 at 01:56:28PM +0100, Pavel Machek wrote:
> Hi!
> 
> > Export an array of supported frequencies in sysfs
> > [scaling_available_frequencies]
> 
> Would it be possible to export [frequency/voltage] pairs, and allow
> user to change it?
> 								Pavel
> 
> 
> 
> -- 
> When do you have a heart between your knees?
> [Johanka's followup: and *two* hearts?]
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

-- 
Tomasz M. Ciolek	
*******************************************************************************
 tmc at dreamcraft dot com dot au or tmc at goldweb dot com dot au 	
*******************************************************************************
	GPG Key ID: 0x41C4C2F0  Key available on www.pgp.net	
*******************************************************************************
  Everything falls under the law of change;	
  Like a dream, a phantom, a bubble, a shadow,
  like dew of flash of lightning.
  You should contemplate like this. 

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Pavel Machek]

Hi!

>  have a loook at the "userpace frequency governer" under 2.6.x 

That's not the same. frequency governor can select frequency *from the
set provided by BIOS*. I want to override frequency/voltage table from
bios.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Bruno Ducrot]

On Tue, Feb 24, 2004 at 11:16:42PM +0100, Pavel Machek wrote:
> Hi!
> 
> >  have a loook at the "userpace frequency governer" under 2.6.x 
> 
> That's not the same. frequency governor can select frequency *from the
> set provided by BIOS*. I want to override frequency/voltage table from
> bios.
> 

It need to be done IMO in a driver, definitely not in cpufreq core, and
worst that may need to be adapted to the acpi perflib certainly (when
all pending patches for will go to mainstream I guess).

For now, you can adapt with something like the powernow-k7 override
patches at http://www.poupinou.org/cpufreq/powernow-k7/ if really
needed.

Also, you should check that in fact the acpi perflib stuff will give
you more accurate results.  For the powernow-k7 case, unfortunately, it
sound like that acpi perflib whereas giving good results still could be
problematics for some acer IIRC due to a bad VID for one entry, and then
it may be usefull for them to get the override patch merged IMO.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Pavel Machek]

On Čt 26-02-04 18:28:23, Bruno Ducrot wrote:
> On Tue, Feb 24, 2004 at 11:16:42PM +0100, Pavel Machek wrote:

> > >  have a loook at the "userpace frequency governer" under 2.6.x 
> > 
> > That's not the same. frequency governor can select frequency *from the
> > set provided by BIOS*. I want to override frequency/voltage table from
> > bios.
> 
> It need to be done IMO in a driver, definitely not in cpufreq core, and
> worst that may need to be adapted to the acpi perflib certainly (when
> all pending patches for will go to mainstream I guess).

Well, it still looks pretty generic to me. Having same code in k7
and k8 drivers does not sound right.

Anyway, lets see what happens. If acpi mostly solves it, it is not
necessary.

> For now, you can adapt with something like the powernow-k7 override
> patches at http://www.poupinou.org/cpufreq/powernow-k7/ if really
> needed.

> Also, you should check that in fact the acpi perflib stuff will give
> you more accurate results.  For the powernow-k7 case, unfortunately, it
> sound like that acpi perflib whereas giving good results still could be
> problematics for some acer IIRC due to a bad VID for one entry, and then
> it may be usefull for them to get the override patch merged IMO.

Hmm, if there's really only _one_ machine to fix, perhaps DMI
blacklist is the right solution.
							Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Bruno Ducrot]

On Thu, Feb 26, 2004 at 10:50:06PM +0100, Pavel Machek wrote:
> On ??t 26-02-04 18:28:23, Bruno Ducrot wrote:
> > On Tue, Feb 24, 2004 at 11:16:42PM +0100, Pavel Machek wrote:
> 
> > > >  have a loook at the "userpace frequency governer" under 2.6.x 
> > > 
> > > That's not the same. frequency governor can select frequency *from the
> > > set provided by BIOS*. I want to override frequency/voltage table from
> > > bios.
> > 
> > It need to be done IMO in a driver, definitely not in cpufreq core, and
> > worst that may need to be adapted to the acpi perflib certainly (when
> > all pending patches for will go to mainstream I guess).
> 
> Well, it still looks pretty generic to me. Having same code in k7
> and k8 drivers does not sound right.

That can be shared by the two drivers if that is needed, but I don't
think that part going to the cpufreq frequency tables.
But I espected that powernow k7 and k8 are different beasts enough?
There is no rvo, irt etc. for example in powernow-k7.

> Anyway, lets see what happens. If acpi mostly solves it, it is not
> necessary.
> 
> > For now, you can adapt with something like the powernow-k7 override
> > patches at http://www.poupinou.org/cpufreq/powernow-k7/ if really
> > needed.
> 
> > Also, you should check that in fact the acpi perflib stuff will give
> > you more accurate results.  For the powernow-k7 case, unfortunately, it
> > sound like that acpi perflib whereas giving good results still could be
> > problematics for some acer IIRC due to a bad VID for one entry, and then
> > it may be usefull for them to get the override patch merged IMO.
> 
> Hmm, if there's really only _one_ machine to fix, perhaps DMI
> blacklist is the right solution.

Yes, but I guess there are more though.  Just that we don't get enough
reports yet.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Pavel Machek]

> On Thu, Feb 26, 2004 at 10:50:06PM +0100, Pavel Machek wrote:
> > On ??t 26-02-04 18:28:23, Bruno Ducrot wrote:
> > > On Tue, Feb 24, 2004 at 11:16:42PM +0100, Pavel Machek wrote:
> > 
> > > > >  have a loook at the "userpace frequency governer" under 2.6.x 
> > > > 
> > > > That's not the same. frequency governor can select frequency *from the
> > > > set provided by BIOS*. I want to override frequency/voltage table from
> > > > bios.
> > > 
> > > It need to be done IMO in a driver, definitely not in cpufreq core, and
> > > worst that may need to be adapted to the acpi perflib certainly (when
> > > all pending patches for will go to mainstream I guess).
> > 
> > Well, it still looks pretty generic to me. Having same code in k7
> > and k8 drivers does not sound right.
> 
> That can be shared by the two drivers if that is needed, but I don't
> think that part going to the cpufreq frequency tables.
> But I espected that powernow k7 and k8 are different beasts enough?
> There is no rvo, irt etc. for example in powernow-k7.

They are different, but like every other driver, they have table of
(voltage, frequency) pairs, and that table is exactly the thing user
is trying to override. [And that's probably same with all other
drivers..] 

As long as people don't want to change rvo, irt, etc, we should be
fine.

First step in that direction would be to have voltage in milivolts in
those frequency tables, so that core can print them etc... like this:

--- clean/include/linux/cpufreq.h	2004-01-09 20:24:26.000000000 +0100
+++ linux/include/linux/cpufreq.h	2004-03-01 19:02:48.000000000 +0100
@@ -316,6 +316,7 @@
 	unsigned int	index;     /* any */
 	unsigned int	frequency; /* kHz - doesn't need to be in ascending
 				    * order */
+	unsigned int	voltage;   /* mV */
 };
 
 int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,


								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Bruno Ducrot]

On Mon, Mar 01, 2004 at 07:03:25PM +0100, Pavel Machek wrote:
> 
> As long as people don't want to change rvo, irt, etc, we should be
> fine.

Yes, probably, but in case of powernow-k7 I need to pass specifically
fsb and latency.  And I much prefer to do it atomic.  Also I want to
check that the user do not enter stupid things.  For example, I
requested that frequency being passed even though it's actually only
here in order to check that frequency and FID being OK with something
like
if (frequency != table[vid] * fsb * ...) then fail.
for each entry passed.

> First step in that direction would be to have voltage in milivolts in
> those frequency tables, so that core can print them etc... like this:
> 
> --- clean/include/linux/cpufreq.h	2004-01-09 20:24:26.000000000 +0100
> +++ linux/include/linux/cpufreq.h	2004-03-01 19:02:48.000000000 +0100
> @@ -316,6 +316,7 @@
>  	unsigned int	index;     /* any */
>  	unsigned int	frequency; /* kHz - doesn't need to be in ascending
>  				    * order */
> +	unsigned int	voltage;   /* mV */
>  };

Well, why not?

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 918 bytes --]

On Wed, Mar 03, 2004 at 05:22:55PM +0100, Bruno Ducrot wrote:
> > --- clean/include/linux/cpufreq.h	2004-01-09 20:24:26.000000000 +0100
> > +++ linux/include/linux/cpufreq.h	2004-03-01 19:02:48.000000000 +0100
> > @@ -316,6 +316,7 @@
> >  	unsigned int	index;     /* any */
> >  	unsigned int	frequency; /* kHz - doesn't need to be in ascending
> >  				    * order */
> > +	unsigned int	voltage;   /* mV */
> >  };
> 
> Well, why not?

Four reasons:

1.) not all cpufreq drivers which use frequency table helpers know the
voltage

2.) most cpufreq drivers don't need to know the voltage -- they need to know
a value [==index] to be written to some sort of register [msr/io/whatever].

3.) sizeof(struct cpufreq_table_entry)

4.) the overrides discussed for k{7,8} are very driver-specific and do
neither belong into the cpufreq core nor into the cpufreq frequency table
helpers. 

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: [ACPI] [PATCH 1/2] 2.6: use scaling_available_freqs in acpi-cpufreq-ioport driver

[Pavel Machek]

Hi!

+0100, Bruno Ducrot wrote:
> > > --- clean/include/linux/cpufreq.h	2004-01-09 20:24:26.000000000 +0100
> > > +++ linux/include/linux/cpufreq.h	2004-03-01 19:02:48.000000000 +0100
> > > @@ -316,6 +316,7 @@
> > >  	unsigned int	index;     /* any */
> > >  	unsigned int	frequency; /* kHz - doesn't need to be in ascending
> > >  				    * order */
> > > +	unsigned int	voltage;   /* mV */
> > >  };
> > 
> > Well, why not?
> 
> Four reasons:
> 
> 1.) not all cpufreq drivers which use frequency table helpers know the
> voltage
> 
> 2.) most cpufreq drivers don't need to know the voltage -- they need to know
> a value [==index] to be written to some sort of register [msr/io/whatever].
> 
> 3.) sizeof(struct cpufreq_table_entry)
> 
> 4.) the overrides discussed for k{7,8} are very driver-specific and do
> neither belong into the cpufreq core nor into the cpufreq frequency table
> helpers. 

After seeing k7 table that contains specific parameters (settle time etc)
for each state, I have to agree that what I suggested is bad idea.


-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms