-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
arch: riscv: Add support for custom SOC IPI, per-core init #65824
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - this is similar to what was done for sys_io in #60771
d82ffcb
to
a468172
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally *_SOC_HAS_CUSTOM_*
would turn these into default implementation and allows devs to implement their own z_soc_*
APIs to overwrite, are we breaking that convention here?
4594cb5
a468172
to
4594cb5
Compare
This one encompasses a number of SOC-specific overrides which are not easily encompassed with conditional z_soc_*. I added more details to the Kconfig |
4594cb5
to
486192a
Compare
hmm, this is basically removing most of the SMP implementation out, even the SYS_INIT()! It is not really clear what needs to be implemented because this is just disabling a bunch of calls and interfaces, that does not look right. |
Toggled to trigger CI |
Does this still need to go through an architecture review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me. My preference would be made of an overridable weak empty
stub to cut down on all the kconfig noise but current trend is to go the
noisy way.
arch/riscv/core/smp.c
Outdated
/* IPI */ | ||
#if defined(CONFIG_SMP) && !defined(CONFIG_RISCV_SOC_HAS_CUSTOM_SMP_IPI) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit [1/2]: I think the following makes it clearer that this portion of code is for SMP
, and within it, there's a portion of code that shouldn't be compiled when CONFIG_RISCV_SOC_HAS_CUSTOM_SMP_IPI=y
/* IPI */ | |
#if defined(CONFIG_SMP) && !defined(CONFIG_RISCV_SOC_HAS_CUSTOM_SMP_IPI) | |
#ifdef CONFIG_SMP | |
#ifndef CONFIG_RISCV_SOC_HAS_CUSTOM_SMP_IPI |
arch/riscv/core/smp.c
Outdated
@@ -74,11 +75,15 @@ void arch_secondary_cpu_init(int hartid) | |||
#endif | |||
#ifdef CONFIG_SMP | |||
irq_enable(RISCV_IRQ_MSOFT); | |||
#endif | |||
#ifdef CONFIG_RISCV_SOC_HAS_CUSTOM_PER_CORE_INIT | |||
z_soc_per_core_init(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there should be an entry for this in arch_kernel_init()
similar to the z_riscv_pmp_init()
, so that the function is ran by the main core as well - https://github.com/zephyrproject-rtos/zephyr/blob/main/arch/riscv/include/kernel_arch_func.h#L54
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably should be in a separate commit as well
For context, this PR essentially allows us to do what's being done with esp32 in For example, the Andes AE350 SoC's MSIP is connected to the plic-sw, and IPI has to be routed via the plic-sw instead. zephyr/dts/riscv/andes/andes_v5_ae350.dtsi Lines 182 to 188 in 6194159
zephyr/drivers/mbox/mbox_andes_plic_sw.c Lines 200 to 210 in 6194159
I guess the architecture-review is probably not required since this is not something alien, removing the tag for now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -119,6 +119,22 @@ config RISCV_SOC_HAS_CUSTOM_SYS_IO | |||
the RISC-V SoC needs to do something different and more than reading and | |||
writing the registers. | |||
|
|||
config RISCV_SOC_HAS_CUSTOM_SMP_IPI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current implementation is using CLINT, I wonder if we should name this RISCV_SOC_SMP_IPI_CLINT
instead to pave the way for the intro of RISCV_SOC_SMP_IPI_PLIC
in the future, so that it is a choice between CLINT & PLIC, instead of default vs custom?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would make sense if we upstream our implementation as the default PLIC implementation, otherwise it would be unclear as to what the behavior would be if RISCV_SOC_SMP_IPI_CLINT was not set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be fine as this is an arch-level Kconfig, would like to hear from @fkokosinski @npitre and others as well
Or even `RISCV_SMP_IPI_CLINT`.
|
7134bbd
7134bbd
to
abce116
Compare
abce116
to
ec45018
Compare
Allow RISCV implementation to define its own custom IPI implementation (e.g. Andes usage of PLIC for IPI) Signed-off-by: Maxim Adelman <[email protected]> Update arch/riscv/core/smp.c Co-authored-by: Yong Cong Sin <[email protected]>
ec45018
to
ce32a59
Compare
@@ -74,12 +76,17 @@ void arch_secondary_cpu_init(int hartid) | |||
#endif | |||
#ifdef CONFIG_SMP | |||
irq_enable(RISCV_IRQ_MSOFT); | |||
#endif | |||
#ifdef CONFIG_SOC_SMP_PER_CORE_INIT_HOOK | |||
soc_smp_per_core_init_hook(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should run this for the main core, probably by adding an invocation of this in arch_kernel_init()
similar to the z_riscv_pmp_init()
, so that the function is ran by the main core as well, otherwise this would be a per_secondary_core_init_hook
I also think that it would be nice to generalize this new hook as soc_per_core_init_hook()
so that it is not SMP-specific. Any soc that would like some additional core initialization code can use this hook
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
Allow RISCV SOC implementation to define its own custom:
Signed-off-by: Maxim Adelman [email protected]