summaryrefslogtreecommitdiff
path: root/src/southbridge/intel/lynxpoint/acpi
AgeCommit message (Collapse)Author
2014-11-25intel: Remove IRQ1 from possible PIRQ assignemnt.Vladimir Serbinenko
According to spec IRQ1 isn't available for PIRQ assignment. Has gone unnoticed probably because modern OS use MSI or at least APIC and even with noapic don't use IRQ1 with PCI IRQs. Change-Id: Idc7db249007df629b27e8cae41cc80358d5306f6 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/7478 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins)
2014-09-22haswell: Move to per-device ACPIVladimir Serbinenko
Change-Id: Ic724dcf516d9cb78e89698da603151a32d24e978 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6814 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-08-10lynxpoint: Add interrupt for GPIO controller in ACPI deviceDuncan Laurie
The GPIO controller uses IRQ14 as an active high level triggered source for GPIOs that are configured to trigger shared interrupt. This was also tested on bolt by configuring the touchscreen to use a shared GPIO interrupt: localhost ~ $ grep atmel_mxt_ts /proc/interrupts 54: 24 188 93 124 LP-GPIO-demux atmel_mxt_ts Change-Id: I3765120112bae11407e5b2020399d0d0b8e3cef8 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171901 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 63a0c80ce5a19410d0608fede5a9fe0ec1c8e5c1) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6541 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-17southbridge,ASL: Trivial - drop trailing blank lines at EOFEdward O'Callaghan
Change-Id: I8ef5f1571ad14ead2d4cc0d61b6b7133d7fc8550 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6293 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-04-09lynxpoint: Fix SerialIO ACPI compile issue with recent IASLDuncan Laurie
The SerialIO DwordIo() definition is fixed up before returning it in the serialio device _CRS method, so the values that are set in the raw ASL are not actually used. However modern versions of IASL do not like that the RangeLength is set to zero and will fail to compile. Set this value to 1 to make IASL stop complaining, but the real value is still fixed up in _CRS so this has no real effect on the end result. Change-Id: Iceb888e54dd4d627c12d078915108a11f45b1a2d Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/5182 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-12lynxpoint: Do not put SerialIO devices into D3Hot in ACPI modeDuncan Laurie
Remove the bit of code that was putting the SerialIO devices into D3Hot state when they are switched from PCI to ACPI mode. Instead, add the appropriate ACPI Methods to allow the kernel to control the power state of the device. The problem seems to be that if the device is put in D3Hot state before it is switched from PCI to ACPI mode then it does not properly export its PCI configuration space and cannot be woken back up. Adding the ACPI Methods for _PS0/_PS3 allows the kernel to transition the device into D0 state only when it is necessary to communicate with the device, then put it back into D3Hot state. Change-Id: I2384ba10bf47750d1c1a35216169ddeee26881df Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/5193 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-12-21lynxpoint: XHCI: Don't put device in D3 in _PS0 MethodDuncan Laurie
The end of the _PS0 method that is supposed to transition the XHCI device to D0 state is instead putting it in D3 state. This triggers a PME_B0 GPE which causes a Notify to the XHCI ACPI Device in the kernel and that increments the wakeup counter and causes aborted suspends. Instead if we just leave the device in D0 where it should be after executing this function then the PME_B0 is not generated and the kernel does not see a wakeup on XHCI. Similarly I changed the _PS3 method to always put the device in D3 at the end of the method, rather than depending on the state to be D3 at the start. Before this change the kernel would see the following sequence when trying to suspend when the XHCI controller is in D3cold: kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff88017802bf28) kernel: evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [XHCI] (Device) Value 0x02 (Device Wake) Node ffff88017802bc30 kernel: evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [EHCI] (Device) Value 0x02 (Device Wake) Node ffff88017802b8e8 kernel: evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [HDEF] (Device) Value 0x02 (Device Wake) Node ffff88017802b1b8 kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0 kernel: xhci_hcd 0000:00:14.0: PME# disabled kernel: xhci_hcd 0000:00:14.0: enabling bus mastering kernel: xhci_hcd 0000:00:14.0: setting latency timer to 64 kernel: PM: Wakeup pending, aborting suspend kernel: last active wakeup source: 0000:00:14.0 Now it does not get a notification (due to PME_B0) when going to D0 on the way into suspend. XHCI goes from D3cold to D0 (in order to be able to read mmio) and then back to D3hot before suspend. kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff88017802bf28) kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0 kernel: xhci_hcd 0000:00:14.0: PME# disabled kernel: xhci_hcd 0000:00:14.0: enabling bus mastering kernel: xhci_hcd 0000:00:14.0: setting latency timer to 64 kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._S3D] (Node ffff88017802c000) kernel: xhci_hcd 0000:00:14.0: PME# enabled kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS3] (Node ffff88017802bf50) kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D3hot Change-Id: Id5cd28eede2b27d97640047feb17349ae4ab79b7 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65236 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4448 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21lynxpoint: Fix an issue clearing port change status bitsDuncan Laurie
The coreboot and ACPI code that clears USB3 PORTSC change status bits was not properly preserving the state of the PED (port enabled or disabled) status bit, and it could write 0 back to this field which would disable the port. Additionally add back the code that resets disconnected USB3 ports on the way into suspend (as stated in the BWG) but take care to clear the PME status bit so we don't immediately wake. suspend/resume with USB3 devices 1) suspend with no devices, plug in while suspended, then resume and verify that the devices are detected 2) suspend with USB3 devices inserted, then suspend and resume and verify that the devices are detected 3) suspend with USB3 devices inserted, then remove the devices while suspended, resume and ensure they can be detected again when inserted after resume Change-Id: Ic7e8d375dfe645cf0dc1f041c3a3d09d0ead1a51 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65733 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4473 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21lynxpoint: XHCI: Advertise D3 as lowest wake stateDuncan Laurie
The recommended value in docs is D2, but lynxpoint XHCI does not even support D2 state which causes the kernel to think this device cannot be used as a wake source: kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI kernel: ACPI: Device does not support D2 kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI Additionally this means the kernel will never put the device into D3 state by itself. There is SMI code that will put the device into D3 before suspend so advertising D3 here should be correct. With this change the kernel will put the controller into D3 on suspend and back to D0 on resume, including executing the ACPI methods for _PS0/_PS3 that contain chipset specific workarounds. In addition add a _PSC method to directly return the D state from the device registers. With ALL USB devices removed the XHCI controller goes into D3 state and the kernel can have a hard time determining the state of the device at boot. A kernel compiled with CONFIG_ACPI_DEBUG=y and module parameters acpi.debug_layer=0x7f acpi.debug_level=0x2f can be used to see what ACPI methods are executed: kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS3] (Node ffff8801000a7f50) kernel: ACPI: Preparing to enter system sleep state S3 ... kernel: ACPI: Waking up from system sleep state S3 kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff8801000a7f28) kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0 Change-Id: Ic64040eb4dd1947a1e2f0ee253a64be683e0ec70 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> meld with s3d Change-Id: Ic6789720c4efe661dcb03a4afce8d88115854472 Reviewed-on: https://gerrit.chromium.org/gerrit/63916 Tested-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4409 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21lynxpoint xhci: Add ACPI D0/D3 workaroundsDuncan Laurie
There are specific programming requirements for the usb3 ports on all LynxPoint chipsets when transitioning to D0 or D3. LynxPoint-LP has additional workaround steps needed involving resetting the disconnected ports when transitioning to D0. The workarounds are implemented in ACPI code so the controller can transition properly into D3 at runtime. Change-Id: I3b428562f48c9cb250b97779a3b2753ed4f81509 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/62632 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4374 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-03lynxpoint: Fix LPT-LP PME_B0 bit offset in ACPI _PRW objectsDuncan Laurie
LynxPoint-LP has a lot of GPEs and the "default" set has been moved to register 4 starting at bit offset 96. This means that PME_B0 bit in GPE0_EN/GPE0_STS is now bit 109 in LPT-LP but still bit 13 in LPT-H. suspend on falco and wake from usb 4 | 2013-06-19 10:49:17 | ACPI Enter | S3 5 | 2013-06-19 10:49:22 | ACPI Wake | S3 6 | 2013-06-19 10:49:22 | Wake Source | Internal PME | 0 Change-Id: I443cd4d17796888debed70c0bda27ae09accd09b Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/59265 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4253 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-11-25lynxpoint: Add ACPI Method to enable GPIO as wake sourceDuncan Laurie
This is an LPT-LP specific method that will enable a specific GPIO as an ACPI SCI wake source. It can be used by a device _DSW method to enable a pin that is otherwise not configured to generate SCI at runtime. It will set: - GPIO owner to ACPI - GPIO route to SCI - GPIO config to GPIO, Input, Inverted Also clean up and remove ACPI field definitions that are unused and/or incorrect. Change-Id: I14acc2de50e6200f61c2898a7bd1252400e0f0be Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56621 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4189 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-11-25lynxpoint: Fix XHCI controller device in ACPIDuncan Laurie
The ACPI code was defining two EHCI controllers and ignoring the XHCI controller. This changes the second EHCI controller to be XHCI instead and changes the wake resource to indicate S3 and not S4. cat /proc/acpi/wakeup Device S-state Status Sysfs node HDEF S4 *disabled pci:0000:00:1b.0 EHCI S3 *enabled pci:0000:00:1d.0 XHCI S3 *enabled pci:0000:00:14.0 Change-Id: If28775e6ef8608c22c85ca91d91d1f598ec7755d Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56263 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4181 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-11-25lynxpoint: Change SerialIO device enable reporting to ACPIDuncan Laurie
In order to report whether coreboot enabled a SerialIO device in ACPI mode we had been relying on reading NVS in the _STA method for the SerialIO device. The ACPI _STA method has restrictions on what it can access and is unable to access OperationRegions outside its scope which means it should not be trying to read NVS. This change adds a new SSDT to the ACPI tables and fills it with constants that indicate whether or not a device is enabled in ACPI mode. The ACPI code is changed to read these variables from the SSDT and use that instead of trying to query a variable in NVS. Attempt to use lpt-clk driver to probe the device clocks for SerialIO devices and see that the kernel does not complain about accessing the GNVS region. Change-Id: I8538bee4390daed4ecca679496ab0cb313f174ce Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51369 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4170 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-11-25lynxpoint: Expose ACPI Device for LP GPIO controllerDuncan Laurie
In order to probe the gpio-lynxpoint kernel driver the LP GPIO controller needs to be exposed as a specific ACPI device. This also allows the resources to be exposed to the OS via this device instead of the catch-all LPC device. Ensure the driver loads at boot: gpiochip_find_base: found new base at 162 gpiochip_add: registered GPIOs 162 to 255 on device: INT33C7:00 Also ensure the driver is visible in sysfs: $ cat /sys/devices/platform/INT33C7:00/gpio/gpiochip162/label INT33C7:00 Change-Id: I9f79c008f88da9b67ed1cdfdb9d3a581ce8f05ff Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50215 Reviewed-on: http://review.coreboot.org/4158 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-11-25lynxpoint: export mem console pointer in ACPIAaron Durbin
Instead of having an OS re-parse cbmem book-keeping records for the cbmem allocator just to get the console buffer export the pointer to the memory console directly in a field named 'CBMC'. This field lives in the GNVS table. Change-Id: Ief0c4da7b18df66feb9c816c9f4abdf5a72bd3a4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/49764 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4149 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01lynxpoint: Basic configuration of SerialIO devicesDuncan Laurie
This adds configuration of SerialIO devices in the Lynxpoint-LP chipset. This includes DMA, I2C, SPI, UART, and SDIO controllers. There is assorted magic setup necessary for the devices and while it is similar for each device there are subtle differences in some register settings. These devices must be put into "ACPI Mode" in order to take advantage of S0ix. When in ACPI mode the allocated PCI BARs must be passed to ACPI so it can be relayed to the OS. When the devices are in ACPI mode BAR0+BAR1 is saved into ACPI NVS and then updated and returned when the OS calls _CRS. Note that is is not entirely complete yet. We need to update the IASL compiler in our build environment to support ACPI 5.0 in order to be able to pass the FixedDMA entries to the kernel. There are also no ACPI methods defined yet to do D0->D3->D0 transitions for actually entering/exiting S0ix states. This is hard to test right now because our kernel does not support any of these devices in ACPI mode. I was able to build and test the upstream bleeding-edge branch of the linux-pm git tree. With that tree I was able to enumerate and load the driver for the DesignWare I2C driver and attempt to probe the I2C bus -- although there are no devices attatched. I am also able to see the resources from ACPI in /proc/iomem get reserved properly in the kernel. Change-Id: Ie311addd6a25f3b7edf3388fe68c1cd691a0a500 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2971 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01lynxpoint: Rework ACPI NVS to add new SerialIO variablesDuncan Laurie
This reclaims space in ACPI NVS by removing unused fields and adds new fields for SerialIO BARs which will be used to communicate the allocated resources to ACPI. Change-Id: I002bf396cf7b495bc5b7e54b741527e507aff716 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2969 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-21lynxpoint: Fix GPIO and PM base reservationsDuncan Laurie
The kernel ACPI was not happy with the Add inside a ResourceTemplate (or perhaps within the IO declaration) Instead make a buffer of IO reservations and turn _CRS into a method that updates the buffer depending on the chipset type. This adds an \ISLP() method that checks the chipset LPC device ID to see if it is -LP or -H. It also increases the PM base reservation to 256 bytes and moves both GPIO and PM base to above 0x1000 on -LP chipsets. Change-Id: I747b658588a4d8ed15a0134009a7c0d74b3916ba Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2815 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14lynxpoint: Add new GPIO interface for Lynxpoint-LPDuncan Laurie
The low power variant of the chipset introduces a completely new interface to the GPIOs. This is a 1KB region and so needs to be moved as well so it does not conflict with other IO regions. Also expose the gpio_get functions to ramstage and move the prototypes to pch.h so they can be used for both GPIO interfaces. Change-Id: I20bc18669525af16de8cdf99f0ccfa9612be63ad Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2648 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: Add initial support for Haswell platformsAaron Durbin
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore, the southbridge support is included as well. The basis for this code is the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires more attention, but this is a good starting point. This code partially gets up through the romstage just before training memory on a Haswell reference board. Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2616 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>