Longhaul - There are limits
PATCH 1/1 Longhaul - There are limits
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.
---
arch/i386/kernel/cpu/cpufreq/Kconfig renamed from arch/i386/kernel/cpu/cpufreq/Kconfig.orig +1 -1
@@ -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
Quoted 13 lines · 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 <[email protected]>---
arch/i386/kernel/cpu/cpufreq/Kconfig config X86_LONGRUN · line 208
Quoted 8 lines
arch/i386/kernel/cpu/cpufreq/Kconfig renamed from arch/i386/kernel/cpu/cpufreq/Kconfig.orig +1
-1@@ -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
Signature · 1 line
http://www.codemonkey.org.uk
Quoted 6 lines
[...]
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
Quoted 9 lines
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.
Quoted 14 lines · RafaÅ‚ Bilski
Quoted 4 lines
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
Quoted 9 lines
if (num_online_cpus() > 1) return -ENODEV;in the init routine.
Thoughts?
Dave
Quoted 7 lines
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
Signature · 1 line
http://www.codemonkey.org.uk
Quoted 10 lines
Quoted 7 lines
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..
Quoted 8 lines
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?
Quoted 12 lines
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)frommpparse.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
Quoted 3 lines
[...]
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
Quoted 5 lines
[...]
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.