aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/dma/mv_xor.h
diff options
context:
space:
mode:
authorThomas Petazzoni <thomas.petazzoni@free-electrons.com>2012-11-22 18:16:37 +0100
committerThomas Petazzoni <thomas.petazzoni@free-electrons.com>2012-11-22 18:16:37 +0100
commitc4b4b732b2e99e6e302d90d57f2a4f5c9516d9a3 (patch)
tree158c098eac7c67375e037578e3f17e689efe03ae /drivers/dma/mv_xor.h
parentarm: mvebu: fix address decoding armada_cfg_base() function (diff)
downloadlinux-dev-c4b4b732b2e99e6e302d90d57f2a4f5c9516d9a3.tar.xz
linux-dev-c4b4b732b2e99e6e302d90d57f2a4f5c9516d9a3.zip
dma: mv_xor: clear the window override control registers
The XOR channels on Marvell SoCs have a Window Override Control register that allow to do some fancy things with addresses. Those features are not used by the driver, but some U-Boot versions anyway modify those registers. For some reason, the U-Boot on OpenBlocks AX3-4 was setting an invalid value in those registers when the addition 2 GB DRAM chip was plugged into the board, causing the XOR driver to fail in using the XOR engines. By setting those registers to 0 during the driver initialization, we ensure that the registers are configured according with the driver operation model. Thanks to Lior Amsalem <alior@marvell.com> for his help in debugging this problem. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Diffstat (limited to 'drivers/dma/mv_xor.h')
-rw-r--r--drivers/dma/mv_xor.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index 17043287b71a..c632a4761fcf 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -53,6 +53,7 @@
#define WINDOW_SIZE(w) (0x270 + ((w) << 2))
#define WINDOW_REMAP_HIGH(w) (0x290 + ((w) << 2))
#define WINDOW_BAR_ENABLE(chan) (0x240 + ((chan) << 2))
+#define WINDOW_OVERRIDE_CTRL(chan) (0x2A0 + ((chan) << 2))
struct mv_xor_device {
void __iomem *xor_base;