pussuw commented on PR #5985:
URL: https://github.com/apache/incubator-nuttx/pull/5985#issuecomment-1088927143
> > @xiaoxiang781216 can you take a look when you have time. I marked this
as draft as it does not compile yet / needs fixing but the basic structure
should be in place.
> > The question I have: Do you think it's appropriate for me to force other
RISC-V targets that use an IRQ stack to use the percpu structure, or should I
wrap the IRQ stack getter, so that it can e.g.:
> > ```
> > uintptr_t riscv_irqstack(void)
> > {
> > #if PERCPU_COMPILED
> > return riscv_percpu_get_irqstack
> > #else
> > return (uintptr_t) &g_intstacktop;
> > #endif
> > }
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Or something along those lines ?
>
> but all arch call the chip specific setintstack macro setup the interrupt
stack. It work very well, do you have any problem with it?
I'm not sure what this "setintstack" macro does, can you provide and example
of what you mean ?
For RISC-V, riscv_exception_common.S defines 1 interrupt stack per CPU and
the location is calculated there.
` .skip (((CONFIG_ARCH_INTERRUPTSTACK * IRQ_NSTACKS) + 8) & ~15)`
My idea was to pre-calculate the location of the IRQ stack per hart and use
the riscv_percpu.c structure and [m/]scratch register for this. However, for it
to work, you need to call riscv_percpu_add_hart to register the hart there.
Only MPFS does this now.
My question was, is it OK to force registering for other RISC-V targets too
or should I do the wrapper.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
