Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 3月, 2015 2 次提交
  3. 10 3月, 2015 1 次提交
  5. 04 3月, 2015 3 次提交
  7. 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
  9. 18 2月, 2015 4 次提交
  11. 16 2月, 2015 1 次提交
  13. 13 2月, 2015 1 次提交
  15. 12 2月, 2015 2 次提交
  17. 09 2月, 2015 2 次提交
  19. 06 2月, 2015 7 次提交
    • L
      ACPI / EC: Add GPE reference counting debugging messages · b5bca896
      由 Lv Zheng 提交于 
      This patch enhances debugging with the GPE reference count messages added.
No functional changes.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b5bca896
    • L
      ACPI / EC: Add query flushing support · f252cb09
      由 Lv Zheng 提交于 
      This patch implementes the QR_EC flushing support.

Grace periods are implemented from the detection of an SCI_EVT to the
submission/completion of the QR_EC transaction. During this period, all
EC command transactions are allowed to be submitted.

Note that query periods and event periods are intentionally distiguished to
allow further improvements.
1. Query period: from the detection of an SCI_EVT to the sumission of the
   QR_EC command. This period is used for storming prevention, as currently
   QR_EC is deferred to a work queue rather than directly issued from the
   IRQ context even there is no other transactions pending, so malicous
   SCI_EVT GPE can act like "level triggered" to trigger a GPE storm. We
   need to be prepared for this. And in the future, we may change it to be
   a part of the advance_transaction() where we will try QR_EC submission
   in appropriate positions to avoid such GPE storming.
2. Event period: from the detection of an SCI_EVT to the completion of the
   QR_EC command. We may extend it to the completion of _Qxx evaluation.
   This is actually a grace period for event flushing, but we only flush
   queries due to the reason stated in known issue 1. That's also why we
   use EC_FLAGS_EVENT_xxx. During this period, QR_EC transactions need to
   pass the flushable submission check.

In this patch, the following flags are implemented:
1. EC_FLAGS_EVENT_ENABLED: this is derived from the old
   EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT handlings.
   With this flag, the logics implemented by the original flag are
   extended:
   1. Old logic: unless both of the flags are set, the event poller will
                 not be scheduled, and
   2. New logic: as soon as both of the flags are set, the evet poller will
                 be scheduled.
2. EC_FLAGS_EVENT_DETECTED: this is also derived from the old
   EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT detection. It thus
   can be used to indicate the storming prevention period for query
   submission.
   acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to
   implement this period so that acpi_set_gpe() can be invoked under the
   "reference count > 0" condition.
3. EC_FLAGS_EVENT_PENDING: this is newly added to indicate the grace period
   for event flushing (query flushing for now).
   acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to
   implement this period so that the flushing process can wait until the
   event handling (query transaction for now) to be completed.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Tested-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f252cb09
    • L
      ACPI / EC: Refine command storm prevention support · e1d4d90f
      由 Lv Zheng 提交于 
      This patch refines EC command storm prevention support.

Current command storming code is wrong, when the storming condition is
detected, it only flags the condition without doing anything for the
current command but performing storming prevention for the follow-up
commands. So:
1. The first command which suffers from the storming still suffers from
   storming.
2. The follow-up commands which may not suffer from the storming are
   unconditionally forced into the storming prevention mode.
Ideally, we should only enable storm prevention immediately after detection
for the current command so that the next command can try the
power/performance efficient interrupt mode again.

This patch improves the command storm prevention by disabling GPE right
after the detection and re-enabling it right before completing the command
transaction using the GPE storming prevention APIs. This thus deploys the
following GPE handling model:
1. acpi_enable_gpe()/acpi_disable_gpe() for reference count changes:
   This set of APIs are used for EC usage reference counting.
2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE):
   This set of APIs are used for preventing GPE storm. They must be invoked
   when the reference count > 0.
   Note that as the storming prevention should always happen when there is
   an outstanding request, or GPE enabling value will be messed up by the
   races. This patch also adds BUG_ON() to enforces this rule to prevent
   future bugs.

The msleep(1) used after completing a transaction is useless now as this
sounds like a guard time only useful for platforms that need the
EC_FLAGS_MSI quirks while we have fixed GPE race issues using the previous
raw handler mode enabling. It is kept to avoid regressions. A seperate
patch which deletes EC_FLAGS_MSI quirks should take care of deleting it.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e1d4d90f
    • L
      ACPI / EC: Add command flushing support. · 9887d22a
      由 Lv Zheng 提交于 
      This patch implements the EC command flushing support.

During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED,
all submitted EC command transactions can be completed and new submissions
are prevented before suspending so that the EC hardware can be ensured to
be in the idle state when the system is resumed.

