linux-stable.git/drivers/bus, branch linux-3.10.y

bus: mvebu: pass the coherency availability information at init time

2015-07-04T02:48:09+00:00

commit 5686a1e5aa436c49187a60052d5885fb1f541ce6 upstream.

Until now, the mvebu-mbus was guessing by itself whether hardware I/O
coherency was available or not by poking into the Device Tree to see
if the coherency fabric Device Tree node was present or not.

However, on some upcoming SoCs, the presence or absence of the
coherency fabric DT node isn't sufficient: in CONFIG_SMP, the
coherency can be enabled, but not in !CONFIG_SMP.

In order to clean this up, the mvebu_mbus_dt_init() function is
extended to get a boolean argument telling whether coherency is
enabled or not. Therefore, the logic to decide whether coherency is
available or not now belongs to the core SoC code instead of the
mvebu-mbus driver itself, which is much better.

Signed-off-by: Thomas Petazzoni
Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper

[ Greg Ungerer: back ported to linux-3.10.y
Back port necessary due to large code differences in affected files.
This change in combination with commit e553554536 ("ARM: mvebu: disable
I/O coherency on non-SMP situations on Armada 370/375/38x/XP") is
critical to the hardware I/O coherency being set correctly by both the
mbus driver and all peripheral hardware drivers. Without this change
drivers will incorrectly enable I/O coherency window attributes and
this causes rare unreliable system behavior including oops. ]

Signed-off-by: Greg Ungerer
Acked-by: Gregory CLEMENT
Signed-off-by: Greg Kroah-Hartman

bus: mvebu-mbus: fix support of MBus window 13

2015-01-30T01:40:56+00:00

commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream.

On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.

As a minimal fix for stable, don't use window 13. A full fix will
follow later.

Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver")
Reviewed-by: Thomas Petazzoni 
Signed-off-by: Andrew Lunn 
Signed-off-by: Greg Kroah-Hartman

bus: mvebu-mbus: allow several windows with the same target/attribute

2014-06-07T20:25:37+00:00

commit b566e782be32145664d96ada3e389f17d32742e5 upstream.

Having multiple windows with the same target and attribute is actually
legal, and can be useful for PCIe windows, when PCIe BARs have a size
that isn't a power of two, and we therefore need to create several
MBus windows to cover the PCIe BAR for a given PCIe interface.

Fixes: fddddb52a6c4 ('bus: introduce an Marvell EBU MBus driver')
Signed-off-by: Thomas Petazzoni 
Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Neil Greatorex 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood

2013-04-11T17:05:37+00:00

The target and attributes for the PCIe address decoding windows were
not correct on Kirkwood for the second PCIe interface.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Jason Cooper

bus: mvebu-mbus: Restore checking for coherency fabric hardware

2013-03-30T21:11:40+00:00

The new mvebu-mbus driver was not checking the device tree for
coherency fabric hardware and hence was not setting the hw_io_coherency
flag in mbus_state. This prevented the mvsdio driver from operating
correctly. This patch restores the check.

Signed-off-by: Neil Greatorex 
Signed-off-by: Jason Cooper

bus: introduce an Marvell EBU MBus driver

2013-03-28T19:04:16+00:00

The Marvell EBU SoCs have a configurable physical address space
layout: the physical ranges of memory used to address PCI(e)
interfaces, NOR flashes, SRAM and various other types of memory are
configurable by software, through a mechanism of so-called 'address
decoding windows'.

This new driver mvebu-mbus consolidates the existing code to address
the configuration of these memory ranges, which is spread into
mach-mvebu, mach-orion5x, mach-mv78xx0, mach-dove and mach-kirkwood.

Following patches convert each Marvell EBU SoC family to use this
driver, therefore removing the old code that was configuring the
address decoding windows.

It is worth mentioning that the MVEBU_MBUS Kconfig option is
intentionally added as a blind option. The new driver implements and
exports the mv_mbus_dram_info() function, which is used by various
Marvell drivers throughout the tree to get access to window
configuration parameters that they require. This function is also
implemented in arch/arm/plat-orion/addr-map.c, which ultimately gets
removed at the end of this patch series. So, in order to preserve
bisectability, we want to ensure that *either* this new driver, *or*
the legacy code in plat-orion/addr-map.c gets compiled in.

By making MVEBU_MBUS a blind option, we are sure that only a platform
that does 'select MVEBU_MBUS' will get this new driver compiled
in. Therefore, throughout the next patches that convert the Marvell
sub-architectures one after the other to this new driver, we add the
'select MVEBU_MBUS' and also ensure to remove plat-orion/addr-map.c
from the build for this specific sub-architecture. This ensures that
bisectability is preserved.

Ealier versions of this driver had a DT binding, but since those were
not yet agreed upon, they were removed. The driver still uses
of_device_id to find the SoC specific details according to the string
passed to mvebu_mbus_init(). The plan is to re-introduce a proper DT
binding as a followup set of patches.

Signed-off-by: Thomas Petazzoni 
Acked-by: Arnd Bergmann 
Signed-off-by: Jason Cooper

Drivers: misc: remove __dev* attributes.

2013-01-03T23:57:16+00:00

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP: Fix drivers to depend on omap for internal devices

2012-12-16T23:23:37+00:00

These devices are not available on other architectures, so
let's limit them to omap.

If the driver subsystem maintainers want to build test
system wide changes without building for each target,
it's easy to carry a test patch that just strips out the
depends entries from Kconfig files.

Signed-off-by: Tony Lindgren 
Signed-off-by: Linus Torvalds

drivers: bus: ocp2scp: add pdata support

2012-11-07T17:35:53+00:00

ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
information to create the devices that is attached to ocp2scp.

This is needed to fix MUSB regression caused by commit c9e4412a
(arm: omap: phy: remove unused functions from omap-phy-internal.c)

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
[tony@atomide.com: updated comments for regression info]
Signed-off-by: Tony Lindgren

drivers: bus: omap_l3: fixup merge conflict resolution

2012-10-02T02:39:48+00:00

This fixes a local merge conflict resolution done wrong locally in
arm-soc for-next. soc.h was added on a cleanup branch, but the driver
was moved and the header no longer needed.

Signed-off-by: Olof Johansson 
[ .. and I did the same wrong merge, since git automatically does the
  whole rename detection etc, so applying this patch from Olof  - Linus ]
Signed-off-by: Linus Torvalds