Commit 659e142b authored Sep 18, 2014 by Doug Anderson Committed by Lee Jones Oct 06, 2014

mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC



If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
unresponsive for quite a while.  Add a delay to the end of the command
to prevent random failures of future commands.

NOTES:
* This could be optimized a bit by simply delaying the next command
  sent, but EC_CMD_REBOOT_EC is such a rare command that the extra
  complexity doesn't seem worth it.
* This is a bit of an "ugly hack" since the SPI driver is effectively
  snooping on the communication and making a lot of assumptions.  It
  would be nice to architect in some better solution long term.
* This same logic probably needs to be applied to the i2c driver.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

parent 48b490d2

drivers/mfd/cros_ec_spi.c

+9 −0

Original line number	Diff line number	Diff line
		@@ -65,6 +65,12 @@
		*/
		#define EC_SPI_RECOVERY_TIME_NS (200 * 1000)

		/*
		* The EC is unresponsive for a time after a reboot command. Add a
		* simple delay to make sure that the bus stays locked.
		*/
		#define EC_REBOOT_DELAY_MS 50

		/**
		* struct cros_ec_spi - information about a SPI-connected EC
		*
		@@ -318,6 +324,9 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,

		ret = len;
		exit:
		if (ec_msg->command == EC_CMD_REBOOT_EC)
		msleep(EC_REBOOT_DELAY_MS);

		mutex_unlock(&ec_spi->lock);
		return ret;
		}