[PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"

[Sean Anderson]

On 9/11/20 3:38 AM, Bin Meng wrote:
> Hi Sean,
> 
> On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson <seanga2 at 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 <seanga2 at 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

[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 <seanga2 at 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 <seanga2 at gmail.com>
>     Reviewed-by: Rick Chen <rick at andestech.com>
> 
>>         csrs    MODE_PREFIX(ie), t0
>>  #endif
>>

--Sean