Re: [microblaze-uclinux] why intr->ack() is null?

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Yashi,

Yasushi SHOJI wrote:
> # sorry for the bounce

No worries, that's what list-admins are for :)

> Could you elaborate me on the following comment from irq.c?
> 
> 	/* This is to acknolwedge receipt of the IRQ.   In microblaze
> 	   this is null - we don't wan't to ack until after handling.
> 	   We do this in the handler->end(irq) call */
> 	desc->handler->ack(irq);
> 
> and microblaze_intc.c:
> 
> /* For now, don't ack interrupt until end of interrupt processing */
> /* Same uncertainty exists in PPC xintc driver */
> #define ACKNOWLEDGE_AFTER
> 
> IMO, it'd be nice to ack as fast as possible. what am I missing?
> 
I spent a lot of time and brain-hurt on this, and currently our 
RTAI-porting effort is also hitting this same wall.  Here's the deal:

Consider a device like opb_timer.  It generates an interrupt, which must 
be cleared on the device, by the driver  - in this example 
time.c:timer_interrupt():

         csr = timer_get_csr(MICROBLAZE_TIMER_BASE_ADDR,0);
         /* write the timer status back to the control register,
          * to clear the interrupt.  Once again, timer 0 is hard coded */
         timer_set_csr(MICROBLAZE_TIMER_BASE_ADDR, 0, csr);


When the interrupt occurs, the XINTC registers it, and generates 
microblaze IRQ signal.  We can ACK it immediately on the XINTC, but the 
timer itself is still generating the interrupt, and will continue to do 
so until we enter the code above.

Of course we also mask the interrupt, but we might still get a spurious 
interrupt generated.  Bad news.

Here's where the confusion starts.  Two possible approaches:

(1) we mask, handle, ack, unmask (current approach).

or

(2) we mask, ack, handle, unmask (your intuition, and mine!)

When I've tested option (2), (you can try this yourself, it's controlled 
by the ACKNOWLEDGE_AFTER #define), it's my observation that performance 
gets very "stuttery" - just what I'd expect if I was getting gross 
interrupt re-entrancy.  It smoothes out if you go for option (1).

This suggests to me that even if you mask then ack a particular IRQ in 
the XINTC, if the "source" device keeps generating its interrupt output 
(like the timer does), then a spurious interrupt is regstered, and is 
triggered when interrupts are re-eanbled, some time later.

It might be possible to define two types of hw_interrupt_type (see 
microblaze_intc.c), one that acks before, one that acks afterwards, and 
choose based on our knowledge of the device (ie the UARTlite requires no 
"clear interrupt" sequence, while the timer does).  This seems pretty 
unclean, and it's not immediately clear to me how a device driver can 
indicate its requirements back to the kernel.

 > I couldn't find refered xintc.  Is there mailing list archive or
 > something that I can dig?

I looked at the V2Pro/PPC source as well, and their driver for the 
XINTC, and it shows the same uncertainty about the behaviour of the 
XINTC. Their source is available (via bitkeeper) from penguinppc.org.  I 
can send you the specific source file if you want to look into it.

Well sorry for the long post, but it's a bit of a can of worms!  If you 
are still conscious, any comments or thoughts?

John

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/