summaryrefslogtreecommitdiffstats
path: root/include/linux/mbus.h
Commit message (Collapse)AuthorAgeFilesLines
* bus: mvebu: pass the coherency availability information at init timeThomas Petazzoni2014-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | 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 <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* bus: mvebu-mbus: Remove the no longer used name-based APIThomas Petazzoni2013-08-061-5/+0
| | | | | | | | | | Now that every user of the deprecated name-based API has been converted to using the ID-based API, let's remove the former one. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* bus: mvebu-mbus: Add new API for the PCIe memory and IO apertureEzequiel Garcia2013-08-061-0/+4
| | | | | | | | | | | | | | | We add two optional properties to the MBus DT binding, to encode the PCIe memory and IO aperture. This allows such information to be retrieved by -for instance- the pci driver to allocate the MBus decoding windows. Correspondingly, and in order to retrieve this information, we add two new APIs. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* bus: mvebu-mbus: Introduce device tree bindingEzequiel Garcia2013-08-061-0/+1
| | | | | | | | | | | | | This patch adds the most fundamental device-tree initialization. We only introduce what's required to be able to probe the mvebu-mbus driver from the DT. Follow-up patches will extend the device tree binding, allowing to describe static address decoding windows. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* bus: mvebu-mbus: Add new API for window creationThomas Petazzoni2013-08-061-0/+6
| | | | | | | | | | | We add an API to create MBus address decoding windows from the target ID and attribute. This function will be used later and deprecate the current name based scheme. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* arm: mach-mv78xx0: convert to use the mvebu-mbus driverThomas Petazzoni2013-04-151-0/+3
| | | | | | | | | | | | This commit convers the mach-mv78xx0 sub-architecture to use the mvebu-mbus driver. We simply have to call mvebu_mbus_init() in the ->init_early() function, and modify the PCIe code so that it uses the new functions provided by mvebu-mbus to create the needed PCIe windows. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* bus: introduce an Marvell EBU MBus driverThomas Petazzoni2013-03-281-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: Orion: Get address map from plat-orion instead of via platform_dataAndrew Lunn2011-12-131-1/+12
| | | | | | | | | | | | Use an getter function in plat-orion/addr-map.c to get the address map structure, rather than pass it to drivers in the platform_data structures. When the drivers are built for none orion platforms, a dummy function is provided instead which returns NULL. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Michael Walle <michael@walle.cc> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
* introduce mbus DRAM target info abstractionLennert Buytenhek2008-03-271-0/+36
Introduce struct mbus_dram_target_info, which will be used for passing information about the mbus target ID of the DDR unit, and mbus target attribute, base address and size for each of the DRAM chip selects from the platform code to peripheral drivers. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
OpenPOWER on IntegriCloud