Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 11月, 2014 3 次提交
  3. 29 10月, 2014 2 次提交
    • L
      ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer. · 79149001
      由 Lv Zheng 提交于 
      It is reported that Samsung laptops that need to poll events are broken by
the following commit:
 Commit 3afcf2ec
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

The behaviors of the 2 vendor firmwares are conflict:
 1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
         automatically sets SCI_EVT as long as there is event queued up.
 2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
            returns 0 when there is no event queued up.

This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.

Fixes: 3afcf2ec (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161Reported-and-tested-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
[ rjw : Subject ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      79149001
    • L
      Revert "ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC" · df9ff918
      由 Lv Zheng 提交于 
      It is reported that the following commit breaks Samsung hardware:
 Commit: 558e4736.
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued before
          completing previous QR_EC

Which means the Samsung behavior conflicts with the Acer behavior.

1. Samsung may behave like:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ] SCI_EVT set
                              write QR_EC
                              read event
   [ -event 1 ] SCI_EVT clear
   Without the above commit, Samsung can work:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ] SCI_EVT set
                              write QR_EC
                              CAN prepare next QR_EC as SCI_EVT=1
                              read event
   [ -event 1 ] SCI_EVT clear
                              write QR_EC
                              read event
   [ -event 2 ] SCI_EVT clear
   With the above commit, Samsung cannot work:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ] SCI_EVT set
                              write QR_EC
                              read event
   [ -event 1 ] SCI_EVT clear
                              CANNOT prepare next QR_EC as SCI_EVT=0
2. Acer may behave like:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ]
                              write QR_EC
                              read event
   [ -event 1 ] SCI_EVT clear
   [ +event 2 ] SCI_EVT set
   Without the above commit, Acer cannot work when there is only 1 event:
   [ +event 1 ] SCI_EVT set
                              write QR_EC
                              can prepared next QR_EC as SCI_EVT=1
                              read event
   [ -event 1 ] SCI_EVT clear
                              CANNOT write QR_EC as SCI_EVT=0
   With the above commit, Acer can work:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ]
                              write QR_EC
                              read event
   [ -event 1 ] SCI_EVT set
                              can prepare next QR_EC because SCI_EVT=0
                              CAN write QR_EC as SCI_EVT=1

Since Acer can also work with only the following commit applied:
 Commit: 3afcf2ec
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when
          SCI_EVT isn't set
commit 558e4736 can be reverted.

Fixes: 558e4736 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161Reported-and-tested-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      df9ff918
  5. 28 10月, 2014 1 次提交
    • M
      ACPI: Use ACPI companion to match only the first physical device · 52870786
      由 Mika Westerberg 提交于 
      Commit 6ab34301 ("mfd: Add ACPI support") made the MFD subdevices
share the parent MFD ACPI companion if no _HID/_CID is specified for
the subdevice in mfd_cell description. However, since all the subdevices
share the ACPI companion, the match and modalias generation logic started
to use the ACPI companion as well resulting this:

  # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
  acpi:INT33D1:PNP0C50:

instead of the expected one

  # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
  platform:HID-SENSOR-200041

In other words the subdevice modalias is overwritten by the one taken from
ACPI companion. This causes udev not to load the driver anymore.

It is useful to be able to share the ACPI companion so that MFD subdevices
(and possibly other devices as well) can access the ACPI resources even if
they do not have ACPI representation in the namespace themselves.

An example where this is used is Minnowboard LPC driver that creates GPIO
as a subdevice among other things. Without the ACPI companion gpiolib is
not able to lookup the corresponding GPIO controller from ACPI GpioIo
resource.

To fix this, restrict the match and modalias logic to be limited to the
first (primary) physical device associated with the given ACPI comapnion.
The secondary devices will still be able to access the ACPI companion,
but they will be matched in a different way.

Fixes: 6ab34301 (mfd: Add ACPI support)
Reported-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      52870786
  7. 24 10月, 2014 1 次提交
  9. 22 10月, 2014 1 次提交
  11. 21 10月, 2014 12 次提交
  13. 17 10月, 2014 1 次提交
  15. 10 10月, 2014 10 次提交
  17. 07 10月, 2014 1 次提交
  19. 01 10月, 2014 4 次提交
    • R
      ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle · a8d46b9e
      由 Rafael J. Wysocki 提交于 
      The ACPI GPE wakeup from suspend-to-idle is currently based on using
the IRQF_NO_SUSPEND flag for the ACPI SCI, but that is problematic
for a couple of reasons.  First, in principle the ACPI SCI may be
shared and IRQF_NO_SUSPEND does not really work well with shared
interrupts.  Second, it may require the ACPI subsystem to special-case
the handling of device notifications depending on whether or not
they are received during suspend-to-idle in some places which would
lead to fragile code.  Finally, it's better the handle ACPI wakeup
interrupts consistently with wakeup interrupts from other sources.

