openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/arch/mips/kernel/cps-vec.S

626 lines
12 KiB
ArmAsm
Raw Normal View History

MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
/*
* Copyright (C) 2013 Imagination Technologies
* Author: Paul Burton <paul.burton@imgtec.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
#include <asm/addrspace.h>
#include <asm/asm.h>
#include <asm/asm-offsets.h>
#include <asm/asmmacro.h>
#include <asm/cacheops.h>
MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores The CPS code is doing several memory loads when configuring the VPEs from secondary cores, so the segmentation control registers must be initialized in time otherwise the kernel will crash with strange TLB exceptions. Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Patchwork: http://patchwork.linux-mips.org/patch/7424/ Signed-off-by: James Hogan <james.hogan@imgtec.com>
2014-07-21 21:35:56 +08:00
#include <asm/eva.h>
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
#include <asm/mipsregs.h>
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
#include <asm/mipsmtregs.h>
MIPS: pm-cps: add PM state entry code for CPS systems This patch adds code to generate entry & exit code for various low power states available on systems based around the MIPS Coherent Processing System architecture (ie. those with a Coherence Manager, Global Interrupt Controller & for >=CM2 a Cluster Power Controller). States supported are: - Non-coherent wait. This state first leaves the coherent domain and then executes a regular MIPS wait instruction. Power savings are found from the elimination of coherency interventions between the core and any other coherent requestors in the system. - Clock gated. This state leaves the coherent domain and then gates the clock input to the core. This removes all dynamic power from the core but leaves the core at the mercy of another to restart its clock. Register state is preserved, but the core can not service interrupts whilst its clock is gated. - Power gated. This deepest state removes all power input to the core. All register state is lost and the core will restart execution from its BEV when another core powers it back up. Because register state is lost this state requires cooperation with the CONFIG_MIPS_CPS SMP implementation in order for the core to exit the state successfully. The code will detect which states are available on the current system during boot & generate the entry/exit code for those states. This will be used by cpuidle & hotplug implementations. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 18:00:56 +08:00
#include <asm/pm.h>
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
#define GCR_CPC_BASE_OFS 0x0088
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
#define GCR_CL_COHERENCE_OFS 0x2008
#define GCR_CL_ID_OFS 0x2028
MIPS: CPS: Handle spurious VP starts more gracefully On pre-r6 systems with the MT ASE the CPS SMP code included checks to halt the VPE running mips_cps_boot_vpes() if its bit in the struct core_boot_config vpe_mask field is clear. This was largely done in order to allow us to start arbitrary VPEs within a core despite the fact that hardware is typically configured to run only VPE0 after powering up a core. VPE0 would start the desired other VPEs, halt itself, and the fact that VPE0 started would be largely hidden & irrelevant. In MIPSr6 multithreading we have control over which VPs start executing when a core powers up via the cores CPC registers accessed remotely through the redirect block. For this reason the MIPSr6 multithreading path in mips_cps_boot_vpes() hasn't bothered up until now to handle halting the VP running it. However it is possible to power up cores entirely in hardware by using a pwr_up pin associated with the core. Unfortunately some systems wire this pin to a logic 1, which means that it is possible for a core to power up at a point that software doesn't expect. The result is that we generally go execute the kernel on a CPU that ought not to be running & the results can be unpredictable. Handle this case by stopping VPs that we don't expect to be running in mips_cps_boot_vpes() - with this change even if a core powers up it will do nothing useful & all VPs within it will stop running before they proceed to run general kernel code & do any damage. Ideally we would produce some sort of warning here, but given the stage of core bringup this happens at that would be non-trivial. We also will only hit this if a core starts up after being offlined via hotplug, and when that happens we will already produce a warning that the CPU didn't power down in cps_cpu_die() which seems sufficient. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16198/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-06-03 05:48:55 +08:00
#define CPC_CL_VC_STOP_OFS 0x2020
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
#define CPC_CL_VC_RUN_OFS 0x2028
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
.extern mips_cm_base
.set noreorder
MIPS: CPS: Set Status.KX on entry for MIPS64 kernels If the kernel may make use of 64 bit addresses outside of the compatibility address space then we need to set KX such that those accesses can succeed. Do so for MIPS64 kernels. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11201/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:10 +08:00
#ifdef CONFIG_64BIT
# define STATUS_BITDEPS ST0_KX
#else
# define STATUS_BITDEPS 0
#endif
MIPS: CPS: Early debug using an ns16550-compatible UART Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11202/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:11 +08:00
#ifdef CONFIG_MIPS_CPS_NS16550
#define DUMP_EXCEP(name) \
PTR_LA a0, 8f; \
jal mips_cps_bev_dump; \
nop; \
TEXT(name)
#else /* !CONFIG_MIPS_CPS_NS16550 */
#define DUMP_EXCEP(name)
#endif /* !CONFIG_MIPS_CPS_NS16550 */
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/*
* Set dest to non-zero if the core supports the MT ASE, else zero. If
* MT is not supported then branch to nomt.
*/
.macro has_mt dest, nomt
MIPS: CPS: Skip Config1 presence check The Config1 register is architecturally defined as required, and is thus present in all systems which may make use of cps-vec.S. Skip the check for its presence via the Config.M bit. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11204/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:13 +08:00
mfc0 \dest, CP0_CONFIG, 1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
bgez \dest, \nomt
mfc0 \dest, CP0_CONFIG, 2
bgez \dest, \nomt
mfc0 \dest, CP0_CONFIG, 3
andi \dest, \dest, MIPS_CONF3_MT
beqz \dest, \nomt
MIPS: CPS: Stop dangling delay slot from has_mt. The has_mt macro ended with a branch, leaving its callers with a delay slot that would be executed if Config3.MT is not set. However it would not be executed if Config3 (or earlier Config registers) don't exist which makes it somewhat inconsistent at best. Fill the delay slot in the macro & fix the mips_cps_boot_vpes caller appropriately. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10865/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-08-06 06:42:36 +08:00
nop
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
.endm
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
/*
* Set dest to non-zero if the core supports MIPSr6 multithreading
* (ie. VPs), else zero. If MIPSr6 multithreading is not supported then
* branch to nomt.
*/
.macro has_vp dest, nomt
mfc0 \dest, CP0_CONFIG, 1
bgez \dest, \nomt
mfc0 \dest, CP0_CONFIG, 2
bgez \dest, \nomt
mfc0 \dest, CP0_CONFIG, 3
bgez \dest, \nomt
mfc0 \dest, CP0_CONFIG, 4
bgez \dest, \nomt
mfc0 \dest, CP0_CONFIG, 5
andi \dest, \dest, MIPS_CONF5_VP
beqz \dest, \nomt
nop
.endm
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
/* Calculate an uncached address for the CM GCRs */
.macro cmgcrb dest
.set push
.set noat
MFC0 $1, CP0_CMGCRBASE
PTR_SLL $1, $1, 4
PTR_LI \dest, UNCAC_BASE
PTR_ADDU \dest, \dest, $1
.set pop
.endm
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
.section .text.cps-vec
.balign 0x1000
LEAF(mips_cps_core_entry)
/*
MIPS: CPS: Read CM GCR base from cop0 Rather than patching the start of mips_cps_core_entry to provide the base address of the CM GCRs, simply read that base address from the cop0 CMGCRBase register, converting from the physical address to an uncached virtual address. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: linux-kernel@vger.kernel.org Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11203/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:12 +08:00
* These first 4 bytes will be patched by cps_smp_setup to load the
* CCA to use into register s0.
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
*/
MIPS: smp-cps: duplicate core0 CCA on secondary cores Rather than hardcoding CCA=0x5 for secondary cores, re-use the CCA from the boot CPU. This allows overrides of the CCA using the cca= kernel parameter to take effect on all CPUs for consistency. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-16 18:10:57 +08:00
.word 0
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
/* Check whether we're here due to an NMI */
mfc0 k0, CP0_STATUS
and k0, k0, ST0_NMI
beqz k0, not_nmi
nop
/* This is an NMI */
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA k0, nmi_handler
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
jr k0
nop
not_nmi:
/* Setup Cause */
li t0, CAUSEF_IV
mtc0 t0, CP0_CAUSE
/* Setup Status */
MIPS: CPS: Set Status.KX on entry for MIPS64 kernels If the kernel may make use of 64 bit addresses outside of the compatibility address space then we need to set KX such that those accesses can succeed. Do so for MIPS64 kernels. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11201/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:10 +08:00
li t0, ST0_CU1 | ST0_CU0 | ST0_BEV | STATUS_BITDEPS
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
mtc0 t0, CP0_STATUS
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
/* Skip cache & coherence setup if we're already coherent */
cmgcrb v1
lw s7, GCR_CL_COHERENCE_OFS(v1)
bnez s7, 1f
nop
MIPS: smp-cps: Pull cache init into a function In preparation for further modifications to mips_cps_core_entry, pull the L1 cache initialisation out into a separate function. This both makes the code in mips_cps_core_entry read more clearly, particularly when modifying it, and shortens it which will become important as code is added that needs to continue to fit within the reset vector. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12336/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:30 +08:00
/* Initialize the L1 caches */
jal mips_cps_cache_init
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
nop
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
/* Enter the coherent domain */
li t0, 0xff
sw t0, GCR_CL_COHERENCE_OFS(v1)
ehb
MIPS: smp-cps: duplicate core0 CCA on secondary cores Rather than hardcoding CCA=0x5 for secondary cores, re-use the CCA from the boot CPU. This allows overrides of the CCA using the cca= kernel parameter to take effect on all CPUs for consistency. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-16 18:10:57 +08:00
/* Set Kseg0 CCA to that in s0 */
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
1: mfc0 t0, CP0_CONFIG
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
ori t0, 0x7
MIPS: smp-cps: duplicate core0 CCA on secondary cores Rather than hardcoding CCA=0x5 for secondary cores, re-use the CCA from the boot CPU. This allows overrides of the CCA using the cca= kernel parameter to take effect on all CPUs for consistency. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-16 18:10:57 +08:00
xori t0, 0x7
or t0, t0, s0
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
mtc0 t0, CP0_CONFIG
ehb
/* Jump to kseg0 */
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA t0, 1f
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
jr t0
nop
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/*
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
* We're up, cached & coherent. Perform any EVA initialization necessary
* before we access memory.
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
*/
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
1: eva_init
MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores The CPS code is doing several memory loads when configuring the VPEs from secondary cores, so the segmentation control registers must be initialized in time otherwise the kernel will crash with strange TLB exceptions. Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Patchwork: http://patchwork.linux-mips.org/patch/7424/ Signed-off-by: James Hogan <james.hogan@imgtec.com>
2014-07-21 21:35:56 +08:00
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
/* Retrieve boot configuration pointers */
jal mips_cps_get_bootcfg
nop
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
/* Skip core-level init if we started up coherent */
bnez s7, 1f
nop
/* Perform any further required core-level initialisation */
jal mips_cps_core_init
nop
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
/*
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
* Boot any other VPEs within this core that should be online, and
* deactivate this VPE if it should be offline.
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
*/
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
move a1, t9
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
jal mips_cps_boot_vpes
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
move a0, v0
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
/* Off we go! */
MIPS: smp-cps: Skip core setup if coherent In preparation for supporting MIPSr6 multithreading (ie. VPs) which will begin execution from the core reset vector, skip core level setup if the core is already coherent. This is never the case when a core is first started, since boot_core explicitly clears the cores GCR_Cx_COH_EN register, and always the case when secondary VPs start since the first VP to start will have enabled coherence after initialising the core & its caches. One notable side effect of this patch is that eva_init gets called slightly earlier, prior to mips_cps_core_init rather than after it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:32 +08:00
1: PTR_L t1, VPEBOOTCFG_PC(v1)
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
PTR_L gp, VPEBOOTCFG_GP(v1)
PTR_L sp, VPEBOOTCFG_SP(v1)
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
jr t1
nop
END(mips_cps_core_entry)
.org 0x200
LEAF(excep_tlbfill)
MIPS: CPS: Early debug using an ns16550-compatible UART Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11202/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:11 +08:00
DUMP_EXCEP("TLB Fill")
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
b .
nop
END(excep_tlbfill)
.org 0x280
LEAF(excep_xtlbfill)
MIPS: CPS: Early debug using an ns16550-compatible UART Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11202/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:11 +08:00
DUMP_EXCEP("XTLB Fill")
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
b .
nop
END(excep_xtlbfill)
.org 0x300
LEAF(excep_cache)
MIPS: CPS: Early debug using an ns16550-compatible UART Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11202/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:11 +08:00
DUMP_EXCEP("Cache")
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
b .
nop
END(excep_cache)
.org 0x380
LEAF(excep_genex)
MIPS: CPS: Early debug using an ns16550-compatible UART Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11202/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:11 +08:00
DUMP_EXCEP("General")
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
b .
nop
END(excep_genex)
.org 0x400
LEAF(excep_intex)
MIPS: CPS: Early debug using an ns16550-compatible UART Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11202/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-09-23 02:12:11 +08:00
DUMP_EXCEP("Interrupt")
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
b .
nop
END(excep_intex)
.org 0x480
LEAF(excep_ejtag)
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA k0, ejtag_debug_handler
MIPS: Coherent Processing System SMP implementation This patch introduces a new SMP implementation for systems implementing the MIPS Coherent Processing System architecture. The kernel will make use of the Coherence Manager, Cluster Power Controller & Global Interrupt Controller in order to detect, bring up & make use of other cores in the system. SMTC is not supported, so only a single TC per VPE in the system is used. That is, this option enables an SMVP style setup but across multiple cores. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6362/ Patchwork: https://patchwork.linux-mips.org/patch/6611/ Patchwork: https://patchwork.linux-mips.org/patch/6651/ Patchwork: https://patchwork.linux-mips.org/patch/6652/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-01-15 18:31:53 +08:00
jr k0
nop
END(excep_ejtag)
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
LEAF(mips_cps_core_init)
MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot vector if we're using MT for SMP. Thus switch the config symbol we ifdef against to CONFIG_MIPS_MT_SMP. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10867/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-08-06 06:42:38 +08:00
#ifdef CONFIG_MIPS_MT_SMP
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Check that the core implements the MT ASE */
has_mt t0, 3f
.set push
.set mt
/* Only allow 1 TC per VPE to execute... */
dmt
/* ...and for the moment only 1 VPE */
dvpe
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA t1, 1f
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
jr.hb t1
nop
/* Enter VPE configuration state */
1: mfc0 t0, CP0_MVPCONTROL
ori t0, t0, MVPCONTROL_VPC
mtc0 t0, CP0_MVPCONTROL
/* Retrieve the number of VPEs within the core */
mfc0 t0, CP0_MVPCONF0
srl t0, t0, MVPCONF0_PVPE_SHIFT
andi t0, t0, (MVPCONF0_PVPE >> MVPCONF0_PVPE_SHIFT)
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
addiu ta3, t0, 1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* If there's only 1, we're done */
beqz t0, 2f
nop
/* Loop through each VPE within this core */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
li ta1, 1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
1: /* Operate on the appropriate TC */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
mtc0 ta1, CP0_VPECONTROL
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
ehb
/* Bind TC to VPE (1:1 TC:VPE mapping) */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
mttc0 ta1, CP0_TCBIND
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Set exclusive TC, non-active, master */
li t0, VPECONF0_MVP
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
sll t1, ta1, VPECONF0_XTC_SHIFT
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
or t0, t0, t1
mttc0 t0, CP0_VPECONF0
/* Set TC non-active, non-allocatable */
mttc0 zero, CP0_TCSTATUS
/* Set TC halted */
li t0, TCHALT_H
mttc0 t0, CP0_TCHALT
/* Next VPE */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
addiu ta1, ta1, 1
slt t0, ta1, ta3
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
bnez t0, 1b
nop
/* Leave VPE configuration state */
2: mfc0 t0, CP0_MVPCONTROL
xori t0, t0, MVPCONTROL_VPC
mtc0 t0, CP0_MVPCONTROL
3: .set pop
#endif
jr ra
nop
END(mips_cps_core_init)
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
/**
* mips_cps_get_bootcfg() - retrieve boot configuration pointers
*
* Returns: pointer to struct core_boot_config in v0, pointer to
* struct vpe_boot_config in v1, VPE ID in t9
*/
LEAF(mips_cps_get_bootcfg)
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Calculate a pointer to this cores struct core_boot_config */
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
cmgcrb t0
MIPS: CPS: use 32b accesses to GCRs Commit b677bc03d757 ("MIPS: cps-vec: Use macros for various arithmetics and memory operations") replaced various load & store instructions through cps-vec.S with the PTR_L & PTR_S macros. However it was somewhat overzealous in doing so for CM GCR accesses, since the bit width of the CM doesn't necessarily match that of the CPU. The registers accessed (GCR_CL_COHERENCE & GCR_CL_ID) should be safe to simply always access using 32b instructions, so do so in order to avoid issues when using a 32b CM with a 64b CPU. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/10864/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-08-06 06:42:35 +08:00
lw t0, GCR_CL_ID_OFS(t0)
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
li t1, COREBOOTCFG_SIZE
mul t0, t0, t1
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA t1, mips_cps_core_bootcfg
MIPS: cps-vec: Use macros for various arithmetics and memory operations Replace lw/sw and various arithmetic instructions with macros so the code can work on 64-bit kernels as well. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10591/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:33 +08:00
PTR_L t1, 0(t1)
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
PTR_ADDU v0, t0, t1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Calculate this VPEs ID. If the core doesn't support MT use 0 */
MIPS: CPS: Stop dangling delay slot from has_mt. The has_mt macro ended with a branch, leaving its callers with a delay slot that would be executed if Config3.MT is not set. However it would not be executed if Config3 (or earlier Config registers) don't exist which makes it somewhat inconsistent at best. Fill the delay slot in the macro & fix the mips_cps_boot_vpes caller appropriately. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10865/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-08-06 06:42:36 +08:00
li t9, 0
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
#if defined(CONFIG_CPU_MIPSR6)
has_vp ta2, 1f
/*
* Assume non-contiguous numbering. Perhaps some day we'll need
* to handle contiguous VP numbering, but no such systems yet
* exist.
*/
MIPS: CPS: Use GlobalNumber macros rather than magic numbers We now have definitions for the GlobalNumber register in asm/mipsregs.h, so use them in place of magic numbers in cps-vec.S. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17008/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-13 10:49:34 +08:00
mfc0 t9, CP0_GLOBALNUMBER
andi t9, t9, MIPS_GLOBALNUMBER_VP
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
#elif defined(CONFIG_MIPS_MT_SMP)
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
has_mt ta2, 1f
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Find the number of VPEs present in the core */
mfc0 t1, CP0_MVPCONF0
srl t1, t1, MVPCONF0_PVPE_SHIFT
andi t1, t1, MVPCONF0_PVPE >> MVPCONF0_PVPE_SHIFT
MIPS: kernel: cps-vec: Replace "addi" with "addiu" The "addi" instruction will trap on overflows which is not something we need in this code, so we replace that with "addiu". Link: http://www.linux-mips.org/archives/linux-mips/2015-01/msg00430.html Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: <stable@vger.kernel.org> # v3.15+ Cc: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
2014-11-24 22:40:11 +08:00
addiu t1, t1, 1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Calculate a mask for the VPE ID from EBase.CPUNum */
clz t1, t1
li t2, 31
subu t1, t2, t1
li t2, 1
sll t1, t2, t1
addiu t1, t1, -1
/* Retrieve the VPE ID from EBase.CPUNum */
mfc0 t9, $15, 1
and t9, t9, t1
MIPS: CPS: Don't include MT code in non-MT kernels. The MT-specific code in mips_cps_boot_vpes can safely be omitted from kernels which don't support MT, with the default VPE==0 case being used as it would be after the has_mt (Config3.MT) check failed at runtime. Discarding the code entirely will save us a few bytes & allow cleaner handling of MT ASE instructions by later patches. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10866/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-08-06 06:42:37 +08:00
#endif
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
1: /* Calculate a pointer to this VPEs struct vpe_boot_config */
li t1, VPEBOOTCFG_SIZE
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
mul v1, t9, t1
PTR_L ta3, COREBOOTCFG_VPECONFIG(v0)
PTR_ADDU v1, v1, ta3
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
jr ra
nop
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
END(mips_cps_get_bootcfg)
LEAF(mips_cps_boot_vpes)
MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs The vpe_mask member of struct core_boot_config is of type atomic_t, which is a 32bit type. In cps-vec.S this member was being retrieved by a PTR_L macro, which on 64bit systems is a 64bit load. On little endian systems this is OK, since the double word that is retrieved will have the required less significant word in the correct position. However, on big endian systems the less significant word of the load is retrieved from address+4, and the more significant from address+0. The destination register therefore ends up with the required word in the more significant word e.g. when starting the second VP of a big endian 64bit system, the load PTR_L ta2, COREBOOTCFG_VPEMASK(a0) ends up setting register ta2 to 0x0000000300000000 When this value is written to the CPC it is ignored, since it is invalid to write anything larger than 4 bits. This results in any VP other than VP0 in a core failing to start in 64bit big endian systems. Change the load to a 32bit load word instruction to fix the bug. Fixes: f12401d7219f ("MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes") Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15787/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-03-21 22:39:19 +08:00
lw ta2, COREBOOTCFG_VPEMASK(a0)
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
PTR_L ta3, COREBOOTCFG_VPECONFIG(a0)
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
#if defined(CONFIG_CPU_MIPSR6)
has_vp t0, 5f
/* Find base address of CPC */
cmgcrb t3
PTR_L t1, GCR_CPC_BASE_OFS(t3)
PTR_LI t2, ~0x7fff
and t1, t1, t2
PTR_LI t2, UNCAC_BASE
PTR_ADD t1, t1, t2
MIPS: CPS: Handle spurious VP starts more gracefully On pre-r6 systems with the MT ASE the CPS SMP code included checks to halt the VPE running mips_cps_boot_vpes() if its bit in the struct core_boot_config vpe_mask field is clear. This was largely done in order to allow us to start arbitrary VPEs within a core despite the fact that hardware is typically configured to run only VPE0 after powering up a core. VPE0 would start the desired other VPEs, halt itself, and the fact that VPE0 started would be largely hidden & irrelevant. In MIPSr6 multithreading we have control over which VPs start executing when a core powers up via the cores CPC registers accessed remotely through the redirect block. For this reason the MIPSr6 multithreading path in mips_cps_boot_vpes() hasn't bothered up until now to handle halting the VP running it. However it is possible to power up cores entirely in hardware by using a pwr_up pin associated with the core. Unfortunately some systems wire this pin to a logic 1, which means that it is possible for a core to power up at a point that software doesn't expect. The result is that we generally go execute the kernel on a CPU that ought not to be running & the results can be unpredictable. Handle this case by stopping VPs that we don't expect to be running in mips_cps_boot_vpes() - with this change even if a core powers up it will do nothing useful & all VPs within it will stop running before they proceed to run general kernel code & do any damage. Ideally we would produce some sort of warning here, but given the stage of core bringup this happens at that would be non-trivial. We also will only hit this if a core starts up after being offlined via hotplug, and when that happens we will already produce a warning that the CPU didn't power down in cps_cpu_die() which seems sufficient. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16198/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-06-03 05:48:55 +08:00
/* Start any other VPs that ought to be running */
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
PTR_S ta2, CPC_CL_VC_RUN_OFS(t1)
MIPS: CPS: Handle spurious VP starts more gracefully On pre-r6 systems with the MT ASE the CPS SMP code included checks to halt the VPE running mips_cps_boot_vpes() if its bit in the struct core_boot_config vpe_mask field is clear. This was largely done in order to allow us to start arbitrary VPEs within a core despite the fact that hardware is typically configured to run only VPE0 after powering up a core. VPE0 would start the desired other VPEs, halt itself, and the fact that VPE0 started would be largely hidden & irrelevant. In MIPSr6 multithreading we have control over which VPs start executing when a core powers up via the cores CPC registers accessed remotely through the redirect block. For this reason the MIPSr6 multithreading path in mips_cps_boot_vpes() hasn't bothered up until now to handle halting the VP running it. However it is possible to power up cores entirely in hardware by using a pwr_up pin associated with the core. Unfortunately some systems wire this pin to a logic 1, which means that it is possible for a core to power up at a point that software doesn't expect. The result is that we generally go execute the kernel on a CPU that ought not to be running & the results can be unpredictable. Handle this case by stopping VPs that we don't expect to be running in mips_cps_boot_vpes() - with this change even if a core powers up it will do nothing useful & all VPs within it will stop running before they proceed to run general kernel code & do any damage. Ideally we would produce some sort of warning here, but given the stage of core bringup this happens at that would be non-trivial. We also will only hit this if a core starts up after being offlined via hotplug, and when that happens we will already produce a warning that the CPU didn't power down in cps_cpu_die() which seems sufficient. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16198/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-06-03 05:48:55 +08:00
/* Ensure this VP stops running if it shouldn't be */
not ta2
PTR_S ta2, CPC_CL_VC_STOP_OFS(t1)
MIPS: smp-cps: Support MIPSr6 Virtual Processors Introduce support for bringing up Virtual Processors in MIPSr6 systems as CPUs, much like their VPE parallel from the now-deprecated MT ASE. The existing mips_cps_boot_vpes function fits the MIPSr6 architecture pretty well - it can now simply write the mask of running VPs to the VC_RUN register, rather than looping through each & starting or stopping as appropriate as is done for VPEs from the MT ASE. Thus the VP support is in general an extension & simplification of the existing MT ASE VPE (aka SMVP) support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:33 +08:00
ehb
#elif defined(CONFIG_MIPS_MT)
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
.set push
.set mt
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
/* If the core doesn't support MT then return */
has_mt t0, 5f
/* Enter VPE configuration state */
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
dvpe
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA t1, 1f
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
jr.hb t1
nop
1: mfc0 t1, CP0_MVPCONTROL
ori t1, t1, MVPCONTROL_VPC
mtc0 t1, CP0_MVPCONTROL
ehb
/* Loop through each VPE */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
move t8, ta2
li ta1, 0
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Check whether the VPE should be running. If not, skip it */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
1: andi t0, ta2, 1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
beqz t0, 2f
nop
/* Operate on the appropriate TC */
mfc0 t0, CP0_VPECONTROL
ori t0, t0, VPECONTROL_TARGTC
xori t0, t0, VPECONTROL_TARGTC
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
or t0, t0, ta1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
mtc0 t0, CP0_VPECONTROL
ehb
/* Skip the VPE if its TC is not halted */
mftc0 t0, CP0_TCHALT
beqz t0, 2f
nop
/* Calculate a pointer to the VPEs struct vpe_boot_config */
li t0, VPEBOOTCFG_SIZE
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
mul t0, t0, ta1
addu t0, t0, ta3
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Set the TC restart PC */
lw t1, VPEBOOTCFG_PC(t0)
mttc0 t1, CP0_TCRESTART
/* Set the TC stack pointer */
lw t1, VPEBOOTCFG_SP(t0)
mttgpr t1, sp
/* Set the TC global pointer */
lw t1, VPEBOOTCFG_GP(t0)
mttgpr t1, gp
/* Copy config from this VPE */
mfc0 t0, CP0_CONFIG
mttc0 t0, CP0_CONFIG
MIPS: CPS: Copy EVA configuration when starting secondary VPs. When starting secondary VPEs which support EVA and the SegCtl registers, copy the memory segmentation configuration from the running VPE to ensure that all VPEs in the core have a consistent virtual memory map. The EVA configuration of secondary cores is dealt with when starting the core via the CM. Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13291/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-19 00:12:36 +08:00
/*
* Copy the EVA config from this VPE if the CPU supports it.
* CONFIG3 must exist to be running MT startup - just read it.
*/
mfc0 t0, CP0_CONFIG, 3
and t0, t0, MIPS_CONF3_SC
beqz t0, 3f
nop
mfc0 t0, CP0_SEGCTL0
mttc0 t0, CP0_SEGCTL0
mfc0 t0, CP0_SEGCTL1
mttc0 t0, CP0_SEGCTL1
mfc0 t0, CP0_SEGCTL2
mttc0 t0, CP0_SEGCTL2
3:
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Ensure no software interrupts are pending */
mttc0 zero, CP0_CAUSE
mttc0 zero, CP0_STATUS
/* Set TC active, not interrupt exempt */
mftc0 t0, CP0_TCSTATUS
li t1, ~TCSTATUS_IXMT
and t0, t0, t1
ori t0, t0, TCSTATUS_A
mttc0 t0, CP0_TCSTATUS
/* Clear the TC halt bit */
mttc0 zero, CP0_TCHALT
/* Set VPE active */
mftc0 t0, CP0_VPECONF0
ori t0, t0, VPECONF0_VPA
mttc0 t0, CP0_VPECONF0
/* Next VPE */
MIPS: kernel: cps-vec: Use ta0-ta3 pseudo-registers for 64-bit The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This breaks the build on 64-bit. As a result of which, use the pseudo-registers ta0-ta3 to make the code compatible with 64-bit. Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10589/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:31 +08:00
2: srl ta2, ta2, 1
addiu ta1, ta1, 1
bnez ta2, 1b
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
nop
/* Leave VPE configuration state */
mfc0 t1, CP0_MVPCONTROL
xori t1, t1, MVPCONTROL_VPC
mtc0 t1, CP0_MVPCONTROL
ehb
evpe
/* Check whether this VPE is meant to be running */
li t0, 1
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
sll t0, t0, a1
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
and t0, t0, t8
bnez t0, 2f
nop
/* This VPE should be offline, halt the TC */
li t0, TCHALT_H
mtc0 t0, CP0_TCHALT
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA t0, 1f
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
1: jr.hb t0
nop
2: .set pop
MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot vector if we're using MT for SMP. Thus switch the config symbol we ifdef against to CONFIG_MIPS_MT_SMP. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10867/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-08-06 06:42:38 +08:00
#endif /* CONFIG_MIPS_MT_SMP */
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
/* Return */
MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes The mips_cps_boot_vpes function previously included code to retrieve pointers to the core & VPE boot configuration structs. These structures were used both by mips_cps_boot_vpes and by its mips_cps_core_entry callsite. In preparation for skipping the call to mips_cps_boot_vpes on some invocations of mips_cps_core_entry, pull the calculation of those pointers out into a separate function such that it can continue to be shared. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12337/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:31 +08:00
5: jr ra
MIPS: smp-cps: rework core/VPE initialisation When hotplug and/or a powered down idle state are supported cases will arise where a non-zero VPE must be brought online without VPE 0, and it where multiple VPEs must be onlined simultaneously. This patch prepares for that by: - Splitting struct boot_config into core & VPE boot config structures, allocated one per core or VPE respectively. This allows for multiple VPEs to be onlined simultaneously without clobbering each others configuration. - Indicating which VPEs should be online within a core at any given time using a bitmap. This allows multiple VPEs to be brought online simultaneously and also indicates to VPE 0 whether it should halt after starting any non-zero VPEs that should be online within the core. For example if all VPEs within a core are offlined via hotplug and the user onlines the second VPE within that core: 1) The core will be powered up. 2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to initialise the core. 3) VPE 0 will start VPE 1 because its bit is set in the cores bitmap. 4) VPE 0 will halt itself because its bit is clear in the cores bitmap. - Moving the core & VPE initialisation to assembly code which does not make any use of the stack. This is because if a non-zero VPE is to be brought online in a powered down core then when VPE 0 of that core runs it may not have a valid stack, and even if it did then it's messy to run through parts of generic kernel code on VPE 0 before starting the correct VPE. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 19:04:27 +08:00
nop
END(mips_cps_boot_vpes)
MIPS: pm-cps: add PM state entry code for CPS systems This patch adds code to generate entry & exit code for various low power states available on systems based around the MIPS Coherent Processing System architecture (ie. those with a Coherence Manager, Global Interrupt Controller & for >=CM2 a Cluster Power Controller). States supported are: - Non-coherent wait. This state first leaves the coherent domain and then executes a regular MIPS wait instruction. Power savings are found from the elimination of coherency interventions between the core and any other coherent requestors in the system. - Clock gated. This state leaves the coherent domain and then gates the clock input to the core. This removes all dynamic power from the core but leaves the core at the mercy of another to restart its clock. Register state is preserved, but the core can not service interrupts whilst its clock is gated. - Power gated. This deepest state removes all power input to the core. All register state is lost and the core will restart execution from its BEV when another core powers it back up. Because register state is lost this state requires cooperation with the CONFIG_MIPS_CPS SMP implementation in order for the core to exit the state successfully. The code will detect which states are available on the current system during boot & generate the entry/exit code for those states. This will be used by cpuidle & hotplug implementations. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 18:00:56 +08:00
MIPS: smp-cps: Pull cache init into a function In preparation for further modifications to mips_cps_core_entry, pull the L1 cache initialisation out into a separate function. This both makes the code in mips_cps_core_entry read more clearly, particularly when modifying it, and shortens it which will become important as code is added that needs to continue to fit within the reset vector. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12336/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-03 11:15:30 +08:00
LEAF(mips_cps_cache_init)
/*
* Clear the bits used to index the caches. Note that the architecture
* dictates that writing to any of TagLo or TagHi selects 0 or 2 should
* be valid for all MIPS32 CPUs, even those for which said writes are
* unnecessary.
*/
mtc0 zero, CP0_TAGLO, 0
mtc0 zero, CP0_TAGHI, 0
mtc0 zero, CP0_TAGLO, 2
mtc0 zero, CP0_TAGHI, 2
ehb
/* Primary cache configuration is indicated by Config1 */
mfc0 v0, CP0_CONFIG, 1
/* Detect I-cache line size */
_EXT t0, v0, MIPS_CONF1_IL_SHF, MIPS_CONF1_IL_SZ
beqz t0, icache_done
li t1, 2
sllv t0, t1, t0
/* Detect I-cache size */
_EXT t1, v0, MIPS_CONF1_IS_SHF, MIPS_CONF1_IS_SZ
xori t2, t1, 0x7
beqz t2, 1f
li t3, 32
addiu t1, t1, 1
sllv t1, t3, t1
1: /* At this point t1 == I-cache sets per way */
_EXT t2, v0, MIPS_CONF1_IA_SHF, MIPS_CONF1_IA_SZ
addiu t2, t2, 1
mul t1, t1, t0
mul t1, t1, t2
li a0, CKSEG0
PTR_ADD a1, a0, t1
1: cache Index_Store_Tag_I, 0(a0)
PTR_ADD a0, a0, t0
bne a0, a1, 1b
nop
icache_done:
/* Detect D-cache line size */
_EXT t0, v0, MIPS_CONF1_DL_SHF, MIPS_CONF1_DL_SZ
beqz t0, dcache_done
li t1, 2
sllv t0, t1, t0
/* Detect D-cache size */
_EXT t1, v0, MIPS_CONF1_DS_SHF, MIPS_CONF1_DS_SZ
xori t2, t1, 0x7
beqz t2, 1f
li t3, 32
addiu t1, t1, 1
sllv t1, t3, t1
1: /* At this point t1 == D-cache sets per way */
_EXT t2, v0, MIPS_CONF1_DA_SHF, MIPS_CONF1_DA_SZ
addiu t2, t2, 1
mul t1, t1, t0
mul t1, t1, t2
li a0, CKSEG0
PTR_ADDU a1, a0, t1
PTR_SUBU a1, a1, t0
1: cache Index_Store_Tag_D, 0(a0)
bne a0, a1, 1b
PTR_ADD a0, a0, t0
dcache_done:
jr ra
nop
END(mips_cps_cache_init)
MIPS: pm-cps: add PM state entry code for CPS systems This patch adds code to generate entry & exit code for various low power states available on systems based around the MIPS Coherent Processing System architecture (ie. those with a Coherence Manager, Global Interrupt Controller & for >=CM2 a Cluster Power Controller). States supported are: - Non-coherent wait. This state first leaves the coherent domain and then executes a regular MIPS wait instruction. Power savings are found from the elimination of coherency interventions between the core and any other coherent requestors in the system. - Clock gated. This state leaves the coherent domain and then gates the clock input to the core. This removes all dynamic power from the core but leaves the core at the mercy of another to restart its clock. Register state is preserved, but the core can not service interrupts whilst its clock is gated. - Power gated. This deepest state removes all power input to the core. All register state is lost and the core will restart execution from its BEV when another core powers it back up. Because register state is lost this state requires cooperation with the CONFIG_MIPS_CPS SMP implementation in order for the core to exit the state successfully. The code will detect which states are available on the current system during boot & generate the entry/exit code for those states. This will be used by cpuidle & hotplug implementations. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 18:00:56 +08:00
#if defined(CONFIG_MIPS_CPS_PM) && defined(CONFIG_CPU_PM)
/* Calculate a pointer to this CPUs struct mips_static_suspend_state */
.macro psstate dest
.set push
.set noat
lw $1, TI_CPU(gp)
sll $1, $1, LONGLOG
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA \dest, __per_cpu_offset
MIPS: pm-cps: add PM state entry code for CPS systems This patch adds code to generate entry & exit code for various low power states available on systems based around the MIPS Coherent Processing System architecture (ie. those with a Coherence Manager, Global Interrupt Controller & for >=CM2 a Cluster Power Controller). States supported are: - Non-coherent wait. This state first leaves the coherent domain and then executes a regular MIPS wait instruction. Power savings are found from the elimination of coherency interventions between the core and any other coherent requestors in the system. - Clock gated. This state leaves the coherent domain and then gates the clock input to the core. This removes all dynamic power from the core but leaves the core at the mercy of another to restart its clock. Register state is preserved, but the core can not service interrupts whilst its clock is gated. - Power gated. This deepest state removes all power input to the core. All register state is lost and the core will restart execution from its BEV when another core powers it back up. Because register state is lost this state requires cooperation with the CONFIG_MIPS_CPS SMP implementation in order for the core to exit the state successfully. The code will detect which states are available on the current system during boot & generate the entry/exit code for those states. This will be used by cpuidle & hotplug implementations. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 18:00:56 +08:00
addu $1, $1, \dest
lw $1, 0($1)
MIPS: kernel: cps-vec: Replace 'la' macro with PTR_LA The PTR_LA macro will pick the correct "la" or "dla" macro to load an address to a register. This gets rids of the following warnings (and others) when building a 64-bit CPS kernel: arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address [...] Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10587/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-01 16:13:29 +08:00
PTR_LA \dest, cps_cpu_state
MIPS: pm-cps: add PM state entry code for CPS systems This patch adds code to generate entry & exit code for various low power states available on systems based around the MIPS Coherent Processing System architecture (ie. those with a Coherence Manager, Global Interrupt Controller & for >=CM2 a Cluster Power Controller). States supported are: - Non-coherent wait. This state first leaves the coherent domain and then executes a regular MIPS wait instruction. Power savings are found from the elimination of coherency interventions between the core and any other coherent requestors in the system. - Clock gated. This state leaves the coherent domain and then gates the clock input to the core. This removes all dynamic power from the core but leaves the core at the mercy of another to restart its clock. Register state is preserved, but the core can not service interrupts whilst its clock is gated. - Power gated. This deepest state removes all power input to the core. All register state is lost and the core will restart execution from its BEV when another core powers it back up. Because register state is lost this state requires cooperation with the CONFIG_MIPS_CPS SMP implementation in order for the core to exit the state successfully. The code will detect which states are available on the current system during boot & generate the entry/exit code for those states. This will be used by cpuidle & hotplug implementations. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
2014-04-14 18:00:56 +08:00
addu \dest, \dest, $1
.set pop
.endm
LEAF(mips_cps_pm_save)
/* Save CPU state */
SUSPEND_SAVE_REGS
psstate t1
SUSPEND_SAVE_STATIC
jr v0
nop
END(mips_cps_pm_save)
LEAF(mips_cps_pm_restore)
/* Restore CPU state */
psstate t1
RESUME_RESTORE_STATIC
RESUME_RESTORE_REGS_RETURN
END(mips_cps_pm_restore)
#endif /* CONFIG_MIPS_CPS_PM && CONFIG_CPU_PM */