1. 10 8月, 2017 1 次提交
    • R
      ACPI / LPSS: Don't abort ACPI scan on missing mem resource · a4bb2b49
      Ronald Tschalär 提交于
      The keyboard and touchpad on MacBook's from 2015 onwards are connected
      via an SPI bus. On MacBook8's (2015) the ACPI device for the SPI master
      for this bus has _CID "INT33C1", and hence the acpi-lpss handler here is
      triggered for it. However, the DSDT lists no memory resources for this
      device, resulting in an error being returned by the attach callback and
      therefore the SPI master device being ignored. This prevents us from
      being able to register the keyboard and touchpad driver.
      
      Furthermore, the controller (a Wildcat Point-LP controller) does not
      appear to need the functionality provided by the apci-lpss handler.
      Therefore we now just skip the handler if no memory resources are found
      and let the ACPI scan complete successfully for this device.
      
      All of this is not an issue on later MacBook(Pro)'s because their ACPI
      SPI devices don't have any _CID and therefore no attempt is made to attach
      this handler.
      
      Returning an error was introduced in commit d3e13ff3 - this restores
      the original behaviour.
      
      Link: https://github.com/cb22/macbook12-spi-driverSigned-off-by: NRonald Tschalär <ronald@innovation.ch>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a4bb2b49
  2. 07 7月, 2017 1 次提交
  3. 05 7月, 2017 1 次提交
  4. 29 4月, 2017 1 次提交
  5. 10 2月, 2017 1 次提交
  6. 27 1月, 2017 1 次提交
  7. 17 11月, 2016 1 次提交
  8. 10 11月, 2016 1 次提交
  9. 31 8月, 2016 1 次提交
  10. 08 6月, 2016 1 次提交
  11. 03 2月, 2016 1 次提交
  12. 08 1月, 2016 1 次提交
  13. 07 1月, 2016 2 次提交
  14. 09 12月, 2015 4 次提交
  15. 14 10月, 2015 1 次提交
    • R
      PM / PCI / ACPI: Kick devices that might have been reset by firmware · 58a1fbbb
      Rafael J. Wysocki 提交于
      There is a concern that if the platform firmware was involved in
      the system resume that's being completed,  some devices might have
      been reset by it and if those devices had the power.direct_complete
      flag set during the preceding suspend transition, they may stay
      in a reset-power-on state indefinitely (until they are runtime-resumed
      and then suspended again).  That may not be a big deal from the
      individual device's perspective, but if the system is an SoC, it may
      be prevented from entering deep SoC-wide low-power states on idle
      because of that.
      
      The devices that are most likely to be affected by this issue are
      PCI devices and ACPI-enumerated devices using the general ACPI PM
      domain, so to prevent it from happening for those devices, force a
      runtime resume for them if they have their power.direct_complete
      flags set and the platform firmware was involved in the resume
      transition currently in progress.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      58a1fbbb
  16. 28 8月, 2015 1 次提交
  17. 21 7月, 2015 1 次提交
    • S
      ACPI: Remove clk.h include · 887e5a91
      Stephen Boyd 提交于
      Clock provider drivers generally shouldn't include clk.h because
      it's the consumer API. Remove the includes here because these are
      a provider drivers.
      
      Cc: Ken Xue <Ken.Xue@amd.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      887e5a91
  18. 07 7月, 2015 1 次提交
  19. 15 6月, 2015 1 次提交
  20. 10 3月, 2015 1 次提交
  21. 19 2月, 2015 2 次提交
    • M
      ACPI / LPSS: Deassert resets for SPI host controllers on Braswell · 3095794a
      Mika Westerberg 提交于
      On some Braswell systems BIOS leaves resets for SPI host controllers
      active. This prevents the SPI driver from transferring messages on wire.
      
      Fix this in similar way that we do for I2C already by deasserting resets
      for the SPI host controllers.
      Reported-by: NYang A Fang <yang.a.fang@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3095794a
    • M
      ACPI / LPSS: Always disable I2C host controllers · 3293c7b8
      Mika Westerberg 提交于
      On Baytrail and Braswell the BIOS might leave the I2C host controllers
      enabled, probably because it uses them for its own purposes. This is fine
      in normal cases because the I2C driver will disable the hardware when it
      is probed anyway.
      
      However, in case of suspend to disk it is different story. If the driver
      happens to be compiled as a module the boot kernel never loads the driver
      thus leaving host controllers enabled upon loading the hibernation image.
      
      The I2C host controller interrupt mask register has default value of 0x8ff,
      in other words it has most of the interrupts unmasked. When combined with
      the fact that the host controller is enabled, the driver immediately starts
      getting interrupts even before its resume hook is called (once IO-APIC is
      resumed). Since the driver is not prepared for this it will crash the
      kernel due to NULL pointer derefence because dev->msgs is NULL.
      
      Unfortunately we were not able to get full backtrace to from the console
      which could be reproduced here.
      
      In order to fix this even when the driver is compiled as module, we disable
      the I2C host controllers in byt_i2c_setup() before devices are created.
      Reported-by: NYu Chen <yu.c.chen@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3293c7b8
  22. 18 2月, 2015 1 次提交
  23. 05 2月, 2015 1 次提交
  24. 03 2月, 2015 1 次提交
  25. 24 1月, 2015 1 次提交
  26. 22 1月, 2015 1 次提交
  27. 04 12月, 2014 1 次提交
  28. 12 11月, 2014 3 次提交
  29. 25 9月, 2014 2 次提交
  30. 09 9月, 2014 1 次提交
  31. 03 9月, 2014 2 次提交