summaryrefslogtreecommitdiff
path: root/drivers/bus/mvebu-mbus.c
AgeCommit message (Collapse)Author
2017-10-12bus: mbus: fix window size calculation for 4GB windowsJan Luebbe
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 <jlu@pengutronix.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-07-11bus: mvebu-mbus: make mvebu_mbus_syscore_ops staticBen Dooks
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 <ben.dooks@codethink.co.uk> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-07-11bus: mvebu-mbus: fix __iomem on register pointersBen Dooks
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] <asn:2>*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] <asn:2>*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] <asn:2>*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] <asn:2>*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] <asn:2>*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] <asn:2>*addr drivers/bus/mvebu-mbus.c:792:17: got unsigned int [usertype] * Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-03-30bus: mvebu-mbus: use %pa to print phys_addr_tArnd Bergmann
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 <arnd@arndb.de> Fixes: f2900acea801 ("bus: mvebu-mbus: provide api for obtaining IO and DRAM window information") Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-03-14bus: mvebu-mbus: provide api for obtaining IO and DRAM window informationMarcin Wojtas
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 <mw@semihalf.com> [DRAM window information reference in LKv3.10] Signed-off-by: Evan Wang <xswang@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-28bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()Thomas Petazzoni
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 <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-05-28Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus ↵Thomas Petazzoni
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>
2015-05-28bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms.Nicolas Schichan
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 <nschichan@freebox.fr> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v4.0+ Fixes: a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-01-19bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge windowThomas Petazzoni
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 <boris.brezillon@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Fixed merge conflict] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38xMichal Mazur
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. To make things even more fun, the hardware designers have chosen to put the window 13 remap registers in a completely custom location, using a logic that differs from the one used for all other remappable windows. To solve this problem, this commit: * Adds a SoC specific function to calculate offset of remap registers to the mvebu_mbus_soc_data structure. This function, ->win_remap_offset(), returns the offset of the remap registers, or MVEBU_MBUS_NO_REMAP if the window does not have the remap capability. This new function replaces the previous integer field num_remappable_wins, which was insufficient to encode the special case of window 13. * Adds an implementation of the ->win_remap_offset() function for the various SoC families. Some have 2 first windows that are remapable, some the 4 first, some the 8 first, and then the Armada XP/375/38x case where the 8 first are remapable plus the special window 13. This is implemented in functions generic_mbus_win_remap_2_offset(), generic_mbus_win_remap_4_offset(), generic_mbus_win_remap_8_offset() and armada_xp_mbus_win_remap_offset() respectively. * Change the code to use the ->win_remap_offset() function when accessing the remap registers, and also to use a newly introduced mvebu_mbus_window_is_remappable() helper function that tells whether a given window is remapable or not. * Separate Armada 370 from XP/375/38X because the window 13 of Armada 370 does not support the remap capability. [Thomas: adapted for the mainline kernel, minor clarifications in the code, reword the commit log.] Signed-off-by: Michal Mazur <arg@semihalf.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Undo the simple fix for stable] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19bus: mvebu-mbus: use automatic I/O synchronization barriersThomas Petazzoni
Instead of using explicit I/O synchronization barriers shoehorned inside the streaming DMA mappings API (in arch/arm/mach-mvebu/coherency.c), we are switching to use automatic I/O synchronization barrier. The primary motivation for this change is that explicit I/O synchronization barriers are not only needed for streaming DMA mappings (which can easily be done by overriding the dma_map_ops), but also for coherent DMA mappings (which is a lot less easy to do, since the kernel assumes such mappings are coherent and don't require any sort of cache maintenance operation to ensure the consistency of the buffers). Switching to automatic I/O synchronization barriers will also allow us to use the existing arm_coherent_dma_ops instead of our custom arm_dma_ops. In order to use automatic I/O synchronization barriers, this commit changes mvebu-mbus in two ways: - It enables automatic I/O synchronization barriers in the 0x84 register of the MBus bridge, by enabling such barriers for all MBus units. This enables automatic barriers for the on-SoC peripherals that are doing DMA. - It enables the SyncEnable bit in the MBus windows, so that PCIe devices also use automatic I/O synchronization barrier. This automatic synchronization barrier relies on the assumption that at least one register of a given hardware unit is read before the driver accesses the DMA mappings modified by this unit. This assumption is guaranteed for PCI devices by vertue of the PCI standard, and we can reasonably verify that this assumption is also true for the limited number of platform drivers doing DMA used on Marvell EBU platforms. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19bus: mvebu-mbus: fix support of MBus window 13Andrew Lunn
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") Cc: <stable@vger.kernel.org> # v3.10+ Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2014-11-30bus: mvebu-mbus: provide a mechanism to save SDRAM window configurationThomas Petazzoni
On Marvell EBU platforms, when doing suspend/resume, the SDRAM window configuration must be saved on suspend, and restored on resume. However, it needs to be restored on resume *before* re-entering the kernel, because the SDRAM window configuration defines the layout of the memory. For this reason, it cannot simply be done in the ->suspend() and ->resume() hooks of the mvebu-mbus driver. Instead, it needs to be restored by the bootloader "boot info" mechanism used when resuming. This mechanism allows the kernel to define a list of (address, value) pairs when suspending, that the bootloader will restore on resume before jumping back into the kernel. This commit therefore adds a new function to the mvebu-mbus driver, called mvebu_mbus_save_cpu_target(), which will be called by the platform code to make the mvebu-mbus driver save the SDRAM window configuration in a way that can be understood by the bootloader "boot info" mechanism. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-8-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30bus: mvebu-mbus: suspend/resume supportThomas Petazzoni
This commit extends the mvebu-mbus driver to provide suspend/resume support. Since mvebu-mbus is not a platform_driver, the syscore_ops mechanism is used to get ->suspend() and ->resume() hooks called into the driver. In those hooks, we save and restore the MBus windows state, to make sure after resume all Mbus windows are properly restored. Note that while the state of some windows could be gathered by looking again at the Device Tree (for statically described windows), it is not the case of dynamically described windows such as the PCIe memory and I/O windows. Therefore, we take the simple approach of saving and restoring the registers for all MBus windows. In addition, the commit extends the Device Tree binding of the MBus controller, to control the MBus bridge registers (which define which parts of the physical address space is routed to MBus windows vs. normal RAM memory). Those registers must be saved and restored during suspend/resume. The Device Tree binding extension is made is a backward compatible fashion, but of course, suspend/resume will not work without the Device Tree update. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-7-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-06-02Merge tag 'soc-for-3.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into next Pull part one of ARM SoC updates from Olof Johansson: "A quite large set of SoC updates this cycle. In no particular order: - Multi-cluster power management for Samsung Exynos, adding support for big.LITTLE CPU switching on EXYNOS5 - SMP support for Marvell Armada 375 and 38x - SMP rework on Allwinner A31 - Xilinx Zynq support for SOC_BUS, big endian - Marvell orion5x platform cleanup, modernizing the implementation and moving to DT. - _Finally_ moving Samsung Exynos over to support MULTIPLATFORM, so that their platform can be enabled in the same kernel binary as most of the other v7 platforms in the tree. \o/ The work isn't quite complete, there's some driver fixes still needed, but the basics now work. New SoC support added: - Freescale i.MX6SX - LSI Axxia AXM55xx SoCs - Samsung EXYNOS 3250, 5260, 5410, 5420 and 5800 - STi STIH407 plus a large set of various smaller updates for different platforms. I'm probably missing some important one here" * tag 'soc-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (281 commits) ARM: exynos: don't run exynos4 l2x0 setup on other platforms ARM: exynos: Fix "allmodconfig" build errors in mcpm and hotplug ARM: EXYNOS: mcpm rename the power_down_finish ARM: EXYNOS: Enable mcpm for dual-cluster exynos5800 SoC ARM: EXYNOS: Enable multi-platform build support ARM: EXYNOS: Consolidate Kconfig entries ARM: EXYNOS: Add support for EXYNOS5410 SoC ARM: EXYNOS: Support secondary CPU boot of Exynos3250 ARM: EXYNOS: Add Exynos3250 SoC ID ARM: EXYNOS: Add 5800 SoC support ARM: EXYNOS: initial board support for exynos5260 SoC clk: exynos5410: register clocks using common clock framework ARM: debug: qcom: add UART addresses to Kconfig help for APQ8084 ARM: sunxi: allow building without reset controller Documentation: devicetree: arm: sort enable-method entries ARM: rockchip: convert smp bringup to CPU_METHOD_OF_DECLARE clk: exynos5250: Add missing sysmmu clocks for DISP and ISP blocks ARM: dts: axxia: Add reset controller power: reset: Add Axxia system reset driver ARM: axxia: Adding defconfig for AXM55xx ...
2014-04-24bus: mvebu: pass the coherency availability information at init timeThomas Petazzoni
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>
2014-04-24bus: mvebu-mbus: allow several windows with the same target/attributeThomas Petazzoni
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') Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24bus: mvebu-mbus: Avoid setting an undefined window sizeJason Gunthorpe
The mbus hardware requires a power of two size, and size aligned base. Currently, if a non-power of two is passed in to the low level routines they configure the register in a way that results in undefined behaviour. Call WARN and return EINVAL instead. Also, update the debugfs routines to show a message if there is an invalid register setting. All together this makes the recent problems with silent failure of PCI very obvious, noisy and debuggable. Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-05Merge tag 'drivers-3.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver changes from Arnd Bergmann: "These changes are mostly for ARM specific device drivers that either don't have an upstream maintainer, or that had the maintainer ask us to pick up the changes to avoid conflicts. A large chunk of this are clock drivers (bcm281xx, exynos, versatile, shmobile), aside from that, reset controllers for STi as well as a large rework of the Marvell Orion/EBU watchdog driver are notable" * tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (99 commits) Revert "dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac." Revert "net: stmmac: Add SOCFPGA glue driver" ARM: shmobile: r8a7791: Fix SCIFA3-5 clocks ARM: STi: Add reset controller support to mach-sti Kconfig drivers: reset: stih416: add softreset controller drivers: reset: stih415: add softreset controller drivers: reset: Reset controller driver for STiH416 drivers: reset: Reset controller driver for STiH415 drivers: reset: STi SoC system configuration reset controller support dts: socfpga: Add sysmgr node so the gmac can use to reference dts: socfpga: Add support for SD/MMC on the SOCFPGA platform reset: Add optional resets and stubs ARM: shmobile: r7s72100: fix bus clock calculation Power: Reset: Generalize qnap-poweroff to work on Synology devices. dts: socfpga: Update clock entry to support multiple parents ARM: socfpga: Update socfpga_defconfig dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac. net: stmmac: Add SOCFPGA glue driver watchdog: orion_wdt: Use %pa to print 'phys_addr_t' drivers: cci: Export CCI PMU revision ...
2014-02-18bus: mvebu-mbus: Fix incorrect size for PCI aperture resourcesJason Gunthorpe
reg[0] is the DT base, reg[1] is the DT length in bytes, struct resource.end is the inclusive end address, so a -1 is required. Tested on kirkwood. Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Arnd Bergmann <arnd@arndb.de>
2014-02-11bus: mvebu-mbus: make use of of_find_matching_node_and_matchJosh Cartwright
Instead of the of_find_matching_node()/of_match_node() pair, which requires two iterations through the match table, make use of of_find_matching_node_and_match(), which only iterates through the table once. Signed-off-by: Josh Cartwright <joshc@codeaurora.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-11-24bus: mvebu-mbus: Remove deprecated commentEzequiel Garcia
Remove a comment about the lack of a devicetree binding: this driver's binding is already implemented and in use. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-11-24bus: mvebu-mbus: potential forever loop in mvebu_mbus_init()Dan Carpenter
"of_id->compatible" is an array and not a pointer so it can never be NULL. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-10-01bus: mvebu-mbus: Fix optional pcie-mem/io-aperture propertiesJason Gunthorpe
If the property was not specified then the returned resource had a resource_size(..) == 1, rather than 0. The PCI-E driver checks for 0 so it blindly continues on with a corrupted resource. The regression was introduced into v3.12 by: 11be654 PCI: mvebu: Adapt to the new device tree layout Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-09-18bus: mvebu: add missing of_node_put() to fix reference leakJisheng Zhang
Add of_node_put to properly decrement the refcount when we are done using a given node. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Conflicts: drivers/bus/mvebu-mbus.c
2013-08-06bus: mvebu-mbus: Factorize Armada 370/XP data structuresThomas Petazzoni
These structures were only different in the mapping tables. Now that those tables have been removed, it doesn't make any sense to keep different structures. 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: Update main descriptionThomas Petazzoni
After replacing the MBus name-based by the new ID-based API let's fix the general description of the driver at the beginning of the file. 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: Remove name -> target, attribute mapping tablesThomas Petazzoni
This tables were used together with the name-based MBus window creation API. Since that's has been removed, we can also remove the tables. 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: Remove the no longer used name-based APIThomas Petazzoni
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 Garcia
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: Add static window allocation to the DT bindingEzequiel Garcia
This patch adds static window allocation to the device tree binding. Each first-child of the mbus-compatible node, with a suitable 'ranges' property, declaring an address translation, will trigger an address decoding window allocation. 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 Garcia
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: Factor out initialization detailsEzequiel Garcia
We introduce a common initialization function mvebu_mbus_common_init() that will be used by both legacy and device-tree initialization code. This patch is an intermediate step, which will allow to introduce the DT binding for this driver in a less intrusive way. 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 Petazzoni
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-06-08bus: mvebu-mbus: Use pr_fmtEzequiel Garcia
In order to clean message printing, we replace pr_info with pr_fmt. This is purely cosmetic change, with the sole purpose of making the code a bit more readable. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-11bus: mvebu: fix mistake in PCIe window target attribute for KirkwoodThomas Petazzoni
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 <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-03-30bus: mvebu-mbus: Restore checking for coherency fabric hardwareNeil Greatorex
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 <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-03-28bus: introduce an Marvell EBU MBus driverThomas Petazzoni
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>