| commit | 1a7d91d651f25005c4f507aebf9eab17e508889c | |
| author | Michael Hennerich <michael.hennerich@analog.com> | |
| Wed, 10 Oct 2007 09:42:55 +0000 (10 17:42 +0800) | ||
| committer | Bryan Wu <bryan.wu@analog.com> | |
| Wed, 10 Oct 2007 09:42:55 +0000 (10 17:42 +0800) | ||
| tree | d3070fe9edd252e485a07fb41c5ee8a4df4cec5c | treesnapshot (tar.gz zip) |
| parent | a359cca71e73a83612b5bbecea41d3b7a47160ca | commitdiff |
Blackfin arch: flush/inv the correct range when using write back cache and fix bugs find by dmacopy
- flush/inv the correct range
- dmacopy test failed when policy is write_back - invalidate before dma
http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3367
It's the cache invalidate what is causing the issue.
There is no invalidate only instruction it's always: FLUSHINV
So when we "invalidate" after the DMA we might (do) overwrite freshly
dma'ed data by dirty Cache WB content.
Fixed by moving the "invalidate" at the beginning of dma_memcpy.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
- flush/inv the correct range
- dmacopy test failed when policy is write_back - invalidate before dma
http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3367
It's the cache invalidate what is causing the issue.
There is no invalidate only instruction it's always: FLUSHINV
So when we "invalidate" after the DMA we might (do) overwrite freshly
dma'ed data by dirty Cache WB content.
Fixed by moving the "invalidate" at the beginning of dma_memcpy.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
| arch/blackfin/kernel/bfin_dma_5xx.c | diffblobblamehistory |