2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-28 23:23:55 +08:00
linux-next/drivers/acpi/acpi_lpss.c

1378 lines
36 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
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
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
* Authors: Mika Westerberg <mika.westerberg@linux.intel.com>
* Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*/
#include <linux/acpi.h>
#include <linux/clkdev.h>
#include <linux/clk-provider.h>
#include <linux/dmi.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 <linux/err.h>
#include <linux/io.h>
#include <linux/mutex.h>
#include <linux/pci.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 <linux/platform_device.h>
#include <linux/platform_data/x86/clk-lpss.h>
#include <linux/platform_data/x86/pmc_atom.h>
#include <linux/pm_domain.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>
#include <linux/pwm.h>
#include <linux/pxa2xx_ssp.h>
#include <linux/suspend.h>
#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"
#ifdef CONFIG_X86_INTEL_LPSS
#include <asm/cpu_device_id.h>
#include <asm/intel-family.h>
#include <asm/iosf_mbi.h>
#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 */
#define LPSS_CLK_DIVIDER_DEF_MASK (BIT(1) | BIT(16))
#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)
#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
#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
#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
#define LPSS_PRV_REG_COUNT 9
/* LPSS Flags */
#define LPSS_CLK BIT(0)
#define LPSS_CLK_GATE BIT(1)
#define LPSS_CLK_DIVIDER BIT(2)
#define LPSS_LTR BIT(3)
#define LPSS_SAVE_CTX BIT(4)
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets turned off from the _PS3 method of the graphics-card dev: Method (_PS3, 0, Serialized) // _PS3: Power State 3 { ... PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */ PSAT |= 0x03 Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ ... } Where PSAT is the power-status register of the PWM controller. Since the i915 driver will do a pwm_get on the pwm device as it uses it to control the LCD panel backlight, there is a device-link marking the i915 device as a consumer of the pwm device. So that the PWM controller will always be suspended after the i915 driver suspends (which is the right thing to do). This causes the above GFX0 PS3 AML code to run before acpi_lpss.c calls acpi_lpss_save_ctx(). So on these devices the PWM controller will already be off when acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff) as ctx register values. When these bogus values get restored on resume the PWM controller actually keeps working, since most bits are reserved, but this does set bit 3 of the LPSS General purpose register, which for the PWM controller has the following function: "This bit is re-used to support 32kHz slow mode. Default is 19.2MHz as PWM source clock". This causes the clock of the PWM controller to switch from 19.2MHz to 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far there have been few bug reports about this. This is likely because the i915 driver was hardcoding the PWM frequency to 46 KHz, which divided by 600 would result in a PWM frequency of approx. 78 Hz, which mostly still works fine. There are some bug reports about the LCD backlight flickering after suspend/resume which are likely caused by this issue. But with the upcoming patch-series to finally switch the i915 drivers code for external PWM controllers to use the atomic API and to honor the PWM frequency specified in the video BIOS (VBT), this becomes a much bigger problem. On most cases the VBT specifies either 200 Hz or 20 KHz as PWM frequency, which with the mentioned issue ends up being either 1/3 Hz, where the backlight actually visible blinks on and off every 3s, or in 33 Hz and horrible flickering of the backlight. There are a number of possible solutions to this problem: 1. Make acpi_lpss_save_ctx() run before GFX0._PS3 Pro: Clean solution from pov of not medling with save/restore ctx code Con: As mentioned the current ordering is the right thing to do Con: Requires assymmetry in at what suspend/resume phase we do the save vs restore, requiring more suspend/resume ordering hacks in already convoluted acpi_lpss.c suspend/resume code. 2. Do some sort of save once mode for the LPSS ctx Pro: Reasonably clean Con: Needs a new LPSS flag + code changes to handle the flag 3. Detect we have failed to save the ctx registers and do not restore them Pro: Not PWM specific, might help with issues on other LPSS devices too Con: If we can get away with not restoring the ctx why bother with it at all? 4. Do not save the ctx for CHT PWM controllers Pro: Clean, as simple as dropping a flag? Con: Not so simple as dropping a flag, needs a new flag to ensure that we still do lpss_deassert_reset() on device activation. 5. Make the pwm-lpss code fixup the LPSS-context registers Pro: Keeps acpi_lpss.c code clean Con: Moves knowledge of LPSS-context into the pwm-lpss.c code 1 and 5 both do not seem to be a desirable way forward. 3 and 4 seem ok, but they both assume that restoring the LPSS-context registers is not necessary. I have done a couple of test and those do show that restoring the LPSS-context indeed does not seem to be necessary on devices using s2idle suspend (and successfully reaching S0i3). But I have no hardware to test deep / S3 suspend. So I'm not sure that not restoring the context is safe. That leaves solution 2, which is about as simple / clean as 3 and 4, so this commit fixes the described problem by implementing a new LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-3-hdegoede@redhat.com
2020-09-03 19:23:22 +08:00
/*
* For some devices the DSDT AML code for another device turns off the device
* before our suspend handler runs, causing us to read/save all 1-s (0xffffffff)
* as ctx register values.
* Luckily these devices always use the same ctx register values, so we can
* work around this by saving the ctx registers once on activation.
*/
#define LPSS_SAVE_CTX_ONCE BIT(5)
#define LPSS_NO_D3_DELAY BIT(6)
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 {
unsigned int flags;
const char *clk_con_id;
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
unsigned int prv_offset;
size_t prv_size_override;
const struct property_entry *properties;
void (*setup)(struct lpss_private_data *pdata);
2018-09-23 21:58:11 +08:00
bool resume_from_noirq;
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 lpss_device_desc lpss_dma_desc = {
.flags = LPSS_CLK,
};
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 06:46:20 +08:00
struct lpss_private_data {
struct acpi_device *adev;
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 __iomem *mmio_base;
resource_size_t mmio_size;
unsigned int fixed_clk_rate;
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 06:46:20 +08:00
struct clk *clk;
const struct lpss_device_desc *dev_desc;
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
};
/* Devices which need to be in D3 before lpss_iosf_enter_d3_state() proceeds */
static u32 pmc_atom_d3_mask = 0xfe000ffe;
/* LPSS run time quirks */
static unsigned int lpss_quirks;
/*
* LPSS_QUIRK_ALWAYS_POWER_ON: override power state for LPSS DMA device.
*
* The LPSS DMA controller has neither _PS0 nor _PS3 method. Moreover
* it can be powered off automatically whenever the last LPSS device goes down.
* In case of no power any access to the DMA controller will hang the system.
* The behaviour is reproduced on some HP laptops based on Intel BayTrail as
* well as on ASuS T100TA transformer.
*
* This quirk overrides power state of entire LPSS island to keep DMA powered
* on whenever we have at least one other device in use.
*/
#define LPSS_QUIRK_ALWAYS_POWER_ON BIT(0)
/* UART Component Parameter Register */
#define LPSS_UART_CPR 0xF4
#define LPSS_UART_CPR_AFCE BIT(4)
static void lpss_uart_setup(struct lpss_private_data *pdata)
{
unsigned int offset;
u32 val;
offset = pdata->dev_desc->prv_offset + LPSS_TX_INT;
val = readl(pdata->mmio_base + offset);
writel(val | LPSS_TX_INT_MASK, pdata->mmio_base + offset);
val = readl(pdata->mmio_base + LPSS_UART_CPR);
if (!(val & LPSS_UART_CPR_AFCE)) {
offset = pdata->dev_desc->prv_offset + LPSS_GENERAL;
val = readl(pdata->mmio_base + offset);
val |= LPSS_GENERAL_UART_RTS_OVRD;
writel(val, pdata->mmio_base + offset);
}
}
static void lpss_deassert_reset(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);
}
/*
* BYT PWM used for backlight control by the i915 driver on systems without
* the Crystal Cove PMIC.
*/
static struct pwm_lookup byt_pwm_lookup[] = {
PWM_LOOKUP_WITH_MODULE("80860F09:00", 0, "0000:00:02.0",
ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for the right controller depending on the VBT bit, instead of the i915 driver relying on a "pwm_backlight" lookup getting registered which magically points to the right controller. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-2-hdegoede@redhat.com
2019-12-17 04:29:04 +08:00
"pwm_soc_backlight", 0, PWM_POLARITY_NORMAL,
"pwm-lpss-platform"),
};
static void byt_pwm_setup(struct lpss_private_data *pdata)
{
u64 uid;
/* Only call pwm_add_table for the first PWM controller */
if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1)
return;
ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for the right controller depending on the VBT bit, instead of the i915 driver relying on a "pwm_backlight" lookup getting registered which magically points to the right controller. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-2-hdegoede@redhat.com
2019-12-17 04:29:04 +08:00
pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup));
}
#define LPSS_I2C_ENABLE 0x6c
static void byt_i2c_setup(struct lpss_private_data *pdata)
{
acpi_handle handle = pdata->adev->handle;
unsigned long long shared_host = 0;
acpi_status status;
u64 uid;
/* Expected to always be successfull, but better safe then sorry */
if (!acpi_dev_uid_to_integer(pdata->adev, &uid) && uid) {
/* Detect I2C bus shared with PUNIT and ignore its d3 status */
status = acpi_evaluate_integer(handle, "_SEM", NULL, &shared_host);
if (ACPI_SUCCESS(status) && shared_host)
pmc_atom_d3_mask &= ~(BIT_LPSS2_F1_I2C1 << (uid - 1));
}
lpss_deassert_reset(pdata);
if (readl(pdata->mmio_base + pdata->dev_desc->prv_offset))
pdata->fixed_clk_rate = 133000000;
writel(0, pdata->mmio_base + LPSS_I2C_ENABLE);
}
/* BSW PWM used for backlight control by the i915 driver */
static struct pwm_lookup bsw_pwm_lookup[] = {
PWM_LOOKUP_WITH_MODULE("80862288:00", 0, "0000:00:02.0",
ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for the right controller depending on the VBT bit, instead of the i915 driver relying on a "pwm_backlight" lookup getting registered which magically points to the right controller. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-2-hdegoede@redhat.com
2019-12-17 04:29:04 +08:00
"pwm_soc_backlight", 0, PWM_POLARITY_NORMAL,
"pwm-lpss-platform"),
};
static void bsw_pwm_setup(struct lpss_private_data *pdata)
{
u64 uid;
/* Only call pwm_add_table for the first PWM controller */
if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1)
return;
pwm_add_table(bsw_pwm_lookup, ARRAY_SIZE(bsw_pwm_lookup));
}
static const struct property_entry lpt_spi_properties[] = {
PROPERTY_ENTRY_U32("intel,spi-pxa2xx-type", LPSS_LPT_SSP),
{ }
};
static const struct lpss_device_desc lpt_spi_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_LTR
| LPSS_SAVE_CTX,
.prv_offset = 0x800,
.properties = lpt_spi_properties,
};
static const struct lpss_device_desc lpt_i2c_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_LTR | LPSS_SAVE_CTX,
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,
};
static struct property_entry uart_properties[] = {
PROPERTY_ENTRY_U32("reg-io-width", 4),
PROPERTY_ENTRY_U32("reg-shift", 2),
PROPERTY_ENTRY_BOOL("snps,uart-16550-compatible"),
{ },
};
static const struct lpss_device_desc lpt_uart_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_LTR
| LPSS_SAVE_CTX,
.clk_con_id = "baudclk",
.prv_offset = 0x800,
.setup = lpss_uart_setup,
.properties = uart_properties,
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 const struct lpss_device_desc lpt_sdio_dev_desc = {
.flags = LPSS_LTR,
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 06:46:28 +08:00
.prv_offset = 0x1000,
.prv_size_override = 0x1018,
};
static const struct lpss_device_desc byt_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX,
.prv_offset = 0x800,
.setup = byt_pwm_setup,
};
static const struct lpss_device_desc bsw_pwm_dev_desc = {
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets turned off from the _PS3 method of the graphics-card dev: Method (_PS3, 0, Serialized) // _PS3: Power State 3 { ... PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */ PSAT |= 0x03 Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ ... } Where PSAT is the power-status register of the PWM controller. Since the i915 driver will do a pwm_get on the pwm device as it uses it to control the LCD panel backlight, there is a device-link marking the i915 device as a consumer of the pwm device. So that the PWM controller will always be suspended after the i915 driver suspends (which is the right thing to do). This causes the above GFX0 PS3 AML code to run before acpi_lpss.c calls acpi_lpss_save_ctx(). So on these devices the PWM controller will already be off when acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff) as ctx register values. When these bogus values get restored on resume the PWM controller actually keeps working, since most bits are reserved, but this does set bit 3 of the LPSS General purpose register, which for the PWM controller has the following function: "This bit is re-used to support 32kHz slow mode. Default is 19.2MHz as PWM source clock". This causes the clock of the PWM controller to switch from 19.2MHz to 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far there have been few bug reports about this. This is likely because the i915 driver was hardcoding the PWM frequency to 46 KHz, which divided by 600 would result in a PWM frequency of approx. 78 Hz, which mostly still works fine. There are some bug reports about the LCD backlight flickering after suspend/resume which are likely caused by this issue. But with the upcoming patch-series to finally switch the i915 drivers code for external PWM controllers to use the atomic API and to honor the PWM frequency specified in the video BIOS (VBT), this becomes a much bigger problem. On most cases the VBT specifies either 200 Hz or 20 KHz as PWM frequency, which with the mentioned issue ends up being either 1/3 Hz, where the backlight actually visible blinks on and off every 3s, or in 33 Hz and horrible flickering of the backlight. There are a number of possible solutions to this problem: 1. Make acpi_lpss_save_ctx() run before GFX0._PS3 Pro: Clean solution from pov of not medling with save/restore ctx code Con: As mentioned the current ordering is the right thing to do Con: Requires assymmetry in at what suspend/resume phase we do the save vs restore, requiring more suspend/resume ordering hacks in already convoluted acpi_lpss.c suspend/resume code. 2. Do some sort of save once mode for the LPSS ctx Pro: Reasonably clean Con: Needs a new LPSS flag + code changes to handle the flag 3. Detect we have failed to save the ctx registers and do not restore them Pro: Not PWM specific, might help with issues on other LPSS devices too Con: If we can get away with not restoring the ctx why bother with it at all? 4. Do not save the ctx for CHT PWM controllers Pro: Clean, as simple as dropping a flag? Con: Not so simple as dropping a flag, needs a new flag to ensure that we still do lpss_deassert_reset() on device activation. 5. Make the pwm-lpss code fixup the LPSS-context registers Pro: Keeps acpi_lpss.c code clean Con: Moves knowledge of LPSS-context into the pwm-lpss.c code 1 and 5 both do not seem to be a desirable way forward. 3 and 4 seem ok, but they both assume that restoring the LPSS-context registers is not necessary. I have done a couple of test and those do show that restoring the LPSS-context indeed does not seem to be necessary on devices using s2idle suspend (and successfully reaching S0i3). But I have no hardware to test deep / S3 suspend. So I'm not sure that not restoring the context is safe. That leaves solution 2, which is about as simple / clean as 3 and 4, so this commit fixes the described problem by implementing a new LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-3-hdegoede@redhat.com
2020-09-03 19:23:22 +08:00
.flags = LPSS_SAVE_CTX_ONCE | LPSS_NO_D3_DELAY,
.prv_offset = 0x800,
.setup = bsw_pwm_setup,
ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets poked from the _PS0 method of the graphics-card device: Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ If (((Local0 & 0x03) == 0x03)) { PSAT &= 0xFFFFFFFC Local1 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ RSTA = Zero RSTF = Zero RSTA = One RSTF = One PWMB |= 0xC0000000 PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */ } Where PSAT is the power-status register of the PWM controller, so if it is in D3 when the GFX0 device's PS0 method runs then it will turn it on and restore the PWM ctrl register value it saved from its PS3 handler. Note not only does it restore it, it ors it with 0xC0000000 turning it on at a time where we may not want it to get turned on at all. The pwm_get call which the i915 driver does to get a reference to the PWM controller, already adds a device-link making the GFX0 device a consumer of the PWM device. So it should already have been resumed when the above AML runs and the AML should thus not do its undesirable poking of the PWM controller register. But the PCI core powers on PCI devices in the no-irq resume phase and thus calls the troublesome PS0 method in the no-irq resume phase. Where as LPSS devices by default are resumed in the early resume phase. This commit sets the resume_from_noirq flag in the bsw_pwm_dev_desc struct, so that Cherry Trail PWM controllers will be resumed in the no-irq phase. Together with the device-link added by the pwm-get this ensures that the PWM controller will be on when the troublesome PS0 method runs, which stops it from poking the PWM controller. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-2-hdegoede@redhat.com
2020-09-03 19:23:21 +08:00
.resume_from_noirq = true,
};
static const struct lpss_device_desc byt_uart_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX,
.clk_con_id = "baudclk",
.prv_offset = 0x800,
.setup = lpss_uart_setup,
.properties = uart_properties,
};
static const struct lpss_device_desc bsw_uart_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX
| LPSS_NO_D3_DELAY,
.clk_con_id = "baudclk",
.prv_offset = 0x800,
.setup = lpss_uart_setup,
.properties = uart_properties,
};
static const struct property_entry byt_spi_properties[] = {
PROPERTY_ENTRY_U32("intel,spi-pxa2xx-type", LPSS_BYT_SSP),
{ }
};
static const struct lpss_device_desc byt_spi_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX,
.prv_offset = 0x400,
.properties = byt_spi_properties,
};
static const struct lpss_device_desc byt_sdio_dev_desc = {
.flags = LPSS_CLK,
};
static const struct lpss_device_desc byt_i2c_dev_desc = {
.flags = LPSS_CLK | LPSS_SAVE_CTX,
.prv_offset = 0x800,
.setup = byt_i2c_setup,
2018-09-23 21:58:11 +08:00
.resume_from_noirq = true,
};
static const struct lpss_device_desc bsw_i2c_dev_desc = {
.flags = LPSS_CLK | LPSS_SAVE_CTX | LPSS_NO_D3_DELAY,
.prv_offset = 0x800,
.setup = byt_i2c_setup,
2018-09-23 21:58:11 +08:00
.resume_from_noirq = true,
};
static const struct property_entry bsw_spi_properties[] = {
PROPERTY_ENTRY_U32("intel,spi-pxa2xx-type", LPSS_BSW_SSP),
{ }
};
static const struct lpss_device_desc bsw_spi_dev_desc = {
.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX
| LPSS_NO_D3_DELAY,
.prv_offset = 0x400,
.setup = lpss_deassert_reset,
.properties = bsw_spi_properties,
};
static const struct x86_cpu_id lpss_cpu_ids[] = {
X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT, NULL),
X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT, NULL),
{}
};
#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[] = {
/* Generic LPSS devices */
{ "INTL9C60", LPSS_ADDR(lpss_dma_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
/* Lynxpoint LPSS devices */
{ "INT33C0", LPSS_ADDR(lpt_spi_dev_desc) },
{ "INT33C1", LPSS_ADDR(lpt_spi_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", },
/* BayTrail LPSS devices */
{ "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) },
{ "INT33B2", },
{ "INT33FC", },
/* Braswell LPSS devices */
{ "80862286", LPSS_ADDR(lpss_dma_desc) },
{ "80862288", LPSS_ADDR(bsw_pwm_dev_desc) },
{ "8086228A", LPSS_ADDR(bsw_uart_dev_desc) },
{ "8086228E", LPSS_ADDR(bsw_spi_dev_desc) },
{ "808622C0", LPSS_ADDR(lpss_dma_desc) },
{ "808622C1", LPSS_ADDR(bsw_i2c_dev_desc) },
/* Broadwell LPSS devices */
{ "INT3430", LPSS_ADDR(lpt_spi_dev_desc) },
{ "INT3431", LPSS_ADDR(lpt_spi_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) },
{ "INT3437", },
/* Wildcat Point LPSS devices */
{ "INT3438", LPSS_ADDR(lpt_spi_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
{ }
};
#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
/* 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-lpss-atom",
PLATFORM_DEVID_NONE,
NULL, 0);
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 register_device_clock(struct acpi_device *adev,
struct lpss_private_data *pdata)
{
const struct lpss_device_desc *dev_desc = pdata->dev_desc;
const char *devname = dev_name(&adev->dev);
struct clk *clk;
struct lpss_clk_data *clk_data;
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();
if (IS_ERR(lpss_clk_dev))
return PTR_ERR(lpss_clk_dev);
clk_data = platform_get_drvdata(lpss_clk_dev);
if (!clk_data)
return -ENODEV;
clk = clk_data->clk;
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;
parent = clk_data->name;
prv_base = pdata->mmio_base + dev_desc->prv_offset;
if (pdata->fixed_clk_rate) {
clk = clk_register_fixed_rate(NULL, devname, parent, 0,
pdata->fixed_clk_rate);
goto out;
}
if (dev_desc->flags & LPSS_CLK_GATE) {
clk = clk_register_gate(NULL, devname, parent, 0,
prv_base, 0, 0, NULL);
parent = devname;
}
if (dev_desc->flags & LPSS_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,
CLK_FRAC_DIVIDER_POWER_OF_TWO_PS,
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);
}
out:
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
pdata->clk = clk;
clk_register_clkdev(clk, dev_desc->clk_con_id, 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;
}
struct lpss_device_links {
const char *supplier_hid;
const char *supplier_uid;
const char *consumer_hid;
const char *consumer_uid;
u32 flags;
const struct dmi_system_id *dep_missing_ids;
};
/* Please keep this list sorted alphabetically by vendor and model */
static const struct dmi_system_id i2c1_dep_missing_dmi_ids[] = {
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "T200TA"),
},
},
{}
};
/*
* The _DEP method is used to identify dependencies but instead of creating
* device links for every handle in _DEP, only links in the following list are
* created. That is necessary because, in the general case, _DEP can refer to
* devices that might not have drivers, or that are on different buses, or where
* the supplier is not enumerated until after the consumer is probed.
*/
static const struct lpss_device_links lpss_device_links[] = {
/* CHT External sdcard slot controller depends on PMIC I2C ctrl */
{"808622C1", "7", "80860F14", "3", DL_FLAG_PM_RUNTIME},
/* CHT iGPU depends on PMIC I2C controller */
{"808622C1", "7", "LNXVIDEO", NULL, DL_FLAG_PM_RUNTIME},
/* BYT iGPU depends on the Embedded Controller I2C controller (UID 1) */
{"80860F41", "1", "LNXVIDEO", NULL, DL_FLAG_PM_RUNTIME,
i2c1_dep_missing_dmi_ids},
/* BYT CR iGPU depends on PMIC I2C controller (UID 5 on CR) */
2018-09-23 21:58:10 +08:00
{"80860F41", "5", "LNXVIDEO", NULL, DL_FLAG_PM_RUNTIME},
/* BYT iGPU depends on PMIC I2C controller (UID 7 on non CR) */
{"80860F41", "7", "LNXVIDEO", NULL, DL_FLAG_PM_RUNTIME},
};
static bool acpi_lpss_is_supplier(struct acpi_device *adev,
const struct lpss_device_links *link)
{
return acpi_dev_hid_uid_match(adev, link->supplier_hid, link->supplier_uid);
}
static bool acpi_lpss_is_consumer(struct acpi_device *adev,
const struct lpss_device_links *link)
{
return acpi_dev_hid_uid_match(adev, link->consumer_hid, link->consumer_uid);
}
struct hid_uid {
const char *hid;
const char *uid;
};
bus_find_device: Unify the match callback with class_find_device There is an arbitrary difference between the prototypes of bus_find_device() and class_find_device() preventing their callers from passing the same pair of data and match() arguments to both of them, which is the const qualifier used in the prototype of class_find_device(). If that qualifier is also used in the bus_find_device() prototype, it will be possible to pass the same match() callback function to both bus_find_device() and class_find_device(), which will allow some optimizations to be made in order to avoid code duplication going forward. Also with that, constify the "data" parameter as it is passed as a const to the match function. For this reason, change the prototype of bus_find_device() to match the prototype of class_find_device() and adjust its callers to use the const qualifier in accordance with the new prototype of it. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Corey Minyard <minyard@acm.org> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Kershner <david.kershner@unisys.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Airlie <airlied@linux.ie> Cc: Felipe Balbi <balbi@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jonathan Cameron <jic23@kernel.org> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michael Jamet <michael.jamet@intel.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Sebastian Ott <sebott@linux.ibm.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: rafael@kernel.org Acked-by: Corey Minyard <minyard@acm.org> Acked-by: David Kershner <david.kershner@unisys.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> # for the I2C parts Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-15 01:53:59 +08:00
static int match_hid_uid(struct device *dev, const void *data)
{
struct acpi_device *adev = ACPI_COMPANION(dev);
bus_find_device: Unify the match callback with class_find_device There is an arbitrary difference between the prototypes of bus_find_device() and class_find_device() preventing their callers from passing the same pair of data and match() arguments to both of them, which is the const qualifier used in the prototype of class_find_device(). If that qualifier is also used in the bus_find_device() prototype, it will be possible to pass the same match() callback function to both bus_find_device() and class_find_device(), which will allow some optimizations to be made in order to avoid code duplication going forward. Also with that, constify the "data" parameter as it is passed as a const to the match function. For this reason, change the prototype of bus_find_device() to match the prototype of class_find_device() and adjust its callers to use the const qualifier in accordance with the new prototype of it. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Corey Minyard <minyard@acm.org> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Kershner <david.kershner@unisys.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Airlie <airlied@linux.ie> Cc: Felipe Balbi <balbi@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jonathan Cameron <jic23@kernel.org> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michael Jamet <michael.jamet@intel.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Sebastian Ott <sebott@linux.ibm.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: rafael@kernel.org Acked-by: Corey Minyard <minyard@acm.org> Acked-by: David Kershner <david.kershner@unisys.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> # for the I2C parts Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-15 01:53:59 +08:00
const struct hid_uid *id = data;
if (!adev)
return 0;
return acpi_dev_hid_uid_match(adev, id->hid, id->uid);
}
static struct device *acpi_lpss_find_device(const char *hid, const char *uid)
{
struct device *dev;
struct hid_uid data = {
.hid = hid,
.uid = uid,
};
dev = bus_find_device(&platform_bus_type, NULL, &data, match_hid_uid);
if (dev)
return dev;
return bus_find_device(&pci_bus_type, NULL, &data, match_hid_uid);
}
static bool acpi_lpss_dep(struct acpi_device *adev, acpi_handle handle)
{
struct acpi_handle_list dep_devices;
acpi_status status;
int i;
if (!acpi_has_method(adev->handle, "_DEP"))
return false;
status = acpi_evaluate_reference(adev->handle, "_DEP", NULL,
&dep_devices);
if (ACPI_FAILURE(status)) {
dev_dbg(&adev->dev, "Failed to evaluate _DEP.\n");
return false;
}
for (i = 0; i < dep_devices.count; i++) {
if (dep_devices.handles[i] == handle)
return true;
}
return false;
}
static void acpi_lpss_link_consumer(struct device *dev1,
const struct lpss_device_links *link)
{
struct device *dev2;
dev2 = acpi_lpss_find_device(link->consumer_hid, link->consumer_uid);
if (!dev2)
return;
if ((link->dep_missing_ids && dmi_check_system(link->dep_missing_ids))
|| acpi_lpss_dep(ACPI_COMPANION(dev2), ACPI_HANDLE(dev1)))
device_link_add(dev2, dev1, link->flags);
put_device(dev2);
}
static void acpi_lpss_link_supplier(struct device *dev1,
const struct lpss_device_links *link)
{
struct device *dev2;
dev2 = acpi_lpss_find_device(link->supplier_hid, link->supplier_uid);
if (!dev2)
return;
if ((link->dep_missing_ids && dmi_check_system(link->dep_missing_ids))
|| acpi_lpss_dep(ACPI_COMPANION(dev1), ACPI_HANDLE(dev2)))
device_link_add(dev1, dev2, link->flags);
put_device(dev2);
}
static void acpi_lpss_create_device_links(struct acpi_device *adev,
struct platform_device *pdev)
{
int i;
for (i = 0; i < ARRAY_SIZE(lpss_device_links); i++) {
const struct lpss_device_links *link = &lpss_device_links[i];
if (acpi_lpss_is_supplier(adev, link))
acpi_lpss_link_consumer(&pdev->dev, link);
if (acpi_lpss_is_consumer(adev, link))
acpi_lpss_link_supplier(&pdev->dev, link);
}
}
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 acpi_lpss_create_device(struct acpi_device *adev,
const struct acpi_device_id *id)
{
const struct lpss_device_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
struct lpss_private_data *pdata;
struct resource_entry *rentry;
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 list_head resource_list;
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 = (const struct lpss_device_desc *)id->driver_data;
if (!dev_desc) {
pdev = acpi_create_platform_device(adev, NULL);
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_memory_resources(adev, &resource_list);
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 (ret < 0)
goto err_out;
rentry = list_first_entry_or_null(&resource_list, struct resource_entry, node);
if (rentry) {
if (dev_desc->prv_size_override)
pdata->mmio_size = dev_desc->prv_size_override;
else
pdata->mmio_size = resource_size(rentry->res);
pdata->mmio_base = ioremap(rentry->res->start, pdata->mmio_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
acpi_dev_free_resource_list(&resource_list);
if (!pdata->mmio_base) {
/* Avoid acpi_bus_attach() instantiating a pdev for this dev. */
adev->pnp.type.platform_id = 0;
goto out_free;
}
pdata->adev = adev;
pdata->dev_desc = dev_desc;
if (dev_desc->setup)
dev_desc->setup(pdata);
if (dev_desc->flags & LPSS_CLK) {
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
2013-03-07 06:46:20 +08:00
ret = register_device_clock(adev, pdata);
if (ret)
goto out_free;
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
}
/*
* 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.
*/
acpi_device_fix_up_power(adev);
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;
pdev = acpi_create_platform_device(adev, dev_desc->properties);
if (IS_ERR_OR_NULL(pdev)) {
adev->driver_data = NULL;
ret = PTR_ERR(pdev);
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_create_device_links(adev, pdev);
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
out_free:
/* Skip the device, but continue the namespace scan */
ret = 0;
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
kfree(pdata);
return ret;
}
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 = ACPI_COMPANION(dev);
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
struct lpss_private_data *pdata;
unsigned long flags;
int ret;
if (WARN_ON(!adev))
return -ENODEV;
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
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;
}
*val = __lpss_reg_read(pdata, reg);
ret = 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
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 sysfs_emit(buf, "%08x\n", ltr_value);
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 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 const struct attribute_group lpss_attr_group = {
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
.attrs = lpss_attrs,
.name = "lpss_ltr",
};
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);
}
}
#ifdef CONFIG_PM
/**
* acpi_lpss_save_ctx() - Save the private registers of LPSS device
* @dev: LPSS device
* @pdata: pointer to the private data of the 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)
{
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
* @pdata: pointer to the private data of the 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)
{
unsigned int i;
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);
}
}
static void acpi_lpss_d3_to_d0_delay(struct lpss_private_data *pdata)
{
/*
* 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. However some platforms like BSW does not need this delay.
*/
unsigned int delay = 10; /* default 10ms delay */
if (pdata->dev_desc->flags & LPSS_NO_D3_DELAY)
delay = 0;
msleep(delay);
}
ACPI / LPSS: power on when probe() and otherwise when remove() When LPSS drivers are compiled as a module, which is usually the case, the second probe of that driver may fail because the driver is written in an assumption that device is powered on. That is not the case for all drivers. Moreover we would like not drain power in vain. Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power domain. -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Case 1: The I2C probe() repeat. /sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot] /sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot] /sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot] /sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot] /sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot] /sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot] % modprobe i2c-designware-platform i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff Case 2: The power drain in case of SDHCI. /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot] % modprobe -r sdhci-acpi mmc0: card 0001 removed /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0] -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Patch fixes above problems. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-05 05:49:20 +08:00
static int acpi_lpss_activate(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
ret = acpi_dev_resume(dev);
ACPI / LPSS: power on when probe() and otherwise when remove() When LPSS drivers are compiled as a module, which is usually the case, the second probe of that driver may fail because the driver is written in an assumption that device is powered on. That is not the case for all drivers. Moreover we would like not drain power in vain. Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power domain. -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Case 1: The I2C probe() repeat. /sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot] /sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot] /sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot] /sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot] /sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot] /sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot] % modprobe i2c-designware-platform i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff Case 2: The power drain in case of SDHCI. /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot] % modprobe -r sdhci-acpi mmc0: card 0001 removed /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0] -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Patch fixes above problems. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-05 05:49:20 +08:00
if (ret)
return ret;
acpi_lpss_d3_to_d0_delay(pdata);
/*
* This is called only on ->probe() stage where a device is either in
* known state defined by BIOS or most likely powered off. Due to this
* we have to deassert reset line to be sure that ->probe() will
* recognize the device.
*/
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets turned off from the _PS3 method of the graphics-card dev: Method (_PS3, 0, Serialized) // _PS3: Power State 3 { ... PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */ PSAT |= 0x03 Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ ... } Where PSAT is the power-status register of the PWM controller. Since the i915 driver will do a pwm_get on the pwm device as it uses it to control the LCD panel backlight, there is a device-link marking the i915 device as a consumer of the pwm device. So that the PWM controller will always be suspended after the i915 driver suspends (which is the right thing to do). This causes the above GFX0 PS3 AML code to run before acpi_lpss.c calls acpi_lpss_save_ctx(). So on these devices the PWM controller will already be off when acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff) as ctx register values. When these bogus values get restored on resume the PWM controller actually keeps working, since most bits are reserved, but this does set bit 3 of the LPSS General purpose register, which for the PWM controller has the following function: "This bit is re-used to support 32kHz slow mode. Default is 19.2MHz as PWM source clock". This causes the clock of the PWM controller to switch from 19.2MHz to 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far there have been few bug reports about this. This is likely because the i915 driver was hardcoding the PWM frequency to 46 KHz, which divided by 600 would result in a PWM frequency of approx. 78 Hz, which mostly still works fine. There are some bug reports about the LCD backlight flickering after suspend/resume which are likely caused by this issue. But with the upcoming patch-series to finally switch the i915 drivers code for external PWM controllers to use the atomic API and to honor the PWM frequency specified in the video BIOS (VBT), this becomes a much bigger problem. On most cases the VBT specifies either 200 Hz or 20 KHz as PWM frequency, which with the mentioned issue ends up being either 1/3 Hz, where the backlight actually visible blinks on and off every 3s, or in 33 Hz and horrible flickering of the backlight. There are a number of possible solutions to this problem: 1. Make acpi_lpss_save_ctx() run before GFX0._PS3 Pro: Clean solution from pov of not medling with save/restore ctx code Con: As mentioned the current ordering is the right thing to do Con: Requires assymmetry in at what suspend/resume phase we do the save vs restore, requiring more suspend/resume ordering hacks in already convoluted acpi_lpss.c suspend/resume code. 2. Do some sort of save once mode for the LPSS ctx Pro: Reasonably clean Con: Needs a new LPSS flag + code changes to handle the flag 3. Detect we have failed to save the ctx registers and do not restore them Pro: Not PWM specific, might help with issues on other LPSS devices too Con: If we can get away with not restoring the ctx why bother with it at all? 4. Do not save the ctx for CHT PWM controllers Pro: Clean, as simple as dropping a flag? Con: Not so simple as dropping a flag, needs a new flag to ensure that we still do lpss_deassert_reset() on device activation. 5. Make the pwm-lpss code fixup the LPSS-context registers Pro: Keeps acpi_lpss.c code clean Con: Moves knowledge of LPSS-context into the pwm-lpss.c code 1 and 5 both do not seem to be a desirable way forward. 3 and 4 seem ok, but they both assume that restoring the LPSS-context registers is not necessary. I have done a couple of test and those do show that restoring the LPSS-context indeed does not seem to be necessary on devices using s2idle suspend (and successfully reaching S0i3). But I have no hardware to test deep / S3 suspend. So I'm not sure that not restoring the context is safe. That leaves solution 2, which is about as simple / clean as 3 and 4, so this commit fixes the described problem by implementing a new LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-3-hdegoede@redhat.com
2020-09-03 19:23:22 +08:00
if (pdata->dev_desc->flags & (LPSS_SAVE_CTX | LPSS_SAVE_CTX_ONCE))
ACPI / LPSS: power on when probe() and otherwise when remove() When LPSS drivers are compiled as a module, which is usually the case, the second probe of that driver may fail because the driver is written in an assumption that device is powered on. That is not the case for all drivers. Moreover we would like not drain power in vain. Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power domain. -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Case 1: The I2C probe() repeat. /sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot] /sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot] /sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot] /sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot] /sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot] /sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot] % modprobe i2c-designware-platform i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff Case 2: The power drain in case of SDHCI. /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot] % modprobe -r sdhci-acpi mmc0: card 0001 removed /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0] -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Patch fixes above problems. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-05 05:49:20 +08:00
lpss_deassert_reset(pdata);
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets turned off from the _PS3 method of the graphics-card dev: Method (_PS3, 0, Serialized) // _PS3: Power State 3 { ... PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */ PSAT |= 0x03 Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ ... } Where PSAT is the power-status register of the PWM controller. Since the i915 driver will do a pwm_get on the pwm device as it uses it to control the LCD panel backlight, there is a device-link marking the i915 device as a consumer of the pwm device. So that the PWM controller will always be suspended after the i915 driver suspends (which is the right thing to do). This causes the above GFX0 PS3 AML code to run before acpi_lpss.c calls acpi_lpss_save_ctx(). So on these devices the PWM controller will already be off when acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff) as ctx register values. When these bogus values get restored on resume the PWM controller actually keeps working, since most bits are reserved, but this does set bit 3 of the LPSS General purpose register, which for the PWM controller has the following function: "This bit is re-used to support 32kHz slow mode. Default is 19.2MHz as PWM source clock". This causes the clock of the PWM controller to switch from 19.2MHz to 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far there have been few bug reports about this. This is likely because the i915 driver was hardcoding the PWM frequency to 46 KHz, which divided by 600 would result in a PWM frequency of approx. 78 Hz, which mostly still works fine. There are some bug reports about the LCD backlight flickering after suspend/resume which are likely caused by this issue. But with the upcoming patch-series to finally switch the i915 drivers code for external PWM controllers to use the atomic API and to honor the PWM frequency specified in the video BIOS (VBT), this becomes a much bigger problem. On most cases the VBT specifies either 200 Hz or 20 KHz as PWM frequency, which with the mentioned issue ends up being either 1/3 Hz, where the backlight actually visible blinks on and off every 3s, or in 33 Hz and horrible flickering of the backlight. There are a number of possible solutions to this problem: 1. Make acpi_lpss_save_ctx() run before GFX0._PS3 Pro: Clean solution from pov of not medling with save/restore ctx code Con: As mentioned the current ordering is the right thing to do Con: Requires assymmetry in at what suspend/resume phase we do the save vs restore, requiring more suspend/resume ordering hacks in already convoluted acpi_lpss.c suspend/resume code. 2. Do some sort of save once mode for the LPSS ctx Pro: Reasonably clean Con: Needs a new LPSS flag + code changes to handle the flag 3. Detect we have failed to save the ctx registers and do not restore them Pro: Not PWM specific, might help with issues on other LPSS devices too Con: If we can get away with not restoring the ctx why bother with it at all? 4. Do not save the ctx for CHT PWM controllers Pro: Clean, as simple as dropping a flag? Con: Not so simple as dropping a flag, needs a new flag to ensure that we still do lpss_deassert_reset() on device activation. 5. Make the pwm-lpss code fixup the LPSS-context registers Pro: Keeps acpi_lpss.c code clean Con: Moves knowledge of LPSS-context into the pwm-lpss.c code 1 and 5 both do not seem to be a desirable way forward. 3 and 4 seem ok, but they both assume that restoring the LPSS-context registers is not necessary. I have done a couple of test and those do show that restoring the LPSS-context indeed does not seem to be necessary on devices using s2idle suspend (and successfully reaching S0i3). But I have no hardware to test deep / S3 suspend. So I'm not sure that not restoring the context is safe. That leaves solution 2, which is about as simple / clean as 3 and 4, so this commit fixes the described problem by implementing a new LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-3-hdegoede@redhat.com
2020-09-03 19:23:22 +08:00
#ifdef CONFIG_PM
if (pdata->dev_desc->flags & LPSS_SAVE_CTX_ONCE)
acpi_lpss_save_ctx(dev, pdata);
#endif
ACPI / LPSS: power on when probe() and otherwise when remove() When LPSS drivers are compiled as a module, which is usually the case, the second probe of that driver may fail because the driver is written in an assumption that device is powered on. That is not the case for all drivers. Moreover we would like not drain power in vain. Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power domain. -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Case 1: The I2C probe() repeat. /sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot] /sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot] /sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot] /sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot] /sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot] /sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot] % modprobe i2c-designware-platform i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff Case 2: The power drain in case of SDHCI. /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot] % modprobe -r sdhci-acpi mmc0: card 0001 removed /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0] -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Patch fixes above problems. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-05 05:49:20 +08:00
return 0;
}
static void acpi_lpss_dismiss(struct device *dev)
{
acpi_dev_suspend(dev, false);
ACPI / LPSS: power on when probe() and otherwise when remove() When LPSS drivers are compiled as a module, which is usually the case, the second probe of that driver may fail because the driver is written in an assumption that device is powered on. That is not the case for all drivers. Moreover we would like not drain power in vain. Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power domain. -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Case 1: The I2C probe() repeat. /sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot] /sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot] /sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot] /sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot] /sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot] /sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot] % modprobe i2c-designware-platform i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff Case 2: The power drain in case of SDHCI. /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot] % modprobe -r sdhci-acpi mmc0: card 0001 removed /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0] -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Patch fixes above problems. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-05 05:49:20 +08:00
}
/* IOSF SB for LPSS island */
#define LPSS_IOSF_UNIT_LPIOEP 0xA0
#define LPSS_IOSF_UNIT_LPIO1 0xAB
#define LPSS_IOSF_UNIT_LPIO2 0xAC
#define LPSS_IOSF_PMCSR 0x84
#define LPSS_PMCSR_D0 0
#define LPSS_PMCSR_D3hot 3
#define LPSS_PMCSR_Dx_MASK GENMASK(1, 0)
#define LPSS_IOSF_GPIODEF0 0x154
#define LPSS_GPIODEF0_DMA1_D3 BIT(2)
#define LPSS_GPIODEF0_DMA2_D3 BIT(3)
#define LPSS_GPIODEF0_DMA_D3_MASK GENMASK(3, 2)
#define LPSS_GPIODEF0_DMA_LLP BIT(13)
static DEFINE_MUTEX(lpss_iosf_mutex);
static bool lpss_iosf_d3_entered = true;
static void lpss_iosf_enter_d3_state(void)
{
u32 value1 = 0;
u32 mask1 = LPSS_GPIODEF0_DMA_D3_MASK | LPSS_GPIODEF0_DMA_LLP;
u32 value2 = LPSS_PMCSR_D3hot;
u32 mask2 = LPSS_PMCSR_Dx_MASK;
/*
* PMC provides an information about actual status of the LPSS devices.
* Here we read the values related to LPSS power island, i.e. LPSS
* devices, excluding both LPSS DMA controllers, along with SCC domain.
*/
u32 func_dis, d3_sts_0, pmc_status;
int ret;
ret = pmc_atom_read(PMC_FUNC_DIS, &func_dis);
if (ret)
return;
mutex_lock(&lpss_iosf_mutex);
ret = pmc_atom_read(PMC_D3_STS_0, &d3_sts_0);
if (ret)
goto exit;
/*
* Get the status of entire LPSS power island per device basis.
* Shutdown both LPSS DMA controllers if and only if all other devices
* are already in D3hot.
*/
pmc_status = (~(d3_sts_0 | func_dis)) & pmc_atom_d3_mask;
if (pmc_status)
goto exit;
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO1, MBI_CFG_WRITE,
LPSS_IOSF_PMCSR, value2, mask2);
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO2, MBI_CFG_WRITE,
LPSS_IOSF_PMCSR, value2, mask2);
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
LPSS_IOSF_GPIODEF0, value1, mask1);
lpss_iosf_d3_entered = true;
exit:
mutex_unlock(&lpss_iosf_mutex);
}
static void lpss_iosf_exit_d3_state(void)
{
u32 value1 = LPSS_GPIODEF0_DMA1_D3 | LPSS_GPIODEF0_DMA2_D3 |
LPSS_GPIODEF0_DMA_LLP;
u32 mask1 = LPSS_GPIODEF0_DMA_D3_MASK | LPSS_GPIODEF0_DMA_LLP;
u32 value2 = LPSS_PMCSR_D0;
u32 mask2 = LPSS_PMCSR_Dx_MASK;
mutex_lock(&lpss_iosf_mutex);
if (!lpss_iosf_d3_entered)
goto exit;
lpss_iosf_d3_entered = false;
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
LPSS_IOSF_GPIODEF0, value1, mask1);
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO2, MBI_CFG_WRITE,
LPSS_IOSF_PMCSR, value2, mask2);
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO1, MBI_CFG_WRITE,
LPSS_IOSF_PMCSR, value2, mask2);
exit:
mutex_unlock(&lpss_iosf_mutex);
}
static int acpi_lpss_suspend(struct device *dev, bool wakeup)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_save_ctx(dev, pdata);
ret = acpi_dev_suspend(dev, wakeup);
/*
* This call must be last in the sequence, otherwise PMC will return
* wrong status for devices being about to be powered off. See
* lpss_iosf_enter_d3_state() for further information.
*/
if (acpi_target_system_state() == ACPI_STATE_S0 &&
lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_enter_d3_state();
return ret;
}
static int acpi_lpss_resume(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
/*
* This call is kept first to be in symmetry with
* acpi_lpss_runtime_suspend() one.
*/
if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_exit_d3_state();
ret = acpi_dev_resume(dev);
if (ret)
return ret;
acpi_lpss_d3_to_d0_delay(pdata);
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets turned off from the _PS3 method of the graphics-card dev: Method (_PS3, 0, Serialized) // _PS3: Power State 3 { ... PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */ PSAT |= 0x03 Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */ ... } Where PSAT is the power-status register of the PWM controller. Since the i915 driver will do a pwm_get on the pwm device as it uses it to control the LCD panel backlight, there is a device-link marking the i915 device as a consumer of the pwm device. So that the PWM controller will always be suspended after the i915 driver suspends (which is the right thing to do). This causes the above GFX0 PS3 AML code to run before acpi_lpss.c calls acpi_lpss_save_ctx(). So on these devices the PWM controller will already be off when acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff) as ctx register values. When these bogus values get restored on resume the PWM controller actually keeps working, since most bits are reserved, but this does set bit 3 of the LPSS General purpose register, which for the PWM controller has the following function: "This bit is re-used to support 32kHz slow mode. Default is 19.2MHz as PWM source clock". This causes the clock of the PWM controller to switch from 19.2MHz to 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far there have been few bug reports about this. This is likely because the i915 driver was hardcoding the PWM frequency to 46 KHz, which divided by 600 would result in a PWM frequency of approx. 78 Hz, which mostly still works fine. There are some bug reports about the LCD backlight flickering after suspend/resume which are likely caused by this issue. But with the upcoming patch-series to finally switch the i915 drivers code for external PWM controllers to use the atomic API and to honor the PWM frequency specified in the video BIOS (VBT), this becomes a much bigger problem. On most cases the VBT specifies either 200 Hz or 20 KHz as PWM frequency, which with the mentioned issue ends up being either 1/3 Hz, where the backlight actually visible blinks on and off every 3s, or in 33 Hz and horrible flickering of the backlight. There are a number of possible solutions to this problem: 1. Make acpi_lpss_save_ctx() run before GFX0._PS3 Pro: Clean solution from pov of not medling with save/restore ctx code Con: As mentioned the current ordering is the right thing to do Con: Requires assymmetry in at what suspend/resume phase we do the save vs restore, requiring more suspend/resume ordering hacks in already convoluted acpi_lpss.c suspend/resume code. 2. Do some sort of save once mode for the LPSS ctx Pro: Reasonably clean Con: Needs a new LPSS flag + code changes to handle the flag 3. Detect we have failed to save the ctx registers and do not restore them Pro: Not PWM specific, might help with issues on other LPSS devices too Con: If we can get away with not restoring the ctx why bother with it at all? 4. Do not save the ctx for CHT PWM controllers Pro: Clean, as simple as dropping a flag? Con: Not so simple as dropping a flag, needs a new flag to ensure that we still do lpss_deassert_reset() on device activation. 5. Make the pwm-lpss code fixup the LPSS-context registers Pro: Keeps acpi_lpss.c code clean Con: Moves knowledge of LPSS-context into the pwm-lpss.c code 1 and 5 both do not seem to be a desirable way forward. 3 and 4 seem ok, but they both assume that restoring the LPSS-context registers is not necessary. I have done a couple of test and those do show that restoring the LPSS-context indeed does not seem to be necessary on devices using s2idle suspend (and successfully reaching S0i3). But I have no hardware to test deep / S3 suspend. So I'm not sure that not restoring the context is safe. That leaves solution 2, which is about as simple / clean as 3 and 4, so this commit fixes the described problem by implementing a new LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-3-hdegoede@redhat.com
2020-09-03 19:23:22 +08:00
if (pdata->dev_desc->flags & (LPSS_SAVE_CTX | LPSS_SAVE_CTX_ONCE))
acpi_lpss_restore_ctx(dev, pdata);
return 0;
}
#ifdef CONFIG_PM_SLEEP
2018-09-23 21:58:11 +08:00
static int acpi_lpss_do_suspend_late(struct device *dev)
{
ACPI / PM: Take SMART_SUSPEND driver flag into account Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in its system suspend callbacks. [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume() is an optimization, because if is not passed, all of the subsequent checks may be skipped and some of them are much more overhead in general.] Also use the observation that if the device is in runtime suspend at the beginning of the "late" phase of a system-wide suspend-like transition, its state cannot change going forward (runtime PM is disabled for it at that time) until the transition is over and the subsequent system-wide PM callbacks should be skipped for it (as they generally assume the device to not be suspended), so add checks for that in acpi_subsys_suspend_late/noirq() and acpi_subsys_freeze_late/noirq(). Moreover, if acpi_subsys_resume_noirq() is called during the subsequent system-wide resume transition and if the device was left in runtime suspend previously, its runtime PM status needs to be changed to "active" as it is going to be put into the full-power state going forward, so add a check for that too in there. In turn, if acpi_subsys_thaw_noirq() runs after the device has been left in runtime suspend, the subsequent "thaw" callbacks need to be skipped for it (as they may not work correctly with a suspended device), so set the power.direct_complete flag for the device then to make the PM core skip those callbacks. On top of the above, make the analogous changes in the acpi_lpss driver that uses the ACPI PM domain callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 16:10:16 +08:00
int ret;
if (dev_pm_skip_suspend(dev))
ACPI / PM: Take SMART_SUSPEND driver flag into account Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in its system suspend callbacks. [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume() is an optimization, because if is not passed, all of the subsequent checks may be skipped and some of them are much more overhead in general.] Also use the observation that if the device is in runtime suspend at the beginning of the "late" phase of a system-wide suspend-like transition, its state cannot change going forward (runtime PM is disabled for it at that time) until the transition is over and the subsequent system-wide PM callbacks should be skipped for it (as they generally assume the device to not be suspended), so add checks for that in acpi_subsys_suspend_late/noirq() and acpi_subsys_freeze_late/noirq(). Moreover, if acpi_subsys_resume_noirq() is called during the subsequent system-wide resume transition and if the device was left in runtime suspend previously, its runtime PM status needs to be changed to "active" as it is going to be put into the full-power state going forward, so add a check for that too in there. In turn, if acpi_subsys_thaw_noirq() runs after the device has been left in runtime suspend, the subsequent "thaw" callbacks need to be skipped for it (as they may not work correctly with a suspended device), so set the power.direct_complete flag for the device then to make the PM core skip those callbacks. On top of the above, make the analogous changes in the acpi_lpss driver that uses the ACPI PM domain callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 16:10:16 +08:00
return 0;
ACPI / PM: Take SMART_SUSPEND driver flag into account Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in its system suspend callbacks. [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume() is an optimization, because if is not passed, all of the subsequent checks may be skipped and some of them are much more overhead in general.] Also use the observation that if the device is in runtime suspend at the beginning of the "late" phase of a system-wide suspend-like transition, its state cannot change going forward (runtime PM is disabled for it at that time) until the transition is over and the subsequent system-wide PM callbacks should be skipped for it (as they generally assume the device to not be suspended), so add checks for that in acpi_subsys_suspend_late/noirq() and acpi_subsys_freeze_late/noirq(). Moreover, if acpi_subsys_resume_noirq() is called during the subsequent system-wide resume transition and if the device was left in runtime suspend previously, its runtime PM status needs to be changed to "active" as it is going to be put into the full-power state going forward, so add a check for that too in there. In turn, if acpi_subsys_thaw_noirq() runs after the device has been left in runtime suspend, the subsequent "thaw" callbacks need to be skipped for it (as they may not work correctly with a suspended device), so set the power.direct_complete flag for the device then to make the PM core skip those callbacks. On top of the above, make the analogous changes in the acpi_lpss driver that uses the ACPI PM domain callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 16:10:16 +08:00
ret = pm_generic_suspend_late(dev);
return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
}
2018-09-23 21:58:11 +08:00
static int acpi_lpss_suspend_late(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
if (pdata->dev_desc->resume_from_noirq)
return 0;
return acpi_lpss_do_suspend_late(dev);
}
static int acpi_lpss_suspend_noirq(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
if (pdata->dev_desc->resume_from_noirq) {
/*
* The driver's ->suspend_late callback will be invoked by
* acpi_lpss_do_suspend_late(), with the assumption that the
* driver really wanted to run that code in ->suspend_noirq, but
* it could not run after acpi_dev_suspend() and the driver
* expected the latter to be called in the "late" phase.
*/
2018-09-23 21:58:11 +08:00
ret = acpi_lpss_do_suspend_late(dev);
if (ret)
return ret;
}
return acpi_subsys_suspend_noirq(dev);
}
static int acpi_lpss_do_resume_early(struct device *dev)
{
int ret = acpi_lpss_resume(dev);
return ret ? ret : pm_generic_resume_early(dev);
}
2018-09-23 21:58:11 +08:00
static int acpi_lpss_resume_early(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
if (pdata->dev_desc->resume_from_noirq)
return 0;
if (dev_pm_skip_resume(dev))
PM: sleep: core: Do not skip callbacks in the resume phase The current code in device_resume_noirq() causes the entire early resume and resume phases of device suspend to be skipped for devices for which the noirq resume phase have been skipped (due to the LEAVE_SUSPENDED flag being set) on the premise that those devices should stay in runtime-suspend after system-wide resume. However, that may not be correct in two situations. First, the middle layer (subsystem) noirq resume callback may be missing for a given device, but its early resume callback may be present and it may need to do something even if it decides to skip the driver callback. Second, if the device's wakeup settings were adjusted in the suspend phase without resuming the device (that was in runtime suspend at that time), they most likely need to be adjusted again in the resume phase and so the driver callback in that phase needs to be run. For the above reason, modify the core to allow the middle layer ->resume_late callback to run even if its ->resume_noirq callback is missing (and the core has skipped the driver-level callback in that phase) and to allow all device callbacks to run in the resume phase. Also make the core set the PM-runtime status of devices with SMART_SUSPEND set whose resume callbacks are not skipped to "active" in the "noirq" resume phase and update the affected subsystems (PCI and ACPI) accordingly. After this change, middle-layer (subsystem) callbacks will always be invoked in all phases of system suspend and resume and driver callbacks will always run in the prepare, suspend, resume, and complete phases for all devices. For devices with SMART_SUSPEND set, driver callbacks will be skipped in the late and noirq phases of system suspend if those devices remain in runtime suspend in __device_suspend_late(). Driver callbacks will also be skipped for them during the noirq and early phases of the "thaw" transition related to hibernation in that case. Setting LEAVE_SUSPENDED means that the driver allows its callbacks to be skipped in the noirq and early phases of system resume, but some additional conditions need to be met for that to happen (among other things, the power.may_skip_resume flag needs to be set for the device during system suspend for the driver callbacks to be skipped during the subsequent resume transition). For all devices with SMART_SUSPEND set whose driver callbacks are invoked during system resume, the PM-runtime status will be set to "active" (by the core). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-19 00:52:08 +08:00
return 0;
2018-09-23 21:58:11 +08:00
return acpi_lpss_do_resume_early(dev);
}
static int acpi_lpss_resume_noirq(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
/* Follow acpi_subsys_resume_noirq(). */
if (dev_pm_skip_resume(dev))
return 0;
ret = pm_generic_resume_noirq(dev);
2018-09-23 21:58:11 +08:00
if (ret)
return ret;
if (!pdata->dev_desc->resume_from_noirq)
return 0;
2018-09-23 21:58:11 +08:00
/*
* The driver's ->resume_early callback will be invoked by
* acpi_lpss_do_resume_early(), with the assumption that the driver
* really wanted to run that code in ->resume_noirq, but it could not
* run before acpi_dev_resume() and the driver expected the latter to be
* called in the "early" phase.
*/
return acpi_lpss_do_resume_early(dev);
}
static int acpi_lpss_do_restore_early(struct device *dev)
{
int ret = acpi_lpss_resume(dev);
return ret ? ret : pm_generic_restore_early(dev);
2018-09-23 21:58:11 +08:00
}
static int acpi_lpss_restore_early(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
if (pdata->dev_desc->resume_from_noirq)
return 0;
return acpi_lpss_do_restore_early(dev);
2018-09-23 21:58:11 +08:00
}
static int acpi_lpss_restore_noirq(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
ret = pm_generic_restore_noirq(dev);
if (ret)
return ret;
if (!pdata->dev_desc->resume_from_noirq)
return 0;
/* This is analogous to what happens in acpi_lpss_resume_noirq(). */
return acpi_lpss_do_restore_early(dev);
}
static int acpi_lpss_do_poweroff_late(struct device *dev)
{
int ret = pm_generic_poweroff_late(dev);
return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
}
static int acpi_lpss_poweroff_late(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
if (dev_pm_skip_suspend(dev))
return 0;
if (pdata->dev_desc->resume_from_noirq)
return 0;
return acpi_lpss_do_poweroff_late(dev);
}
static int acpi_lpss_poweroff_noirq(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
if (dev_pm_skip_suspend(dev))
return 0;
if (pdata->dev_desc->resume_from_noirq) {
/* This is analogous to the acpi_lpss_suspend_noirq() case. */
int ret = acpi_lpss_do_poweroff_late(dev);
if (ret)
return ret;
}
return pm_generic_poweroff_noirq(dev);
}
#endif /* CONFIG_PM_SLEEP */
static int acpi_lpss_runtime_suspend(struct device *dev)
{
int ret = pm_generic_runtime_suspend(dev);
return ret ? ret : acpi_lpss_suspend(dev, true);
}
static int acpi_lpss_runtime_resume(struct device *dev)
{
int ret = acpi_lpss_resume(dev);
return ret ? ret : pm_generic_runtime_resume(dev);
}
#endif /* CONFIG_PM */
static struct dev_pm_domain acpi_lpss_pm_domain = {
ACPI / LPSS: power on when probe() and otherwise when remove() When LPSS drivers are compiled as a module, which is usually the case, the second probe of that driver may fail because the driver is written in an assumption that device is powered on. That is not the case for all drivers. Moreover we would like not drain power in vain. Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power domain. -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Case 1: The I2C probe() repeat. /sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot] /sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot] /sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot] /sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot] /sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot] /sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot] % modprobe i2c-designware-platform i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff Case 2: The power drain in case of SDHCI. /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot] % modprobe -r sdhci-acpi mmc0: card 0001 removed /sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0] /sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0] -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- Patch fixes above problems. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-05 05:49:20 +08:00
#ifdef CONFIG_PM
.activate = acpi_lpss_activate,
.dismiss = acpi_lpss_dismiss,
#endif
.ops = {
#ifdef CONFIG_PM
#ifdef CONFIG_PM_SLEEP
.prepare = acpi_subsys_prepare,
.complete = acpi_subsys_complete,
.suspend = acpi_subsys_suspend,
.suspend_late = acpi_lpss_suspend_late,
2018-09-23 21:58:11 +08:00
.suspend_noirq = acpi_lpss_suspend_noirq,
.resume_noirq = acpi_lpss_resume_noirq,
.resume_early = acpi_lpss_resume_early,
.freeze = acpi_subsys_freeze,
.poweroff = acpi_subsys_poweroff,
.poweroff_late = acpi_lpss_poweroff_late,
.poweroff_noirq = acpi_lpss_poweroff_noirq,
.restore_noirq = acpi_lpss_restore_noirq,
.restore_early = acpi_lpss_restore_early,
#endif
.runtime_suspend = acpi_lpss_runtime_suspend,
.runtime_resume = acpi_lpss_runtime_resume,
#endif
},
};
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 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;
adev = ACPI_COMPANION(&pdev->dev);
if (!adev)
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;
pdata = acpi_driver_data(adev);
if (!pdata)
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 06:46:28 +08:00
return 0;
if (pdata->mmio_base &&
pdata->mmio_size < pdata->dev_desc->prv_offset + LPSS_LTR_SIZE) {
ACPI / LPSS: Add support for exposing LTR registers to user space Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have registers providing access to LTR (Latency Tolerance Reporting) functionality that allows software to monitor and possibly influence the aggressiveness of the platform's active-state power management. For each LPSS device, there are two modes of operation related to LTR, the auto mode and the software mode. In the auto mode the LTR is set up by the platform firmware and managed by hardware. Software can only read the LTR register values to monitor the platform's behavior. In the software mode it is possible to use LTR to control the extent to which the platform will use its built-in power management features. This changeset adds support for reading the LPSS devices' LTR registers and exposing their values to user space for monitoring and diagnostics purposes. It re-uses the MMIO mappings created to access the LPSS devices' clock registers for reading the values of the LTR registers and exposes them to user space through sysfs device attributes. Namely, a new atrribute group, lpss_ltr, is created for each LPSS device. It contains three new attributes: ltr_mode, auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the LTR mode being used at the moment (software vs auto) and the other two contain the actual register values (raw) whose meaning depends on the LTR mode. All of these attributes are read-only. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-07 06:46:28 +08:00
dev_err(&pdev->dev, "MMIO size insufficient to access LTR\n");
return 0;
}
switch (action) {
case BUS_NOTIFY_BIND_DRIVER:
dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
break;
case BUS_NOTIFY_DRIVER_NOT_BOUND:
case BUS_NOTIFY_UNBOUND_DRIVER:
dev_pm_domain_set(&pdev->dev, NULL);
break;
case BUS_NOTIFY_ADD_DEVICE:
dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(&pdev->dev.kobj,
&lpss_attr_group);
break;
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
dev_pm_domain_set(&pdev->dev, NULL);
break;
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
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,
};
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->flags & LPSS_LTR))
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,
.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)
{
const struct x86_cpu_id *id;
int ret;
ret = lpss_atom_clk_init();
if (ret)
return;
id = x86_match_cpu(lpss_cpu_ids);
if (id)
lpss_quirks |= LPSS_QUIRK_ALWAYS_POWER_ON;
bus_register_notifier(&platform_bus_type, &acpi_lpss_nb);
acpi_scan_add_handler(&lpss_handler);
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
}
#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 */