There is a good indicator for flush support:
All acpi_ec_submit_request() is invoked after checking driver state with
acpi_ec_started() except the first one. This means all code paths can be
flushed as fast as possible by discarding the requests occurred after the
flush operation. The reference increased for such kind of code path is
wrapped by acpi_ec_submit_flushable_request().
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Tested-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9887d22a
    • L
      ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag · ad479e7f
      由 Lv Zheng 提交于 
      By using the 2 flags, we can indicate an inter-mediate state where the
current transactions should be completed while the new transactions should
be dropped.

The comparison of the old flag and the new flags:
  Old			New
  about to set BLOCKED	STOPPED set / STARTED set
  BLOCKED set		STOPPED clear / STARTED clear
  BLOCKED clear		STOPPED clear / STARTED set
A new period can be indicated by the 2 flags. The new period is between the
point where we are about to set BLOCKED and the point when the BLOCKED is
set. The new flags facilitate us with acpi_ec_started() check to allow the
EC transaction to be submitted during the new period. This period thus can
be used as a grace period for the EC transaction flushing.

The only functional change after applying this patch is:
1. The GPE enabling/disabling is protected by the EC specific lock. We can
   do this because of recent ACPICA GPE API enhancement. This is reasonable
   as the GPE disabling/enabling state should only be determined by the EC
   driver's state machine which is protected by the EC spinlock.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Tested-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ad479e7f
    • K
      ACPI: add AMD ACPI2Platform device support for x86 system · 92082a88
      由 Ken Xue 提交于 
      This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART, GPIO found on AMD CZ and
later chipsets. It based on example intel LPSS. Now, it can
support AMD I2C, UART and GPIO.
Signed-off-by: NKen Xue <Ken.Xue@amd.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      92082a88
    • H
      ACPI / table: remove duplicate NULL check for the handler of acpi_table_parse() · 2fad9308
      由 Hanjun Guo 提交于 
      In acpi_table_parse(), pointer of the table to pass to handler() is
checked before handler() called, so remove all the duplicate NULL
check in the handler function.

CC: Tony Luck <tony.luck@intel.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2fad9308
  21. 05 2月, 2015 15 次提交
    • L
      ACPI / EC: Update revision due to raw handler mode. · a8d4fc22
      由 Lv Zheng 提交于 
      The bug fixes around GPE races have been done to the EC driver by the
previous commits. This patch increases the revision to 3 to indicate the
behavior differences between the old and the new drivers. The
copyright/authorship notices are also updated.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a8d4fc22
    • L
      ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp. · 9e295ac1
      由 Lv Zheng 提交于 
      Timeout in the ec_poll() doesn't refer to the last register access time. It
thus can win the competition against the acpi_ec_gpe_handler() if a
transaction takes longer than 1ms but individual register accesses are less
than 1ms.  In some cases, it can make the following silicon bug easier to
be triggered:
 GPE EN is not wired to the GPE trigger line, so when GPE STS is already
 set when 1 is written to GPE EN, no GPE can be triggered.

This patch adds register access timestamp reference support for ec_poll()
to reduce the number of ec_poll() invocations.
Reported-by: NVenkat Raghavulu <venkat.raghavulu@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9e295ac1
    • L
      ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode. · ca37bfdf
      由 Lv Zheng 提交于 
      This patch switches EC driver into ACPI_GPE_DISPATCH_RAW_HANDLER mode where
the GPE lock is not held for acpi_ec_gpe_handler() and the ACPICA internal
GPE enabling/disabling/clearing operations are bypassed so that further
improvements are possible with the GPE APIs.

There are 2 strong reasons for deploying raw GPE handler mode in the EC
driver:
1. Some hardware logics can control their interrupts via their own
   registers, so their interrupts can be disabled/enabled/acknowledged
   without using the super IRQ controller provided functions. While there
   is no mean (EC commands) for the EC driver to achieve this.
2. During suspending, the EC driver is still working for a while to
   complete the platform firmware provided functionailities using ec_poll()
   after all GPEs are disabled (see acpi_ec_block_transactions()), which
   means the EC driver will drive the EC GPE out of the GPE core's control.

