linux-toradex.git/drivers/acpi/internal.h, branch v3.11

Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"

2013-07-26T12:59:20+00:00

We attempted to address a regression introduced by commit a57f7f9
(ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
ACPI video backlight support doesn't work on a number of systems,
because the relevant AML methods in the ACPI tables in their BIOSes
become useless after the BIOS has been told that the OS is compatible
with Windows 8.  That problem is tracked by the bug entry at:

https://bugzilla.kernel.org/show_bug.cgi?id=51231

Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
expects Windows 8) introduced for this purpose essentially prevented
the ACPI backlight support from being used if the BIOS had been told
that the OS was compatible with Windows 8 and the i915 driver was
loaded, in which case the backlight would always be handled by i915.
Unfortunately, however, that turned out to cause problems with
backlight to appear on multiple systems with symptoms indicating that
i915 was unable to control the backlight on those systems as
expected.

For this reason, revert commit 8c5bd7a, but leave the function
acpi_video_backlight_quirks() introduced by it, because another
commit on top of it uses that function.

References: https://lkml.org/lkml/2013/7/21/119
References: https://lkml.org/lkml/2013/7/22/261
References: https://lkml.org/lkml/2013/7/23/429
References: https://lkml.org/lkml/2013/7/23/459
References: https://lkml.org/lkml/2013/7/23/81
References: https://lkml.org/lkml/2013/7/24/27
Reported-and-tested-by: James Hogan 
Reported-and-tested-by: Kamal Mostafa 
Reported-and-tested-by: Jörg Otte 
Reported-and-tested-by: Steven Newbury 
Reported-by: Martin Steigerwald 
Reported-by: Kalle Valo 
Tested-by: Joerg Platte 
Signed-off-by: Rafael J. Wysocki

ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

2013-07-18T00:08:06+00:00

According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8.  The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".

There's a problem with that approach, however, because simply
avoiding to register the ACPI backlight interface if the firmware
calls _OSI for Windows 8 may not work in the following situations:
 (1) The ACPI backlight interface actually works on the given system
     and the i915 driver is not loaded (e.g. another graphics driver
     is used).
 (2) The ACPI backlight interface doesn't work on the given system,
     but there is a vendor platform driver that will register its
     own, equally broken, backlight interface if not prevented from
     doing so by the ACPI subsystem.
Therefore we need to allow the ACPI backlight interface to be
registered until the i915 driver is loaded which then will unregister
it if the firmware has called _OSI for Windows 8 (or will register
the ACPI video driver without backlight support if not already
present).

For this reason, introduce an alternative function for registering
ACPI video, acpi_video_register_with_quirks(), that will check
whether or not the ACPI video driver has already been registered
and whether or not the backlight Windows 8 quirk has to be applied.
If the quirk has to be applied, it will block the ACPI backlight
support and either unregister the backlight interface if the ACPI
video driver has already been registered, or register the ACPI
video driver without the backlight interface otherwise.  Make
the i915 driver use acpi_video_register_with_quirks() instead of
acpi_video_register() in i915_driver_load().

This change is based on earlier patches from Matthew Garrett,
Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's.

References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Tested-by: Aaron Lu 
Tested-by: Igor Gnatenko 
Tested-by: Yves-Alexis Perez 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Aaron Lu 
Acked-by: Matthew Garrett

Merge branch 'acpi-assorted'

2013-06-28T11:00:38+00:00

* acpi-assorted:
  ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
  ACPI: Add CMOS RTC Operation Region handler support
  ACPI: Remove unused flags in acpi_device_flags
  ACPI: Remove useless initializers
  ACPI / battery: Make sure all spaces are in correct places
  ACPI: add _STA evaluation at do_acpi_find_child()
  ACPI / EC: access user space with get_user()/put_user()

Merge branch 'acpi-hotplug'

2013-06-28T10:58:05+00:00

