From: Wei-Ning Huang <wnhuang@chromium.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Douglas Anderson <dianders@google.com>,
Duncan Laurie <dlaurie@google.com>,
Andrew de los Reyes <adlr@google.com>,
Wei-Ning Huang <wnhuang@chromium.org>,
lee.jones@linaro.org
Subject: [PATCH v3] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE
Date: Tue, 16 May 2017 02:01:38 +0800 [thread overview]
Message-ID: <20170515180138.91592-1-wnhuang@google.com> (raw)
From: Wei-Ning Huang <wnhuang@chromium.org>
Some EC chip has larger flash sector size which requires longer erase
time. During erase the CPU is usually stalled and can't even respond to
interrupts. We sleep a while to block any EC command from executing
during the flash erase period.
Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
---
drivers/mfd/cros_ec_i2c.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1e4c70..c1b5c831b9cb 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -23,6 +23,14 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
+/*
+ * Some EC chip has larger flash sector size which requires longer erase time.
+ * During erase the CPU is usually stalled and can't even respond to
+ * interrupts. We sleep for a while to block any EC command from executing
+ * during the flash erase period to prevent i2c timeout.
+ */
+#define EC_FLASH_ERASE_DELAY_MS 5000
+
/**
* Request format for protocol v3
* byte 0 0xda (EC_COMMAND_PROTOCOL_3)
@@ -120,7 +128,7 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device *ec_dev,
ret = -EAGAIN;
dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
msg->command);
- goto done;
+ goto inprogress;
default:
dev_dbg(ec_dev->dev, "command 0x%02x returned %d\n",
@@ -177,7 +185,19 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device *ec_dev,
ret = ec_response->data_len;
+inprogress:
+ /*
+ * If we get EC_RES_IN_PROGRESS for EC_CMD_FLASH_ERASE this means EC
+ * need a long time to erase flash, during flash erase CPU is stalled
+ * and can't respond to interrupts, so we sleep for a while to stop new
+ * EC commands from communicating with EC.
+ */
+ if (msg->command == EC_CMD_FLASH_ERASE &&
+ msg->result == EC_RES_IN_PROGRESS)
+ msleep(EC_FLASH_ERASE_DELAY_MS);
+
done:
+
if (msg->command == EC_CMD_REBOOT_EC)
msleep(EC_REBOOT_DELAY_MS);
--
2.12.2
reply other threads:[~2017-05-16 2:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170515180138.91592-1-wnhuang@google.com \
--to=wnhuang@chromium.org \
--cc=adlr@google.com \
--cc=dianders@google.com \
--cc=dlaurie@google.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®