linux - Linux Kernel (branches are rebased on master from time to time)

Age	Commit message (Collapse)	Author	Files	Lines
2012-11-24	Merge branch 'mvebu-misc-fixes' of ↵	Jason Cooper	1	-1/+1
	git://github.com/MISL-EBU-System-SW/mainline-public into mvebu/everything
2012-11-22	arm: mvebu: fix address decoding armada_cfg_base() function	Thomas Petazzoni	1	-1/+1
	The armada_cfg_base() function returns the base address of the registers that allow to configure the decoding for a particular address window. On Armada 370/XP, the lower windows have more configuration registers (4 registers) than the higher windows (2 registers). This armada_cfg_base() takes this into account by doing a different offset calculation depending on the window number, but this offset calculation was wrong for the higher windows. Even though we were not using high window numbers until now (only window 0 is used to map the BootROM, needed for SMP), we use this function at boot time to disable all windows to ensure that nothing remains intialized from what the bootloader has done. Unfortunately, the U-Boot on the OpenBlocks AX3-4 uses a window with a high number (above 8) to remap the BootROM. And then when the kernel boots, it remaps the BootROM in window 0. Normally, this is not a problem, because all windows have previously been disabled. Except that due to our wrong offset calculation, the windows with high numbers were not properly disabled, leading to the BootROM being mapped twice. The visible result of this bug was that the kernel was unable to get the second CPU started on the OpenBlocks AX3-4 platform. With this fix, all windows are properly cleared at boot time, the BootROM is remapped only once in window 0, and the second CPU boots fine. Thanks a lot to Lior Amsamlen <alior@marvell.com> for his help in debugging this problem. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Strictly speaking, this bug was introduced in 3.7, but since the only platforms supported in 3.7 were Armada 370 and Armada XP, and there was anyway no SMP support at this time, it isn't really worth the effort to push this patch in 3.7.
2012-11-21	arm: mvebu: Add hardware I/O Coherency support	Gregory CLEMENT	1	-0/+3
	Armada 370 and XP come with an unit called coherency fabric. This unit allows to use the Armada 370/XP as a nearly coherent architecture. The coherency mechanism uses snoop filters to ensure the coherency between caches, DRAM and devices. This mechanism needs a synchronization barrier which guarantees that all the memory writes initiated by the devices have reached their target and do not reside in intermediate write buffers. That's why the architecture is not totally coherent and we need to provide our own functions for some DMA operations. Beside the use of the coherency fabric, the device units will have to set the attribute flag of the decoding address window to select the accurate coherency process for the memory transaction. This is done each device driver programs the DRAM address windows. The value of the attribute set by the driver is retrieved through the orion_addr_map_cfg struct filled during the early initialization of the platform. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Yehuda Yitschak <yehuday@marvell.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
2012-09-21	arm: mvebu: add basic address decoding support to Armada 370/XP	Thomas Petazzoni	1	-0/+134
	This commit adds basic support for address decoding configuration for the Armada 370 and Armada XP SoCs, re-using the infrastructure provided in plat-orion. For now, only a BootROM window is configured on Armada XP, which is needed to get the non-boot CPUs started and is therefore a requirement for SMP support. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>