- 22 Jan, 2013 4 commits
-
-
Rafael J. Wysocki authored
After the only user of acpi_power_on_resources(), acpi_bus_init_power(), has been changed to avoid calling it for state equal to ACPI_STATE_D3_COLD, it doesn't have to special case that state any more. For this reason, modify the checks in acpi_power_on_resources() so that it returns -EINVAL for ACPI_STATE_D3_COLD as it should. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The ACPI specitication (ACPI 5, Sections 7.2.8 - 7.2.11) requires that the _PSn (n = 0..3) method, if present, be executed after the power resources for the given device power state have been set appropriately. However, acpi_device_set_power() does that only if the new power state is going to be higher-power (lower-number) than the power state the device is in already. Otherwise, the ordering is reverse to protect against situations in which _PSn might access device registers unavailable after configuring the power resources for power state Dn (D3 meaning D3hot). Such situations are very unlikely to happen, though, and _PSn may actually be implemented with the assumption that power resources have been configured for power state Dn in advance, so change the code to follow the specification literally. This change was previously porposed in a different form by Lv Zheng. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
To reduce code duplication between acpi_device_set_power() and acpi_bus_init_power(), introduce a new helper function for executing ACPI devices' _PSn (n = 0..3) methods, acpi_dev_pm_explicit_set(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The ACPI specification requires the _PSC method to be present under a device object if its power state cannot be inferred from the states of power resources used by it (ACPI 5, Section 7.6.2). However, it also requires that (for power states D0-D2 and D3hot) if the _PSn (n = 0, 1, 2, 3) method is present under the device object, it also must be executed after the power resources have been set appropriately for the device to go into power state Dn (D3 means D3hot in this case). Thus it is not clear from the specification whether or not the _PSn method should be executed if the initial configuraion of power resources used by the device indicates power state Dn and the _PSC method is not present. The current implementation of acpi_bus_init_power() is based on the assumption that it should not be necessary to execute _PSn in the above situation, but experience shows that in fact that assumption need not be satisfied. For this reason, make acpi_bus_init_power() always execute _PSn if the initial configuration of device power resources indicates power state Dn. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 19 Jan, 2013 4 commits
-
-
Rafael J. Wysocki authored
CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset, although that is unusual. For this reason, make the headers of functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set simultaneously depend on that combination of Kconfig options instead of CONFIG_ACPI_SLEEP. This fixes a build problem reported by Randy Dunlap. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Mika Westerberg authored
It is there probably due to an accident, get rid of it so that the format is consistent across the file. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Move some suspend-specific and hibernate-specific code from acpi_sleep_init() into separate functions to get rid of explicit #ifdefs in acpi_sleep_init(). Use pr_info() to start and pr_cont() to continue printing the supported ACPI sleep states line. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Move ACPI device power management functions from drivers/acpi/bus.c to drivers/acpi/device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 Jan, 2013 16 commits
-
-
Rafael J. Wysocki authored
The function returning string representations of ACPI device power states, state_string((), is now static, because it is only used internally in drivers/acpi/bus.c. However, it will be used outside of that file going forward, so rename it to acpi_power_state_string(), add a kerneldoc comment to it and add its header to acpi_bus.h. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The function used for retrieving ACPI device power states, __acpi_bus_get_power(), is now static, because it is only used internally in drivers/acpi/bus.c. However, it will be used outside of that file going forward, so rename it to acpi_device_get_power(), in analogy with acpi_device_set_power(), add a kerneldoc comment to it and add its header to acpi_bus.h. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
During power transitions into D3cold from any shallower power states we are supposed to transition the device into D3hot and remove power from it afterward, but the current code in acpi_device_set_power() doesn't work this way. At the same time, though, we need to be careful enough to preserve backwards compatibility for systems that don't distinguish between D3hot and D3cold (e.g. designed before ACPI 4). Modify acpi_device_set_power() so that it works in accordance with the expectations in both cases. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The system level attribute of ACPI power resources is the lowest system sleep level (S0, S2 etc.) in which the given resource can be "on" (ACPI 5.0, Section 7.1). On the other hand, wakeup power resources have to be "on" for devices depending on them to be able to signal wakeup. Therefore devices cannot wake up the system from sleep states higher than the minimum of the system level attributes of their wakeup power resources. Use the wakeup power resources' system level values to get the deepest system sleep state (highest system sleep level) the given device can wake up the system from. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Some ACPI power resource initialization errors, like memory allocation errors, are not taken into account appropriately in some cases, which may lead to a device having an incomplete list of power resources that one of its power states depends on, for one example. Rework the power resource initialization and namespace scanning code so that power resource initialization errors are treated more seriously. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The lists of ACPI power resources are currently extracted in two different ways, one for wakeup power resources and one for power resources that device power states depend on. There is no reason why it should be done differently in those two cases, so introduce a common routine for extracting power resources lists from data returned by AML, acpi_extract_power_resources(), and make the namespace scanning code use it for both wakeup and device power states power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The local variables in acpi_bus_get_power_flags() need not be initialized upfront, so change the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
To reduce indentation level and improve code readability, move the initialization code related to device power states from acpi_bus_get_power_flags() to a new routine, acpi_bus_init_power_state(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of wakeup power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of power resources that power states of devices depend on (analogous changes will be done separately for power resources used for wakeup). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI power resource objects have struct acpi_device components, but they are only used for registering those resources in the device hierarchy. In particular, power state information stored in them is completely useless (amnong other things, because the power resources "devices" are not power manageable), so there is no reason for the power resources management code to keep it up to date. Remove the code updating device power states of power resources from drivers/acpi/power.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The ACPI power resources driver is not very useful, because the only thing it really does is to restore the state of the power resources that were "on" before system suspend or hibernation, but that may be achieved in a different way. Drop the ACPI power resources driver entirely and add acpi_resume_power_resources() that will walk the list of all registered power resources during system resume and turn on the ones that were "on" before the preceding system suspend or hibernation. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI power resources need to be treated in a special way by the namespace scanning code, because they need to be ready to use as soon as they have been discovered (even before registering ACPI device nodes using them for power management). For this reason, it doesn't make sense to separate the preparation of struct acpi_device objects representing them in the device hierarchy from the creation of struct acpi_power_resource objects actually used for power resource manipulation. Accordingly, it doesn't make sense to define non-empty .add() and .remove() callbacks in the power resources "driver" (in fact, it is questionable whether or not it is useful to register such a "driver" at all). Rearrange the code in scan.c and power.c so that power resources are initialized entirely by one routine, acpi_add_power_resource(), that also prepares their struct acpi_device objects and registers them with the driver core, telling it to use a special release routine, acpi_release_power_resource(), for removing objects that represent power resources from memory. Make the ACPI namespace scanning code in scan.c always use acpi_add_power_resource() for preparing and registering objects that represent power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Simplify the code preparing struct acpi_device objects for registration by removing useless code, moving different pieces of code into the functions they belong to and making a couple of int functions always returning 0 void. This also fixes a possible memory leak in ACPI device registration error code path by making acpi_device_register() detach data from device->handle if device_register() fails and prepares the scanning code for special-casing ACPI power resources (next patch). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Commit 0090def6 (ACPI: Add interface to register/unregister device to/from power resources) made it possible to indicate to the ACPI core that if the given device depends on any power resources, then it should be resumed as soon as all of the power resources required by it to transition to the D0 power state have been turned on. Unfortunately, however, this was a mistake, because all devices depending on power resources should be treated this way (i.e. they should be resumed when all power resources required by their D0 state have been turned on) and for the majority of those devices the ACPI core can figure out by itself which (physical) devices depend on what power resources. For this reason, replace the code added by commit 0090def6 with a new, much more straightforward, mechanism that will be used internally by the ACPI core and remove all references to that code from kernel subsystems using ACPI. For the cases when there are (physical) devices that should be resumed whenever a not directly related ACPI device node goes into D0 as a result of power resources configuration changes, like in the SATA case, add two new routines, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), allowing subsystems to manage such dependencies. Convert the SATA subsystem to use the new functions accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The following commits depend on the 'acpi-scan' material.
-
- 15 Jan, 2013 6 commits
-
-
Yinghai Lu authored
Should use acpi_device pointer directly instead of use handle and get the device pointer again later. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Make acpi_bus_trim() work in analogy with acpi_bus_scan() and carry out two passes such that ACPI drivers will be detached from device nodes being removed in the first pass and the device nodes themselves will be removed in the second pass. For this purpose split the driver unregistration out of acpi_bus_remove() into a new routine, acpi_bus_device_detach(), that will be executed by acpi_bus_trim() in the additional first pass as a post-order callback. This is necessary, because some ACPI drivers' .remove() routines unregister struct device objects associated with the ACPI device nodes being removed and that needs to happen while the ACPI device nodes are still around (for example, in case they need to be used for power management or similar things at that time). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
Rafael J. Wysocki authored
The current acpi_bus_trim() implementation is not really straightforward and may be simplified significantly by using acpi_walk_namespace() with acpi_bus_remove() as a post-order callback. Observe that acpi_bus_remove(), as called by acpi_bus_trim(), cannot actually fail, because its first argument is guaranteed not to be NULL thanks to the acpi_bus_get_device() check in acpi_bus_trim(), so simply move the acpi_bus_get_device() check to acpi_bus_remove() and use acpi_walk_namespace() to execute it for every device under start->handle as a post-order callback. The, run it directly for start->handle itself. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
Rafael J. Wysocki authored
All callers of acpi_bus_trim() pass 1 (true) as the second argument of it, so remove that argument entirely and change acpi_bus_trim() to always behave as though it were 1. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
Rafael J. Wysocki authored
Drop the second argument of acpi_device_unregister(), type, which is not used by that function. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
Rafael J. Wysocki authored
The ops field in struct acpi_device is not used anywhere, so remove it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
- 14 Jan, 2013 1 commit
-
-
Jiang Liu authored
With commit f2a33cde55a03 "ACPI: Drop ACPI device .bind() and .unbind() callbacks", acpi_op_bind and acpi_op_unbind are not used any more. So remove them. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 11 Jan, 2013 1 commit
-
-
Mika Westerberg authored
Since device_attach() returns 1 on success (a driver has been bound to the device), the check against its return value in acpi_bus_device_attach() should modified to take that into accout. Make it so. [rjw: Subject and changelog.] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 Jan, 2013 1 commit
-
-
Linus Torvalds authored
-
- 09 Jan, 2013 6 commits
-
-
git://git.linaro.org/people/rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King. * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: 7616/1: cache-l2x0: aurora: Use writel_relaxed instead of writel ARM: 7615/1: cache-l2x0: aurora: Invalidate during clean operation with WT enable ARM: 7614/1: mm: fix wrong branch from Cortex-A9 to PJ4b ARM: 7612/1: imx: Do not select some errata that depends on !ARCH_MULTIPLATFORM ARM: 7611/1: VIC: fix bug in VIC irqdomain code ARM: 7610/1: versatile: bump IRQ numbers ARM: 7609/1: disable errata work-arounds which access secure registers ARM: 7608/1: l2x0: Only set .set_debug on PL310 r3p0 and earlier
-
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bpLinus Torvalds authored
Pull EDAC fixes from Borislav Petkov: "Two error path fixes causing a crash and a Kconfig fix for an issue which spilled all EDAC suboptions into the 'Device Drivers' menu." * tag 'edac_fixes_for_3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp: EDAC: Cleanup device deregistering path EDAC: Fix EDAC Kconfig menu EDAC: Fix kernel panic on module unloading
-
Linus Torvalds authored
The check for a pmd being in the process of being split was dropped by mistake by commit d10e63f2 ("mm: numa: Create basic numa page hinting infrastructure"). Put it back. Reported-by: Dave Jones <davej@redhat.com> Debugged-by: Hillf Danton <dhillf@gmail.com> Acked-by: Andrea Arcangeli <aarcange@redhat.com> Acked-by: Mel Gorman <mgorman@suse.de> Cc: Kirill Shutemov <kirill@shutemov.name> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Marc Dionne authored
Commit 3a50597d ("KEYS: Make the session and process keyrings per-thread") removed the definition of the thread_group_cred structure, but left a now unused pointer in struct cred. Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "People are back from the holiday breaks, and it shows. Here are a bunch of fixes for a number of platforms: - A couple of small fixes for Nomadik - A larger set of changes for kirkwood/mvebu - uart driver selection, dt clocks, gpio-poweroff fixups, a few __init annotation fixes and some error handling improvement in their xor dma driver. - i.MX had a couple of minor fixes (and a critical one for flexcan2 clock setup) - MXS has a small board fix and a framebuffer bugfix - A set of fixes for Samsung Exynos, fixing default bootargs and some Exynos5440 clock issues - A set of OMAP changes including PM fixes and a few sparse warning fixups All in all a bit more positive code delta than we'd ideally want to see here, mostly from the OMAP PM changes, but nothing overly crazy." * tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (44 commits) ARM: clps711x: Fix bad merge of clockevents setup ARM: highbank: save and restore L2 cache and GIC on suspend ARM: highbank: add a power request clear ARM: highbank: fix secondary boot and hotplug ARM: highbank: fix typos with hignbank in power request functions ARM: dts: fix highbank cpu mpidr values ARM: dts: add device_type prop to cpu nodes on Calxeda platforms ARM: mx5: Fix MX53 flexcan2 clock ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array pinctrl: mvebu: make pdma clock on dove mandatory ARM: Dove: Add pinctrl clock to DT dma: mv_xor: fix error handling for clocks dma: mv_xor: fix error handling of mv_xor_channel_add() arm: mvebu: Add missing ; for cpu node. arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces arm: mvebu: Armada XP MV78230 has two cores, not one clk: mvebu: Remove inappropriate __init tagging ARM: Kirkwood: Use fixed-regulator instead of board gpio call ARM: Kirkwood: Fix missing sdio clock ARM: Kirkwood: Switch TWSI1 of 88f6282 to DT clock providers ...
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm update from Dave Airlie: "Exynos and Radeon mostly, with a dma-buf and ttm fix thrown in. It's a bit big but its mostly exynos license fix ups and I'd rather not hold those up since its legally stuff. Radeon has a couple of fixes from dma engine work, TTM is just a locking fix, and dma-buf fix has been hanging around and I finally got a chance to review it." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (30 commits) drm/ttm: fix fence locking in ttm_buffer_object_transfer drm/prime: drop reference on imported dma-buf come from gem drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks drm/exynos: move finish page flip to a common place drm/exynos: fimd: modify condition in fimd resume drm/radeon: fix DMA CS parser for r6xx linear copy packet drm/radeon: split r6xx and r7xx copy_dma functions drm/exynos: Use devm_clk_get in exynos_drm_gsc.c drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_gsc.c drm/exynos: Use devm_clk_get in exynos_drm_rotator.c drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c drm/exynos: Remove unnecessary devm_* freeing APIs in exynos_drm_rotator.c drm/exynos: Use devm_clk_get in exynos_drm_fimc.c drm/exynos: Remove redundant NULL check drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_fimc.c drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c drm/exynos: fix gem buffer allocation type checking drm/exynos: remove needless parenthesis. drm/exynos: fix incorrect interrupt induced by m2m operation. ...
-
- 08 Jan, 2013 1 commit
-
-
Olof Johansson authored
Merge tag 'omap-for-v3.8-rc2/fixes-signed-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes From Tony Lindgren: The biggest change is a fix to deal with different power state on omap2 registers that causes issues trying to use common PM code. Also fix few incorrect registers, and an issue for omap1 USB, and few sparse fixes for issues that sneaked in with all the clean-up. * tag 'omap-for-v3.8-rc2/fixes-signed-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array ARM: OMAP1: fix USB configuration use-after-release ARM: OMAP2/3: PRM: fix bogus OMAP2xxx powerstate return values ARM: OMAP3: clock data: Add missing enable/disable for EMU clock ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets ARM: OMAP4: PRM: Correct reset source map ARM: OMAP: SRAM: resolve sparse warnings ARM: OMAP AM33xx: hwmod data: resolve sparse warnings ARM: OMAP: 32k counter: resolve sparse warnings Signed-off-by: Olof Johansson <olof@lixom.net>
-