Without deploying the raw GPE handler mode, we can see many races between
the EC driver and the GPE core due to the above restrictions:
1. There is a race condition due to ACPICA internal GPE
   disabling/clearing/enabling logics in acpi_ev_gpe_dispatch():
     Orignally EC GPE is disabled (EN=0), cleared (STS=0) before invoking a
     GPE handler and re-enabled (EN=1) after invoking a GPE handler in
     acpi_ev_gpe_dispatch(). When re-enabling appears, GPE may be flagged
     (STS=1).
       =================================================================
       (event pending A)
       =================================================================
       acpi_ev_gpe_dispatch()    ec_poll()
         EN=0
         STS=0
         acpi_ec_gpe_handler()
       *****************************************************************
       (event handling A)
           Lock(EC)
           advance_transaction()
             EC_SC read
       =================================================================
       (event pending B)
       =================================================================
             EC_SC handled
           Unlock(EC)
       *****************************************************************
       *****************************************************************
       (event handling B)
                                   Lock(EC)
                                   advance_transaction()
                                     EC_SC read
       =================================================================
       (event pending C)
       =================================================================
                                     EC_SC handled
                                   Unlock(EC)
       *****************************************************************
           EN=1
   This race condition is the root cause of different issues on different
   silicon variations.
   A. Silicon variation A:
      On some platforms, GPE will be triggered due to "writing 1 to EN when
      STS=1". This is because both EN and STS lines are wired to the GPE
      trigger line.
      1. Issue 1:
         We can see no-op acpi_ec_gpe_handler() invoked on such platforms.
         This is because:
         a. event pending B: An event can arrive after ACPICA's GPE
            clearing performed in acpi_ev_gpe_dispatch(), this event may
            fail to be detected by EC_SC read that is performed before its
            arrival;
         b. event handling B: The event can be handled in ec_poll() because
            EC lock is released after acpi_ec_gpe_handler() invocation;
         c. There is no code in ec_poll() to clear STS but the GPE can
            still be triggered by the EN=1 write performed in
            acpi_ev_finish_gpe(), this leads to a no-op EC GPE handler
            invocation;
         d. As no-op GPE handler invocations are counted by the EC driver
            to trigger the command storming conditions, the wrong no-op
            GPE handler invocations thus can easily trigger wrong command
            storming conditions.
         Note 1:
         If we removed GPE disabling/enabling code from
         acpi_ev_gpe_dispatch(), we could still see no-op GPE handlers
         triggered by the event arriving after the GPE clearing and before
         the GPE handling on both silicon variation A and B. This can only
         occur if the CPU is very slow (timing slice between STS=0 write
         and EC_SC read should be short enough before hardware sets another
         GPE indication). Thus this is very rare and is not what we need to
         fix.
   B. Silicon variation B:
      On other platforms, GPE may not be triggered due to "writing 1 to EN
      when STS=1". This is because only STS line is wired to the GPE
      trigger line.
      2. Issue 2:
         We can see GPE loss on such platforms. This is because:
         a. event pending B vs. event handling A: An event can arrive after
            ACPICA's GPE handling performed in acpi_ev_gpe_dispatch(), or
            event pending C vs. event handling B: An event can arrive after
            Linux's GPE handling performed in ec_poll(),
            these events may fail to be detected by EC_SC read that is
            performed before their arrival;
         b. The GPE cannot be triggered by EN=1 write performed in
            acpi_ev_finish_gpe();
         c. If no polling mechanism is implemented in the driver for the
            pending event (for example, SCI_EVT), this event is lost due to
            no GPE being triggered.
         Note 2:
         On most platforms, there might be another rule that GPE may not be
         triggered due to "writing 1 to STS when STS=1 and EN=1".
         Then on silicon variation B, an even worse case is if the issue 2
         event loss happens, further events may never trigger GPE again on
         such platforms due to being blocked by the current STS=1. Unless
         someone clears STS, all events have to be polled.
2. There is a race condition due to lacking in GPE status checking in EC
   driver:
     Originally, GPE status is checked in ACPICA core but not checked in
     the GPE handler. Thus since the status checking and handling is not
     locked, it can be interrupted by another handling path.
       =================================================================
       (event pending A)
       =================================================================
       acpi_ev_gpe_detect()        ec_poll()
         if (EN==1 && STS==1)
       *****************************************************************
       (event handling A)
                                     Lock(EC)
                                     advance_transaction()
                                       EC_SC read
                                       EC_SC handled
                                     Unlock(EC)
       *****************************************************************
         acpi_ev_gpe_dispatch()
           EN=0
           STS=0
           acpi_ec_gpe_handler()
       *****************************************************************
       (event handling B)
             Lock(EC)
             advance_transaction()
               EC_SC read
             Unlock(EC)
       *****************************************************************
      3. Issue 3:
         We can see no-op acpi_ec_gpe_handler() invoked on both silicon
         variation A and B. This is because:
         a. event pending A: An event can arrive to trigger an EC GPE and
            ACPICA checks it and is about to invoke the EC GPE handler;
         b. event handling A: The event can be handled in ec_poll() because
            EC lock is not held after the GPE status checking;
         c. event handling B: Then when the EC GPE handler is invoked, it
            becomes a no-op GPE handler invocation.
         d. As no-op GPE handler invocations are counted by the EC driver
            to trigger the command storming conditions, the wrong no-op
            GPE handler invocations thus can easily trigger wrong command
            storming conditions.
      Note 3:
      This no-op GPE handler invocation is rare because the time between
      the IRQ arrival and the acpi_ec_gpe_handler() invocation is less than
      the timeout value waited in ec_poll(). So most of the no-op GPE
      handler invocations are caused by the reason described in issue 1.
