summaryrefslogtreecommitdiffstats
path: root/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
diff options
context:
space:
mode:
authorThomas Petazzoni <thomas.petazzoni@free-electrons.com>2015-05-28 10:40:13 +0200
committerGregory CLEMENT <gregory.clement@free-electrons.com>2015-05-28 11:14:31 +0200
commit885dbd154b2f2ee305cec6fd0a162e1a77ae2b06 (patch)
treee83f10d53bf5ff3bb959d96d629fe5252aca7577 /arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
parent8c9e06e64768665503e778088a39ecff3a6f2e0c (diff)
downloadblackbird-op-linux-885dbd154b2f2ee305cec6fd0a162e1a77ae2b06.tar.gz
blackbird-op-linux-885dbd154b2f2ee305cec6fd0a162e1a77ae2b06.zip
Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"
This reverts commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"), because it breaks DMA on platforms having more than 2 GB of RAM. This commit changed the information reported to DMA masters device drivers through the mv_mbus_dram_info() function so that the returned DRAM ranges do not overlap with I/O windows. This was necessary as a preparation to support the new CESA Crypto Engine driver, which will use DMA for cryptographic operations. But since it does DMA with the SRAM which is mapped as an I/O window, having DRAM ranges overlapping with I/O windows was problematic. To solve this, the above mentioned commit changed the mvebu-mbus to adjust the DRAM ranges so that they don't overlap with the I/O windows. However, by doing this, we re-adjust the DRAM ranges in a way that makes them have a size that is no longer a power of two. While this is perfectly fine for the Crypto Engine, which supports DRAM ranges with a granularity of 64 KB, it breaks basically all other DMA masters, which expect power of two sizes for the DRAM ranges. Due to this, if the installed system memory is 4 GB, in two chip-selects of 2 GB, the second DRAM range will be reduced from 2 GB to a little bit less than 2 GB to not overlap with the I/O windows, in a way that results in a DRAM range that doesn't have a power of two size. This means that whenever you do a DMA transfer with an address located in the [ 2 GB ; 4 GB ] area, it will freeze the system. Any serious DMA activity like simply running: for i in $(seq 1 64) ; do dd if=/dev/urandom of=file$i bs=1M count=16 ; done in an ext3 partition mounted over a SATA drive will freeze the system. Since the new CESA crypto driver that uses DMA has not been merged yet, the easiest fix is to simply revert this commit. A follow-up commit will introduce a different solution for the CESA crypto driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window") Cc: <stable@vger.kernel.org> # v4.0+ Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Diffstat (limited to 'arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud