linux-toradex.git/drivers/xen/xen-acpi-processor.c, branch v3.12.33

xen: Convert printks to pr_

2013-06-28T15:19:58+00:00

Convert printks to pr_ (excludes printk(KERN_DEBUG...)
to be more consistent throughout the xen subsystem.

Add pr_fmt with KBUILD_MODNAME or "xen:" KBUILD_MODNAME
Coalesce formats and add missing word spaces
Add missing newlines
Align arguments and reflow to 80 columns
Remove DRV_NAME from formats as pr_fmt adds the same content

This does change some of the prefixes of these messages
but it also does make them more consistent.

Signed-off-by: Joe Perches 
Signed-off-by: Konrad Rzeszutek Wilk

xen: resolve section mismatch warnings in xen-acpi-processor

2013-04-19T14:44:23+00:00

The following resolves a section mismatch warning below in xen-acpi-processor introduced by
3fac10145b766a2244422788f62dc35978613fd8 [13/13] xen: Re-upload processor PM data to hypervisor after S3 resume (v2)

Warning:
WARNING: drivers/xen/built-in.o(.text+0x2056a): Section mismatch in reference from the function xen_upload_processor_pm_data() to the function .init.text:read_acpi_id()
   The function xen_upload_processor_pm_data() references
   the function __init read_acpi_id().
   This is often because xen_upload_processor_pm_data lacks a __init
   annotation or the annotation of read_acpi_id is wrong.

Reported-by: kbuild test robot 

Signed-off-by: Ben Guthro 
Signed-off-by: Konrad Rzeszutek Wilk

xen: Re-upload processor PM data to hypervisor after S3 resume (v2)

2013-04-17T14:43:56+00:00

Upon resume, it was found that ACPI C-states were missing from non-boot CPUs.
This change registers a syscore_ops handler for this case, and re-uploads the
PM information to the hypervisor to properly reset the C-state on these
processors.

v2:
v1 did not go through the check_acpi_ids() code-path, and missed some cases when
xen was running with the dom0_max_vcpus= command line parameter.

Signed-Off-By: Ben Guthro 
[v3: Ate some tabs, s/printk/pr_info/]
Signed-off-by: Konrad Rzeszutek Wilk

xen/acpi-processor: Don't dereference struct acpi_processor on all CPUs.

2013-03-22T12:23:11+00:00

With git commit c705c78c0d0835a4aa5d0d9a3422e3218462030c
"acpi: Export the acpi_processor_get_performance_info" we are now
using a different mechanism to access the P-states.

The acpi_processor per-cpu structure is set and filtered by the
core ACPI code which shrinks the per_cpu contents to only online CPUs.
In the past we would call acpi_processor_register_performance()
which would have not tried to dereference offline cpus.

With the new patch and the fact that the loop we take is for
for_all_possible_cpus we end up crashing on some machines.
We could modify the loop to be for online_cpus - but all the other
loops in the code use possible_cpus (for a good reason) - so lets
leave it as so and just check if per_cpu(processor) is NULL.

With this patch we will bypass the !online but possible CPUs.
This fixes:

IP: [] xen_acpi_processor_init+0x1b6/0xe01 [xen_acpi_processor]
PGD 4126e6067 PUD 4126e3067 PMD 0
Oops: 0002 [#1] SMP
Pid: 432, comm: modprobe Not tainted 3.9.0-rc3+ #28 To be filled by O.E.M. To be filled by O.E.M./M5A97
RIP: e030:[]  [] xen_acpi_processor_init+0x1b6/0xe01 [xen_acpi_processor]
RSP: e02b:ffff88040c8a3ce8  EFLAGS: 00010282
.. snip..
Call Trace:
 [] ? read_acpi_id+0x12b/0x12b [xen_acpi_processor]
 [] do_one_initcall+0x12a/0x180
 [] load_module+0x1cd3/0x2870
 [] ? ddebug_proc_open+0xc0/0xc0
 [] sys_init_module+0xd7/0x120
 [] system_call_fastpath+0x16/0x1b

on some machines.

Signed-off-by: Konrad Rzeszutek Wilk

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

cpuidle / ACPI : remove power from acpi_processor_cx structure

2012-09-05T13:13:48+00:00

Remove the unused power field from struct struct acpi_processor_cx.

[rjw: Modified changelog.]

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

xen/acpi: Fix potential memory leak.

2012-07-19T19:51:42+00:00

Coverity points out that we do not free in one case the
pr_backup - and sure enough we forgot.

Found by Coverity (CID 401970)

Signed-off-by: Konrad Rzeszutek Wilk

xen-acpi-processor: Add missing #include

2012-05-17T17:03:02+00:00

This file depends on , but the dependency was hidden due
to:  ->  ->  -> 

With the removal of , this exposed the missing

Reported-by: Ingo Molnar 
Cc: Len Brown 
Cc: Konrad Rzeszutek Wilk 
Cc: Jeremy Fitzhardinge 
Cc: Jarkko Sakkinen 
Signed-off-by: H. Peter Anvin

xen/acpi: Workaround broken BIOSes exporting non-existing C-states.

2012-04-27T02:07:28+00:00

We did a similar check for the P-states but did not do it for
the C-states. What we want to do is ignore cases where the DSDT
has definition for sixteen CPUs, but the machine only has eight
CPUs and we get:
xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14

Reported-by: Tobias Geiger 
Signed-off-by: Konrad Rzeszutek Wilk

xen/acpi: Remove the WARN's as they just create noise.

2012-03-21T16:17:22+00:00

When booting the kernel under machines that do not have P-states
we would end up with:

------------[ cut here ]------------
 WARNING: at drivers/xen/xen-acpi-processor.c:504
 xen_acpi_processor_init+0x286/0
 x2e0()
 Hardware name: ProLiant BL460c G6
 Modules linked in:
 Pid: 1, comm: swapper Not tainted 2.6.39-200.0.3.el5uek #1
 Call Trace:
  [] ? xen_acpi_processor_init+0x286/0x2e0
  [] warn_slowpath_common+0x90/0xc0
  [] ? check_acpi_ids+0x1e0/0x1e0
  [] warn_slowpath_null+0x1a/0x20
  [] xen_acpi_processor_init+0x286/0x2e0
  [] ? check_acpi_ids+0x1e0/0x1e0
  [] do_one_initcall+0xe8/0x130

.. snip..

Which is OK - the machines do not have P-states, so we fail to register
to process the _PXX states. But there is no need to WARN the user
of it.

Oracle BZ# 13871288
Signed-off-by: Konrad Rzeszutek Wilk