diff options
author | Marek Vasut <marex@denx.de> | 2012-08-31 16:07:59 +0000 |
---|---|---|
committer | Stefano Babic <sbabic@denx.de> | 2012-09-06 14:17:55 +0200 |
commit | 88d155596879035532f8be05172d605965c733ed (patch) | |
tree | 03312a62ce08fe8179250e939e54017a48e44385 /drivers/spi/altera_spi.c | |
parent | 697191d57fb2fae7b31cec9581fb7749f965d877 (diff) | |
download | u-boot-imx-88d155596879035532f8be05172d605965c733ed.zip u-boot-imx-88d155596879035532f8be05172d605965c733ed.tar.gz u-boot-imx-88d155596879035532f8be05172d605965c733ed.tar.bz2 |
MX28: SPI: Fix the DMA DCache race condition
This patch fixes dcache-related problem. The problem manifested
when dcache was enabled and the following command issued twice:
mw 0x42000000 0 0x4000 ; sf probe ; sf read 0x42000000 0x0 0x10000 ; sha1sum 0x42000000 0x10000
The SHA1 checksum was correct during the first call. Yet with
every subsequent call of the above command, it differed and was
wrong.
It turns out this was because of a race condition. On the first
time the command was called, no cacheline contained any data from
the destination memory location. The DMA transfered data into the
location and the cache above the location was invalidated. Then the
checksum was computed, but that meant the data were loaded into data
cache.
On any subsequent call, the DMA again transfered data into the same
destination. Yet during the transfer, some of the DCache lines were
evicted and written back into the main memory. Once the DMA transfer
completed, the data cache was invalidated over the memory location as
usual. But the data that were to be loaded back into the data cache
by subsequent SHA1 checksuming were corrupted.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
Diffstat (limited to 'drivers/spi/altera_spi.c')
0 files changed, 0 insertions, 0 deletions