linux.git/drivers/bus/mvebu-mbus.c, branch v5.4.302

bus: mvebu-mbus: Convert to using %pOFn instead of device_node.name

2018-09-28T21:41:57+00:00

In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.

Signed-off-by: Rob Herring

bus: mbus: fix window size calculation for 4GB windows

2017-10-12T13:01:30+00:00

At least the Armada XP SoC supports 4GB on a single DRAM window. Because
the size register values contain the actual size - 1, the MSB is set in
that case. For example, the SDRAM window's control register's value is
0xffffffe1 for 4GB (bits 31 to 24 contain the size).

The MBUS driver reads back each window's size from registers and
calculates the actual size as (control_reg | ~DDR_SIZE_MASK) + 1, which
overflows for 32 bit values, resulting in other miscalculations further
on (a bad RAM window for the CESA crypto engine calculated by
mvebu_mbus_setup_cpu_target_nooverlap() in my case).

This patch changes the type in 'struct mbus_dram_window' from u32 to
u64, which allows us to keep using the same register calculation code in
most MBUS-using drivers (which calculate ->size - 1 again).

Fixes: fddddb52a6c4 ("bus: introduce an Marvell EBU MBus driver")
CC: stable@vger.kernel.org
Signed-off-by: Jan Luebbe 
Signed-off-by: Gregory CLEMENT

bus: mvebu-mbus: make mvebu_mbus_syscore_ops static

2016-07-11T15:59:24+00:00

Make mvebu_mbus_syscore_ops static as it does not get
used or declared outside mvebu-mbus.c to fix the following
sparse warning:

linux/drivers/bus/mvebu-mbus.c:1092:20: warning: symbol 'mvebu_mbus_syscore_ops' was not declared. Should it be static?

Signed-off-by: Ben Dooks 
Acked-by: Arnd Bergmann 
Signed-off-by: Gregory CLEMENT

bus: mvebu-mbus: fix __iomem on register pointers

2016-07-11T15:58:30+00:00

The save_cpu_target functions should take "u32 __iomem *", not a
plain "u32 *" as it is passed to register access functions. Fix
the following warnings by adding the annotation:

drivers/bus/mvebu-mbus.c:739:17: warning: incorrect type in argument 2 (different address spaces)
drivers/bus/mvebu-mbus.c:739:17:    expected void volatile [noderef] *addr
drivers/bus/mvebu-mbus.c:739:17:    got unsigned int [usertype] *
drivers/bus/mvebu-mbus.c:741:17: warning: incorrect type in argument 2 (different address spaces)
drivers/bus/mvebu-mbus.c:741:17:    expected void volatile [noderef] *addr
drivers/bus/mvebu-mbus.c:741:17:    got unsigned int [usertype] *
drivers/bus/mvebu-mbus.c:742:17: warning: incorrect type in argument 2 (different address spaces)
drivers/bus/mvebu-mbus.c:742:17:    expected void volatile [noderef] *addr
drivers/bus/mvebu-mbus.c:742:17:    got unsigned int [usertype] *
drivers/bus/mvebu-mbus.c:744:17: warning: incorrect type in argument 2 (different address spaces)
drivers/bus/mvebu-mbus.c:744:17:    expected void volatile [noderef] *addr
drivers/bus/mvebu-mbus.c:744:17:    got unsigned int [usertype] *
drivers/bus/mvebu-mbus.c:790:17: warning: incorrect type in argument 2 (different address spaces)
drivers/bus/mvebu-mbus.c:790:17:    expected void volatile [noderef] *addr
drivers/bus/mvebu-mbus.c:790:17:    got unsigned int [usertype] *
drivers/bus/mvebu-mbus.c:792:17: warning: incorrect type in argument 2 (different address spaces)
drivers/bus/mvebu-mbus.c:792:17:    expected void volatile [noderef] *addr
drivers/bus/mvebu-mbus.c:792:17:    got unsigned int [usertype] *

Signed-off-by: Ben Dooks 
Acked-by: Arnd Bergmann 
Signed-off-by: Gregory CLEMENT

bus: mvebu-mbus: use %pa to print phys_addr_t

2016-03-30T09:36:01+00:00

A recent change to the mbus driver added a warning printk that
prints a phys_addr_t using the %x format string, which fails in
case we build with 64-bit phys_addr_t:

drivers/bus/mvebu-mbus.c: In function 'mvebu_mbus_get_dram_win_info':
drivers/bus/mvebu-mbus.c:975:9: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'phys_addr_t {aka long long unsigned int}' [-Werror=format=]

This uses the special %pa format string instead, so we always
print the correct type.