3. There is a race condition due to ACPICA internal GPE clearing logic in
   acpi_enable_gpe():
     During runtime, acpi_enable_gpe() can be invoked by the EC storming
     prevention code. When it is invoked, GPE may be flagged (STS=1).
       =================================================================
       (event pending A)
       =================================================================
       acpi_ev_gpe_dispatch()    acpi_ec_transaction()
         EN=0
         STS=0
         acpi_ec_gpe_handler()
       *****************************************************************
       (event handling A)
           Lock(EC)
           advance_transaction()
             EC_SC read
             EC_SC handled
           Unlock(EC)
       *****************************************************************
         EN=1 ?
                                   Lock(EC)
                                   Unlock(EC)
       =================================================================
       (event pending B)
       =================================================================
                                   acpi_enable_gpe()
                                     STS=0
                                     EN=1
    4. Issue 4:
       We can see GPE loss on both silicon variation A and B platforms.
       This is because:
       a. event pending B: An event can arrive right before ACPICA's GPE
          clearing performed in acpi_enable_gpe();
       b. If the GPE is cleared when GPE is disabled, then EN=1 write in
          acpi_enable_gpe() cannot trigger this GPE;
       c. If no polling mechanism is implemented in the driver for this
          event (for example, SCI_EVT), this event is lost due to no GPE
          being triggered.
       Note 4:
       Currently we don't have this issue, but after we switch the EC
       driver into ACPI_GPE_DISPATCH_RAW_HANDLER mode, we need to take care
       of handling this because the EN=1 write in acpi_ev_gpe_dispatch()
       will be abandoned.

There might be more race issues for the current GPE handler usages. This is
because the EC IRQ's enabling/disabling/checking/clearing/handling
operations should be locked by a single lock that is under the EC driver's
control to achieve the serialization. Which means we need to invoke GPE
APIs with EC driver's lock held and all ACPICA internal GPE operations
related to the GPE handler should be abandoned. Invoking GPE APIs inside of
the EC driver lock and bypassing ACPICA internal GPE operations requires
the ACPI_GPE_DISPATCH_RAW_HANDLER mode where the same lock used by the APIs
are released prior than invoking the handlers. Otherwise, we can see dead
locks due to circular locking dependencies (see Reference below).

This patch then switches the EC driver into the
ACPI_GPE_DISPATCH_RAW_HANDLER mode so that it can perform correct GPE
operations using the GPE APIs:
1. Bypasses EN modifications performed in acpi_ev_gpe_dispatch() by
   using acpi_install_gpe_raw_handler() and invoking all GPE APIs with EC
   spin lock held. This can fix issue 1 as it makes a non frequent GPE
   enabling/disabling environment.
2. Bypasses STS clearing performed in acpi_enable_gpe() by replacing
   acpi_enable_gpe()/acpi_disable_gpe() with acpi_set_gpe(). This can fix
   issue 4. And this can also help to fix issue 1 as it makes a no sudden
   GPE clearing environment when GPE is frequently enabled/disabled.
3. Ensures STS acknowledged before handling by invoking acpi_clear_gpe()
   in advance_transaction(). This can finally fix issue 1 even in a
   frequent GPE enabling/disabling environment. And this can also finally
   fix issue 3 when issue 2 is fixed.
   Note 3:
   GPE clearing is edge triggered W1C, which means we can clear it right
   before handling it. Since all EC GPE indications are handled in
   advance_transaction() by previous commits, we can now move GPE clearing
   into it to implement the correct GPE clearing.
   Note 4:
   We can use acpi_set_gpe() which is not shared GPE safer instead of
   acpi_enable_gpe()/acpi_disable_gpe() because EC GPE is not shared by
   other hardware, which is mentioned in the ACPI specification 5.0, 12.6
   Interrupt Model: "OSPM driver treats this as an edge event (the EC SCI
   cannot be shared)". So we can stop using shared GPE safer APIs
   acpi_enable_gpe()/acpi_disable_gpe() in the EC driver. Otherwise
   cleanups need to be made in acpi_ev_enable_gpe() to bypass the GPE
   clearing logic before keeping acpi_enable_gpe().
