summaryrefslogtreecommitdiff
path: root/drivers/acpi/acpi_lpss.c
AgeCommit message (Collapse)Author
2014-04-07Rewind v3.13-rc3+ (78fd82238d0e5716) to v3.12Scott Wood
2013-11-16Merge branch 'acpi-lpss'Rafael J. Wysocki
* acpi-lpss: ACPI / LPSS: add ACPI IDs for newer Intel PCHs
2013-11-12ACPI / LPSS: add ACPI IDs for newer Intel PCHsMika Westerberg
Some recent Intel PCHs with LPSS have different ACPI IDs for the LPSS devices, so add these to the list as well. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-10ACPI / LPSS: fix UART Auto Flow ControlHeikki Krogerus
There is an additional bit in the GENERAL register on newer silicon that needs to be set or UART's RTS pin fails to reflect the flow control settings in the Modem Control Register. This will fix an issue where the RTS pin of the UART stays always at 1.8V, regardless of the register settings. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-02ACPI / LPSS: don't crash if a device has no MMIO resourcesMika Westerberg
Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ resources returned in their _CRS method. However, Apple Macbook Air with Haswell has LPSS devices enumerated from PCI bus instead and _CRS method returns only an interrupt number (but the device has _HID set that causes the scan handler to match it). The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource is found for the device and in case of Macbook Air it is never found. That leads to a NULL pointer dereference in register_device_clock(). Correct this by always setting the pdata->dev_desc. Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-28Merge branch 'acpi-lpss'Rafael J. Wysocki
* acpi-lpss: ACPI / LPSS: override SDIO private register space size from ACPI tables ACPI / LPSS: mask the UART TX completion interrupt ACPI / LPSS: add support for Intel BayTrail Conflicts: drivers/acpi/acpi_lpss.c (with commit b9e95fc)
2013-06-19ACPI / LPSS: Power up LPSS devices during enumerationRafael J. Wysocki
Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-18ACPI / LPSS: override SDIO private register space size from ACPI tablesMika Westerberg
The SDIO device in Lynxpoint has its LTR registers reserved for a WiFi device (a child of the SDIO device) in the ACPI namespace even though those registers physically belong to the SDIO device itself. In order to be able to access the SDIO LTR registers from the ACPI LPSS driver for diagnostic purposes we need to use a size override for the SDIO private register space. Add a possibility to override the size of the private register space of an LPSS device provided by the ACPI tables in the ACPI LPSS driver and set the correct size for the SDIO device in there. [rjw: Changelog] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-18ACPI / LPSS: mask the UART TX completion interruptHeikki Krogerus
Intel LPSS provides an extra TX byte counter and an extra TX completion interrupt for some of its bus controllers. However, there is no use for the extra UART interrupt and it has to be masked out during initialization. Otherwise, if the firmware does not mask the interrupt and the driver does not clear it, it may cause an interrupt flood freezing the board to happen. Add code masking that problematic interrupt to the ACPI LPSS driver. [rjw: Changelog] Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-18ACPI / LPSS: add support for Intel BayTrailMika Westerberg
Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with few differences. Peripherals are clocked with different speeds (typically lower) and the clock is not always gated. To support this we add possibility to share a common fixed rate clock and make clock gating optional. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-14ACPI / LPSS: register clock device for Lynxpoint DMA properlyRafael J. Wysocki
The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-03-24ACPI / LPSS: make code less confusing for readerAndy Shevchenko
The excerpt like this: if (err) { err = 0; goto error_out; } makes a reader confused even if it's commented. Let's do necessary actions and return no error explicitly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-21ACPI / LPSS: Add support for exposing LTR registers to user spaceRafael J. Wysocki
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-21ACPI / scan: Add special handler for Intel Lynxpoint LPSS devicesRafael J. Wysocki
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>