
Hello Stefano,
Am 13.03.2019 um 11:04 schrieb Stefano Babic:
Hi Ian,
On 31/01/19 15:21, Ian Ray wrote:
Since 2018.11, the pattern of bootcount load and store has changed such that bootcount_inc() and bootcount_error() will load, increment, store, and load *again*. The second load exposes a timing problem whereby the i2c read fails. The root cause _seems_ to relate to performance of the 24c08 EEPROM. Insert a delay after writing to work around this.
Signed-off-by: Ian Ray ian.ray@ge.com
drivers/bootcount/bootcount_i2c.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/bootcount/bootcount_i2c.c b/drivers/bootcount/bootcount_i2c.c index ed22389..dd86426 100644 --- a/drivers/bootcount/bootcount_i2c.c +++ b/drivers/bootcount/bootcount_i2c.c @@ -64,6 +64,10 @@ void bootcount_store(ulong a) CONFIG_BOOTCOUNT_ALEN, buf, sizeof(buf)); if (ret != 0) puts("Error writing bootcount\n");
- else
/* Datasheet claims 2 ms typical write cycle time.
* This delay ensures that next read will succeed. */
mdelay(5);
I see, but this is device specific while bootcount_i2c should be device-unaware. I know this driver is used with PMIC where no delay is required. Heiko, is it ok to put a fix delay here or should be configurable ?
I would prefer here to make this timeout configurable, thinking about boottime constraints.
bye, Heiko