Re: Question about edge-triggered interrupt

[LIU Zhiwei]

On 2021/3/12 4:45, Alistair Francis wrote:
> On Thu, Mar 11, 2021 at 11:21 AM LIU Zhiwei<zhiwei_liu@c-sky.com>  wrote:
> > On 2021/3/11 21:17, Peter Maydell wrote:
> > > On Thu, 11 Mar 2021 at 12:59, LIU Zhiwei<zhiwei_liu@c-sky.com>  wrote:
> > > >   From the specification, I find that software will not clean the pending bit 
> > > > on interrupt controller via a register write.
> > > >
> > > > "When a vectored interrupt is selected and serviced, the hardware will 
> > > > automatically clear the
> > > >
> > > > corresponding pending bit in edge-triggered mode. In this case, software does 
> > > > not need to clear
> > > >
> > > > pending bit at all in the service routine."
> > > >
> > > > Hardware can always select a pending interrupt as it is cycle-driven. But QEMU 
> > > > is event-driven.
> > > > I don't know if there is a chance to select other pending interrupts after 
> > > > serving the selected interrupt.
> > > Something must change that the hardware (and thus the model) can use to
> > > determine that it needs to do something else. The interrupt controller
> > > must be able to tell when the interrupt is "selected and serviced"
> > > somehow.
> > That's a case I can't understand.
> >
> > 1.  An device causes an edge-triggered interrupt A.
> > 2.  The interrupt controller sample the interrupt A, and setting pending
> > bit for A.
> > 3.  The interrupt controller select the interrupt  A to CPU and clean
> > the pending bit for A(according to the specification).

> I'm not a CLIC expert but from what I can tell I think the interrupt
> is only cleared after being read.
>
> The key lines in the spec are:
>
> "When a vectored interrupt is selected and serviced, the hardware will
> automatically clear the corresponding pending bit in edge-triggered
> mode."
>
> and
>
> "The xnxti CSR can be used by software to service the next horizontal
> interrupt..."
>
> The C-ABI code 
> (https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#81-c-abi-trampoline-code)
> seems to say something similar
>
>
>      csrrsi a0, mnxti, MIE   # Get highest current interrupt and enable
> interrupts.
>                              # Will return original interrupt if no
> others appear. (6)
Hi Alistair,

Thanks for your reply.

It is right if the interrupt routine really takes the C-ABI code. 
However, there may
be many other implementations for interrupt routine.

As the pending bit has been automatically cleaned by hardware, it will 
be unnecessary to
read xnxti in interrupt routine or access other registers to clean it, 
e.g. my RTOS case
never reads xnxti.

Zhiwei
> Does that sound right?
>
> Alistair
>
>
> > 4.  CPU start to execute the A's service routine.
> > 5.  Another device causes interrupt B.
> > 6.  The interrupt controller sample the interrupt B, and setting pending
> > bit for B.
> > 7.  As B's priority is lower than A, it can't preempt  A's service routine.
> > 8.  A's service routine return.
> > 9. No other interrupt comes after B.
> >
> > After the sequence, B is pending in interrupt controller, and has no
> > chance to be selected by interrupt controller.
> > A's service routine will neither write interrupt controller's register
> > nor device's register.
> >
> > In my RTOS case, the interrupt A here is really a software interrupt.
> > Just for clarity here.
> >
> > Thanks for sharing your ideas.
> >
> > Zhiwei
> > > thanks
> > > -- PMM