Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-11 22:03:15 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/riscv/lib/smp.c

129 lines
2.7 KiB
C
Raw Normal View History

riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2019 Fraunhofer AISEC,
* Lukas Auer <lukas.auer@aisec.fraunhofer.de>
*/
#include <common.h>
common: Move ARM cache operations out of common.h These functions are CPU-related and do not use driver model. Move them to cpu_func.h Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-11-14 19:57:39 +00:00
#include <cpu_func.h>
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
#include <dm.h>
#include <asm/barrier.h>
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-10-31 03:38:53 +00:00
#include <asm/global_data.h>
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
#include <asm/smp.h>
DECLARE_GLOBAL_DATA_PTR;
riscv: add option to wait for ack from secondary harts in smp functions Add a wait option to smp_call_function() to wait for the secondary harts to acknowledge the call-function request. The request is considered to be acknowledged once each secondary hart has cleared the corresponding IPI. As part of the call-function request, the secondary harts invalidate the instruction cache after clearing the IPI. This adds a delay between acknowledgment (clear IPI) and fulfillment (call function) of the request. We want to use the acknowledgment to be able to judge when the request has been completed. Remove the delay by clearing the IPI after cache invalidation and just before calling the function from the request. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Rick Chen <rick@andestech.com> Tested-by: Rick Chen <rick@andestech.com> Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-08 22:28:51 +00:00
static int send_ipi_many(struct ipi_data *ipi, int wait)
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
{
ofnode node, cpus;
u32 reg;
riscv: add option to wait for ack from secondary harts in smp functions Add a wait option to smp_call_function() to wait for the secondary harts to acknowledge the call-function request. The request is considered to be acknowledged once each secondary hart has cleared the corresponding IPI. As part of the call-function request, the secondary harts invalidate the instruction cache after clearing the IPI. This adds a delay between acknowledgment (clear IPI) and fulfillment (call function) of the request. We want to use the acknowledgment to be able to judge when the request has been completed. Remove the delay by clearing the IPI after cache invalidation and just before calling the function from the request. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Rick Chen <rick@andestech.com> Tested-by: Rick Chen <rick@andestech.com> Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-08 22:28:51 +00:00
int ret, pending;
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
cpus = ofnode_path("/cpus");
if (!ofnode_valid(cpus)) {
pr_err("Can't find cpus node!\n");
return -EINVAL;
}
ofnode_for_each_subnode(node, cpus) {
/* skip if hart is marked as not available in the device tree */
dm: core: Drop ofnode_is_available() This function is also available as ofnode_is_enabled(), so use that instead. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-09-07 02:27:17 +00:00
if (!ofnode_is_enabled(node))
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
continue;
/* read hart ID of CPU */
ret = ofnode_read_u32(node, "reg", &reg);
if (ret)
continue;
/* skip if it is the hart we are running on */
if (reg == gd->arch.boot_hart)
continue;
if (reg >= CONFIG_NR_CPUS) {
pr_err("Hart ID %d is out of range, increase CONFIG_NR_CPUS\n",
reg);
continue;
}
spl: introduce SPL_XIP to config U-Boot and SPL don't necessary share the same location, so we might end with U-Boot SPL in read-only memory (XIP) and U-Boot in read-write memory. In case of non XIP boot mode, we rely on such variables as "hart_lottery" and "available_harts_lock" which we use as atomics. The problem is that CONFIG_XIP also propagate to main U-Boot, not only SPL, so we need CONFIG_SPL_XIP to distinguish SPL XIP from other XIP modes. This adds an option special for SPL to behave it in XIP manner and we don't use hart_lottery and available_harts_lock, during start proccess. Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Reviewed-by: Rick Chen <rick@andestech.com>
2022-09-02 08:47:39 +00:00
#if !CONFIG_IS_ENABLED(XIP)
riscv: Introduce AVAILABLE_HARTS In SMP all harts will register themself in available_hart during start up. Then main hart will send IPI to other harts according to this variables. But this mechanism may not guarantee that all other harts can jump to next stage. When main hart is sending IPI to other hart according to available_harts, but other harts maybe still not finish the registration. Then the SMP booting will miss some harts finally. So let it become an option and it will be enabled by default. Please refer to the discussion: https://www.mail-archive.com/u-boot@lists.denx.de/msg449997.html Signed-off-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2022-09-21 06:34:54 +00:00
#ifdef CONFIG_AVAILABLE_HARTS
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
/* skip if hart is not available */
if (!(gd->arch.available_harts & (1 << reg)))
continue;
riscv: Introduce AVAILABLE_HARTS In SMP all harts will register themself in available_hart during start up. Then main hart will send IPI to other harts according to this variables. But this mechanism may not guarantee that all other harts can jump to next stage. When main hart is sending IPI to other hart according to available_harts, but other harts maybe still not finish the registration. Then the SMP booting will miss some harts finally. So let it become an option and it will be enabled by default. Please refer to the discussion: https://www.mail-archive.com/u-boot@lists.denx.de/msg449997.html Signed-off-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2022-09-21 06:34:54 +00:00
#endif
riscv: Introduce CONFIG_XIP to support booting from flash When U-Boot boots from flash, during the boot process, hart_lottery and available_harts_lock variable addresses point to flash which is not writable. This causes boot failures on AE350. Introduce a config option CONFIG_XIP to support such configuration. Signed-off-by: Rick Chen <rick@andestech.com> Cc: Greentime Hu <greentime@andestech.com> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-30 05:49:33 +00:00
#endif
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
gd->arch.ipi[reg].addr = ipi->addr;
gd->arch.ipi[reg].arg0 = ipi->arg0;
gd->arch.ipi[reg].arg1 = ipi->arg1;
riscv: Use a valid bit to ignore already-pending IPIs Some IPIs may already be pending when U-Boot is started. This could be a problem if a secondary hart tries to handle an IPI before the boot hart has initialized the IPI device. To be specific, the Kendryte K210 ROM-based bootloader does not clear IPIs before passing control to U-Boot. Without this patch, the secondary hart jumps to address 0x0 as soon as it enters secondary_hart_loop, and then hangs in its trap handler. This commit introduces a valid bit so secondary harts know when and IPI originates from U-Boot, and it is safe to use the IPI API. The valid bit is initialized to 0 by board_init_f_init_reserve. Before this, secondary harts wait in wait_for_gd_init. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
2020-09-21 11:51:37 +00:00
/*
* Ensure valid only becomes set when the IPI parameters are
* set. An IPI may already be pending on other harts, so we
* need a way to signal that the IPI device has been
* initialized, and that it is ok to call the function.
*/
__smp_store_release(&gd->arch.ipi[reg].valid, 1);
riscv: Match memory barriers between send_ipi_many and handle_ipi Without a matching barrier on the write side, the barrier in handle_ipi does nothing. It was entirely possible for the boot hart to write to addr, arg0, and arg1 *after* sending the IPI, because there was no barrier on the sending side. Fixes: 90ae281437 ("riscv: add option to wait for ack from secondary harts in smp functions") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
2020-09-21 11:51:36 +00:00
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
ret = riscv_send_ipi(reg);
if (ret) {
pr_err("Cannot send IPI to hart %d\n", reg);
return ret;
}
riscv: add option to wait for ack from secondary harts in smp functions Add a wait option to smp_call_function() to wait for the secondary harts to acknowledge the call-function request. The request is considered to be acknowledged once each secondary hart has cleared the corresponding IPI. As part of the call-function request, the secondary harts invalidate the instruction cache after clearing the IPI. This adds a delay between acknowledgment (clear IPI) and fulfillment (call function) of the request. We want to use the acknowledgment to be able to judge when the request has been completed. Remove the delay by clearing the IPI after cache invalidation and just before calling the function from the request. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Rick Chen <rick@andestech.com> Tested-by: Rick Chen <rick@andestech.com> Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-08 22:28:51 +00:00
if (wait) {
pending = 1;
while (pending) {
ret = riscv_get_ipi(reg, &pending);
if (ret)
return ret;
}
}
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
}
return 0;
}
void handle_ipi(ulong hart)
{
int ret;
void (*smp_function)(ulong hart, ulong arg0, ulong arg1);
if (hart >= CONFIG_NR_CPUS)
return;
riscv: Use a valid bit to ignore already-pending IPIs Some IPIs may already be pending when U-Boot is started. This could be a problem if a secondary hart tries to handle an IPI before the boot hart has initialized the IPI device. To be specific, the Kendryte K210 ROM-based bootloader does not clear IPIs before passing control to U-Boot. Without this patch, the secondary hart jumps to address 0x0 as soon as it enters secondary_hart_loop, and then hangs in its trap handler. This commit introduces a valid bit so secondary harts know when and IPI originates from U-Boot, and it is safe to use the IPI API. The valid bit is initialized to 0 by board_init_f_init_reserve. Before this, secondary harts wait in wait_for_gd_init. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
2020-09-21 11:51:37 +00:00
/*
* If valid is not set, then U-Boot has not requested the IPI. The
* IPI device may not be initialized, so all we can do is wait for
* U-Boot to initialize it and send an IPI
*/
if (!__smp_load_acquire(&gd->arch.ipi[hart].valid))
return;
riscv: add option to wait for ack from secondary harts in smp functions Add a wait option to smp_call_function() to wait for the secondary harts to acknowledge the call-function request. The request is considered to be acknowledged once each secondary hart has cleared the corresponding IPI. As part of the call-function request, the secondary harts invalidate the instruction cache after clearing the IPI. This adds a delay between acknowledgment (clear IPI) and fulfillment (call function) of the request. We want to use the acknowledgment to be able to judge when the request has been completed. Remove the delay by clearing the IPI after cache invalidation and just before calling the function from the request. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Rick Chen <rick@andestech.com> Tested-by: Rick Chen <rick@andestech.com> Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-08 22:28:51 +00:00
smp_function = (void (*)(ulong, ulong, ulong))gd->arch.ipi[hart].addr;
invalidate_icache_all();
/*
* Clear the IPI to acknowledge the request before jumping to the
* requested function.
*/
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
ret = riscv_clear_ipi(hart);
if (ret) {
riscv: Clean up IPI initialization code The previous IPI code initialized the device whenever the first call was made to a riscv_*_ipi function. This made it difficult to determine when the IPI device was initialized. This patch introduces a new function riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions should be called. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-06-24 10:41:18 +00:00
pr_err("Cannot clear IPI of hart %ld (error %d)\n", hart, ret);
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
return;
}
smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1);
}
riscv: add option to wait for ack from secondary harts in smp functions Add a wait option to smp_call_function() to wait for the secondary harts to acknowledge the call-function request. The request is considered to be acknowledged once each secondary hart has cleared the corresponding IPI. As part of the call-function request, the secondary harts invalidate the instruction cache after clearing the IPI. This adds a delay between acknowledgment (clear IPI) and fulfillment (call function) of the request. We want to use the acknowledgment to be able to judge when the request has been completed. Remove the delay by clearing the IPI after cache invalidation and just before calling the function from the request. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Rick Chen <rick@andestech.com> Tested-by: Rick Chen <rick@andestech.com> Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-12-08 22:28:51 +00:00
int smp_call_function(ulong addr, ulong arg0, ulong arg1, int wait)
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
{
riscv: Clean up IPI initialization code The previous IPI code initialized the device whenever the first call was made to a riscv_*_ipi function. This made it difficult to determine when the IPI device was initialized. This patch introduces a new function riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions should be called. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-06-24 10:41:18 +00:00
struct ipi_data ipi = {
.addr = addr,
.arg0 = arg0,
.arg1 = arg1,
};
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
riscv: Clean up IPI initialization code The previous IPI code initialized the device whenever the first call was made to a riscv_*_ipi function. This made it difficult to determine when the IPI device was initialized. This patch introduces a new function riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions should be called. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-06-24 10:41:18 +00:00
return send_ipi_many(&ipi, wait);
riscv: add infrastructure for calling functions on other harts Harts on RISC-V boot independently, U-Boot is responsible for managing them. Functions are called on other harts with smp_call_function(), which sends inter-processor interrupts (IPIs) to all other available harts. Available harts are those marked as available in the device tree and present in the available_harts mask stored in global data. The available_harts mask is used to register all harts that have entered U-Boot. Functions are specified with their address and two function arguments (argument 2 and 3). The first function argument is always the hart ID of the hart calling the function. On the other harts, the IPI interrupt handler handle_ipi() must be called on software interrupts to handle the request and call the specified function. Functions are stored in the ipi_data data structure. Every hart has its own data structure in global data. While this is not required at the moment (all harts are expected to boot Linux), this does allow future expansion, where other harts may be used for monitoring or other tasks. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-03-17 18:28:32 +00:00
}
Reference in a new issue Copy permalink