summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/ec.c
Commit message (Collapse)AuthorAgeFilesLines
...
* ACPI / EC: Add command flushing support.Lv Zheng2015-02-061-3/+65
| | | | | | | | | | | | | | | | | | | | 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: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flagLv Zheng2015-02-061-11/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Update revision due to raw handler mode.Lv Zheng2015-02-051-3/+3
| | | | | | | | | | 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: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp.Lv Zheng2015-02-051-3/+14
| | | | | | | | | | | | | | | | | 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: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix several GPE handling issues by deploying ↵Lv Zheng2015-02-051-8/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI_GPE_DISPATCH_RAW_HANDLER mode. 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.html Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Cleanup QR_EC related codeLv Zheng2015-01-231-50/+20
| | | | | | | | | | | | | | | | | The QR_EC related code pieces have redundants, this patch merges them into acpi_ec_query() which invokes acpi_ec_transaction() where EC mutex and the global lock are already held. After doing so, query handler traversal still need to be locked by EC mutex after invoking acpi_ec_transaction(). Note that EC event handling is sequential. We fetch one event from firmware event queue and process it until 0x00 or error returned. So we don't need to hold mutex for whole acpi_ec_clear() process to determine whether we should continue to drain. And for the same reason, we don't need to hold mutex for the whole procedure from the QR_EC transaction to the query handler traversal. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix issues related to the SCI_EVT handlingLv Zheng2015-01-231-34/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes 2 issues related to the draining behavior. But it doesn't implement the draining support, it only cleans up code so that further draining support is possible. The draining behavior is expected by some platforms (for example, Samsung) where SCI_EVT is set only once for a set of events and might be cleared for the very first QR_EC command issued after SCI_EVT is set. EC firmware on such platforms will return 0x00 to indicate "no outstanding event". Thus after seeing an SCI_EVT indication, EC driver need to fetch events until 0x00 returned (see acpi_ec_clear()). Issue 1 - acpi_ec_submit_query(): It's reported on Samsung laptops that SCI_EVT isn't checked when the transactions are advanced in ec_poll(), which leads to SCI_EVT triggering source lost: If no EC GPE IRQs are arrived after that, EC driver cannot detect this event and handle it. See comment 244/247 for kernel bugzilla 44161. This patch fixes this issue by moving SCI_EVT checks into advance_transaction(). So that SCI_EVT is checked each time we are going to handle the EC firmware indications. And this check will happen for both IRQ context and task context. Since after doing that, SCI_EVT is also checked after completing a transaction, ec_check_sci() and ec_check_sci_sync() can be removed. Issue 2 - acpi_ec_complete_query(): We expect to clear EC_FLAGS_QUERY_PENDING to allow queuing another draining QR_EC after writing a QR_EC command and before reading the event. After reading the event, SCI_EVT might be cleared by the firmware, thus it may not be possible to queue such a draining QR_EC at that time. But putting the EC_FLAGS_QUERY_PENDING clearing code after start_transaction() is wrong as there are chances that after start_transaction(), QR_EC can fail to be sent. If this happens, EC_FLAG_QUERY_PENDING will be cleared earlier. As a consequence, the draining QR_EC will also be queued earlier than expected. This patch also moves this code into advance_transaction() where QR_EC is just sent (ACPI_EC_COMMAND_POLL flagged) to fix this issue. Notes: 1. After introducing the 2 SCI_EVT related handlings into advance_transaction(), a next QR_EC can be queued right after writing the current QR_EC command and before reading the event. But this still hasn't implemented the draining behavior as the draining support requires: If a previous returned event value isn't 0x00, a draining QR_EC need to be issued even when SCI_EVT isn't set. 2. In this patch, acpi_os_execute() is also converted into a seperate work item to avoid invoking kmalloc() in the atomic context. We can do this because of the previous global lock fix. 3. Originally, EC_FLAGS_EVENT_PENDING is also used to avoid queuing up multiple work items (created by acpi_os_execute()), this can be covered by only using a single work item. But this patch still keeps this flag as there are different usages in the driver initialization steps relying on this flag. Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-by: Kieran Clancy <clancy.kieran@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix a code path that global lock is not heldLv Zheng2015-01-231-0/+10
| | | | | | | | | | | | | | | | | | | Currently QR_EC is queued up on CPU 0 to be safe with SMM because there is no global lock held for acpi_ec_gpe_query(). As we are about to move QR_EC to a non CPU 0 bound work queue to avoid invoking kmalloc() in advance_transaction(), we have to acquire global lock for the new QR_EC work item to avoid regressions. Known issue: 1. Global lock for acpi_ec_clear(). This is an existing issue that acpi_ec_clear() which invokes acpi_ec_sync_query() also suffers from the same issue. But this patch's target is only the code to invoke acpi_ec_sync_query() in a CPU 0 bound work queue item, and the acpi_ec_clear() can be automatically fixed by further patch that merges the redundant code, so it is left unchanged. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix returning values in acpi_ec_sync_query()Lv Zheng2015-01-231-6/+10
| | | | | | | | | The returning value of acpi_os_execute() is erroneously handled as errno. This patch corrects it by returning EBUSY to indicate the work queue item creation failure. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add reference counting for query handlersLv Zheng2015-01-231-10/+33
| | | | | | | | | | This patch adds reference counting for query handlers in order to eliminate kmalloc()/kfree() usage. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Cleanup transaction wakeup codeLv Zheng2015-01-231-8/+9
| | | | | | | | This patch moves transaction wakeup code into advance_transaction(). No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix unexpected ec_remove_handlers() invocationsLv Zheng2014-12-151-0/+2
| | | | | | | | | | | | The ec_remove_handlers() is invoked without checking EC_FLAGS_HANDLERS_INSTALLED, this patch enhances this check to avoid issues that acpi_disable_gpe() is invoked unexpectedly to reduce the GPE runtime count. This may happen when the EC handler installation failed on some platforms. Reported-by: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix regression due to conflicting firmware behavior between ↵Lv Zheng2014-10-291-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Samsung and Acer. It is reported that Samsung laptops that need to poll events are broken by the following commit: Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 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: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ [ rjw : Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Revert "ACPI / EC: Add support to disallow QR_EC to be issued before ↵Lv Zheng2014-10-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | completing previous QR_EC" It is reported that the following commit breaks Samsung hardware: Commit: 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4. 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: 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 can be reverted. Fixes: 558e4736f2e1 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Cleanup coding style.Lv Zheng2014-10-211-26/+30
| | | | | | | | | | | | | | | | | | | This patch cleans up the following coding style issues that are detected by scripts/checkpatch.pl: ERROR: code indent should use tabs where possible ERROR: "foo * bar" should be "foo *bar" WARNING: Missing a blank line after declarations WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable WARNING: void function return statements are not generally useful WARNING: else is not generally useful after a break or return WARNING: break is not useful after a goto or return WARNING: braces {} are not necessary for single statement blocks WARNING: line over 80 characters WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Refine event/query debugging messages.Lv Zheng2014-10-211-6/+8
| | | | | | | | | This patch refines event/query debugging messages to use a unified format as commands. Developers can clearly find different processes by checking different log seperators. No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add detailed command/query debugging information.Lv Zheng2014-10-211-5/+29
| | | | | | | | | | Developers really don't need to translate EC commands in mind. This patch adds detailed debugging information for the EC commands. The address can be found in the follow-up sequential EC_DATA(W) accesses, thus this patch also removes some of the redundant address information. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Enhance the logs to apply to QR_EC transactions.Lv Zheng2014-10-211-3/+3
| | | | | | | | | Currently some logs are applied to new transactions, but QR_EC transactions are not included. This patch merges the code path to make the logs also applying to the QR_EC transactions. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add CPU ID to debugging messages.Lv Zheng2014-10-211-1/+2
| | | | | | | | This patch adds CPU ID to the context entries' debugging output. no functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add msi quirk for Clevo W350etqLan Tianyu2014-09-021-0/+4
| | | | | | | | | | | | Clevo W350etq's EC will not produce GPE interrupt some time after booting. The ACPI notify event won't trigger when the issue takes place. After debugging, adding msi quirk for the machine can fix the issue. This patch is to add msi quirk for the machine. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Reported-and-tested-by: qbanin@gmail.com Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add support to disallow QR_EC to be issued before completing ↵Lv Zheng2014-08-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | previous QR_EC There is platform refusing to respond QR_EC when SCI_EVT isn't set which is Acer Aspire V5-573G. By disallowing QR_EC to be issued before the previous one has been completed we are able to reduce the possibilities to trigger issues on such platforms. Note that this fix can only reduce the occurrence rate of this issue, but this issue may still occur when such a platform doesn't clear SCI_EVT before or immediately after completing the previous QR_EC transaction. This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. But this patch is still useful as it can help to reduce the number of scheduled QR_EC work items. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't setLv Zheng2014-08-261-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a platform refusing to respond QR_EC when SCI_EVT isn't set (Acer Aspire V5-573G). Currently, we rely on the behaviour that the EC firmware can respond something (for example, 0x00 to indicate "no outstanding events") to QR_EC even when SCI_EVT is not set, but the reporter has complained about AC/battery pluging/unpluging and video brightness change delay on that platform. This is because the work item that has issued QR_EC has to wait until timeout in this case, and the _Qxx method evaluation work item queued after QR_EC one is delayed. It sounds reasonable to fix this issue by: 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC driver's main state machine. 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation to a seperate IRQ handling thread. This patch fixes this issue using solution 1. By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to handle such platform in the EC driver's main state machine. This patch enhances the state machine in this way to survive with such malfunctioning EC firmware. Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed() Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Free saved_ec on error exit pathColin Ian King2014-07-071-1/+4
| | | | | | | | | | | | | | | | Smatch detected two memory leaks on saved_ec: drivers/acpi/ec.c:1070 acpi_ec_ecdt_probe() warn: possible memory leak of 'saved_ec' drivers/acpi/ec.c:1109 acpi_ec_ecdt_probe() warn: possible memory leak of 'saved_ec' Free saved_ec on these two error exit paths to stop the memory leak. Note that saved_ec maybe null, but kfree on null is allowed. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add detailed fields debugging support of EC_SC(R).Lv Zheng2014-07-071-4/+12
| | | | | | | | | | | | Developers really don't need to translate EC_SC(R) in mind as long as the field details are decoded in the debugging message. Tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Update revision due to recent changesLv Zheng2014-07-071-6/+9
| | | | | | | | | | The bug fixes and asynchronous improvements have been done to the EC driver by the previous commits. This patch increases the revision to 2.2 to indicate the behavior differences between the old and the new drivers. The copyright/authorship notices are also updated. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Fix race condition in ec_transaction_completed()Lv Zheng2014-07-071-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a race condition in ec_transaction_completed(). When ec_transaction_completed() is called in the GPE handler, it could return true because of (ec->curr == NULL). Then the wake_up() invocation could complete the next command unexpectedly since there is no lock between the 2 invocations. With the previous cleanup, the IBF=0 waiter race need not be handled any more. It's now safe to return a flag from advance_condition() to indicate the requirement of wakeup, the flag is returned from a locked context. The ec_transaction_completed() is now only invoked by the ec_poll() where the ec->curr is ensured to be different from NULL. After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a QR_SC command. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Remove duplicated ec_wait_ibf0() waiterLv Zheng2014-07-071-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | | After we've added the first command byte write into advance_transaction(), the IBF=0 waiter is duplicated with the command completion waiter implemented in the ec_poll() because: If IBF=1 blocked the first command byte write invoked in the task context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed out and retried again in the task context. Remove this seperate and duplicate IBF=0 waiter. By doing so we can reduce the overall number of times to access the EC_SC(R) status register. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add asynchronous command byte write supportLv Zheng2014-07-071-35/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the first command byte write into advance_transaction() so that all EC register accesses that can affect the command processing state machine can happen in this asynchronous state machine advancement function. The advance_transaction() function then can be a complete implementation of an asyncrhonous transaction for a single command so that: 1. The first command byte can be written in the interrupt context; 2. The command completion waiter can also be used to wait the first command byte's timeout; 3. In BURST mode, the follow-up command bytes can be written in the interrupt context directly, so that it doesn't need to return to the task context. Returning to the task context reduces the throughput of the BURST mode and in the worst cases where the system workload is very high, this leads to the hardware driven automatic BURST mode exit. In order not to increase memory consumption, convert 'done' into 'flags' to contain multiple indications: 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition, indicating the completion of the command transaction. 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first command byte. A new command can utilize this flag to compete for the right of accessing the underlying hardware. There is a follow-up bug fix that has utilized this new flag. The 2 flags are important because it also reflects a key concept of IO programs' design used in the system softwares. Normally an IO program running in the kernel should first be implemented in the asynchronous way. And the 2 flags are the most common way to implement its synchronous operations on top of the asynchronous operations: 1. POLL: This flag can be used to block until the asynchronous operations can happen. 2. COMPLETE: This flag can be used to block until the asynchronous operations have completed. By constructing code cleanly in this way, many difficult problems can be solved smoothly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Avoid race condition related to advance_transaction()Lv Zheng2014-07-071-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The advance_transaction() will be invoked from the IRQ context GPE handler and the task context ec_poll(). The handling of this function is locked so that the EC state machine are ensured to be advanced sequentially. But there is a problem. Before invoking advance_transaction(), EC_SC(R) is read. Then for advance_transaction(), there could be race condition around the lock from both contexts. The first one reading the register could fail this race and when it passes the stale register value to the state machine advancement code, the hardware condition is totally different from when the register is read. And the hardware accesses determined from the wrong hardware status can break the EC state machine. And there could be cases that the functionalities of the platform firmware are seriously affected. For example: 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the hardware will either refuse to respond a next EC_SC(W) write of the next command or discard the current WR_EC command when it receives a EC_SC(W) write of the next command. 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write. The next EC_DATA(R) could never be responded by the hardware. This is the root cause of the reported issue. Fix this issue by moving the EC_SC(R) access into the lock so that we can ensure that the state machine is advanced consistently. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Process rather than discard events in acpi_ec_clearKieran Clancy2014-04-291-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address a regression caused by commit ad332c8a4533: (ACPI / EC: Clear stale EC events on Samsung systems) After the earlier patch, there was found to be a race condition on some earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was sometimes discarding a new EC event before its GPE was triggered by the system. In the case of these systems, this meant that the "lid open" event was not registered on resume if that was the cause of the wake, leading to problems when attempting to close the lid to suspend again. After testing on a number of Samsung systems, both those affected by the previous EC bug and those affected by the race condition, it seemed that the best course of action was to process rather than discard the events. On Samsung systems which accumulate stale EC events, there does not seem to be any adverse side-effects of running the associated _Q methods. This patch adds an argument to the static function acpi_ec_sync_query so that it may be used within the acpi_ec_clear loop in place of acpi_ec_query_unlocked which was used previously. With thanks to Stefan Biereigel for reporting the issue, and for all the people who helped test the new patch on affected systems. Fixes: ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems) References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173 Reported-by: Stefan Biereigel <stefan@biereigel.de> Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com> Tested-by: Stefan Biereigel <stefan@biereigel.de> Tested-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Nicolas Porcel <nicolasporcel06@gmail.com> Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by: Giannis Koutsou <giannis.koutsou@gmail.com> Tested-by: Kieran Clancy <clancy.kieran@gmail.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Clear stale EC events on Samsung systemsKieran Clancy2014-03-061-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) continue to log events during sleep (lid open/close, AC plug/unplug, battery level change), which accumulate in the EC until a buffer fills. After the buffer is full (tests suggest it holds 8 events), GPEs stop being triggered for new events. This state persists on wake or even on power cycle, and prevents new events from being registered until the EC is manually polled. This is the root cause of a number of bugs, including AC not being detected properly, lid close not triggering suspend, and low ambient light not triggering the keyboard backlight. The bug also seemed to be responsible for performance issues on at least one user's machine. Juan Manuel Cabo found the cause of bug and the workaround of polling the EC manually on wake. The loop which clears the stale events is based on an earlier patch by Lan Tianyu (see referenced attachment). This patch: - Adds a function acpi_ec_clear() which polls the EC for stale _Q events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is logged if this limit is reached. - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI system vendor is Samsung. This check could be replaced by several more specific DMI vendor/product pairs, but it's likely that the bug affects more Samsung products than just the five series mentioned above. Further, it should not be harmful to run acpi_ec_clear() on systems without the bug; it will return immediately after finding no data waiting. - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 References: https://bugzilla.kernel.org/attachment.cgi?id=126801 Suggested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Kieran Clancy <clancy.kieran@gmail.com> Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by: San Zamoyski <san@plusnet.pl> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*-. Merge branches 'acpi-gpe', 'acpi-video', 'acpi-thermal', 'acpi-processor', ↵Rafael J. Wysocki2014-01-121-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'acpi-sleep' * acpi-gpe: ACPI / EC: disable GPE before removing GPE handler ACPI / Button: Fix enabling button GPEs twice * acpi-video: ACPI: Blacklist Win8 OSI for some HP laptop 2013 models ACPI / video: Fix typo in video_detect.c * acpi-thermal: ACPI / thermal: remove const from thermal_zone_device_ops declaration * acpi-processor: ACPI / scan: bail out early if failed to parse APIC ID for CPU * acpi-sleep: ACPI / sleep: remove panic in case hardware has changed after S4
| * | ACPI / EC: disable GPE before removing GPE handlerLan Tianyu2013-12-191-1/+1
| |/ | | | | | | | | | | | | | | | | Adjust the order of disabling the EC GPE and removing its handler to avoid unhandled events. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / EC: Remove unused functions and add prototype declaration in internal.hRashika2014-01-061-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds the prototype declarations of functions acpi_ec_add_query_handler() and acpi_ec_remove_query_handler() in header file internal.h and removes unused functions ec_burst_enable() and ec_burst_disable() in ec.c. This eliminates the following warnings in ec.c: drivers/acpi/ec.c:393:5: warning: no previous prototype for ‘ec_burst_enable’ [-Wmissing-prototypes] drivers/acpi/ec.c:402:5: warning: no previous prototype for ‘ec_burst_disable’ [-Wmissing-prototypes] drivers/acpi/ec.c:531:5: warning: no previous prototype for ‘acpi_ec_add_query_handler’ [-Wmissing-prototypes] drivers/acpi/ec.c:552:6: warning: no previous prototype for ‘acpi_ec_remove_query_handler’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: Clean up inclusions of ACPI header filesLv Zheng2013-12-071-3/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'acpi-ec'Rafael J. Wysocki2013-11-191-1/+2
|\ | | | | | | | | * acpi-ec: ACPI / EC: Ensure lock is acquired before accessing ec struct members
| * ACPI / EC: Ensure lock is acquired before accessing ec struct membersPuneet Kumar2013-11-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') that erroneously caused the struct member to be accessed before acquiring the required lock. This change fixes it by ensuring the lock acquisition is done first. Found by Aaron Durbin <adurbin@chromium.org> Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') References: http://crbug.com/319019 Signed-off-by: Puneet Kumar <puneetster@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [olof: Commit message reworded a bit] Signed-off-by: Olof Johansson <olof@lixom.net> Cc: 3.8+ <stable@vger.kernel.org> # 3.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / EC: Convert all printk() calls to dynamic debug functionLan Tianyu2013-09-251-25/+24
|/ | | | | | | | This patch is to convert all printks in the ec driver to pr_debug/info/err and define pr_fmt macro to replace PREFIX. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'acpi-assorted'Rafael J. Wysocki2013-08-301-0/+4
|\ | | | | | | | | | | * acpi-assorted: ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT ACPI / thermal: Add check of "_TZD" availability and evaluating result
| * ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDTLan Tianyu2013-08-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ECDT of ASUSTEK L4R doesn't provide correct command and data I/O ports. The DSDT provides the correct information instead. For this reason, add this machine to quirk list for ECDT validation and use the EC information from the DSDT. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=60765 Reported-and-tested-by: Daniele Esposti <expo@expobrain.net> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'acpi-assorted'Rafael J. Wysocki2013-08-271-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-assorted: ACPI / osl: Kill macro INVALID_TABLE(). earlycpio.c: Fix the confusing comment of find_cpio_data(). ACPI / x86: Print Hot-Pluggable Field in SRAT. ACPI / thermal: Use THERMAL_TRIPS_NONE macro to replace number ACPI / thermal: Remove unused macros in the driver/acpi/thermal.c ACPI / thermal: Remove the unused lock of struct acpi_thermal ACPI / osl: Fix osi_setup_entries[] __initdata attribute location ACPI / numa: Fix __init attribute location in slit_valid() ACPI / dock: Fix __init attribute location in find_dock_and_bay() ACPI / Sleep: Fix incorrect placement of __initdata ACPI / processor: Fix incorrect placement of __initdata ACPI / EC: Fix incorrect placement of __initdata ACPI / scan: Drop unnecessary label from acpi_create_platform_device() ACPI: Move acpi_bus_get_device() from bus.c to scan.c ACPI / scan: Allow platform device creation without any IO resources ACPI: Cleanup sparse warning on acpi_os_initialize1() platform / thinkpad: Remove deprecated hotkey_report_mode parameter ACPI: Remove the old /proc/acpi/event interface
| * ACPI / EC: Fix incorrect placement of __initdataSachin Kamat2013-08-071-1/+1
| | | | | | | | | | | | | | | | __initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: introduce helper function acpi_has_method()Jiang Liu2013-07-151-3/+1
|/ | | | | | | | | Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scanLan Tianyu2013-06-271-0/+4
| | | | | | | | | | | | | HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's _REG method will access that region. To allow the CMOS RTC region handler to be installed before the EC _REG method is first invoked, add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table. References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Restart transaction even when the IBF flag setLan Tianyu2013-05-121-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The EC driver works abnormally with IBF flag always set. IBF means "The host has written a byte of data to the command or data port, but the embedded controller has not yet read it". If IBF is set in the EC status and not cleared, this will cause all subsequent EC requests to fail with a timeout error. Change the EC driver so that it doesn't refuse to restart a transaction if IBF is set in the status. Also increase the number of transaction restarts to 5, as it turns out that 2 is not sufficient in some cases. This bug happens on several different machines (Asus V1S, Dell Latitude E6530, Samsung R719, Acer Aspire 5930G, Sony Vaio SR19VN and others). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=14733 References: https://bugzilla.kernel.org/show_bug.cgi?id=15560 References: https://bugzilla.kernel.org/show_bug.cgi?id=15946 References: https://bugzilla.kernel.org/show_bug.cgi?id=42945 References: https://bugzilla.kernel.org/show_bug.cgi?id=48221 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Remove useless type argument of driver .remove() operationRafael J. Wysocki2013-01-261-1/+1
| | | | | | | | | | | | | The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
* ACPI / EC: Don't count a SCI interrupt as a false oneFeng Tang2012-11-151-2/+6
| | | | | | | | | | | | | Currently when advance_transaction() is called in EC interrupt handler, if there is nothing driver can do with the interrupt, it will be taken as a false one. But this is not always true, as there may be a SCI EC interrupt fired during normal read/write operation, which should not be counted as a false one. This patch fixes the problem. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Add more debug info and trivial code cleanupFeng Tang2012-11-151-16/+21
| | | | | | | | Add more debug info for EC transaction debugging, like the interrupt status register value, the detail info of a EC transaction. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / EC: Cleanup the member name for spinlock/mutex in structFeng Tang2012-11-151-26/+26
| | | | | | | | | | | | | | | | | | | | Current member names for mutex/spinlock are a little confusing. Change the { struct mutex lock; spinlock_t curr_lock; } to { struct mutex mutex; spinlock_t lock; } So that the code is cleaner and easier to read. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: EC: Add a quirk for CLEVO M720T/M730T laptopFeng Tang2012-10-061-1/+15
| | | | | | | | | | | | By enlarging the GPE storm threshold back to 20, that laptop's EC works fine with interrupt mode instead of polling mode. https://bugzilla.kernel.org/show_bug.cgi?id=45151 Reported-and-Tested-by: Francesco <trentini@dei.unipd.it> Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> cc: stable@vger.kernel.org
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 15:02:41 +0000