This patch also invokes advance_transaction() when GPE is re-enabled in the
task context which:
1. Ensures EN=1 can trigger GPE by checking and handling EC status register
   right after EN=1 writes. This can fix issue 2.

After applying this patch, without frequent GPE enablings considered:
       =================================================================
       (event pending A)
       =================================================================
       acpi_ec_gpe_handler()     ec_poll()
       *****************************************************************
       (event handling A)
         Lock(EC)
           advance_transaction()
             if STS==1
               STS=0
             EC_SC read
       =================================================================
       (event pending B)
       =================================================================
             EC_SC handled
         Unlock(EC)
       *****************************************************************
       *****************************************************************
       (event handling B)
                                   Lock(EC)
                                     advance_transaction()
                                       if STS==1
                                         STS=0
                                       EC_SC read
       =================================================================
       (event pending C)
       =================================================================
                                       EC_SC handled
                                   Unlock(EC)
       *****************************************************************
The event pending for issue 1 (event pending B) can arrive as a next GPE
due to the previous IRQ context STS=0 write. And if it is handled by
ec_poll() (event handling B), as it is also acknowledged by ec_poll(), the
event pending for issue 2 (event pending C) can properly arrive as a next
GPE after the task context STS=0 write. So no GPE will be lost and never
triggered due to GPE clearing performed in the wrong position. And since
all GPE handling is performed after a locked GPE status checking, we can
hardly see no-op GPE handler invocations due to issue 1 and 3. We may still
see no-op GPE handler invocations due to "Note 1", but as it is inevitable,
it needn't be fixed.

After applying this patch, with frequent GPE enablings considered:
       =================================================================
       (event pending A)
       =================================================================
       acpi_ec_gpe_handler()     acpi_ec_transaction()
       *****************************************************************
       (event handling A)
         Lock(EC)
           advance_transaction()
             if STS==1
               STS=0
             EC_SC read
       =================================================================
       (event pending B)
       =================================================================
             EC_SC handled
         Unlock(EC)
       *****************************************************************
       *****************************************************************
       (event handling B)
                                   Lock(EC)
                                     EN=1
                                     if STS==1
                                       advance_transaction()
                                         if STS==1
                                           STS=0
                                         EC_SC read
       =================================================================
       (event pending C)
       =================================================================
                                         EC_SC handled
                                   Unlock(EC)
       *****************************************************************
The event pending for issue 2 can be manually handled by
advance_transaction(). And after the STS=0 write performed in the manual
triggered advance_transaction(), GPE can always arrive. So no GPE will be
lost due to frequent GPE disabling/enabling performed in the driver like
issue 4.
Note 5:
It's ideally when EN=1 write occurred, an IRQ thread should be woken up to
handle the GPE when the GPE was raised. But this requires the IRQ thread to
contain the poller code for all EC GPE indications, while currently some of
the indications are handled in the user tasks. It then is very hard for the
code to determine whether a user task should be invoked or the poller work
item should be scheduled. So we have to invoke advance_transaction()
directly now and it leaves us such a restriction for the GPE re-enabling:
it must be performed in the task context to avoid starving the GPEs.

As a conclusion: we can see the EC GPE is always handled in serial after
deploying the raw GPE handler mode:
  Lock(EC)
  if (STS==1)
    STS=0
  EC_SC read
  EC_SC handled
  Unlock(EC)
The EC driver specific lock is responsible to make the EC GPE handling
processes serialized so that EC can handle its GPE from both IRQ and task
contexts and the next IRQ can be ensured to arrive after this process.

Note 6:
We have many EC_FLAGS_MSI qurik users in the current driver. They all seem
to be suffering from unexpected GPE triggering source lost. And they are
false root caused to a timing issue. Since EC communication protocol has
already flow control defined, timing shouldn't be the root cause, while
this fix might be fixing the root cause of the old bugs.

Link: https://lkml.org/lkml/2014/11/4/974
Link: https://lkml.org/lkml/2014/11/18/316
Link: https://www.spinics.net/lists/linux-acpi/msg54340.htmlSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ca37bfdf
    • L
      ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model · 2eedd3d8
      由 Lv Zheng 提交于 
      ACPICA commit da9a83e1a845f2d7332bdbc0632466b2595e5424

For acpi_set_gpe()/acpi_enable_gpe(), our target is to purify them to be APIs
that can be used for various GPE handling models, so we need them to be
pure GPE enabling APIs. GPE enabling/disabling has 2 use cases:
1. Driver may permanently enable/disable GPEs according to the usage
   counts.
   1. When upper layers (the users of the driver) submit requests to the
      driver, it means they care about the underlying hardware. GPE need
      to be enabled for the first request submission and disabled for the
      last request completion.
   2. When the GPE is shared between 2+ silicon logics. GPE need to be
      enabled for either silicon logic's driver and disabled when all of
      the drivers are not started.
   For these cases, acpi_enable_gpe()/acpi_disable_gpe() should be used. When
   the usage count is increased from 0 to 1, the GPE is enabled and it is
   disabled when the usage count is decrased from 1 to 0.
