| Message ID | 20240603063834.5580-1-ben@jubnut.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/chrome: Fix MEC concurrency problems for Framework Laptop | expand |
On Mon, Jun 3, 2024 at 1:38 AM Ben Walsh <ben@jubnut.com> wrote: > > It has _not_ been tested on any Chromebook devices. Good news! I've tested this patch series on the following devices: - Chromebook Pixel 2013 ("link") - Framework Laptop 11th Gen Intel Core ("hx20"), firmware revision 3.19 - Framework Laptop AMD Ryzen 7040 Series ("azalea"), firmware revision 3.05 It works as expected. There is no detectable difference at runtime on Link, nor does the driver appear to improperly bind any ACPI devices. I cannot reproduce bus contention on hx20, even performing operations that would consistently fail without this patch (e.g. long flash reads). Therefore, for the series: Tested-on: link, hx20, azalea Tested-by: Dustin L. Howett <dustin@howett.net>
Dustin Howett <dustin@howett.net> writes: > I've tested this patch series on the following devices: > > - Chromebook Pixel 2013 ("link") > - Framework Laptop 11th Gen Intel Core ("hx20"), firmware revision 3.19 > - Framework Laptop AMD Ryzen 7040 Series ("azalea"), firmware revision 3.05 > > It works as expected. Very cool! Thanks for looking at this, Dustin.
Framework Laptops with the Microchip EC have a problem where the EC "stops working" after a while. Symptoms include the Fn key not working, and "bad packet checksum" errors appearing in the system log. The problem is caused by ACPI code which accesses the Microchip EC (MEC) memory using the Microchip EMI protocol. It uses an AML mutex to prevent concurrent access. But the cros_ec_lpc driver is not aware of this mutex. The ACPI code and LPC driver both attempt to talk to the EC at the same time, messing up communication with the EC. The solution is to have the cros_ec_lpc_mec code find and use the AML mutex. But to make it all work we have to do a few more things: * Allow the cros_ec_lpc_mec code to return error codes in case it can't lock the mutex. * Have the cros_ec_lpc code find the correct ACPI device (PNP0C09) and then the AML mutex itself. * Use the quirks mechanism to specify the AML mutex name. The code has been tested on an 11th-generation Intel Framework Laptop (with Microchip EC) and an AMD Framework Laptop (without Microchip EC). It has _not_ been tested on any Chromebook devices. Changes in v2: * Put ACPI id in a quirk, not the acpi_match_table. * Add return code check for mutex unlock. * Remove "in_range" check which belongs in a separate patch. * Use "ret" not "sum" variable (same value but clearer). * Remove excessive error logging. * Rebase to latest ChromeOS for-next branch. Ben Walsh (5): platform/chrome: cros_ec_lpc: MEC access can return error code platform/chrome: cros_ec_lpc: MEC access can use an AML mutex platform/chrome: cros_ec_lpc: Add a new quirk for ACPI id platform/chrome: cros_ec_lpc: Add a new quirk for AML mutex platform/chrome: cros_ec_lpc: Add quirks for Framework Laptop drivers/platform/chrome/cros_ec_lpc.c | 210 +++++++++++++++------ drivers/platform/chrome/cros_ec_lpc_mec.c | 87 ++++++++- drivers/platform/chrome/cros_ec_lpc_mec.h | 18 +- drivers/platform/chrome/wilco_ec/mailbox.c | 22 ++- 4 files changed, 264 insertions(+), 73 deletions(-) base-commit: bc3e45258096f2ea2116302abefde4b1cb9bc3c1