summaryrefslogtreecommitdiff
path: root/include/linux/mbus.h
AgeCommit message (Collapse)AuthorFilesLines
2013-08-06bus: mvebu-mbus: Remove the no longer used name-based APIThomas Petazzoni1-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>
2013-08-06bus: mvebu-mbus: Add new API for the PCIe memory and IO apertureEzequiel Garcia1-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>
2013-08-06bus: mvebu-mbus: Introduce device tree bindingEzequiel Garcia1-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>
2013-08-06bus: mvebu-mbus: Add new API for window creationThomas Petazzoni1-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>
2013-04-15arm: mach-mv78xx0: convert to use the mvebu-mbus driverThomas Petazzoni1-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>
2013-03-28bus: introduce an Marvell EBU MBus driverThomas Petazzoni1-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>
2011-12-14ARM: Orion: Get address map from plat-orion instead of via platform_dataAndrew Lunn1-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>
2008-03-27introduce mbus DRAM target info abstractionLennert Buytenhek1-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>