linux/drivers/acpi, branch v3.6

ACPI / PM: Use KERN_DEBUG when no power resources are found

2012-09-14T18:54:44Z

commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link devices which have _PRx, if a device does not have _PRx, a warning message will be printed. This commit is for ZPODD on Intel ZPODD capable platforms, on other platforms, it has no problem if there is no power resource for this device, so a warning here is not appropriate, change it to debug. Reported-by: Borislav Petkov Signed-off-by: Aaron Lu Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

ACPI / PM: Fix resource_lock dead lock in acpi_power_on_device

2012-09-13T22:26:33Z

Commit 0090def("ACPI: Add interface to register/unregister device to/from power resources") used resource_lock to protect the devices list that relies on power resource. It caused a mutex dead lock, as below acpi_power_on ---> lock resource_lock __acpi_power_on acpi_power_on_device acpi_power_get_inferred_state acpi_power_get_list_state ---> lock resource_lock This patch adds a new mutex "devices_lock" to protect the devices list and calls acpi_power_on_device in acpi_power_on, instead of __acpi_power_on, after the resource_lock is released. [rjw: Changed data type of a boolean variable to bool.] Signed-off-by: Lin Ming Signed-off-by: Aaron Lu Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

ACPI / PM: Infer parent power state from child if unknown, v2

2012-09-13T22:26:24Z

It turns out that there are ACPI BIOSes defining device objects with _PSx and without either _PSC or _PRx. For devices corresponding to those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN and their initial power states are regarded as unknown as a result. If such a device is a parent of another power-manageable device, the child cannot be put into a low-power state through ACPI, because __acpi_bus_set_power() refuses to change power states of devices whose parents' power states are unknown. To work around this problem, observe that the ACPI power state of a device cannot be higher-power (lower-number) than the power state of its parent. Thus, if the device's _PSC method or the configuration of its power resources indicates that the device is in D0, the device's parent has to be in D0 as well. Consequently, if the parent's power state is unknown when we've just learned that its child's power state is D0, we can safely set the parent's power.state field to ACPI_STATE_D0. Tested-by: Aaron Lu Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2012-08-21T23:18:49Z

Alex writes: "This is the current set of radeon fixes for 3.6. Nothing too major. Highlights: - fix vbios fetch on pure uefi systems - fix vbios fetch on thunderbolt systems - MSAA fixes - lockup timeout fix - modesetting fix" * 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/ss: use num_crtc rather than hardcoded 6 Revert "drm/radeon: fix bo creation retry path" drm/radeon: split ATRM support out from the ATPX handler (v3) drm/radeon: convert radeon vfct code to use acpi_get_table_with_size ACPI: export symbol acpi_get_table_with_size drm/radeon: implement ACPI VFCT vbios fetch (v3) drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping drm/radeon: fix checking of MSAA renderbuffers on r600-r700 drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700 drm/radeon: init lockup timeout on ring init drm/radeon: avoid turning off spread spectrum for used pll

ACPI: export symbol acpi_get_table_with_size

2012-08-20T15:13:04Z

We need it in the radeon drm module to fetch and verify the vbios image on UEFI systems. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

Merge tag 'pm-for-3.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2012-08-12T18:34:09Z

Pull power management fixes from Rafael J. Wysocki: - Fix for two recent regressions in the generic PM domains framework. - Revert of a commit that introduced a resume regression and is conceptually incorrect in my opinion. - Fix for a return value in pcc-cpufreq.c from Julia Lawall. - RTC wakeup signaling fix from Neil Brown. - Suppression of compiler warnings for CONFIG_PM_SLEEP unset in ACPI, platform/x86 and TPM drivers. * tag 'pm-for-3.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: tpm_tis / PM: Fix unused function warning for CONFIG_PM_SLEEP platform / x86 / PM: Fix unused function warnings for CONFIG_PM_SLEEP ACPI / PM: Fix unused function warnings for CONFIG_PM_SLEEP Revert "NMI watchdog: fix for lockup detector breakage on resume" PM: Make dev_pm_get_subsys_data() always return 0 on success drivers/cpufreq/pcc-cpufreq.c: fix error return code RTC: Avoid races between RTC alarm wakeup and suspend.

ACPI / PM: Fix unused function warnings for CONFIG_PM_SLEEP

2012-08-10T11:35:32Z

According to compiler warnings, several suspend/resume functions in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add #ifdefs to prevent them from being built in that case. Signed-off-by: Rafael J. Wysocki

Merge branches 'delete-gts-bfs', 'misc', 'novell-bugzilla-757888-numa' and 'osc-pcie' into base

2012-08-03T04:31:23Z

ACPI processor: Fix tick_broadcast_mask online/offline regression

2012-08-03T04:25:34Z

In commit 99b725084 "ACPI processor hotplug: Delay acpi_processor_start() call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This patch will restore it back, fixing the tick_broadcast_mask regression: https://lkml.org/lkml/2012/7/30/169 Signed-off-by: Feng Tang Cc: Thomas Renninger Cc: # 3.3+ Reviewed-by: Rafael J. Wysocki Reviewed-by: Deepthi Dharwar Signed-off-by: Len Brown

ACPI: Only count valid srat memory structures

2012-08-03T04:15:53Z

Otherwise you could run into: WARN_ON in numa_register_memblks(), because node_possible_map is zero References: https://bugzilla.novell.com/show_bug.cgi?id=757888 On this machine (ProLiant ML570 G3) the SRAT table contains: - No processor affinities - One memory affinity structure (which is set disabled) CC: Per Jessen CC: Andi Kleen Signed-off-by: Thomas Renninger Signed-off-by: Len Brown