summaryrefslogtreecommitdiff
path: root/drivers/dma
diff options
context:
space:
mode:
authorMarek Vasut <marex@denx.de>2014-02-06 02:59:34 +0100
committerHeiko Schocher <hs@denx.de>2014-02-20 06:46:57 +0100
commitd22643e7e819a94a32652cfb041c24d4fd99a7ec (patch)
tree0bf83f65b6afdc07dfd1496cd9d915389a0a33f8 /drivers/dma
parent070cbaf821e07531db6e55946932f4172dd72045 (diff)
downloadu-boot-imx-d22643e7e819a94a32652cfb041c24d4fd99a7ec.zip
u-boot-imx-d22643e7e819a94a32652cfb041c24d4fd99a7ec.tar.gz
u-boot-imx-d22643e7e819a94a32652cfb041c24d4fd99a7ec.tar.bz2
i2c: i2c-mxs: Wait for I2C to empty queue
Make sure the I2C write queue is empty before leaving the mxs_i2c_write(). If we start and I2C write and only wait for ACK, the MXS I2C IP block may enter next operation while still processing the write aftermath internally. This will in turn disrupt one or more subsequent transfer(s). A testcase for this issue is as such. This testcase is also interesting because the first I2C_WRITE which becomes disruptive happens in the 'i2c read' command. The 'i2c read' command first uses I2C_WRITE to send I2C address of the chip and then uses I2C_READ to read data from the chip. After this command completes, the 'i2c probe' will use sequence of I2C_WRITE commands to probe the I2C bus. The problem is that the first I2C_WRITE disrupted the I2C IP block operation and this sideeffect propagates all the way to this next I2C_WRITE used by the 'i2c probe' call. The result is the 'i2c probe' receives an ACK on I2C address 0x00, even if this ACK was owned by the previous I2C_WRITE operation. Note that the 'i2c read' command must read from a valid I2C chip address. Wrong: > i2c probe Valid chip addresses: 50 51 > i2c read 0x50 0x0.2 0x10 0x42000000 > i2c probe Valid chip addresses: 00 50 51 With this patch > i2c probe Valid chip addresses: 50 51 > i2c read 0x50 0x0.2 0x10 0x42000000 > i2c probe Valid chip addresses: 50 51 Signed-off-by: Marek Vasut <marex@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Fabio Estevam <festevam@gmail.com>
Diffstat (limited to 'drivers/dma')
0 files changed, 0 insertions, 0 deletions