[PATCH] Longhaul - There are limits

[PATCH] Longhaul - There are limits

[Rafał Bilski]

Changes in Kconfig:
1. ACPI_PROCESSOR - next patch need ACPI C3 state working,
2. !X86_UP_APIC - (un)patched "longhaul" isn't APIC compatible,
3. !SMP - (un)patched "longhaul" isn't SMP compatible. First 
step would be APIC support. Second - per CPU private data.

Signed-off-by: Rafa³ Bilski <rafalbilski@interia.pl>

---

--- linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/Kconfig.orig	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/Kconfig	2006-07-02 19:48:40.000000000 +0200
@@ -202,7 +202,7 @@ config X86_LONGRUN
 config X86_LONGHAUL
 	tristate "VIA Cyrix III Longhaul"
 	select CPU_FREQ_TABLE
-	depends on BROKEN
+	depends on !SMP && !X86_UP_APIC && ACPI_PROCESSOR
 	help
 	  This adds the CPUFreq driver for VIA Samuel/CyrixIII,
 	  VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T


------------------------------------------------------------------------
Wyje¿d¿asz na wakacje? Zaplanuj trasê z map24. 
http://map24.interia.pl

Re: [PATCH] Longhaul - There are limits

[Dave Jones]

On Mon, Jul 03, 2006 at 07:18:12AM +0200, Rafał Bilski wrote:
 > Changes in Kconfig:
 > 1. ACPI_PROCESSOR - next patch need ACPI C3 state working,
 > 2. !X86_UP_APIC - (un)patched "longhaul" isn't APIC compatible,
 > 3. !SMP - (un)patched "longhaul" isn't SMP compatible. First 
 > step would be APIC support. Second - per CPU private data.
 > 
 > Signed-off-by: Rafał Bilski <rafalbilski@interia.pl>
 > 
 > ---
 > 
 > --- linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/Kconfig.orig	2006-06-18 03:49:35.000000000 +0200
 > +++ linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/Kconfig	2006-07-02 19:48:40.000000000 +0200
 > @@ -202,7 +202,7 @@ config X86_LONGRUN
 >  config X86_LONGHAUL
 >  	tristate "VIA Cyrix III Longhaul"
 >  	select CPU_FREQ_TABLE
 > -	depends on BROKEN
 > +	depends on !SMP && !X86_UP_APIC && ACPI_PROCESSOR
 >  	help
 >  	  This adds the CPUFreq driver for VIA Samuel/CyrixIII,
 >  	  VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T

It's not unfeasible for an SMP kernel to be run on UP hardware,
(and several distros are shipping SMP kernels as default)
so I'm in two minds about removing the !SMP check, and making it be a

	if (num_online_cpus() > 1)
		return -ENODEV;

in the init routine.

Thoughts?

		Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] Longhaul - There are limits

[Rafał Bilski]

> [...]
> 
> It's not unfeasible for an SMP kernel to be run on UP hardware,
> (and several distros are shipping SMP kernels as default)
> so I'm in two minds about removing the !SMP check, and making it be a
> 
> 	if (num_online_cpus() > 1)
> 		return -ENODEV;
> 
> in the init routine.
> 
> Thoughts?
> 
> 		Dave
> 

It is good idea, but I think there should be check for APIC too, 
but I don't know how to make it. !X86_UP_APIC is for non SMP 
kernels only. It is possible that in this case there will be 
SMP kernel running on single processor with APIC enabled. 
I don't know much about APIC, but as far I know we are poking 
PIC registers direcly and in such case not all interrupts will
be disabled.

Rafa³


------------------------------------------------------------------------
Znajd¼ krótsz± drogê do pracy!
http://map24.interia.pl - interaktywny planer podró¿y.

Re: [PATCH] Longhaul - There are limits

[Dave Jones]

On Mon, Jul 03, 2006 at 06:00:07PM +0200, Rafał Bilski wrote:

 > > It's not unfeasible for an SMP kernel to be run on UP hardware,
 > > (and several distros are shipping SMP kernels as default)
 > > so I'm in two minds about removing the !SMP check, and making it be a
 > > 
 > > 	if (num_online_cpus() > 1)
 > > 		return -ENODEV;
 > > 
 > > in the init routine.
 > > 
 > > Thoughts?
 > > 
 > > 		Dave
 > > 
 > 
 > It is good idea, but I think there should be check for APIC too, 
 > but I don't know how to make it. !X86_UP_APIC is for non SMP 
 > kernels only. It is possible that in this case there will be 
 > SMP kernel running on single processor with APIC enabled. 
 > I don't know much about APIC, but as far I know we are poking 
 > PIC registers direcly and in such case not all interrupts will
 > be disabled.

I wonder if this could be solved with something as trivial as..

	if (cpu_has_apic)
		disable_local_APIC()

	...

	if (cpu_has_apic)
		enable_local_APIC()

We should probably also avoid touching the PIC if we're in APIC mode
with something like..

    if (pic_mode == 1) {
		...
		PIC poking goes here..
	}

(Will also need to EXPORT_SYMBOL(pic_mode) from mpparse.c)

		Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] Longhaul - There are limits

[Rafał Bilski]

>  > It is good idea, but I think there should be check for APIC too, 
>  > but I don't know how to make it. !X86_UP_APIC is for non SMP 
>  > kernels only. It is possible that in this case there will be 
>  > SMP kernel running on single processor with APIC enabled. 
>  > I don't know much about APIC, but as far I know we are poking 
>  > PIC registers direcly and in such case not all interrupts will
>  > be disabled.
> 
> I wonder if this could be solved with something as trivial as..
> 
> 	if (cpu_has_apic)
> 		disable_local_APIC()
> 
> 	...
> 
> 	if (cpu_has_apic)
> 		enable_local_APIC()
> [...]

