AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-27 18:55:08 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
bc4d91f699
linux_dsm_epyc7002/drivers/acpi/acpi_lpss.c

748 lines
19 KiB
C
Raw Normal View History

ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
/*
* ACPI support for Intel Lynxpoint LPSS.
*
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
* Copyright (C) 2013, 2014, Intel Corporation
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
* Authors: Mika Westerberg <mika.westerberg@linux.intel.com>
* Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/acpi.h>
#include <linux/clk.h>
#include <linux/clkdev.h>
#include <linux/clk-provider.h>
#include <linux/err.h>
#include <linux/io.h>
#include <linux/platform_device.h>
#include <linux/platform_data/clk-lpss.h>
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
#include <linux/pm_runtime.h>
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
#include <linux/delay.h>
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
#include "internal.h"
ACPI_MODULE_NAME("acpi_lpss");
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
#ifdef CONFIG_X86_INTEL_LPSS
#define LPSS_ADDR(desc) ((unsigned long)&desc)
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
#define LPSS_CLK_SIZE 0x04
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
#define LPSS_LTR_SIZE 0x18
/* Offsets relative to LPSS_PRIVATE_OFFSET */
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
#define LPSS_CLK_DIVIDER_DEF_MASK (BIT(1) | BIT(16))
ACPI / LPSS: Take I2C host controllers out of reset On Intel Baytrail, some I2C host controllers are held in reset when the OS gets control. This causes the driver to fail to detect the hardware properly. Fix this so that we make sure that the I2C host controller is not in reset when the driver gets probe'd. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-17 18:33:39 +07:00
#define LPSS_RESETS 0x04
#define LPSS_RESETS_RESET_FUNC BIT(0)
#define LPSS_RESETS_RESET_APB BIT(1)
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
#define LPSS_GENERAL 0x08
#define LPSS_GENERAL_LTR_MODE_SW BIT(2)
ACPI / LPSS: fix UART Auto Flow Control There is an additional bit in the GENERAL register on newer silicon that needs to be set or UART's RTS pin fails to reflect the flow control settings in the Modem Control Register. This will fix an issue where the RTS pin of the UART stays always at 1.8V, regardless of the register settings. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-09 13:49:20 +07:00
#define LPSS_GENERAL_UART_RTS_OVRD BIT(3)
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
#define LPSS_SW_LTR 0x10
#define LPSS_AUTO_LTR 0x14
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
#define LPSS_LTR_SNOOP_REQ BIT(15)
#define LPSS_LTR_SNOOP_MASK 0x0000FFFF
#define LPSS_LTR_SNOOP_LAT_1US 0x800
#define LPSS_LTR_SNOOP_LAT_32US 0xC00
#define LPSS_LTR_SNOOP_LAT_SHIFT 5
#define LPSS_LTR_SNOOP_LAT_CUTOFF 3000
#define LPSS_LTR_MAX_VAL 0x3FF
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
#define LPSS_TX_INT 0x20
#define LPSS_TX_INT_MASK BIT(1)
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
#define LPSS_PRV_REG_COUNT 9
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
/* LPSS Flags */
#define LPSS_CLK BIT(0)
#define LPSS_CLK_GATE BIT(1)
#define LPSS_CLK_DIVIDER BIT(2)
#define LPSS_LTR BIT(3)
#define LPSS_SAVE_CTX BIT(4)
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
#define LPSS_DEV_PROXY BIT(5)
#define LPSS_PROXY_REQ BIT(6)
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
struct lpss_private_data;
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
struct lpss_device_desc {
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
unsigned int flags;
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
unsigned int prv_offset;
ACPI / LPSS: override SDIO private register space size from ACPI tables The SDIO device in Lynxpoint has its LTR registers reserved for a WiFi device (a child of the SDIO device) in the ACPI namespace even though those registers physically belong to the SDIO device itself. In order to be able to access the SDIO LTR registers from the ACPI LPSS driver for diagnostic purposes we need to use a size override for the SDIO private register space. Add a possibility to override the size of the private register space of an LPSS device provided by the ACPI tables in the ACPI LPSS driver and set the correct size for the SDIO device in there. [rjw: Changelog] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-18 20:51:35 +07:00
size_t prv_size_override;
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
void (*setup)(struct lpss_private_data *pdata);
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
};
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
static struct device *proxy_device;
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
static struct lpss_device_desc lpss_dma_desc = {
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
.flags = LPSS_CLK | LPSS_PROXY_REQ,
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
};
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
struct lpss_private_data {
void __iomem *mmio_base;
resource_size_t mmio_size;
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
unsigned int fixed_clk_rate;
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
struct clk *clk;
const struct lpss_device_desc *dev_desc;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
u32 prv_reg_ctx[LPSS_PRV_REG_COUNT];
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
};
ACPI / LPSS: not using UART RTS override with Auto Flow Control Adding a check for UART Auto Flow Control feature and only enabling the RTS override when it's not supported. RTS override is not needed when Auto Flow Control is used and they shouldn't be used together. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-11 19:19:33 +07:00
/* UART Component Parameter Register */
#define LPSS_UART_CPR 0xF4
#define LPSS_UART_CPR_AFCE BIT(4)
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
static void lpss_uart_setup(struct lpss_private_data *pdata)
{
ACPI / LPSS: fix UART Auto Flow Control There is an additional bit in the GENERAL register on newer silicon that needs to be set or UART's RTS pin fails to reflect the flow control settings in the Modem Control Register. This will fix an issue where the RTS pin of the UART stays always at 1.8V, regardless of the register settings. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-09 13:49:20 +07:00
unsigned int offset;
ACPI / LPSS: not using UART RTS override with Auto Flow Control Adding a check for UART Auto Flow Control feature and only enabling the RTS override when it's not supported. RTS override is not needed when Auto Flow Control is used and they shouldn't be used together. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-11 19:19:33 +07:00
u32 val;
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
ACPI / LPSS: fix UART Auto Flow Control There is an additional bit in the GENERAL register on newer silicon that needs to be set or UART's RTS pin fails to reflect the flow control settings in the Modem Control Register. This will fix an issue where the RTS pin of the UART stays always at 1.8V, regardless of the register settings. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-09 13:49:20 +07:00
offset = pdata->dev_desc->prv_offset + LPSS_TX_INT;
ACPI / LPSS: not using UART RTS override with Auto Flow Control Adding a check for UART Auto Flow Control feature and only enabling the RTS override when it's not supported. RTS override is not needed when Auto Flow Control is used and they shouldn't be used together. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-11 19:19:33 +07:00
val = readl(pdata->mmio_base + offset);
writel(val | LPSS_TX_INT_MASK, pdata->mmio_base + offset);
val = readl(pdata->mmio_base + LPSS_UART_CPR);
if (!(val & LPSS_UART_CPR_AFCE)) {
offset = pdata->dev_desc->prv_offset + LPSS_GENERAL;
val = readl(pdata->mmio_base + offset);
val |= LPSS_GENERAL_UART_RTS_OVRD;
writel(val, pdata->mmio_base + offset);
}
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
}
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
static void byt_i2c_setup(struct lpss_private_data *pdata)
ACPI / LPSS: Take I2C host controllers out of reset On Intel Baytrail, some I2C host controllers are held in reset when the OS gets control. This causes the driver to fail to detect the hardware properly. Fix this so that we make sure that the I2C host controller is not in reset when the driver gets probe'd. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-17 18:33:39 +07:00
{
unsigned int offset;
u32 val;
offset = pdata->dev_desc->prv_offset + LPSS_RESETS;
val = readl(pdata->mmio_base + offset);
val |= LPSS_RESETS_RESET_APB | LPSS_RESETS_RESET_FUNC;
writel(val, pdata->mmio_base + offset);
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
if (readl(pdata->mmio_base + pdata->dev_desc->prv_offset))
pdata->fixed_clk_rate = 133000000;
ACPI / LPSS: Take I2C host controllers out of reset On Intel Baytrail, some I2C host controllers are held in reset when the OS gets control. This causes the driver to fail to detect the hardware properly. Fix this so that we make sure that the I2C host controller is not in reset when the driver gets probe'd. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-17 18:33:39 +07:00
}
ACPI / LPSS: add LPSS device for Wildcat Point PCH INT3438 is the ADSP device on Wildcat Point platform with 2 DW DMA engines built In. The DMA engines are used for DSP FW loading and audio data transferring. These DMA engine probing need the clock, without it, probing may failed and can't go forward. Add LPSS device "INT3438" for Wildcat Point PCH, to provide clock for its ADSP DMA engine probing. Signed-off-by: Jie Yang <yang.jie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-01 08:06:35 +07:00
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
static struct lpss_device_desc lpt_dev_desc = {
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_LTR,
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
.prv_offset = 0x800,
};
static struct lpss_device_desc lpt_i2c_dev_desc = {
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_LTR,
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
.prv_offset = 0x800,
};
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
static struct lpss_device_desc lpt_uart_dev_desc = {
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_LTR,
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
.prv_offset = 0x800,
.setup = lpss_uart_setup,
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
};
static struct lpss_device_desc lpt_sdio_dev_desc = {
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
.flags = LPSS_LTR,
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
.prv_offset = 0x1000,
ACPI / LPSS: override SDIO private register space size from ACPI tables The SDIO device in Lynxpoint has its LTR registers reserved for a WiFi device (a child of the SDIO device) in the ACPI namespace even though those registers physically belong to the SDIO device itself. In order to be able to access the SDIO LTR registers from the ACPI LPSS driver for diagnostic purposes we need to use a size override for the SDIO private register space. Add a possibility to override the size of the private register space of an LPSS device provided by the ACPI tables in the ACPI LPSS driver and set the correct size for the SDIO device in there. [rjw: Changelog] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-18 20:51:35 +07:00
.prv_size_override = 0x1018,
ACPI / LPSS: Add Intel BayTrail ACPI mode PWM Intel BayTrail LPSS consists of two PWM controllers which can be enumerated from ACPI namespace. This change will cause platform device objects to be created for Intel BayTrail PWM controllers which will allow the pwm-lpss driver to bind to them and handle those devices. Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-19 01:24:29 +07:00
};
static struct lpss_device_desc byt_pwm_dev_desc = {
ACPI / LPSS: remove struct lpss_shared_clock Nothing requires it anymore. The PWM driver no longer uses clk framework to get the rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:10 +07:00
.flags = LPSS_SAVE_CTX,
ACPI / LPSS: Add Intel BayTrail ACPI mode PWM Intel BayTrail LPSS consists of two PWM controllers which can be enumerated from ACPI namespace. This change will cause platform device objects to be created for Intel BayTrail PWM controllers which will allow the pwm-lpss driver to bind to them and handle those devices. Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-19 01:24:29 +07:00
};
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
static struct lpss_device_desc byt_uart_dev_desc = {
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX |
LPSS_DEV_PROXY,
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
.prv_offset = 0x800,
ACPI / LPSS: mask the UART TX completion interrupt Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-17 17:25:46 +07:00
.setup = lpss_uart_setup,
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
};
static struct lpss_device_desc byt_spi_dev_desc = {
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX |
LPSS_DEV_PROXY,
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
.prv_offset = 0x400,
};
static struct lpss_device_desc byt_sdio_dev_desc = {
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
.flags = LPSS_CLK | LPSS_DEV_PROXY,
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
};
static struct lpss_device_desc byt_i2c_dev_desc = {
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
.flags = LPSS_CLK | LPSS_SAVE_CTX | LPSS_DEV_PROXY,
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
.prv_offset = 0x800,
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
.setup = byt_i2c_setup,
ACPI / LPSS: Add ACPI IDs for Intel Braswell Enable more identifiers for the existing devices for Intel Braswell and Cherryview. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-19 19:55:22 +07:00
};
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
#else
#define LPSS_ADDR(desc) (0UL)
#endif /* CONFIG_X86_INTEL_LPSS */
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
static const struct acpi_device_id acpi_lpss_device_ids[] = {
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
/* Generic LPSS devices */
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
{ "INTL9C60", LPSS_ADDR(lpss_dma_desc) },
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
/* Lynxpoint LPSS devices */
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
{ "INT33C0", LPSS_ADDR(lpt_dev_desc) },
{ "INT33C1", LPSS_ADDR(lpt_dev_desc) },
{ "INT33C2", LPSS_ADDR(lpt_i2c_dev_desc) },
{ "INT33C3", LPSS_ADDR(lpt_i2c_dev_desc) },
{ "INT33C4", LPSS_ADDR(lpt_uart_dev_desc) },
{ "INT33C5", LPSS_ADDR(lpt_uart_dev_desc) },
{ "INT33C6", LPSS_ADDR(lpt_sdio_dev_desc) },
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
{ "INT33C7", },
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
/* BayTrail LPSS devices */
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
{ "80860F09", LPSS_ADDR(byt_pwm_dev_desc) },
{ "80860F0A", LPSS_ADDR(byt_uart_dev_desc) },
{ "80860F0E", LPSS_ADDR(byt_spi_dev_desc) },
{ "80860F14", LPSS_ADDR(byt_sdio_dev_desc) },
{ "80860F41", LPSS_ADDR(byt_i2c_dev_desc) },
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
{ "INT33B2", },
pinctrl: baytrail: Add back Baytrail-T ACPI ID Now that the x86 dynamic IRQ allocation problem has been resolved with commmit 62a08ae2a576 (genirq: x86: Ensure that dynamic irq allocation does not conflict), we can add back Baytrail-T ACPI ID to the pinctrl driver. This makes the driver to work on Asus T100 where it is needed for several things like ACPI GPIO events and SD card detection. References: https://bugzilla.kernel.org/show_bug.cgi?id=68291 Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Jin Yao <yao.jin@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-05-15 22:28:46 +07:00
{ "INT33FC", },
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
ACPI / LPSS: Add ACPI IDs for Intel Braswell Enable more identifiers for the existing devices for Intel Braswell and Cherryview. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-19 19:55:22 +07:00
/* Braswell LPSS devices */
ACPI / LPSS: remove struct lpss_shared_clock Nothing requires it anymore. The PWM driver no longer uses clk framework to get the rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:10 +07:00
{ "80862288", LPSS_ADDR(byt_pwm_dev_desc) },
ACPI / LPSS: Add ACPI IDs for Intel Braswell Enable more identifiers for the existing devices for Intel Braswell and Cherryview. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-19 19:55:22 +07:00
{ "8086228A", LPSS_ADDR(byt_uart_dev_desc) },
{ "8086228E", LPSS_ADDR(byt_spi_dev_desc) },
{ "808622C1", LPSS_ADDR(byt_i2c_dev_desc) },
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
{ "INT3430", LPSS_ADDR(lpt_dev_desc) },
{ "INT3431", LPSS_ADDR(lpt_dev_desc) },
{ "INT3432", LPSS_ADDR(lpt_i2c_dev_desc) },
{ "INT3433", LPSS_ADDR(lpt_i2c_dev_desc) },
{ "INT3434", LPSS_ADDR(lpt_uart_dev_desc) },
{ "INT3435", LPSS_ADDR(lpt_uart_dev_desc) },
{ "INT3436", LPSS_ADDR(lpt_sdio_dev_desc) },
ACPI / LPSS: add ACPI IDs for newer Intel PCHs Some recent Intel PCHs with LPSS have different ACPI IDs for the LPSS devices, so add these to the list as well. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-11-12 16:48:19 +07:00
{ "INT3437", },
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
/* Wildcat Point LPSS devices */
{ "INT3438", LPSS_ADDR(lpt_dev_desc) },
ACPI / LPSS: add LPSS device for Wildcat Point PCH INT3438 is the ADSP device on Wildcat Point platform with 2 DW DMA engines built In. The DMA engines are used for DSP FW loading and audio data transferring. These DMA engine probing need the clock, without it, probing may failed and can't go forward. Add LPSS device "INT3438" for Wildcat Point PCH, to provide clock for its ADSP DMA engine probing. Signed-off-by: Jie Yang <yang.jie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-01 08:06:35 +07:00
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
{ }
};
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
#ifdef CONFIG_X86_INTEL_LPSS
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
static int is_memory(struct acpi_resource *res, void *not_used)
{
struct resource r;
return !acpi_dev_resource_memory(res, &r);
}
/* LPSS main clock device. */
static struct platform_device *lpss_clk_dev;
static inline void lpt_register_clock_device(void)
{
lpss_clk_dev = platform_device_register_simple("clk-lpt", -1, NULL, 0);
}
static int register_device_clock(struct acpi_device *adev,
struct lpss_private_data *pdata)
{
const struct lpss_device_desc *dev_desc = pdata->dev_desc;
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
const char *devname = dev_name(&adev->dev);
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
struct clk *clk = ERR_PTR(-ENODEV);
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
struct lpss_clk_data *clk_data;
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
const char *parent, *clk_name;
void __iomem *prv_base;
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
if (!lpss_clk_dev)
lpt_register_clock_device();
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
clk_data = platform_get_drvdata(lpss_clk_dev);
if (!clk_data)
return -ENODEV;
ACPI / LPSS: drop clkdev_name member from lpss_device_desc It was used to provide the correct con_id for the dma driver, but it's not needed. Even if the driver requests a clock with the con_id, it still gets the correct clock. The device name is enough to match a single clock. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:08 +07:00
clk = clk_data->clk;
ACPI / LPSS: register clock device for Lynxpoint DMA properly The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-05-08 15:55:49 +07:00
if (!pdata->mmio_base
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
|| pdata->mmio_size < dev_desc->prv_offset + LPSS_CLK_SIZE)
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
return -ENODATA;
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
parent = clk_data->name;
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
prv_base = pdata->mmio_base + dev_desc->prv_offset;
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
if (pdata->fixed_clk_rate) {
clk = clk_register_fixed_rate(NULL, devname, parent, 0,
pdata->fixed_clk_rate);
goto out;
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
}
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
if (dev_desc->flags & LPSS_CLK_GATE) {
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
clk = clk_register_gate(NULL, devname, parent, 0,
prv_base, 0, 0, NULL);
parent = devname;
}
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
if (dev_desc->flags & LPSS_CLK_DIVIDER) {
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
/* Prevent division by zero */
if (!readl(prv_base))
writel(LPSS_CLK_DIVIDER_DEF_MASK, prv_base);
clk_name = kasprintf(GFP_KERNEL, "%s-div", devname);
if (!clk_name)
return -ENOMEM;
clk = clk_register_fractional_divider(NULL, clk_name, parent,
0, prv_base,
1, 15, 16, 15, 0, NULL);
parent = clk_name;
clk_name = kasprintf(GFP_KERNEL, "%s-update", devname);
if (!clk_name) {
kfree(parent);
return -ENOMEM;
}
clk = clk_register_gate(NULL, clk_name, parent,
CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
prv_base, 31, 0, NULL);
kfree(parent);
kfree(clk_name);
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
}
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
out:
ACPI / LPSS: add support for Intel BayTrail Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-13 19:42:44 +07:00
if (IS_ERR(clk))
return PTR_ERR(clk);
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
ACPI / LPSS: support for fractional divider clock This creates fractional divider type clock for the ones that have it. It is needed by the UART driver as the clock rate must accommodate to the requested baud rate. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-19 18:42:07 +07:00
pdata->clk = clk;
clk_register_clkdev(clk, NULL, devname);
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
return 0;
}
static int acpi_lpss_create_device(struct acpi_device *adev,
const struct acpi_device_id *id)
{
struct lpss_device_desc *dev_desc;
struct lpss_private_data *pdata;
struct resource_list_entry *rentry;
struct list_head resource_list;
ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices To seed up suspend and resume of devices included into Intel SoCs handled by the ACPI LPSS driver during system suspend, make acpi_lpss_create_device() call device_enable_async_suspend() for every device created by it. This requires acpi_create_platform_device() to be modified to return a pointer to struct platform_device instead of an int. As a result, acpi_create_platform_device() cannot be pointed to by the .attach pointer in platform_handler directly any more, so a simple wrapper around it is necessary for this purpose. That, in turn, allows the second unused argument of acpi_create_platform_device() to be dropped, which is an improvement. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-25 19:38:52 +07:00
struct platform_device *pdev;
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
int ret;
dev_desc = (struct lpss_device_desc *)id->driver_data;
ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices To seed up suspend and resume of devices included into Intel SoCs handled by the ACPI LPSS driver during system suspend, make acpi_lpss_create_device() call device_enable_async_suspend() for every device created by it. This requires acpi_create_platform_device() to be modified to return a pointer to struct platform_device instead of an int. As a result, acpi_create_platform_device() cannot be pointed to by the .attach pointer in platform_handler directly any more, so a simple wrapper around it is necessary for this purpose. That, in turn, allows the second unused argument of acpi_create_platform_device() to be dropped, which is an improvement. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-25 19:38:52 +07:00
if (!dev_desc) {
pdev = acpi_create_platform_device(adev);
return IS_ERR_OR_NULL(pdev) ? PTR_ERR(pdev) : 1;
}
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
INIT_LIST_HEAD(&resource_list);
ret = acpi_dev_get_resources(adev, &resource_list, is_memory, NULL);
if (ret < 0)
goto err_out;
list_for_each_entry(rentry, &resource_list, node)
if (resource_type(&rentry->res) == IORESOURCE_MEM) {
ACPI / LPSS: override SDIO private register space size from ACPI tables The SDIO device in Lynxpoint has its LTR registers reserved for a WiFi device (a child of the SDIO device) in the ACPI namespace even though those registers physically belong to the SDIO device itself. In order to be able to access the SDIO LTR registers from the ACPI LPSS driver for diagnostic purposes we need to use a size override for the SDIO private register space. Add a possibility to override the size of the private register space of an LPSS device provided by the ACPI tables in the ACPI LPSS driver and set the correct size for the SDIO device in there. [rjw: Changelog] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-18 20:51:35 +07:00
if (dev_desc->prv_size_override)
pdata->mmio_size = dev_desc->prv_size_override;
else
pdata->mmio_size = resource_size(&rentry->res);
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
pdata->mmio_base = ioremap(rentry->res.start,
pdata->mmio_size);
break;
}
acpi_dev_free_resource_list(&resource_list);
ACPI / LPSS: don't crash if a device has no MMIO resources Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ resources returned in their _CRS method. However, Apple Macbook Air with Haswell has LPSS devices enumerated from PCI bus instead and _CRS method returns only an interrupt number (but the device has _HID set that causes the scan handler to match it). The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource is found for the device and in case of Macbook Air it is never found. That leads to a NULL pointer dereference in register_device_clock(). Correct this by always setting the pdata->dev_desc. Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-02 17:30:25 +07:00
pdata->dev_desc = dev_desc;
ACPI / LPSS: support for 133MHz I2C source clock on Baytrail The I2C controllers on Baytrail can get the clock from 100MHz or 133MHz source clock. The first bits in the private clock parameter register indicates which one is being used. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:09 +07:00
if (dev_desc->setup)
dev_desc->setup(pdata);
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
if (dev_desc->flags & LPSS_CLK) {
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
ret = register_device_clock(adev, pdata);
if (ret) {
ACPI / LPSS: Power up LPSS devices during enumeration Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-19 05:45:34 +07:00
/* Skip the device, but continue the namespace scan. */
ret = 0;
goto err_out;
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
}
}
ACPI / LPSS: Power up LPSS devices during enumeration Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-19 05:45:34 +07:00
/*
* This works around a known issue in ACPI tables where LPSS devices
* have _PS0 and _PS3 without _PSC (and no power resources), so
* acpi_bus_init_power() will assume that the BIOS has put them into D0.
*/
ret = acpi_device_fix_up_power(adev);
if (ret) {
/* Skip the device, but continue the namespace scan. */
ret = 0;
goto err_out;
}
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
adev->driver_data = pdata;
ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices To seed up suspend and resume of devices included into Intel SoCs handled by the ACPI LPSS driver during system suspend, make acpi_lpss_create_device() call device_enable_async_suspend() for every device created by it. This requires acpi_create_platform_device() to be modified to return a pointer to struct platform_device instead of an int. As a result, acpi_create_platform_device() cannot be pointed to by the .attach pointer in platform_handler directly any more, so a simple wrapper around it is necessary for this purpose. That, in turn, allows the second unused argument of acpi_create_platform_device() to be dropped, which is an improvement. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-25 19:38:52 +07:00
pdev = acpi_create_platform_device(adev);
if (!IS_ERR_OR_NULL(pdev)) {
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
if (!proxy_device && dev_desc->flags & LPSS_DEV_PROXY)
proxy_device = &pdev->dev;
ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices To seed up suspend and resume of devices included into Intel SoCs handled by the ACPI LPSS driver during system suspend, make acpi_lpss_create_device() call device_enable_async_suspend() for every device created by it. This requires acpi_create_platform_device() to be modified to return a pointer to struct platform_device instead of an int. As a result, acpi_create_platform_device() cannot be pointed to by the .attach pointer in platform_handler directly any more, so a simple wrapper around it is necessary for this purpose. That, in turn, allows the second unused argument of acpi_create_platform_device() to be dropped, which is an improvement. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-25 19:38:52 +07:00
return 1;
}
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices To seed up suspend and resume of devices included into Intel SoCs handled by the ACPI LPSS driver during system suspend, make acpi_lpss_create_device() call device_enable_async_suspend() for every device created by it. This requires acpi_create_platform_device() to be modified to return a pointer to struct platform_device instead of an int. As a result, acpi_create_platform_device() cannot be pointed to by the .attach pointer in platform_handler directly any more, so a simple wrapper around it is necessary for this purpose. That, in turn, allows the second unused argument of acpi_create_platform_device() to be dropped, which is an improvement. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-25 19:38:52 +07:00
ret = PTR_ERR(pdev);
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
adev->driver_data = NULL;
err_out:
kfree(pdata);
return ret;
}
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
static u32 __lpss_reg_read(struct lpss_private_data *pdata, unsigned int reg)
{
return readl(pdata->mmio_base + pdata->dev_desc->prv_offset + reg);
}
static void __lpss_reg_write(u32 val, struct lpss_private_data *pdata,
unsigned int reg)
{
writel(val, pdata->mmio_base + pdata->dev_desc->prv_offset + reg);
}
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
static int lpss_reg_read(struct device *dev, unsigned int reg, u32 *val)
{
struct acpi_device *adev;
struct lpss_private_data *pdata;
unsigned long flags;
int ret;
ret = acpi_bus_get_device(ACPI_HANDLE(dev), &adev);
if (WARN_ON(ret))
return ret;
spin_lock_irqsave(&dev->power.lock, flags);
if (pm_runtime_suspended(dev)) {
ret = -EAGAIN;
goto out;
}
pdata = acpi_driver_data(adev);
if (WARN_ON(!pdata || !pdata->mmio_base)) {
ret = -ENODEV;
goto out;
}
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
*val = __lpss_reg_read(pdata, reg);
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
out:
spin_unlock_irqrestore(&dev->power.lock, flags);
return ret;
}
static ssize_t lpss_ltr_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
u32 ltr_value = 0;
unsigned int reg;
int ret;
reg = strcmp(attr->attr.name, "auto_ltr") ? LPSS_SW_LTR : LPSS_AUTO_LTR;
ret = lpss_reg_read(dev, reg, &ltr_value);
if (ret)
return ret;
return snprintf(buf, PAGE_SIZE, "%08x\n", ltr_value);
}
static ssize_t lpss_ltr_mode_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
u32 ltr_mode = 0;
char *outstr;
int ret;
ret = lpss_reg_read(dev, LPSS_GENERAL, &ltr_mode);
if (ret)
return ret;
outstr = (ltr_mode & LPSS_GENERAL_LTR_MODE_SW) ? "sw" : "auto";
return sprintf(buf, "%s\n", outstr);
}
static DEVICE_ATTR(auto_ltr, S_IRUSR, lpss_ltr_show, NULL);
static DEVICE_ATTR(sw_ltr, S_IRUSR, lpss_ltr_show, NULL);
static DEVICE_ATTR(ltr_mode, S_IRUSR, lpss_ltr_mode_show, NULL);
static struct attribute *lpss_attrs[] = {
&dev_attr_auto_ltr.attr,
&dev_attr_sw_ltr.attr,
&dev_attr_ltr_mode.attr,
NULL,
};
static struct attribute_group lpss_attr_group = {
.attrs = lpss_attrs,
.name = "lpss_ltr",
};
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
static void acpi_lpss_set_ltr(struct device *dev, s32 val)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
u32 ltr_mode, ltr_val;
ltr_mode = __lpss_reg_read(pdata, LPSS_GENERAL);
if (val < 0) {
if (ltr_mode & LPSS_GENERAL_LTR_MODE_SW) {
ltr_mode &= ~LPSS_GENERAL_LTR_MODE_SW;
__lpss_reg_write(ltr_mode, pdata, LPSS_GENERAL);
}
return;
}
ltr_val = __lpss_reg_read(pdata, LPSS_SW_LTR) & ~LPSS_LTR_SNOOP_MASK;
if (val >= LPSS_LTR_SNOOP_LAT_CUTOFF) {
ltr_val |= LPSS_LTR_SNOOP_LAT_32US;
val = LPSS_LTR_MAX_VAL;
} else if (val > LPSS_LTR_MAX_VAL) {
ltr_val |= LPSS_LTR_SNOOP_LAT_32US | LPSS_LTR_SNOOP_REQ;
val >>= LPSS_LTR_SNOOP_LAT_SHIFT;
} else {
ltr_val |= LPSS_LTR_SNOOP_LAT_1US | LPSS_LTR_SNOOP_REQ;
}
ltr_val |= val;
__lpss_reg_write(ltr_val, pdata, LPSS_SW_LTR);
if (!(ltr_mode & LPSS_GENERAL_LTR_MODE_SW)) {
ltr_mode |= LPSS_GENERAL_LTR_MODE_SW;
__lpss_reg_write(ltr_mode, pdata, LPSS_GENERAL);
}
}
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
#ifdef CONFIG_PM
/**
* acpi_lpss_save_ctx() - Save the private registers of LPSS device
* @dev: LPSS device
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
* @pdata: pointer to the private data of the LPSS device
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
*
* Most LPSS devices have private registers which may loose their context when
* the device is powered down. acpi_lpss_save_ctx() saves those registers into
* prv_reg_ctx array.
*/
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
static void acpi_lpss_save_ctx(struct device *dev,
struct lpss_private_data *pdata)
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
{
unsigned int i;
for (i = 0; i < LPSS_PRV_REG_COUNT; i++) {
unsigned long offset = i * sizeof(u32);
pdata->prv_reg_ctx[i] = __lpss_reg_read(pdata, offset);
dev_dbg(dev, "saving 0x%08x from LPSS reg at offset 0x%02lx\n",
pdata->prv_reg_ctx[i], offset);
}
}
/**
* acpi_lpss_restore_ctx() - Restore the private registers of LPSS device
* @dev: LPSS device
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
* @pdata: pointer to the private data of the LPSS device
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
*
* Restores the registers that were previously stored with acpi_lpss_save_ctx().
*/
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
static void acpi_lpss_restore_ctx(struct device *dev,
struct lpss_private_data *pdata)
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
{
unsigned int i;
/*
* The following delay is needed or the subsequent write operations may
* fail. The LPSS devices are actually PCI devices and the PCI spec
* expects 10ms delay before the device can be accessed after D3 to D0
* transition.
*/
msleep(10);
for (i = 0; i < LPSS_PRV_REG_COUNT; i++) {
unsigned long offset = i * sizeof(u32);
__lpss_reg_write(pdata->prv_reg_ctx[i], pdata, offset);
dev_dbg(dev, "restoring 0x%08x to LPSS reg at offset 0x%02lx\n",
pdata->prv_reg_ctx[i], offset);
}
}
#ifdef CONFIG_PM_SLEEP
static int acpi_lpss_suspend_late(struct device *dev)
{
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
ret = pm_generic_suspend_late(dev);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
if (ret)
return ret;
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_save_ctx(dev, pdata);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
return acpi_dev_suspend_late(dev);
}
ACPI / LPSS: complete PM entries for LPSS power domain PM entries of LPSS power domain were not implemented correctly in commit c78b0830667a "ACPI / LPSS: custom power domain for LPSS". This patch fixes and completes these PM entries. Fixes: c78b0830667a (ACPI / LPSS: custom power domain for LPSS) Signed-off-by: Li Aubrey <aubrey.li@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-09 21:30:06 +07:00
static int acpi_lpss_resume_early(struct device *dev)
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
{
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
ret = acpi_dev_resume_early(dev);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
if (ret)
return ret;
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_restore_ctx(dev, pdata);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
return pm_generic_resume_early(dev);
}
#endif /* CONFIG_PM_SLEEP */
static int acpi_lpss_runtime_suspend(struct device *dev)
{
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
ret = pm_generic_runtime_suspend(dev);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
if (ret)
return ret;
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_save_ctx(dev, pdata);
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
ret = acpi_dev_runtime_suspend(dev);
if (ret)
return ret;
if (pdata->dev_desc->flags & LPSS_PROXY_REQ && proxy_device)
return pm_runtime_put_sync_suspend(proxy_device);
return 0;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
}
static int acpi_lpss_runtime_resume(struct device *dev)
{
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be powered off automatically whenever the last LPSS device goes down. In case of no power any access to the DMA controller will hang the system. The behaviour is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on Asus T100 transformer. This patch introduces a so called 'proxy' device that has the knobs to handle a power of the LPSS island. When the system needs to program the DMA controller it calls to the ACPI LPSS power domain callbacks that wake or suspend the 'proxy' device. [1] http://www.spinics.net/lists/dmaengine/msg01514.html Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:47 +07:00
if (pdata->dev_desc->flags & LPSS_PROXY_REQ && proxy_device) {
ret = pm_runtime_get_sync(proxy_device);
if (ret)
return ret;
}
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
ret = acpi_dev_runtime_resume(dev);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
if (ret)
return ret;
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_restore_ctx(dev, pdata);
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
return pm_generic_runtime_resume(dev);
}
#endif /* CONFIG_PM */
static struct dev_pm_domain acpi_lpss_pm_domain = {
.ops = {
ACPI / PM: Drop CONFIG_PM_RUNTIME from the ACPI core After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so quite a few depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM in the ACPI core code. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-28 04:38:23 +07:00
#ifdef CONFIG_PM
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
#ifdef CONFIG_PM_SLEEP
.prepare = acpi_subsys_prepare,
.complete = acpi_subsys_complete,
.suspend = acpi_subsys_suspend,
ACPI / LPSS: complete PM entries for LPSS power domain PM entries of LPSS power domain were not implemented correctly in commit c78b0830667a "ACPI / LPSS: custom power domain for LPSS". This patch fixes and completes these PM entries. Fixes: c78b0830667a (ACPI / LPSS: custom power domain for LPSS) Signed-off-by: Li Aubrey <aubrey.li@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-09 21:30:06 +07:00
.suspend_late = acpi_lpss_suspend_late,
.resume_early = acpi_lpss_resume_early,
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
.freeze = acpi_subsys_freeze,
.poweroff = acpi_subsys_suspend,
ACPI / LPSS: complete PM entries for LPSS power domain PM entries of LPSS power domain were not implemented correctly in commit c78b0830667a "ACPI / LPSS: custom power domain for LPSS". This patch fixes and completes these PM entries. Fixes: c78b0830667a (ACPI / LPSS: custom power domain for LPSS) Signed-off-by: Li Aubrey <aubrey.li@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-09 21:30:06 +07:00
.poweroff_late = acpi_lpss_suspend_late,
.restore_early = acpi_lpss_resume_early,
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
#endif
.runtime_suspend = acpi_lpss_runtime_suspend,
.runtime_resume = acpi_lpss_runtime_resume,
#endif
},
};
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
static int acpi_lpss_platform_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
struct platform_device *pdev = to_platform_device(data);
struct lpss_private_data *pdata;
struct acpi_device *adev;
const struct acpi_device_id *id;
id = acpi_match_device(acpi_lpss_device_ids, &pdev->dev);
if (!id || !id->driver_data)
return 0;
if (acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev))
return 0;
pdata = acpi_driver_data(adev);
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
if (!pdata)
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
return 0;
ACPI / LPSS: add all LPSS devices to the specific power domain Currently the LPSS devices are located in the different power domains depends on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all LPSS devices. The LPSS DMA controller has no knobs to control its power state. The specific power domain implementation will handle this case. The patch does a preparation for that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:45 +07:00
if (pdata->mmio_base &&
pdata->mmio_size < pdata->dev_desc->prv_offset + LPSS_LTR_SIZE) {
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
dev_err(&pdev->dev, "MMIO size insufficient to access LTR\n");
return 0;
}
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
ACPI / LPSS: allow to use specific PM domain during ->probe() The LPSS DMA controller would like to use the specific PM domain callbacks during early stage, namely in ->probe(). This patch moves the specific PM domain assignment early to be accessible during a whole life time of the device in the system. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:46 +07:00
pdev->dev.pm_domain = &acpi_lpss_pm_domain;
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
if (pdata->dev_desc->flags & LPSS_LTR)
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
return sysfs_create_group(&pdev->dev.kobj,
&lpss_attr_group);
ACPI / LPSS: allow to use specific PM domain during ->probe() The LPSS DMA controller would like to use the specific PM domain callbacks during early stage, namely in ->probe(). This patch moves the specific PM domain assignment early to be accessible during a whole life time of the device in the system. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:46 +07:00
break;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
case BUS_NOTIFY_DEL_DEVICE:
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
if (pdata->dev_desc->flags & LPSS_LTR)
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
ACPI / LPSS: allow to use specific PM domain during ->probe() The LPSS DMA controller would like to use the specific PM domain callbacks during early stage, namely in ->probe(). This patch moves the specific PM domain assignment early to be accessible during a whole life time of the device in the system. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 23:34:46 +07:00
pdev->dev.pm_domain = NULL;
break;
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
default:
break;
}
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
ACPI / LPSS: custom power domain for LPSS A power domain where we save the context of the additional LPSS registers. We need to do this or all LPSS devices are left in reset state when resuming from D3 on some Baytrails. The devices with the fractional clock divider also have zeros for N and M values after resuming unless they are reset. Li Aubrey found the root cause for the issue. The idea of using power domain for LPSS came from Mika Westerberg. Reported-by: Jin Yao <yao.jin@linux.intel.com> Suggested-by: Li Aubrey <aubrey.li@linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Added the .complete() callback to the PM domain, fixed build warning on 32-bit.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23 20:15:09 +07:00
return 0;
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
}
static struct notifier_block acpi_lpss_nb = {
.notifier_call = acpi_lpss_platform_notify,
};
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
static void acpi_lpss_bind(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
ACPI / LPSS: introduce flags Replace the booleans with a single flags member variable. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02 14:55:07 +07:00
if (!pdata || !pdata->mmio_base || !(pdata->dev_desc->flags & LPSS_LTR))
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
return;
if (pdata->mmio_size >= pdata->dev_desc->prv_offset + LPSS_LTR_SIZE)
dev->power.set_latency_tolerance = acpi_lpss_set_ltr;
else
dev_err(dev, "MMIO size insufficient to access LTR\n");
}
static void acpi_lpss_unbind(struct device *dev)
{
dev->power.set_latency_tolerance = NULL;
}
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
static struct acpi_scan_handler lpss_handler = {
.ids = acpi_lpss_device_ids,
.attach = acpi_lpss_create_device,
ACPI / LPSS: Support for device latency tolerance PM QoS Add a new routine, acpi_lpss_set_ltr(), for setting latency tolerance values for LPSS devices having LTR (Latency Tolerance Reporting) registers. Add .bind()/.unbind() callbacks to lpss_handler to set the LPSS devices' power.set_latency_tolerance callback pointers to acpi_lpss_set_ltr() during device addition and to clear them on device removal, respectively. That will cause the device latency tolerance PM QoS to work for the devices in question as documented. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 06:35:53 +07:00
.bind = acpi_lpss_bind,
.unbind = acpi_lpss_unbind,
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
};
void __init acpi_lpss_init(void)
{
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
if (!lpt_clk_init()) {
bus_register_notifier(&platform_bus_type, &acpi_lpss_nb);
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
acpi_scan_add_handler(&lpss_handler);
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 05:46:28 +07:00
}
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 05:46:20 +07:00
}
ACPI / scan: always register ACPI LPSS scan handler Prevent platform devices from being created for ACPI LPSS devices if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case. This change is based on a prototype from Zhang Rui. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 19:34:05 +07:00
#else
static struct acpi_scan_handler lpss_handler = {
.ids = acpi_lpss_device_ids,
};
void __init acpi_lpss_init(void)
{
acpi_scan_add_handler(&lpss_handler);
}
#endif /* CONFIG_X86_INTEL_LPSS */
Reference in New Issue Copy Permalink