p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
linux_old1/drivers/acpi/acpi_lpss.c

749 lines
18 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 06:46:20 +08:00
/*
* ACPI support for Intel Lynxpoint LPSS.
*
* Copyright (C) 2013, Intel Corporation
* 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 06:46:28 +08: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 21:15:09 +08: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 06:46:20 +08: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 20:34:05 +08: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 06:46:20 +08: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 06:46:28 +08: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 19:42:07 +08: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 19:33:39 +08: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 06:46:28 +08: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 14:49:20 +08: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 06:46:28 +08: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 07:35:53 +08: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 18:25:46 +08: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 06:46:20 +08: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 21:15:09 +08:00
#define LPSS_PRV_REG_COUNT 9
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 20:42:44 +08:00
struct lpss_shared_clock {
const char *name;
unsigned long rate;
struct clk *clk;
};
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 18:25:46 +08: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 06:46:20 +08:00
struct lpss_device_desc {
bool clk_required;
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 16:55:49 +08:00
const char *clkdev_name;
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 06:46:28 +08:00
bool ltr_required;
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 21:51:35 +08:00
size_t prv_size_override;
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 19:42:07 +08:00
bool clk_divider;
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 20:42:44 +08:00
bool clk_gate;
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 21:15:09 +08:00
bool save_ctx;
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 20:42:44 +08:00
struct lpss_shared_clock *shared_clock;
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 18:25:46 +08: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 06:46:20 +08:00
};
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 16:55:49 +08:00
static struct lpss_device_desc lpss_dma_desc = {
.clk_required = true,
.clkdev_name = "hclk",
};
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 06:46:20 +08:00
struct lpss_private_data {
void __iomem *mmio_base;
resource_size_t mmio_size;
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 21:15:09 +08: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 06:46:20 +08: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 18:25:46 +08: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 14:49:20 +08:00
unsigned int 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 18:25:46 +08:00
u32 reg;
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 14:49:20 +08:00
offset = pdata->dev_desc->prv_offset + LPSS_TX_INT;
reg = readl(pdata->mmio_base + offset);
writel(reg | LPSS_TX_INT_MASK, pdata->mmio_base + offset);
offset = pdata->dev_desc->prv_offset + LPSS_GENERAL;
reg = readl(pdata->mmio_base + offset);
writel(reg | LPSS_GENERAL_UART_RTS_OVRD, 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 18:25:46 +08:00
}
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 19:33:39 +08:00
static void lpss_i2c_setup(struct lpss_private_data *pdata)
{
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: 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 09:06:35 +08:00
static struct lpss_device_desc wpt_dev_desc = {
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
.clk_divider = true,
.clk_gate = true,
};
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 06:46:20 +08:00
static struct lpss_device_desc lpt_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 19:42:07 +08:00
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
.clk_divider = true,
.clk_gate = true,
};
static struct lpss_device_desc lpt_i2c_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 06:46:20 +08:00
.clk_required = true,
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 06:46:28 +08:00
.prv_offset = 0x800,
.ltr_required = true,
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 20:42:44 +08:00
.clk_gate = true,
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 06:46:28 +08: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 18:25:46 +08:00
static struct lpss_device_desc lpt_uart_dev_desc = {
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
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 19:42:07 +08:00
.clk_divider = true,
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 18:25:46 +08:00
.clk_gate = true,
.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 06:46:28 +08:00
};
static struct lpss_device_desc lpt_sdio_dev_desc = {
.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 21:51:35 +08:00
.prv_size_override = 0x1018,
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 06:46:28 +08:00
.ltr_required = true,
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 06:46:20 +08:00
};
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 02:24:29 +08:00
static struct lpss_shared_clock pwm_clock = {
.name = "pwm_clk",
.rate = 25000000,
};
static struct lpss_device_desc byt_pwm_dev_desc = {
.clk_required = true,
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 21:15:09 +08:00
.save_ctx = true,
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 02:24:29 +08:00
.shared_clock = &pwm_clock,
};
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 20:42:44 +08:00
static struct lpss_device_desc byt_uart_dev_desc = {
.clk_required = true,
.prv_offset = 0x800,
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 19:42:07 +08:00
.clk_divider = true,
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 20:42:44 +08:00
.clk_gate = true,
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 21:15:09 +08:00
.save_ctx = true,
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 18:25:46 +08: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 20:42:44 +08:00
};
static struct lpss_device_desc byt_spi_dev_desc = {
.clk_required = true,
.prv_offset = 0x400,
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 19:42:07 +08:00
.clk_divider = true,
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 20:42:44 +08:00
.clk_gate = true,
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 21:15:09 +08:00
.save_ctx = true,
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 20:42:44 +08:00
};
static struct lpss_device_desc byt_sdio_dev_desc = {
.clk_required = true,
};
static struct lpss_shared_clock i2c_clock = {
.name = "i2c_clk",
.rate = 100000000,
};
static struct lpss_device_desc byt_i2c_dev_desc = {
.clk_required = true,
.prv_offset = 0x800,
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 21:15:09 +08:00
.save_ctx = true,
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 20:42:44 +08:00
.shared_clock = &i2c_clock,
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 19:33:39 +08:00
.setup = lpss_i2c_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 20:42:44 +08: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 20:34:05 +08: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 06:46:20 +08: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 16:55:49 +08: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 20:34:05 +08: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 16:55:49 +08: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 06:46:20 +08: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 20:34:05 +08: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 06:46:20 +08: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 20:42:44 +08: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 20:34:05 +08: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 20:42:44 +08: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 23:28:46 +08: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 20:42:44 +08: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 20:34:05 +08: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 17:48:19 +08:00
{ "INT3437", },
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 09:06:35 +08:00
{ "INT3438", LPSS_ADDR(wpt_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 06:46:20 +08: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 20:34:05 +08: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 06:46:20 +08: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: 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 20:42:44 +08:00
struct lpss_shared_clock *shared_clock = dev_desc->shared_clock;
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 19:42:07 +08: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 20:42:44 +08: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 16:55:49 +08: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 19:42:07 +08: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 06:46:20 +08: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 16:55:49 +08:00
clk_data = platform_get_drvdata(lpss_clk_dev);
if (!clk_data)
return -ENODEV;
if (dev_desc->clkdev_name) {
clk_register_clkdev(clk_data->clk, dev_desc->clkdev_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 19:42:07 +08:00
devname);
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 16:55:49 +08:00
return 0;
}
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 06:46:28 +08: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 06:46:20 +08: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 20:42:44 +08: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 19:42:07 +08: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 20:42:44 +08:00
if (shared_clock) {
clk = shared_clock->clk;
if (!clk) {
clk = clk_register_fixed_rate(NULL, shared_clock->name,
"lpss_clk", 0,
shared_clock->rate);
shared_clock->clk = clk;
}
parent = shared_clock->name;
}
if (dev_desc->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 19:42:07 +08:00
clk = clk_register_gate(NULL, devname, parent, 0,
prv_base, 0, 0, NULL);
parent = devname;
}
if (dev_desc->clk_divider) {
/* 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 20:42:44 +08: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 06:46:20 +08: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 20:42:44 +08: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 06:46:20 +08: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 19:42:07 +08: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 06:46:20 +08: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 20:38:52 +08: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 06:46:20 +08: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 20:38:52 +08: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 06:46:20 +08: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 21:51:35 +08: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 06:46:20 +08: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 18:30:25 +08:00
pdata->dev_desc = 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 06:46:20 +08:00
if (dev_desc->clk_required) {
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 06:45:34 +08: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 06:46:20 +08: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 06:45:34 +08: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 / 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 18:25:46 +08:00
if (dev_desc->setup)
dev_desc->setup(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 06:46:20 +08: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 20:38:52 +08:00
pdev = acpi_create_platform_device(adev);
if (!IS_ERR_OR_NULL(pdev)) {
device_enable_async_suspend(&pdev->dev);
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 06:46:20 +08: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 20:38:52 +08: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 06:46:20 +08: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 07:35:53 +08: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 06:46:28 +08: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 07:35:53 +08: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 06:46:28 +08: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 07:35:53 +08: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 21:15:09 +08:00
#ifdef CONFIG_PM
/**
* acpi_lpss_save_ctx() - Save the private registers of LPSS device
* @dev: LPSS device
*
* 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.
*/
static void acpi_lpss_save_ctx(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
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
*
* Restores the registers that were previously stored with acpi_lpss_save_ctx().
*/
static void acpi_lpss_restore_ctx(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
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)
{
int ret = pm_generic_suspend_late(dev);
if (ret)
return ret;
acpi_lpss_save_ctx(dev);
return acpi_dev_suspend_late(dev);
}
static int acpi_lpss_restore_early(struct device *dev)
{
int ret = acpi_dev_resume_early(dev);
if (ret)
return ret;
acpi_lpss_restore_ctx(dev);
return pm_generic_resume_early(dev);
}
#endif /* CONFIG_PM_SLEEP */
#ifdef CONFIG_PM_RUNTIME
static int acpi_lpss_runtime_suspend(struct device *dev)
{
int ret = pm_generic_runtime_suspend(dev);
if (ret)
return ret;
acpi_lpss_save_ctx(dev);
return acpi_dev_runtime_suspend(dev);
}
static int acpi_lpss_runtime_resume(struct device *dev)
{
int ret = acpi_dev_runtime_resume(dev);
if (ret)
return ret;
acpi_lpss_restore_ctx(dev);
return pm_generic_runtime_resume(dev);
}
#endif /* CONFIG_PM_RUNTIME */
#endif /* CONFIG_PM */
static struct dev_pm_domain acpi_lpss_pm_domain = {
.ops = {
#ifdef CONFIG_PM_SLEEP
.suspend_late = acpi_lpss_suspend_late,
.restore_early = acpi_lpss_restore_early,
.prepare = acpi_subsys_prepare,
.complete = acpi_subsys_complete,
.suspend = acpi_subsys_suspend,
.resume_early = acpi_subsys_resume_early,
.freeze = acpi_subsys_freeze,
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_subsys_suspend_late,
#endif
#ifdef CONFIG_PM_RUNTIME
.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 06:46:28 +08: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: 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 21:15:09 +08:00
if (!pdata || !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 06:46:28 +08:00
return 0;
if (pdata->mmio_size < pdata->dev_desc->prv_offset + LPSS_LTR_SIZE) {
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 21:15:09 +08:00
switch (action) {
case BUS_NOTIFY_BOUND_DRIVER:
if (pdata->dev_desc->save_ctx)
pdev->dev.pm_domain = &acpi_lpss_pm_domain;
break;
case BUS_NOTIFY_UNBOUND_DRIVER:
if (pdata->dev_desc->save_ctx)
pdev->dev.pm_domain = NULL;
break;
case BUS_NOTIFY_ADD_DEVICE:
if (pdata->dev_desc->ltr_required)
return sysfs_create_group(&pdev->dev.kobj,
&lpss_attr_group);
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->ltr_required)
sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
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 06:46:28 +08: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 21:15:09 +08: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 06:46:28 +08: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 07:35:53 +08:00
static void acpi_lpss_bind(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
if (!pdata || !pdata->mmio_base || !pdata->dev_desc->ltr_required)
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 06:46:20 +08: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 07:35:53 +08: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 06:46:20 +08: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 06:46:28 +08: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 06:46:20 +08: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 06:46:28 +08: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 06:46:20 +08: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 20:34:05 +08: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 */