Wow! But I don't see this symbols exported to modules.
There are functions lapic_suspend / lapic_resume in apic dev 
interface, but do this functions do what we need?

> We should probably also avoid touching the PIC if we're in APIC mode
> with something like..
> 
>     if (pic_mode == 1) {
> 		...
> 		PIC poking goes here..
> 	}
> 
> (Will also need to EXPORT_SYMBOL(pic_mode) from mpparse.c)
> 
> 		Dave
> 

We really need to touch PIC. If we can't then we can't change frequency.

Rafa³


------------------------------------------------------------------------
Wyje¿d¿asz na wakacje? Zaplanuj trasê z map24. 
http://map24.interia.pl

Re: [PATCH] Longhaul - There are limits

[Rafał Bilski]

> [...]
> I wonder if this could be solved with something as trivial as..
> [...]

I just found this:
"The local APIC is enabled at boot-time and can be disabled by 
clearing bit 11 of IA32_APIC_BASE_MSR (the CPU then receives its 
interrupts directly from a 8259-compatible PIC."
So simple?

Rafa³


------------------------------------------------------------------------
Interaktywne mapy miast na http://map24.interia.pl

Re: [PATCH] Longhaul - There are limits

[Rafał Bilski]

> [...]
> I wonder if this could be solved with something as trivial as..
> [...]
> 
> 		Dave

It is. Please ignore previous patches. Changing code.

Rafa³

------------------------------------------------------------------------
Znajd¼ krótsz± drogê do pracy!
http://map24.interia.pl - interaktywny planer podró¿y.

[PATCH] Longhaul - There are limits

[Rafał Bilski]

Hello!

There is no need to worry about local APIC.
There is need to worry about I/O APIC, because I/O APIC 
is replacing good old 8259. Acording to Nehemiah datasheet VIA is 
using 3-wire bus to connect local APIC to I/O APIC.

"[...] When IA32_APIC_BASE[11] is set to 0, processor APICs based on the 3-wire APIC
 bus cannot be generally re-enabled until a system hardware reset. The 3-wire bus
 looses track of arbitration that would be necessary for complete re-enabling. Certain
 (local) APIC functionality can be enabled. [...]"

So we must set disable bit for each interrupt in I/O APIC registers. 
Same situation as for PIC - we must poke registers direcly.
How to do this? I don't know. So at the moment it is better 
to fail.

Signed-off-by: Rafa³ Bilski <rafalbilski@interia.pl>

---

diff -uprN -X linux-2.6.17-git20-vanilla/Documentation/dontdiff linux-2.6.17-git20-vanilla/arch/i386/kernel/cpu/cpufreq/Kconfig linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/Kconfig
--- linux-2.6.17-git20-vanilla/arch/i386/kernel/cpu/cpufreq/Kconfig	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/Kconfig	2006-07-04 16:03:36.000000000 +0200
@@ -202,7 +202,7 @@ config X86_LONGRUN
 config X86_LONGHAUL
 	tristate "VIA Cyrix III Longhaul"
 	select CPU_FREQ_TABLE
-	depends on BROKEN
+	depends on ACPI_PROCESSOR
 	help
 	  This adds the CPUFreq driver for VIA Samuel/CyrixIII,
 	  VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T
diff -uprN -X linux-2.6.17-git20-vanilla/Documentation/dontdiff linux-2.6.17-git20-vanilla/arch/i386/kernel/cpu/cpufreq/longhaul.c linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/longhaul.c
--- linux-2.6.17-git20-vanilla/arch/i386/kernel/cpu/cpufreq/longhaul.c	2006-07-02 19:41:52.000000000 +0200
+++ linux-2.6.17-git20/arch/i386/kernel/cpu/cpufreq/longhaul.c	2006-07-04 17:11:21.000000000 +0200
@@ -534,6 +534,15 @@ static int __init longhaul_cpu_init(stru
 	char *cpuname=NULL;
 	int ret;
 
+#ifdef CONFIG_SMP
+	if (num_online_cpus() > 1)
+		return -ENODEV;
+#endif
+#ifdef CONFIG_X86_IO_APIC
+	if (cpu_has_apic)
+		return -ENODEV;
+#endif
+
 	switch (c->x86_model) {
 	case 6:
 		cpu_model = CPU_SAMUEL;

------------------------------------------------------------------------
Interaktywne mapy miast na http://map24.interia.pl/

Re: [PATCH] Longhaul - There are limits

[Dave Jones]

On Tue, Jul 04, 2006 at 05:50:57PM +0200, Rafał Bilski wrote:
 > Hello!
 > 
 > There is no need to worry about local APIC.
 > There is need to worry about I/O APIC, because I/O APIC 
 > is replacing good old 8259. Acording to Nehemiah datasheet VIA is 
 > using 3-wire bus to connect local APIC to I/O APIC.
 > 
 > "[...] When IA32_APIC_BASE[11] is set to 0, processor APICs based on the 3-wire APIC
 >  bus cannot be generally re-enabled until a system hardware reset. The 3-wire bus
 >  looses track of arbitration that would be necessary for complete re-enabling. Certain
 >  (local) APIC functionality can be enabled. [...]"
 > 
 > So we must set disable bit for each interrupt in I/O APIC registers. 
 > Same situation as for PIC - we must poke registers direcly.
 > How to do this? I don't know. So at the moment it is better 
 > to fail.

Ok, I'll merge this up. We can revisit the APIC stuff later.

Thanks,

		Dave

-- 
http://www.codemonkey.org.uk