Signed-off-by: Arnd Bergmann 
Fixes: f2900acea801 ("bus: mvebu-mbus: provide api for obtaining IO and DRAM window information")
Signed-off-by: Gregory CLEMENT

bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

2016-03-14T16:19:46+00:00

This commit enables finding appropriate mbus window and obtaining its
target id and attribute for given physical address in two separate
routines, both for IO and DRAM windows. This functionality
is needed for Armada XP/38x Network Controller's Buffer Manager and
PnC configuration.

[gregory.clement@free-electrons.com: Fix size test for
mvebu_mbus_get_dram_win_info]

Signed-off-by: Marcin Wojtas 
[DRAM window information reference in LKv3.10]
Signed-off-by: Evan Wang 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: David S. Miller

bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()

2015-05-28T10:21:08+00:00

This commit introduces a variant of the mv_mbus_dram_info() function
called mv_mbus_dram_info_nooverlap(). Both functions are used by
Marvell drivers supporting devices doing DMA, and provide them a
description the DRAM ranges that they need to configure their DRAM
windows.

The ranges provided by the mv_mbus_dram_info() function may overlap
with the I/O windows if there is a lot (>= 4 GB) of RAM
installed. This is not a problem for most of the DMA masters, except
for the upcoming new CESA crypto driver because it does DMA to the
SRAM, which is mapped through an I/O window. For this unit, we need to
have DRAM ranges that do not overlap with the I/O windows.

A first implementation done in commit 1737cac69369 ("bus: mvebu-mbus:
make sure SDRAM CS for DMA don't overlap the MBus bridge window"),
changed the information returned by mv_mbus_dram_info() to match this
requirement. However, it broke the requirement of the other DMA
masters than the DRAM ranges should have power of two sizes.

To solve this situation, this commit introduces a new
mv_mbus_dram_info_nooverlap() function, which returns the same
information as mv_mbus_dram_info(), but guaranteed to not overlap with
the I/O windows.

In the end, it gives us two variants of the mv_mbus_dram_info*()
functions:

 - The normal one, mv_mbus_dram_info(), which has been around for many
   years. This function returns the raw DRAM ranges, which are
   guaranteed to use power of two sizes, but will overlap with I/O
   windows. This function will therefore be used by all DMA masters
   (SATA, XOR, Ethernet, etc.) except the CESA crypto driver.

 - The new 'nooverlap' variant, mv_mbus_dram_info_nooverlap(). This
   function returns DRAM ranges after they have been "tweaked" to make
   sure they don't overlap with I/O windows. By doing this tweaking,
   we remove the power of two size guarantee. This variant will be
   used by the new CESA crypto driver.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT

Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"

2015-05-28T09:14:31+00:00

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 
Fixes: 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window")
Cc:  # v4.0+
Signed-off-by: Gregory CLEMENT

bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms.

2015-05-28T09:14:19+00:00

Commit a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O
synchronization barriers") enabled the usage of automatic I/O
synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the
control registers of MBus windows, but on non io-coherent platforms
(orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in
the window control register is either reserved (all windows except 6
and 7) or enables read-only protection (windows 6 and 7).

Signed-off-by: Nicolas Schichan 
Reviewed-by: Thomas Petazzoni 
Cc:  # v4.0+
Fixes: a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers")
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT

bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window

2015-01-19T22:09:16+00:00

The mvebu-mbus driver reads the SDRAM window registers, and make the
information about the DRAM CS configuration available to device
drivers using the mv_mbus_dram_info() API. This information is used by
the DMA-capable device drivers to program their address decoding
windows.

Until now, we were basically providing the SDRAM window register
details as is. However, it turns out that the DMA capability of the
CESA cryptographic engine consists in doing DMA being the DRAM and the
crypto SRAM mapped as a MBus window. For this case, it is very
important that the SDRAM CS information does not overlap with the MBus
bridge window.

Therefore, this commit improves the mvebu-mbus driver to make sure we
adjust the SDRAM CS information so that it doesn't overlap with the
MBus bridge window. This problem was reported by Boris Brezillon,
while working on the mv_cesa driver for Armada 37x/38x/XP. We use the
memblock memory information to know where the usable RAM is located,
as this information is guaranteed to be correct on all SoC variants.

We could have used the MBus bridge window registers on Armada 370/XP,
but they are not really used on Armada 375/38x (Cortex-A9 based),
since the PL310 L2 filtering is used instead to discriminate between
RAM accesses and I/O accesses. Therefore, using the memblock
information is more generic and works accross the different platforms.

Reported-by: Boris Brezillon 
Signed-off-by: Thomas Petazzoni 
[Andrew Lunn : Fixed merge conflict]
Signed-off-by: Andrew Lunn