For this reason, remove the IRQF_NO_SUSPEND flag from the ACPI SCI
and use enable_irq_wake()/disable_irq_wake() with it instead, which
requires two additional platform hooks to be added to struct
platform_freeze_ops.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a8d46b9e
    • R
      ACPICA: Introduce acpi_enable_all_wakeup_gpes() · e0fa975d
      由 Rafael J. Wysocki 提交于 
      Add a routine for host OSes to enable all wakeup GPEs and disable
all of the non-wakeup ones at the same time.

It will be used for the handling of GPE wakeup from suspend-to-idle
in Linux.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e0fa975d
    • R
      ACPICA: Clear all non-wakeup GPEs in acpi_hw_enable_wakeup_gpe_block() · 5a0b8dee
      由 Rafael J. Wysocki 提交于 
      Since acpi_hw_enable_wakeup_gpe_block() is currently always called
after disabling all GPEs, it can actually write zeros to all
non-wakeup enable bits unconditionally.

That will be useful going forward for disabling runtime GPEs and
enabling wakeup GPEs in one go instead of doing that in two steps
(disable runtime and enable wakeup) which in theory may lead to a
loss of a wakeup event.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5a0b8dee
    • A
      ACPI / video: check _DOD list when creating backlight devices · 0b8db271
      由 Aaron Lu 提交于 
      The _DOD method lists which video output device is currently attached so
we should only care about them and ignore others. An user recently
reported that there are two acpi_video interfaces appeared on his system
and one of them doesn't work. From the acpidump, it is found that there
are more than one video output devices that have _BCM control method but
the _DOD lists only one of them. So this patch checks if the video output
device is in the _DOD list and will not create backlight device if it is
not in the list. Also, we consider the broken _DOD case(reflected by the
video->attached_count is 0) and do not change behaviour for those broken
_DOD systems.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84111
Reported-and-tested-by: ntrrgc@gmail.com
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0b8db271
  21. 28 9月, 2014 1 次提交
  23. 25 9月, 2014 3 次提交
    • J
      Input: soc_button_array - convert to platform bus · 042e1c79
      由 Jin Yao 提交于 
      ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c.
But ACPI folks will continue their effort on shrinking this id list by
converting the PNP drivers to platform drivers, for the devices that don't
belong to PNP bus in nature.
Signed-off-by: NJin Yao <yao.jin@intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      042e1c79
    • M
      ACPI: Support _OSI("Darwin") correctly · 7bc5a2ba
      由 Matthew Garrett 提交于 
      Apple hardware queries _OSI("Darwin") in order to determine whether the
system is running OS X, and changes firmware behaviour based on the
answer.  The most obvious difference in behaviour is that Thunderbolt
hardware is forcibly powered down unless the system is running OS X. The
obvious solution would be to simply add Darwin to the list of supported
_OSI strings, but this causes problems.

Recent Apple hardware includes two separate methods for checking _OSI
strings. The first will check whether Darwin is supported, and if so
will exit. The second will check whether Darwin is supported, but will
then continue to check for further operating systems. If a further
operating system is found then later firmware code will assume that the
OS is not OS X.  This results in the unfortunate situation where the
Thunderbolt controller is available at boot time but remains powered
down after suspend.

The easiest way to handle this is to special-case it in the
Linux-specific OSI handling code. If we see Darwin, we should answer
true and then disable all other _OSI vendor strings.

The next problem is that the Apple PCI _OSC method has the following
code:

if (LEqual (0x01, OSDW ()))
  if (LAnd (LEqual (Arg0, GUID), NEXP)
    (do stuff)
  else
    (fail)
NEXP is a value in high memory and is presumably under the control of
the firmware. No methods sets it. The methods that are called in the "do
stuff" path are dummies. Unless there's some additional firmware call in
early boot, there's no way for this call to succeed - and even if it
does, it doesn't do anything.

The easiest way to handle this is simply to ignore it. We know which
flags would be set, so just set them by hand if the platform is running
in Darwin mode.
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
[andreas.noever@gmail.com: merged two patches, do not touch ACPICA]
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7bc5a2ba
    • M
      ACPI / SBS: Disable smart battery manager on Apple · 9faf6136
      由 Matthew Garrett 提交于 
      Touching the smart battery manager at all on Apple hardware appears to
make it unhappy - unplugging the AC adapter triggers accesses that hang
the controller for several minutes. Quirk it out via DMI in order to
avoid this.  Compensate by changing battery presence if we fail to
communicate with the battery.
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9faf6136