summaryrefslogtreecommitdiffstats
path: root/drivers/uio
diff options
context:
space:
mode:
authorMasahiro Yamada <yamada.masahiro@socionext.com>2018-10-16 12:01:48 +0900
committerWolfram Sang <wsa@the-dreams.de>2018-10-29 18:53:37 +0000
commit39226aaa85f002d695e3cafade3309e12ffdaecd (patch)
treeb6769efb2d5cdf67712a10bea10b62fe10600d51 /drivers/uio
parentf1fdcbbdf45d9609f3d4063b67e9ea941ba3a58f (diff)
downloadblackbird-op-linux-39226aaa85f002d695e3cafade3309e12ffdaecd.tar.gz
blackbird-op-linux-39226aaa85f002d695e3cafade3309e12ffdaecd.zip
i2c: uniphier-f: fix occasional timeout error
Currently, a timeout error could happen at a repeated START condition. For a (non-repeated) START condition, the controller starts sending data when the UNIPHIER_FI2C_CR_STA bit is set. However, for a repeated START condition, the hardware starts running when the slave address is written to the TX FIFO - the write to the UNIPHIER_FI2C_CR register is actually unneeded. Because the hardware is already running before the IRQ is enabled for a repeated START, the driver may miss the IRQ event. In most cases, this problem does not show up since modern CPUs are much faster than the I2C transfer. However, it is still possible that a context switch happens after the controller starts, but before the IRQ register is set up. To fix this, - Do not write UNIPHIER_FI2C_CR for repeated START conditions. - Enable IRQ *before* writing the slave address to the TX FIFO. - Disable IRQ for the current CPU while queuing up the TX FIFO; If the CPU is interrupted by some task, the interrupt handler might be invoked due to the empty TX FIFO before completing the setup. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Diffstat (limited to 'drivers/uio')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud