| Message ID | 1408536812-7836-2-git-send-email-javier.martinez@collabora.co.uk (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote: > From: Doug Anderson <dianders@chromium.org> > > 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. Are you planning on doing that? > * 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> > --- > drivers/mfd/cros_ec_spi.c | 9 +++++++++ > 1 file changed, 9 insertions(+) I'm willing to accept this as a stand-in. Acked-by: Lee Jones <lee.jones@linaro.org>
Hello Lee, On 08/21/2014 03:37 PM, Lee Jones wrote: > On Wed, 20 Aug 2014, Javier Martinez Canillas wrote: >> From: Doug Anderson <dianders@chromium.org> >> >> 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. > > Are you planning on doing that? > Yes, I'll add to my TO-DO list to look how better solve this after the remaining functionality that is present in downstream but is still not in mainline gets merged. >> * 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> >> --- >> drivers/mfd/cros_ec_spi.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) > > I'm willing to accept this as a stand-in. > Thanks. > Acked-by: Lee Jones <lee.jones@linaro.org> > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 588c700..b396705 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -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; }