Skip to content
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

Closed

Conversation

luchnikov
Copy link
Collaborator

@luchnikov luchnikov commented Nov 27, 2023

Allow RISCV SOC implementation to define its own custom:

  • IPI implementation (e.g. Andes usage of PLIC for IPI)
  • per-core init (e.g. per-core PMA implementation)

Signed-off-by: Maxim Adelman [email protected]

@luchnikov luchnikov self-assigned this Nov 27, 2023
@zephyrbot zephyrbot added the area: RISCV RISCV Architecture (32-bit & 64-bit) label Nov 27, 2023
cfriedt
cfriedt previously approved these changes Nov 27, 2023
Copy link
Member

@cfriedt cfriedt left a 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

npitre
npitre previously approved these changes Nov 27, 2023
@cfriedt cfriedt assigned fkokosinski and unassigned luchnikov Nov 27, 2023
fkokosinski
fkokosinski previously approved these changes Nov 28, 2023
Copy link
Member

@ycsin ycsin left a 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?

arch/riscv/Kconfig Outdated Show resolved Hide resolved
arch/riscv/core/smp.c Outdated Show resolved Hide resolved
@luchnikov
Copy link
Collaborator Author

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?

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

@luchnikov luchnikov changed the title arch: riscv: Add support for custom IPI implementation arch: riscv: Add support for custom SOC IPI, per-core init Nov 29, 2023
@nashif
Copy link
Member

nashif commented Nov 29, 2023

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?

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

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.

@ycsin
Copy link
Member

ycsin commented Sep 17, 2024

Toggled to trigger CI

@ycsin ycsin mentioned this pull request Sep 17, 2024
@ycsin
Copy link
Member

ycsin commented Sep 17, 2024

Does this still need to go through an architecture review?

npitre
npitre previously approved these changes Sep 17, 2024
Copy link
Collaborator

@npitre npitre left a 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.

Comment on lines 85 to 86
/* IPI */
#if defined(CONFIG_SMP) && !defined(CONFIG_RISCV_SOC_HAS_CUSTOM_SMP_IPI)
Copy link
Member

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

Suggested change
/* 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 Show resolved Hide resolved
@@ -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();
Copy link
Member

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

Copy link
Member

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

@ycsin
Copy link
Member

ycsin commented Sep 17, 2024

For context, this PR essentially allows us to do what's being done with esp32 in esp32-mp.c. The current RISC-V IPI implementation was based on CLINT, but not all RISC-V SoC can implement their IPI through CLINT.

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.

mbox: mbox-controller@e6400000 {
compatible = "andestech,plic-sw";
reg = <0xe6400000 0x00400000>;
#mbox-cells = <1>;
channel-max = <30>;
status = "okay";
};

static int mbox_andes_init(const struct device *dev)
{
/* Setup IRQ handler for PLIC SW driver */
IRQ_CONNECT(RISCV_IRQ_MSOFT, 1,
andes_plic_sw_irq_handler, DEVICE_DT_INST_GET(0), 0);
#ifndef CONFIG_SMP
irq_enable(RISCV_IRQ_MSOFT);
#endif
return 0;
}

I guess the architecture-review is probably not required since this is not something alien, removing the tag for now

Copy link
Member

@ycsin ycsin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ycsin ycsin removed the Architecture Review Discussion in the Architecture WG required label Sep 17, 2024
@@ -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
Copy link
Member

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?

Copy link
Collaborator Author

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

Copy link
Member

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

@npitre
Copy link
Collaborator

npitre commented Sep 17, 2024 via email

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]>
@@ -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();
Copy link
Member

@ycsin ycsin Sep 19, 2024

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

Copy link

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.

@github-actions github-actions bot added the Stale label Nov 19, 2024
@ycsin
Copy link
Member

ycsin commented Nov 19, 2024

This is now done in #78496 + #81256

@luchnikov luchnikov closed this Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Kernel area: RISCV RISCV Architecture (32-bit & 64-bit) Stale
Projects
Status: Done
Status: Done
Development

Successfully merging this pull request may close these issues.

8 participants