2. Driver may temporarily disables the GPE to enter an GPE polling mode and
   wants to re-enable it later.
   1. Prevent GPE storming: when a driver cannot fully solve the condition
      that triggered the GPE in the GPE context, in order not to trigger
      GPE storm, driver has to disable GPE to switch into the polling mode
      and re-enables it in the non interrupt context after the storming
      condition is cleared.
   2. Meet throughput requirement: some IO drivers need to poll hardware
      again and again until nothing indicated instead of just handling once
      for one interruption, this need to be done in the polling mode or the
      IO flood may prevent the GPE handler from returning.
   3. Meet realtime requirement: in order not to block CPU to handle higher
      realtime prioritized GPEs, lower priority GPEs can be handled in the
      polling mode.
   For these cases, acpi_set_gpe() should be used to switch to/from the
   polling mode.

This patch adds unconditional GPE enabling support into acpi_set_gpe() so
that this API can be used by the drivers to switch back from the GPE
polling mode unconditionally.

Originally this function includes GPE clearing logic in it.
First, the GPE clearing is typically used in the GPE handling code to:
1. Acknowledge the GPE when we know there is an edge triggered GPE raised
   and is about to handle it, otherwise the unexpected clearing may lead to
   a GPE loss;
2. Issue actions after we have handled a level triggered GPE, otherwise
   the unexpected clearing may trigger unwanted OSPM actions to the
   hardware (for example, clocking in out-dated write FIFO data).
Thus the GPE clearing is not suitable to be used in the GPE enabling APIs.
Second, the combination of acknowledging and enabling may also not be
expected by the hardware drivers. For GPE clearing, we have a seperate API
acpi_clear_gpe(). There are cases drivers do want the 2 operations to be
split. So splitting these 2 operations could facilitates drivers the
maximum possibilities to achieve success. For a combined one, we already
have acpi_finish_gpe() ready to be invoked.

Given the fact that drivers should complete all outstanding requests before
putting themselves into the sleep states, as this API is executed for
outstanding requests, it should also have nothing to do with the
"RUN"/"WAKE" distinguishing. That's why the acpi_set_gpe(ACPI_GPE_ENABLE)
should not be implemented by acpi_hw_low_set_gpe(ACPI_GPE_CONDITIONAL_ENABLE).

This patch thus converts acpi_set_gpe(ACPI_GPE_ENABLE) into
acpi_hw_low_set_gpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers then are encouraged to use this API when they need to switch
to/from the GPE polling mode.

Note that the acpi_set_gpe()/acpi_finish_gpe() should be first introduced to
Linux using a divergence reduction patch before sending a linuxized version
of this patch. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/da9a83e1Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2eedd3d8
    • L
      ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences · eb3d80f7
      由 Lv Zheng 提交于 
      This can help to reduce source code differences between Linux and ACPICA
upstream. Further driver cleanups also require these APIs to eliminate GPE
storms.
1. acpi_set_gpe(): An API that driver should invoke in the case it wants
                   to disable/enable IRQ without honoring the reference
                   count implemented in the acpi_disable_gpe() and
                   acpi_enable_gpe(). Note that this API should only be
                   invoked inside a acpi_enable_gpe()/acpi_disable_gpe()
                   pair.
2. acpi_finish_gpe(): Drivers returned ACPI_REENABLE_GPE unset from the
                      GPE handler should use this API instead of
                      invoking acpi_set_gpe()/acpi_enable_gpe() to
                      re-enable the GPE.
The GPE APIs can be invoked inside of a GPE handler or in the task context
with a driver provided lock held. This driver provided lock is safe to be
held in the GPE handler by the driver.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eb3d80f7
    • L
      ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs · 0d0988af
      由 Lv Zheng 提交于 
      ACPICA commit 199cad16530a45aea2bec98e528866e20c5927e1

Since whether the GPE should be disabled/enabled/cleared should only be
determined by the GPE driver's state machine:
1. GPE should be disabled if the driver wants to switch to the GPE polling
   mode when a GPE storm condition is indicated and should be enabled if
   the driver wants to switch back to the GPE interrupt mode when all of
   the storm conditions are cleared. The conditions should be protected by
   the driver's specific lock.
2. GPE should be enabled if the driver has accepted more than one request
   and should be disabled if the driver has completed all of the requests.
   The request count should be protected by the driver's specific lock.
