On Fri, Sep 11, 2020 at 6:22 PM Sean Anderson <sean...@gmail.com> wrote: > > On 9/11/20 3:38 AM, Bin Meng wrote: > > Hi Sean, > > > > On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson <sean...@gmail.com> wrote: > >> > >> Clearing MIP doesn't do anything. Whoops. The following commits should > > > > Which following commits? > > > >> tackle this problem in a more robust manner. > >> > >> This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. > >> > >> Signed-off-by: Sean Anderson <sean...@gmail.com> > >> --- > >> > >> arch/riscv/cpu/start.S | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > >> index bf9fdf369b..e3222b1ea7 100644 > >> --- a/arch/riscv/cpu/start.S > >> +++ b/arch/riscv/cpu/start.S > >> @@ -65,8 +65,6 @@ _start: > >> #else > >> li t0, SIE_SSIE > >> #endif > >> - /* Clear any pending IPIs */ > >> - csrc MODE_PREFIX(ip), t0 > > > > Did you mean the clearing MIP.MSIP actually does nothing, but the > > following commit is the correct fix? > > Yes, but we also need
Is MIP.MSIP read-only on K210? > > [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function > > so the secondary harts know not to take any IPIs not raised by U-Boot. > > > > > commit 40686c394e533fec765fe237936e353c84e73fff > > Author: Sean Anderson <sean...@gmail.com> > > Date: Wed Jun 24 06:41:18 2020 -0400 > > > > 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 <sean...@gmail.com> > > Reviewed-by: Rick Chen <r...@andestech.com> > > > >> csrs MODE_PREFIX(ie), t0 > >> #endif Regards, Bin