The Armada 375 SMP workaround only needs to be applied to the Z1
revision of the SoC. The A0 and later revisions have been fixed, and
no longer need this workaround.
Note that the initialization of the SMP workaround is delayed from
->smp_prepare_cpus() to ->smp_boot_secondary() because when
->smp_prepare_cpus() is called, the early initcalls have not be
called, so the mvebu-soc-id mechanism is not operational. Since the
workaround is anyway not needed before the secondary CPU is started,
we can delay its implementation until the ->smp_boot_secondary() call.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399302326-6917-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Currently, the mvebu-soc-id logic is initialized through a
core_initcall(). However, we will soon need to know the SoC revision
before booting secondary CPUs, because a workaround affects Armada 375
Z1 steppings, but should not be applied on Armada 375 A0 steppings.
Unfortunately, core_initcall() are called way too late compared to the
SMP initialization. Therefore, the mvebu-soc-id initialization is move
to an early_initcall(), which is called before the SMP initialization.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399302326-6917-3-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
In commit 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add
thermal quirk for the Armada 375 DB board'), a check on the Armada SoC
revision was added to decide whether a quirk for the thermal device
should be applied or not.
However, the quirk implementation has a bug: it assumes
mvebu_get_soc_id() returns true on success, but it returns
0. Therefore, the condition:
if (mvebu_get_soc_id(&dev, &rev) && rev > ARMADA_375_Z1_REV)
is always false (as long as mvebu-soc-id is properly initialized). As
a consequence, the quirk is always applied, even on A0 steppings, for
which the quirk should not be applied.
This was spotted by testing the thermal driver on Armada 375 A0, which
Ezequiel could not do since he does not have access to the A0 revision
of the SoC for the moment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399302326-6917-2-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add thermal quirk for the Armada 375 DB board')
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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.ch
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397925170-8202-3-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397925170-8202-2-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-10-git-send-email-gregory.clement@free-electrons.com
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1398709239-6126-1-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-9-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-8-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-7-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-6-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-5-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-4-git-send-email-gregory.clement@free-electrons.com
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-3-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-8-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-10-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-10-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-7-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-7-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-3-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-2-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-6-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483433-25836-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483433-25836-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483433-25836-4-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483433-25836-3-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483433-25836-2-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-8-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-7-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-6-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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>
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-3-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The code that handles the coherency fabric of Armada 370 and Armada XP
in arch/arm/mach-mvebu/coherency.c made the assumption that there was
only one type of coherency fabric. Unfortunately, it turns out that
upcoming SoCs have a slightly different coherency unit.
In preparation to the introduction of the coherency support for more
SoCs, this commit:
* Introduces a data associated to the compatible string in the
compatible string match table, so that the code can differantiate
the variant of coherency unit being used.
* Separates the coherency unit initialization code into its own
function.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-2-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Commit 8f619b5429 ("powerpc/ppc64: Do not turn AIL (reloc-on
interrupts) too early") added code to set the AIL bit in the LPCR
without checking whether the kernel is running in hypervisor mode. The
result is that when the kernel is running as a guest (i.e., under
PowerKVM or PowerVM), the processor takes a privileged instruction
interrupt at that point, causing a panic. The visible result is that
the kernel hangs after printing "returning from prom_init".
This fixes it by checking for hypervisor mode being available before
setting LPCR. If we are not in hypervisor mode, we enable relocation-on
interrupts later in pSeries_setup_arch using the H_SET_MODE hcall.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEABECAAYFAlNFtEkACgkQuseO5dulBZVcPwCdFWY81hKqQaKHaSPFh9m+n1lt
yY0An2VZZGrFSkj162POFy1P2sPpGw5p
=LRFZ
-----END PGP SIGNATURE-----
Merge tag 'llvmlinux-for-v3.15' of git://git.linuxfoundation.org/llvmlinux/kernel
Pull llvm patches from Behan Webster:
"These are some initial updates to support compiling the kernel with
clang.
These patches have been through the proper reviews to the best of my
ability, and have been soaking in linux-next for a few weeks. These
patches by themselves still do not completely allow clang to be used
with the kernel code, but lay the foundation for other patches which
are still under review.
Several other of the LLVMLinux patches have been already added via
maintainer trees"
* tag 'llvmlinux-for-v3.15' of git://git.linuxfoundation.org/llvmlinux/kernel:
x86: LLVMLinux: Fix "incomplete type const struct x86cpu_device_id"
x86 kbuild: LLVMLinux: More cc-options added for clang
x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI
LLVMLinux: Add support for clang to compiler.h and new compiler-clang.h
LLVMLinux: Remove warning about returning an uninitialized variable
kbuild: LLVMLinux: Fix LINUX_COMPILER definition script for compilation with clang
Documentation: LLVMLinux: Update Documentation/dontdiff
kbuild: LLVMLinux: Adapt warnings for compilation with clang
kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang
Pull vfs updates from Al Viro:
"The first vfs pile, with deep apologies for being very late in this
window.
Assorted cleanups and fixes, plus a large preparatory part of iov_iter
work. There's a lot more of that, but it'll probably go into the next
merge window - it *does* shape up nicely, removes a lot of
boilerplate, gets rid of locking inconsistencie between aio_write and
splice_write and I hope to get Kent's direct-io rewrite merged into
the same queue, but some of the stuff after this point is having
(mostly trivial) conflicts with the things already merged into
mainline and with some I want more testing.
This one passes LTP and xfstests without regressions, in addition to
usual beating. BTW, readahead02 in ltp syscalls testsuite has started
giving failures since "mm/readahead.c: fix readahead failure for
memoryless NUMA nodes and limit readahead pages" - might be a false
positive, might be a real regression..."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits)
missing bits of "splice: fix racy pipe->buffers uses"
cifs: fix the race in cifs_writev()
ceph_sync_{,direct_}write: fix an oops on ceph_osdc_new_request() failure
kill generic_file_buffered_write()
ocfs2_file_aio_write(): switch to generic_perform_write()
ceph_aio_write(): switch to generic_perform_write()
xfs_file_buffered_aio_write(): switch to generic_perform_write()
export generic_perform_write(), start getting rid of generic_file_buffer_write()
generic_file_direct_write(): get rid of ppos argument
btrfs_file_aio_write(): get rid of ppos
kill the 5th argument of generic_file_buffered_write()
kill the 4th argument of __generic_file_aio_write()
lustre: don't open-code kernel_recvmsg()
ocfs2: don't open-code kernel_recvmsg()
drbd: don't open-code kernel_recvmsg()
constify blk_rq_map_user_iov() and friends
lustre: switch to kernel_sendmsg()
ocfs2: don't open-code kernel_sendmsg()
take iov_iter stuff to mm/iov_iter.c
process_vm_access: tidy up a bit
...
Pull audit updates from Eric Paris.
* git://git.infradead.org/users/eparis/audit: (28 commits)
AUDIT: make audit_is_compat depend on CONFIG_AUDIT_COMPAT_GENERIC
audit: renumber AUDIT_FEATURE_CHANGE into the 1300 range
audit: do not cast audit_rule_data pointers pointlesly
AUDIT: Allow login in non-init namespaces
audit: define audit_is_compat in kernel internal header
kernel: Use RCU_INIT_POINTER(x, NULL) in audit.c
sched: declare pid_alive as inline
audit: use uapi/linux/audit.h for AUDIT_ARCH declarations
syscall_get_arch: remove useless function arguments
audit: remove stray newline from audit_log_execve_info() audit_panic() call
audit: remove stray newlines from audit_log_lost messages
audit: include subject in login records
audit: remove superfluous new- prefix in AUDIT_LOGIN messages
audit: allow user processes to log from another PID namespace
audit: anchor all pid references in the initial pid namespace
audit: convert PPIDs to the inital PID namespace.
pid: get pid_t ppid of task in init_pid_ns
audit: rename the misleading audit_get_context() to audit_take_context()
audit: Add generic compat syscall support
audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL
...