3. GPE should be cleared either when the driver is about to handle an edge
   triggered GPE or when the driver has completed to handle a level
   triggered GPE. The handling code should be protected by the driver's
   specific lock.
Thus the GPE enabling/disabling/clearing operations are likely to be
performed with the driver's specific lock held while we currently cannot do
this. This is because:
1. We have the acpi_gbl_gpe_lock held before invoking the GPE driver's
   handler. Driver's specific lock is likely to be held inside of the
   handler, thus we can see some dead lock issues due to the reversed
   locking order or recursive locking. In order to solve such dead lock
   issues, we need to unlock the acpi_gbl_gpe_lock before invoking the
   handler. BZ 1100.
2. Since GPE disabling/enabling/clearing should be determined by the GPE
   driver's state machine, we shouldn't perform such operations inside of
   ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101.

Originally this patch includes a logic to flush GPE handlers, it is dropped
due to the following reasons:
1. This is a different issue;
2. Linux OSL has fixed this by flushing SCI in acpi_os_wait_events_complete().
We will pick up this topic when the Linux OSL fix turns out to be not
sufficient.

Note that currently the internal operations and the acpi_gbl_gpe_lock are
also used by ACPI_GPE_DISPATCH_METHOD and ACPI_GPE_DISPATCH_NOTIFY. In
order not to introduce regressions, we add one
ACPI_GPE_DISPATCH_RAW_HANDLER type to be distiguished from
ACPI_GPE_DISPATCH_HANDLER. For which the acpi_gbl_gpe_lock is unlocked before
invoking the GPE handler and the internal enabling/disabling operations are
bypassed to allow drivers to perform them at a proper position using the
GPE APIs and ACPI_GPE_DISPATCH_RAW_HANDLER users should invoke acpi_set_gpe()
instead of acpi_enable_gpe()/acpi_disable_gpe() to bypass the internal GPE
clearing code in acpi_enable_gpe(). Lv Zheng.

Known issues:
1. Edge-triggered GPE lost for frequent enablings
   On some buggy silicon platforms, GPE enable line may not be directly
   wired to the GPE trigger line. In that case, when GPE enabling is
   frequently performed for edge-triggered GPEs, GPE status may stay set
   without being triggered.
   This patch may maginify this problem as it allows GPE enabling to be
   parallel performed during the process the GPEs are handled.
   This is an existing issue, because:
   1. For task context:
      Current ACPI_GPE_DISPATCH_METHOD practices have proven that this
      isn't a real issue - we can re-enable edge-triggered GPE in a work
      queue where the GPE status bit might already be set.
   2. For IRQ context:
      This can even happen when the GPE enabling occurs before returning
      from the GPE handler and after unlocking the GPE lock.
   Thus currently no code is included to protect this.

Link: https://github.com/acpica/acpica/commit/199cad16Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0d0988af
    • D
      ACPICA: Update Copyright headers to 2015 · 82a80941
      由 David E. Box 提交于 
      ACPICA commit 8990e73ab2aa15d6a0068b860ab54feff25bee36

Link: https://github.com/acpica/acpica/commit/8990e73aSigned-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      82a80941
    • D
      ACPICA: Hardware: Cast GPE enable_mask before storing · d6c02669
      由 David E. Box 提交于 
      ACPICA commit 490ec7f7839bf7ee5e8710a34d1d1a78d54a49b6

In function acpi_hw_low_set_gpe(), cast enable_mask to u8 before
storing. The mask was read from a 32 bit register but is an 8 bit
value. Fixes Visual Studio compiler warning.

Link: https://github.com/acpica/acpica/commit/490ec7f7Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d6c02669
    • L
      ACPICA: Events: Cleanup GPE dispatcher type obtaining code · 7c43312a
      由 Lv Zheng 提交于 
      ACPICA commit 7926d5ca9452c87f866938dcea8f12e1efb58f89