* acpi-hotplug:
  ACPI: Do not use CONFIG_ACPI_HOTPLUG_MEMORY_MODULE
  ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq
  Memory hotplug: Move alternative function definitions to header
  ACPI / processor: Fix potential NULL pointer dereference in acpi_processor_add()
  Memory hotplug / ACPI: Simplify memory removal
  ACPI / scan: Add second pass of companion offlining to hot-remove code
  Driver core / MM: Drop offline_memory_block()
  ACPI / processor: Pass processor object handle to acpi_bind_one()
  ACPI: Drop removal_type field from struct acpi_device
  Driver core / memory: Simplify __memory_block_change_state()
  ACPI / processor: Initialize per_cpu(processors, pr->id) properly
  CPU: Fix sysfs cpu/online of offlined CPUs
  Driver core: Introduce offline/online callbacks for memory blocks
  ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes
  ACPI / processor: Use common hotplug infrastructure
  ACPI / hotplug: Use device offline/online for graceful hot-removal
  Driver core: Use generic offline/online for CPU offline/online
  Driver core: Add offline/online device operations

ACPI: Add CMOS RTC Operation Region handler support

2013-06-27T19:35:37+00:00

On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and
the EC's _REG methord accesses that region.  Thus an appropriate
address space handler must be registered for that region before the
EC driver is loaded.

Introduce a mechanism for adding CMOS RTC address space handlers.
Register an ACPI scan handler for CMOS RTC devices such that, when
a device of that kind is detected during an ACPI namespace scan, a
common CMOS RTC operation region address space handler will be
installed for it.

References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy 
Signed-off-by: Lan Tianyu 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki

ACPI / dock: Initialize ACPI dock subsystem upfront

2013-06-22T22:59:55+00:00

Commit 3b63aaa70e1 (PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism) introduced an ACPI dock support regression, because it
changed the relative initialization order of the ACPI dock subsystem
and the ACPI-based PCI hotplug (acpiphp).

Namely, the ACPI dock subsystem has to be initialized before
acpiphp_enumerate_slots() is first run, which after commit
3b63aaa70e1 happens during the initial enumeration of the PCI
hierarchy triggered by the initial ACPI namespace scan in
acpi_scan_init().  For this reason, the dock subsystem has to be
initialized before the initial ACPI namespace scan in
acpi_scan_init().

To make that happen, modify the ACPI dock subsystem to be
non-modular and add the invocation of its initialization routine,
acpi_dock_init(), to acpi_scan_init() directly before the initial
namespace scan.

[rjw: Changelog, removal of dock_exit().]
References: https://bugzilla.kernel.org/show_bug.cgi?id=59501
Reported-and-tested-by: Alexander E. Patrakov 
Tested-by: Illya Klymov 
Signed-off-by: Jiang Liu 
Acked-by: Yinghai Lu 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki

dma: acpi-dma: parse CSRT to extract additional resources

2013-05-14T04:53:57+00:00

Since we have CSRT only to get additional DMA controller resources, let's get
rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Vinod Koul

ACPI / processor: Use common hotplug infrastructure

2013-05-12T12:14:32+00:00

Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.

The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure.  It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.

There are a few reasons to make this change.

First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.

Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset).  That is a more desirable behavior than what the current
code does.

Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).

Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).

Tested on my venerable Toshiba Portege R500.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Toshi Kani

ACPI / hotplug: Use device offline/online for graceful hot-removal

2013-05-12T12:14:24+00:00

Modify the generic ACPI hotplug code to be able to check if devices
scheduled for hot-removal may be gracefully removed from the system
using the device offline/online mechanism introduced previously.

Namely, make acpi_scan_hot_remove() handling device hot-removal call
device_offline() for all physical companions of the ACPI device nodes
involved in the operation and check the results.  If any of the
device_offline() calls fails, the function will not progress to the
removal phase (which cannot be aborted), unless its (new) force
argument is set (in case of a failing offline it will put the devices
offlined by it back online).

In support of 'forced' device hot-removal, add a new sysfs attribute
'force_remove' that will reside under /sys/firmware/acpi/hotplug/.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Toshi Kani

Merge branch 'acpi-lpss'

2013-04-27T23:53:41+00:00

* acpi-lpss:
  ACPI / LPSS: make code less confusing for reader
  ACPI / LPSS: Add support for exposing LTR registers to user space
  ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices