Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 10月, 2017 2 次提交
    • U
      ACPI / PM: Restore acpi_subsys_complete() · e4da817d
      由 Ulf Hansson 提交于 
      Commit 58a1fbbb (PM / PCI / ACPI: Kick devices that might have
been reset by firmware), made PCI's and ACPI's ->complete() callbacks
to be assigned to a new API called pm_complete_with_resume_check(),
which was introduced in the same change.

Later it turned out that using pm_complete_with_resume_check() wasn't
good enough for PCI, as it needed additional PCI specific checks,
before deciding whether runtime resuming the device is needed when
running the ->complete() callback.

This leaves ACPI as the only user of pm_complete_with_resume_check().
Therefore let's restore ACPI's acpi_subsys_complete(), which was
dropped in commit 58a1fbbb (PM / PCI / ACPI: Kick devices that
might have been reset by firmware).

This enables us to remove the pm_complete_with_resume_check() API in
a following change, but it also enables ACPI to add more ACPI
specific checks in acpi_subsys_complete() if that turns out to be
necessary.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e4da817d
    • R
      ACPI / PM: Combine two identical device resume routines · 63705c40
      由 Rafael J. Wysocki 提交于 
      Notice that acpi_dev_runtime_resume() and acpi_dev_resume_early() are
actually literally identical after some more-or-less recent changes,
so rename acpi_dev_runtime_resume() to acpi_dev_resume(), use it
everywhere instead of acpi_dev_resume_early() and drop the latter.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      63705c40
  3. 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
  5. 07 7月, 2017 1 次提交
  7. 05 7月, 2017 1 次提交
  9. 29 4月, 2017 1 次提交
  11. 10 2月, 2017 1 次提交
  13. 27 1月, 2017 1 次提交
  15. 17 11月, 2016 1 次提交
  17. 10 11月, 2016 1 次提交
  19. 31 8月, 2016 1 次提交
  21. 08 6月, 2016 1 次提交
  23. 03 2月, 2016 1 次提交
  25. 08 1月, 2016 1 次提交
  27. 07 1月, 2016 2 次提交
  29. 09 12月, 2015 4 次提交
  31. 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
  33. 28 8月, 2015 1 次提交
  35. 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
  37. 07 7月, 2015 1 次提交
  39. 15 6月, 2015 1 次提交
  41. 10 3月, 2015 1 次提交
  43. 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
  45. 18 2月, 2015 1 次提交
  47. 05 2月, 2015 1 次提交
  49. 03 2月, 2015 1 次提交
  51. 24 1月, 2015 1 次提交
  53. 22 1月, 2015 1 次提交
  55. 04 12月, 2014 1 次提交
  57. 12 11月, 2014 3 次提交
  59. 25 9月, 2014 2 次提交
  61. 09 9月, 2014 1 次提交