There is an issue in acpi_install_gpe_handler() and acpi_remove_gpe_handler().
The code to obtain the GPE dispatcher type from the Handler->original_flags
is wrong:
    if (((Handler->original_flags & ACPI_GPE_DISPATCH_METHOD) ||
         (Handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) &&
ACPI_GPE_DISPATCH_NOTIFY is 0x03 and ACPI_GPE_DISPATCH_METHOD is 0x02, thus
this statement is TRUE for the following dispatcher types:
    0x01 (ACPI_GPE_DISPATCH_HANDLER): not expected
    0x02 (ACPI_GPE_DISPATCH_METHOD): expected
    0x03 (ACPI_GPE_DISPATCH_NOTIFY): expected

There is no functional issue due to this because Handler->original_flags is
only set in acpi_install_gpe_handler(), and an earlier checker has excluded
the ACPI_GPE_DISPATCH_HANDLER:
    if ((gpe_event_info->Flags & ACPI_GPE_DISPATCH_MASK) ==
            ACPI_GPE_DISPATCH_HANDLER)
    {
        Status = AE_ALREADY_EXISTS;
        goto free_and_exit;
    }
    ...
    Handler->original_flags = (u8) (gpe_event_info->Flags &
        (ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK));

We need to clean this up before modifying the GPE dispatcher type values.

In order to prevent such issue from happening in the future, this patch
introduces ACPI_GPE_DISPATCH_TYPE() macro to be used to obtain the GPE
dispatcher types. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/7926d5caSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7c43312a
    • L
      ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out... · 779ba5a3
      由 Lv Zheng 提交于 
      ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out of acpi_ev_gpe_dispatch()

ACPICA commit 04f25acdd4f655ae33f83de789bb5f4b7790171c

This patch follows acpi_ev_fixed_event_detect(), which invokes
acpi_gbl_global_event_handler instead of invoking it in
acpi_ev_fixed_event_dispatch(), moves acpi_gbl_global_event_handler from
acpi_ev_gpe_dispatch() to acpi_ev_gpe_detect(). This makes further cleanups
around acpi_ev_gpe_dispatch() simpler. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/04f25acdSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      779ba5a3
    • L
      ACPICA: Events: Cleanup of resetting the GPE handler to NULL before removing · c539251e
      由 Lv Zheng 提交于 
      ACPICA commit b2b18bb38045404e253f10787b8a4ae6e94cdee6

This patch prevents acpi_remove_gpe_handler() from leaking the stale
gpe_event_info->Dispatch.Handler to the caller to avoid possible NULL pointer
references. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/b2b18bb3Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c539251e
    • D
      ACPICA: Events: Fix uninitialized variable · b7be6883
      由 David E. Box 提交于 
      ACPICA commit 8e21180050270897499652e922c6a41b8eb388b6

Recent changes to acpi_ev_asynch_execute_gpe_method left Status
variable uninitialized before use. Initialize to AE_OK.

Link: https://github.com/acpica/acpica/commit/8e211800Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b7be6883
    • L
      ACPICA: Events: Remove acpi_ev_valid_gpe_event() due to current restriction · b18da580
      由 Lv Zheng 提交于 
      ACPICA commit 8823b44ff53859ab24ecfcfd3fba8cc56b17d223

Currently we rely on the logic that GPE blocks will never be deleted,
otherwise we can be broken by the race between acpi_ev_create_gpe_block(),
acpi_ev_delete_gpe_block() and acpi_ev_gpe_detect().
On the other hand, if we want to protect GPE block creation/deletion, we
need to use a different synchronization facility to protect the period
between acpi_ev_gpe_dispatch() and acpi_ev_asynch_enable_gpe(). Which leaves us
no choice but abandoning the ACPI_MTX_EVENTS used during this period.

This patch removes ACPI_MTX_EVENTS used during this period and the
acpi_ev_valid_gpe_event() to reflect current restriction. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/8823b44fSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b18da580
    • L
      ACPICA: Events: Remove duplicated sanity check in acpi_ev_enable_gpe() · 833bb931
      由 Lv Zheng 提交于 
      ACPICA commit ca10324788bc9bdaf47fa9e51145129c1299144d

This patch deletes a sanity check from acpi_ev_enable_gpe().

This kind of check is already done in
acpi_enable_gpe()/acpi_remove_gpe_handler()/acpi_update_all_gpes() before invoking
acpi_ev_enable_gpe():
1. acpi_enable_gpe(): same check (skip if DISPATCH_NONE) is now implemented.
2. acpi_remove_gpe_handler(): a more strict check (skip if !DISPATCH_HANDLER)
                           is implemented.
3. acpi_update_all_gpes(): a more strict check (skip if DISPATCH_NONE ||
                        DISPATCH_HANDLER || CAN_WAKE)
4. acpi_set_gpe(): since it is invoked by the OSPM driver where the GPE
                 handler is known to be available, such check isn't needed.
So we can simply remove this duplicated check from acpi_ev_enable_gpe().
Lv Zheng.

Link: https://github.com/acpica/acpica/commit/ca103247Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      833bb931
    • L
      ACPICA: Events: Back port "ACPICA: Save current masks of enabled GPEs after enable register writes" · 1c4c81a2
      由 Lv Zheng 提交于 
      This is a back port result of the Linux commit:
  Commit c50f13c6
  Subject: ACPICA: Save current masks of enabled GPEs after enable register writes

Besides of the indent divergences, only a missing prototype added due to
the ACPICA internal coding style.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1c4c81a2