1. 12 10月, 2018 1 次提交
  2. 06 10月, 2018 6 次提交
  3. 05 10月, 2018 3 次提交
  4. 02 10月, 2018 1 次提交
    • W
      eeprom: at24: fix unexpected timeout under high load · 9a9e295e
      Wang Xin 提交于
      Within at24_loop_until_timeout the timestamp used for timeout checking
      is recorded after the I2C transfer and sleep_range(). Under high CPU
      load either the execution time for I2C transfer or sleep_range() could
      actually be larger than the timeout value. Worst case the I2C transfer
      is only tried once because the loop will exit due to the timeout
      although the EEPROM is now ready.
      
      To fix this issue the timestamp is recorded at the beginning of each
      iteration. That is, before I2C transfer and sleep. Then the timeout
      is actually checked against the timestamp of the previous iteration.
      This makes sure that even if the timeout is reached, there is still one
      more chance to try the I2C transfer in case the EEPROM is ready.
      
      Example:
      
      If you have a system which combines high CPU load with repeated EEPROM
      writes you will run into the following scenario.
      
       - System makes a successful regmap_bulk_write() to EEPROM.
       - System wants to perform another write to EEPROM but EEPROM is still
         busy with the last write.
       - Because of high CPU load the usleep_range() will sleep more than
         25 ms (at24_write_timeout).
       - Within the over-long sleeping the EEPROM finished the previous write
         operation and is ready again.
       - at24_loop_until_timeout() will detect timeout and won't try to write.
      Signed-off-by: NWang Xin <xin.wang7@cn.bosch.com>
      Signed-off-by: NMark Jonas <mark.jonas@de.bosch.com>
      Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
      9a9e295e
  5. 01 10月, 2018 3 次提交
  6. 30 9月, 2018 8 次提交
  7. 29 9月, 2018 12 次提交
  8. 28 9月, 2018 6 次提交