- 08 May, 2014 28 commits
-
-
Andrew Lunn authored
Remove platform device instantiating of the audio, which results in board-t5325.c being removed. A DT node will be added to take its place. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1399141819-23924-7-git-send-email-andrew@lunn.chSigned-off-by:
Jason Cooper <jason@lakedaemon.net>
-
Andrew Lunn authored
Remove the platform driver and platform data for the audio codec. A DT node will replace it. Signed-off-by:
-
Ezequiel Garcia authored
The initial release of the Armada 375 DB board has an Armada 375 Z1 stepping silicon. This commit introduces a quirk that allows to workaround a series of issues with the thermal sensor in this stepping, but updating the devicetree: * Updates the compatible string for the thermal, so the driver can perform a specific initialization of the sensor. * Moves the offset of the thermal control register. This quirk allows to specifiy the correct (A0 stepping) offset in the devicetree. Signed-off-by:Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Link: https://lkml.kernel.org/r/1398371004-15807-9-git-send-email-ezequiel.garcia@free-electrons.comSigned-off-by:
-
Ezequiel Garcia authored
HAVE_ARM_TWD depends on SMP, so we should only select it if SMP is enabled, as the others platforms do. Signed-off-by:
-
Gregory CLEMENT authored
The name of the two parameters of mvebu_get_soc_id were inverted. This patch fix it in order to have a more readable code. Reported-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397925170-8202-3-git-send-email-gregory.clement@free-electrons.comSigned-off-by:
-
Gregory CLEMENT authored
l2x0_of_init function is always defined arch/arm/include/asm/hardware/cache-l2x0.h: in case of CONFIG_CACHE_L2X0 is not selected then a placeholder is defined. Then there is no need to have ifdef around l2x0_of_init. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397925170-8202-2-git-send-email-gregory.clement@free-electrons.comSigned-off-by:
-
Gregory CLEMENT authored
The cpuidle is a platform driver so we register the device just after the initialization of the board in an arch_initcall. Signed-off-by:
-
Gregory CLEMENT authored
Add the wfi, cpu idle and cpu deep idle power states support for the Armada XP SoCs. All the latencies and the power consumption values used at the "armada_370_xp_idle_driver" structure are preliminary and will be modified in the future after running some measurements and analysis. Based on the work of Nadav Haklai. Signed-off-by:
Nadav Haklai <nadavh@marvell.com> Link: https://lkml.kernel.org/r/1397488214-20685-11-git-send-email-gregory.clement@free-electrons.comSigned-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Gregory CLEMENT authored
In order to have well encapsulated code, we use notifier callbacks for CPU_PM_ENTER and CPU_PM_EXIT inside the mvebu power management code. Signed-off-by:
-
Thomas Petazzoni authored
Following the integration into mach-mvebu of the Kirkwood ARMv5 support, we need to be more careful about which files get built. For example, the pmsu.c file now calls wfi(), which only exists on ARMv7 platforms. Therefore, this commit changes mach-mvebu/Makefile to build the Armada 370/XP/375/38x specific files only when CONFIG_MACH_MVEBU_V7 is enabled. Signed-off-by:
-
Gregory CLEMENT authored
The cpu idle support will need to access to Power Management Service Unit. This commit adds the architecture related functions that will be used in the idle path of the cpuidle driver. Signed-off-by:
-
Gregory CLEMENT authored
This commit adds a function which adjusts the PMSU configuration to automatically power down the L2 and coherency fabric when we enter a certain idle state. This feature is part of the Power Management Service Unit of the Armada 370 and Armada XP SoCs. Signed-off-by:
-
Gregory CLEMENT authored
When going to deep idle we need to disable the SoC snooping (aka hardware coherency support). Playing with the coherency fabric requires to use assembly code to be sure that the compiler doesn't reorder the instructions nor do wrong optimization. Signed-off-by:
-
Gregory CLEMENT authored
Actually enabling coherency and adding a CPU on a SMP group are two different operations which can be done separately. This patch splits this in two functions. Moreover as they use common pattern, this patch also creates local low level functions (ll_get_coherency_base and ll_get_cpuid) to be used by the exposed functions (ll_add_cpu_to_smp_group and ll_enable_coherency) Signed-off-by:
-
Gregory CLEMENT authored
set_cpu_coherent() took the SMP group ID as parameter. But this parameter was never used, and the CPU always uses the SMP group 0. So we can remove this parameter. Signed-off-by:
-
Gregory CLEMENT authored
ll_set_cpu_coherent is always used on the current CPU, so instead of passing the CPU id as argument, ll_set_cpu_coherent() can find it by itself. Signed-off-by:
-
Gregory CLEMENT authored
In order to be able to deal with the MMU enabled and the MMU disabled cases, the base address of the coherency registers was passed to the function. The address by itself was not interesting as it can't change for a given SoC, the only thing we need is to have a distinction between the physical or the virtual address. This patch add a check of the MMU bit to choose the accurate address, then the calling function doesn't have to pass this information. Signed-off-by:
-
Thomas Petazzoni authored
Since the Armada 38x PMSU registers are slightly different than the Armada 370/XP PMSU ones, we introduce a new compatible string "armada-380-pmsu" in the PMSU driver. These differences are not visible for the current usage of the PMSU, but they might become visible in the future. Signed-off-by:
-
Gregory CLEMENT authored
Due to internal bootrom issue, CPU[1] initial jump code (four instructions) should be placed in SRAM memory of the SoC. In order to achieve this, we have to unmap the BootROM and at some specific location where the BootROM was place, create a specific MBus window for the SRAM. This SRAM is initialized with a few instructions of code that allows to jump into the real secondary CPU boot address. This workaround will most likely be disabled when newer steppings of the Armada 375 will be made available, in which case a dynamic test based on mvebu-soc-id will be added. Signed-off-by:
-
Gregory CLEMENT authored
This commit adds the SMP support for Armada 375 and Armada 38x. It turns out that the SMP logic for both of these SOCs are fairly similar, the only differences being: * A different method to set the secondary CPU boot address * An Armada 375 specific workaround needed for the early Z1 stepping, added by the following patch. Other than that, the patch is fairly straightforward and adds the usual platsmp and headsmp code, defining the smp_operations structure that is referenced from the DT_MACHINE structures. Signed-off-by:
-
Gregory CLEMENT authored
In order to boot the secondary CPUs on Armada 375, we need to set the boot address of these CPUs, through a register part of the System Controller (this deviates from the Armada XP design, where the boot address was defined using a register part of the PMSU unit). Therefore, this commit adds a new helper function in the System Controller driver to set the secondary CPU boot address. Moreover, it moves the System Controller initialization as an early_initcall(), since arch_initcall() is too late for an SMP-related initialization. Signed-off-by:
-
Jason Cooper authored
-
Thomas Petazzoni authored
This commit adds the CPU_METHOD_OF_DECLARE declaration for the Armada XP SMP operations. Note that the .smp_ops field of Armada XP DT_MACHINE structure is kept, in order to ensure we remain compatible with older Device Trees that do not include the "enable-method" property for the CPUs. Signed-off-by:
-
Thomas Petazzoni authored
The pmsu.c driver contained an armada_xp_boot_cpu() function that sets the boot address of a secondary CPUs and deasserts the reset. However, the Armada 375 needs a slightly different logic, so it makes more sense to move this code into the Armada XP specific platsmp.c. In order to achieve this, the mvebu_pmsu_set_cpu_boot_addr() function is exported. It will be needed for both the Armada XP and Armada 38x SMP implementations. Signed-off-by:
-
Jason Cooper authored
-
Sebastian Hesselbarth authored
Non-DT irq handlers were working through irq causes from most-significant to least-significant bit, while DT irqchip driver does it the other way round. This revealed some more HW issues on Kirkwood peripheral IP, where spurious sdio irqs can happen although irqs are masked. Also, the generated binaries show that original non-DT order compared to DT order save two instructions for each bit count check: irqchip DT order with ffs(): 60: e3a06001 mov r6, #1 64: e2643000 rsb r3, r4, #0 68: e0033004 and r3, r3, r4 6c: e16f3f13 clz r3, r3 70: e263301f rsb r3, r3, #31 74: e1c44316 bic r4, r4, r6, lsl r3 78: e5971004 ldr r1, [r7, #4] Original non-DT order with fls(): 60: e3a07001 mov r7, #1 64: e16f3f14 clz r3, r4 68: e263301f rsb r3, r3, #31 6c: e1c44317 bic r4, r4, r7, lsl r3 70: e5951004 ldr r1, [r5, #4] Therefore, reverse irq bit handling back to original order by replacing ffs() with fls(). Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: https://lkml.kernel.org/r/1398719528-23607-1-git-send-email-sebastian.hesselbarth@gmail.comAcked-by:
-
Thomas Petazzoni authored
Some irqchip initialization must be done on secondary CPUs. On mvebu platforms, this is currently achieved by having the arch/arm/mach-mvebu/platsmp.c code directly call into a function exported by the irqchip driver, which isn't really nice. This commit changes this by using the same solution as the one used in the GIC driver: the irqchip driver registers a CPU notifier, which is used to do the secondary CPU IRQ initialization. This way, the irqchip driver is completely autonomous, and the function no longer needs to be exposed from the irqchip driver to the SoC code. Signed-off-by:
-
Thomas Petazzoni authored
Instead of having the SoC code in arch/arm/mach-mvebu/platsmp.c do the set_smp_cross_call() to register the IPI-triggering function, it makes more sense to do exactly what the GIC driver is doing: let the irqchip driver do it. This way, it avoids having to expose the armada_mpic_send_doorbell() function between the irqchip driver and the SoC code. Signed-off-by:
-
- 24 Apr, 2014 12 commits
-
-
Gregory CLEMENT authored
Setting the start (or boot) address of a CPU is no more used only during SMP bring up on Armada 370/XP, but it will also be used by the CPU idle function of Armada XP, and by the Armada 38x SMP support. Therefore this commit creates a separate PMSU function to set the boot address of a CPU with the PMSU. Signed-off-by:
-
Gregory CLEMENT authored
The initial binding for PMSU was wrong, as it didn't take into account all the registers from the PMSU and moreover it referred to the CPU reset registers which are not part of PMSU. The Power Management Unit Service block also controls the Coherency Fabric subsystem. These registers are needed for the CPU idle implementation for the Armada 370/XP, it allows to enter a deep CPU idle state where the Coherency Fabric and the L2 cache are powered down. This commit adds support for a new compatible for the PMSU node which includes the registers related to the coherency fabric. It also keeps compatibility with the old compatible string. Signed-off-by:
-
Thomas Petazzoni authored
Until now, the PMSU driver was using of_iomap() to map its registers, but of_iomap() doesn't call request_mem_region(). This commit fixes the memory mapping code of the PMSU to do so, which will also be useful for a later commit since we will need to adjust the resource base address and size for Device Tree backward compatibility. Signed-off-by:
-
Thomas Petazzoni authored
This commit changes the PMSU driver to no longer map itself the CPU reset registers, and instead call into the CPU reset driver to deassert the secondary CPUs for SMP booting. In order to provide Device Tree backward compatibility, the CPU reset driver is extended to not only support its official compatible string "marvell,armada-370-cpu-reset", but to also look at the PMSU compatible string "marvell,armada-370-xp-pmsu" to find the CPU reset registers address. This allows old Device Tree to work correctly with newer kernel versions. Therefore, the CPU reset driver implements the following logic: * If one of the normal compatible strings "marvell,armada-370-cpu-reset" is found, then we map its first memory resource as the CPU reset registers. * Otherwise, if none of the normal compatible strings have been found, we look for the "marvell,armada-370-xp-pmsu" compatible string, and we map the second memory as the CPU reset registers. Signed-off-by:
-
Thomas Petazzoni authored
The Armada 370 and Armada XP have registers that allow to reset the CPUs, which is particularly useful to take the secondary CPUs out of reset in the context of the SMP support. Unfortunately, an implementation mistake was originally made and the support for these registers was integrated into the PMSU driver, which is in fact completely unrelated. And it turns out that the Armada 375 has the same CPU reset registers, but does not have the PMSU registers. Therefore, this commit creates a small CPU reset driver. All it does is provide a simple mvebu_cpu_reset_deassert() function that the SMP support code can call to take secondary CPUs out of reset. As of this commit, the driver isn't being used, it will be used through changes in the following commits. Note that we initially planned to use the 'reset controller' framework, but it requires the addition of "resets" properties in the Device Tree, which are causing too many problems if we want to keep the Device Tree backward compatibility. Moreover, the 'reset controller' framework is mainly useful when a device driver needs to request a reset of its device from a separate reset controller. In our case, the CPU reset handling and the SMP core code are both located in arch/arm/mach-mvebu/ and are tightly linked together, so there's no real benefit in going through a separate framework. Signed-off-by:
-
Thomas Petazzoni authored
The Armada 38x has a coherency unit that is similar to the one of the Armada 375 SoC, except that it does not have the bug of the Armada 375 coherency unit that requires the XOR based workaround. This commit therefore extends the Marvell EBU coherency code with a new compatible string to support the Armada 38x coherency unit. Signed-off-by:
-
Thomas Petazzoni authored
The early revisions of Armada 375 SOCs (Z1 stepping) have a bug in the I/O coherency unit that prevents using the normal method for the I/O coherency barrier. The recommended workaround is to use a XOR memset transfer to act as the I/O coherency barrier. This involves "borrowing" a XOR engine, which gets disabled in the Device Tree so the normal XOR driver doesn't use it. Signed-off-by:
-
Thomas Petazzoni authored
The Armada 375, like the Armada 370 and Armada XP, has a coherency unit. However, unlike the coherency unit of 370/XP which does both CPU and I/O coherency, the one on Armada 735 only does I/O coherency. Therefore, instead of having two sets of registers (the first one being used mainly to register each CPU in the coherency fabric, the second one being used for the I/O coherency barrier), it has only one set of register (for the I/O coherency barrier). This commit adds a new "marvell,armada-375-coherency-fabric" compatible string for this variant of the coherency fabric. The custom DMA operations, and the way of triggering an I/O barrier is the same as Armada 370/XP, so the code changes are minimal. However, the set_cpu_coherent() function is not needed on Armada 375 and will not work. Signed-off-by:
-
Thomas Petazzoni authored
Contrary to the Armada 370 and XP that used the PJ4B Marvell cores, the Armada 375 and Armada 38x use the ARM Cortex-A9. A consequence of this is that the unit responsible for the coherency between CPUs is now the ARM SCU, and not the Marvell coherency unit (which is still present to do coherency with I/O devices). Therefore this commit: * Ensures that the selection of the Armada 375 or Armada 38x SoC support enables the ARM SCU support in the kernel. * Make sure to initialize the SCU at boot time. Signed-off-by:
-
Thomas Petazzoni authored
In the mach-mvebu coherency code, instead of using of_find_matching_node() and then of_match_node(), directly use the of_find_matching_node_and_match() which does both at once. We take this opportunity to also simplify the initialization of the "type" variable. Signed-off-by:
-
Thomas Petazzoni authored
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 authored
This commit extends the coherency fabric code to provide a coherency_available()function that the SoC code can call to be told whether coherency support is available or not. On Armada 370/XP, coherency support is available as soon as the relevant DT node is present. On some upcoming SoCs, the DT node needs to be present *and* the system running with CONFIG_SMP enabled. Signed-off-by:
-
