fig switch
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Kconfig.x86| 12 +++
drivers/cpufreq/acpi-cpufreq.c | 46 --
2 files c
cpufreq support
after the transition.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/powernow-k8.c | 392 +++---
drivers/cpufreq/powernow-k8.h | 32
3 files changed, 29 insertions
.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/acpi-cpufreq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..70e7173 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
cpufreq modules are often loaded from init scripts that assume that
all recent AMD systems will use powernow-k8.
To inform the user of the change of support and ease the transition
to acpi-cpufreq, emit a warning message.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Kconfig.x86 | 3
From: Matthew Garrett
Some AMD systems may round the frequencies in ACPI tables to 100MHz
boundaries. We can obtain the real frequencies from MSRs, so add a quirk
to fix these frequencies up on AMD systems.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm
Hi,
now the second, revised version of the patch set. I now tested loading
both drivers after each other in several combinations, after two bug
fixes this now works as expected.
I added a patch to move messages from powernow-k8 after the initialization
phase, so it remains silent if driver
Hi,
now the second, revised version of the patch set. I now tested loading
both drivers after each other in several combinations, after two bug
fixes this now works as expected.
I added a patch to move messages from powernow-k8 after the initialization
phase, so it remains silent if driver
From: Matthew Garrett m...@redhat.com
Some AMD systems may round the frequencies in ACPI tables to 100MHz
boundaries. We can obtain the real frequencies from MSRs, so add a quirk
to fix these frequencies up on AMD systems.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre
cpufreq modules are often loaded from init scripts that assume that
all recent AMD systems will use powernow-k8.
To inform the user of the change of support and ease the transition
to acpi-cpufreq, emit a warning message.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq
.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/acpi-cpufreq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..70e7173 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers
without any cpufreq support
after the transition.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/powernow-k8.c | 392 +++---
drivers/cpufreq/powernow
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Kconfig.x86| 12 +++
drivers/cpufreq/acpi-cpufreq.c | 46
patch will re-introduce the cpb knob for compatibility
reasons on AMD CPUs.
Per-CPU boost switching is possible, but not trivial and is thus
postponed to a later patch series.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 11
with hardware P-state control to acpi-cpufreq.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
arch/x86/include/asm/msr-index.h | 2 ++
drivers/cpufreq/Kconfig.x86 | 3 ++-
drivers/cpufreq/acpi-cpufreq.c | 43
not succeed.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/powernow-k8.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 16c7fb6..8ff0621 100644
On 08/22/2012 03:00 AM, Thomas Renninger wrote:
On Monday 20 August 2012 22:49:16 Rafael J. Wysocki wrote:
On Monday, August 20, 2012, Andre Przywara wrote:
On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote:
On Thursday, July 26, 2012, Andre Przywara wrote:
...
If you insist, I can keep
On 08/22/2012 03:00 AM, Thomas Renninger wrote:
On Monday 20 August 2012 22:49:16 Rafael J. Wysocki wrote:
On Monday, August 20, 2012, Andre Przywara wrote:
On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote:
On Thursday, July 26, 2012, Andre Przywara wrote:
...
If you insist, I can keep
On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote:
On Thursday, July 26, 2012, Andre Przywara wrote:
From: Matthew Garrett
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
Would
On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote:
On Thursday, July 26, 2012, Andre Przywara wrote:
From: Matthew Garrett m...@redhat.com
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off
fig switch
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Kconfig.x86| 12 ++
drivers/cpufreq/acpi-cpufreq.c | 46 ++-
2 files c
The new acpi-cpufreq driver supports a system global control switch
to disable the frequency boosting feature of some (x86) CPUs.
Provide documentation about the rationale and the usage.
Signed-off-by: Andre Przywara
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 12
From: Matthew Garrett
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Makefile |2 +-
drivers/cpufreq/powernow-k8.c | 385
control to acpi-cpufreq.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm/msr-index.h |2 +
drivers/cpufreq/acpi-cpufreq.c | 43 -
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/msr
ce the cpb knob for compatibility
reasons on AMD CPUs.
Per-CPU boost switching is possible, but not trivial and is thus
postponed to a later patch series.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/acpi-cpufreq.c | 177
1 files changed, 177 insert
cpufreq support
after the transition.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
drivers/cpufreq/powernow-k8.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index c0e8164..6e35ed2
From: Matthew Garrett
Some AMD systems may round the frequencies in ACPI tables to 100MHz
boundaries. We can obtain the real frequencies from MSRs, so add a quirk
to fix these frequencies up on AMD systems.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm
.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/acpi-cpufreq.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..ea949b8 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq
mostly reworked and documentation for it
has been added. Also there was a need for (yet another) BIOS quirk
on AMD desktop boards.
Signed-off-by: Andre Przywara
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
mostly reworked and documentation for it
has been added. Also there was a need for (yet another) BIOS quirk
on AMD desktop boards.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/acpi-cpufreq.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..ea949b8 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
From: Matthew Garrett m...@redhat.com
Some AMD systems may round the frequencies in ACPI tables to 100MHz
boundaries. We can obtain the real frequencies from MSRs, so add a quirk
to fix these frequencies up on AMD systems.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre
without any cpufreq support
after the transition.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/powernow-k8.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b
for compatibility
reasons on AMD CPUs.
Per-CPU boost switching is possible, but not trivial and is thus
postponed to a later patch series.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/acpi-cpufreq.c | 177
1 files changed, 177
with hardware P-state control to acpi-cpufreq.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
arch/x86/include/asm/msr-index.h |2 +
drivers/cpufreq/acpi-cpufreq.c | 43 -
2 files changed, 39 insertions(+), 6
The new acpi-cpufreq driver supports a system global control switch
to disable the frequency boosting feature of some (x86) CPUs.
Provide documentation about the rationale and the usage.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
Documentation/ABI/testing/sysfs-devices-system-cpu
From: Matthew Garrett m...@redhat.com
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Makefile |2 +-
drivers/cpufreq
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Kconfig.x86| 12 ++
drivers/cpufreq/acpi-cpufreq.c | 46
On 07/25/2012 01:02 PM, Vladimir Davydov wrote:
On 07/25/2012 02:58 PM, Andre Przywara wrote:
On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address
to write the same reply yesterday, but followed the hint in
Alan's previous mail:
# mount --bind /dev/shm/faked_cpuinfo /somepath/proc/cpuinfo
I checked it, it works even with chroots and is not visible from within.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC
to write the same reply yesterday, but followed the hint in
Alan's previous mail:
# mount --bind /dev/shm/faked_cpuinfo /somepath/proc/cpuinfo
I checked it, it works even with chroots and is not visible from within.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC
On 07/25/2012 01:02 PM, Vladimir Davydov wrote:
On 07/25/2012 02:58 PM, Andre Przywara wrote:
On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address
eferably through the container
functionality. I see that you do already massive sysfs filtering and
also /proc/ filtering, so this maybe an option?
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the issues you have?
Regards,
Andre.
--
Andre
the foot, we will not prevent you.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
see that you do already massive sysfs filtering and
also /proc/pid filtering, so this maybe an option?
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the issues you have?
Regards,
Andre.
--
Andre Przywara
AMD-Operating System
901 - 945 of 945 matches
Mail list logo
