linux-toradex.git/drivers/acpi/processor_perflib.c, branch v3.14.3

ACPI: Clean up inclusions of ACPI header files

2013-12-07T00:03:14+00:00

Replace direct inclusions of ,  and
, which are incorrect, with 
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, ,  and 
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
 includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that  be included
prior to  so that the acpi_pci_root declarations the
latter depends on are always there.  And  which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
 as appropriate.

Signed-off-by: Lv Zheng 
Cc: Greg Kroah-Hartman 
Cc: Matthew Garrett 
Cc: Tony Luck 
Cc: "H. Peter Anvin" 
Acked-by: Bjorn Helgaas  (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk  (Xen stuff)
Signed-off-by: Rafael J. Wysocki

ACPI / processor: Do not request ACPI cpufreq module directly

2013-10-29T23:00:30+00:00

Function acpi_processor_load_module() used by the ACPI processor
driver can only really work if the acpi-cpufreq module is available
when acpi_processor_start() is executed which usually is not the case
for systems loading the processor driver module from an initramfs.

Moreover, that used to be a hackish workaround for module autoloading
issues, but udev loads acpi-cpufreq just fine nowadays, so that
function isn't really necessary any more.  For this reason, drop
acpi_processor_load_module() entirely.

Signed-off-by: Rafael J. Wysocki

ACPI: introduce helper function acpi_has_method()

2013-07-14T23:33:10+00:00

Introduce helper function acpi_has_method() and use it in a number
of places to simplify code.

[rjw: Changelog]
Signed-off-by: Jiang Liu 
Signed-off-by: Rafael J. Wysocki

ACPI / processor: Drop unused variable from processor_perflib.c

2013-06-25T21:05:24+00:00

The count variable in acpi_processor_preregister_performance() is
only initalized as 1 for one CPU and incremented when another CPU
sharing the same dependency domain is found.  It isn't referenced
anywhere else, so drop it.

Signed-off-by: Lan Tianyu 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

acpi: Export the acpi_processor_get_performance_info

2013-03-06T15:00:34+00:00

The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
(cpufreq: handle cpufreq being disabled for all exported function)
tightens the cpufreq API by returning errors when disable_cpufreq()
had been called.

The problem we are hitting is that the module xen-acpi-processor which
uses the ACPI's functions: acpi_processor_register_performance,
acpi_processor_preregister_performance, and acpi_processor_notify_smm
fails at acpi_processor_register_performance with -22.

Note that earlier during bootup in arch/x86/xen/setup.c there is also
an call to cpufreq's API: disable_cpufreq().

This is b/c we want the Linux kernel to parse the ACPI data, but leave
the cpufreq decisions to the hypervisor.

In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
added are now hit and the calls to cpufreq_register_notifier will now
fail. This means that acpi_processor_ppc_init ends up printing:

"Warning: Processor Platform Limit not supported"

and the acpi_processor_ppc_status is not set.

The repercussions of that is that the call to
acpi_processor_register_performance fails right away at:

	if (!(acpi_processor_ppc_status & PPC_REGISTERED))

and we don't progress any further on parsing and extracting the _P*
objects.

The only reason the Xen code called that function was b/c it was
exported and the only way to gather the P-states. But we can also
just make acpi_processor_get_performance_info be exported and not
use acpi_processor_register_performance. This patch does so.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Konrad Rzeszutek Wilk

ACPI: Check MSR valid bit before using P-state frequencies

2013-01-22T12:37:21+00:00

To fix incorrect P-state frequencies which can happen on
some AMD systems f594065faf4f9067c2283a34619fc0714e79a98d
   "ACPI: Add fixups for AMD P-state figures"
introduced a quirk to obtain the correct values by reading
from AMD specific MSRs.

This did cause a regression when running a kernel using that
quirk under Xen which does (currently) not pass through MSR
reads to the HW. Instead the guest gets a 0 in return.
And this seems to cause a failure to initialize the ondemand
governour (hard to say for sure as all P-states appear to run
at the same frequency).

While this should also be fixed in the hypervisor (to allow
a guest to read that MSR), this patch is intended to work
around the issue in the meantime. In discussion it turned out
that indeed real HW/BIOSes may choose to not set the valid bit
and thus mark the P-state as invalid. So this could be considered
a fix for broken BIOSes that also works around the issue on Xen.

Signed-off-by: Stefan Bader 
Cc: 3.7+ 
Acked-by: Borislav Petkov 
Signed-off-by: Rafael J. Wysocki

ACPI: Add fixups for AMD P-state figures

2012-09-09T20:05:02+00:00

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 
Signed-off-by: Rafael J. Wysocki

ACPI: Ignore invalid _PSS entries, but use valid ones

2012-05-08T05:56:37+00:00

The EliteBook 8560W has non-initialized entries in its _PSS ACPI
table. Instead of bailing out when the first non-initialized entry is
found, ignore it and use only  the valid entries. Only bail out if there
is no valid entry at all.

[v3: Fixes suggested by Konrad]

Signed-off-by: Marco Aurelio da Costa 
Signed-off-by: Len Brown

ACPI: Load acpi-cpufreq from processor driver automatically

2012-01-27T00:48:12+00:00

The only left over hole in automatic cpufreq driver loading was the loading
of ACPI cpufreq. This driver should be loaded when ACPI supports a _PDC
method and the CPU vendor wants to use acpi cpufreq.

Simply add a request module call to the acpi processor core driver
when this is true. This seems like the simplest solution for this.

Cc: Len Brown 
Signed-off-by: Andi Kleen 
Signed-off-by: Thomas Renninger 
Acked-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

[CPUFREQ] use dynamic debug instead of custom infrastructure

2011-05-04T15:50:57+00:00

With dynamic debug having gained the capability to report debug messages
also during the boot process, it offers a far superior interface for
debug messages than the custom cpufreq infrastructure. As a first step,
remove the old cpufreq_debug_printk() function and replace it with a call
to the generic pr_debug() function.

How can dynamic debug be used on cpufreq? You need a kernel which has
CONFIG_DYNAMIC_DEBUG enabled.

To enabled debugging during runtime, mount debugfs and

$ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control

for debugging the complete "cpufreq" module. To achieve the same goal during
boot, append

	ddebug_query="module cpufreq +p"

as a boot parameter to the kernel of your choice.

For more detailled instructions, please see
Documentation/dynamic-debug-howto.txt

Signed-off-by: Dominik Brodowski 
Signed-off-by: Dave Jones