On Thu, 24 Mar 2011, Thomas Gleixner wrote:
> On Thu, 24 Mar 2011, Maciej W. Rozycki wrote:
> > On Thu, 24 Mar 2011, Ralf Baechle wrote:
> > > Thanks, queued for 2.6.39.
> > Ralf, thanks for cc-ing me.
> > NACK, where's the logic to ack IOASIC DMA IRQs gone? The SIR has to be
> > written as in clear_ioasic_irq() for the respective DMA transfer to resume
> > and the interrupt in question be able to retrigger in the future.
> #define ack_ioasic_dma_irq ack_ioasic_irq
> .name = "IO-ASIC-DMA",
> .ack = ack_ioasic_dma_irq
> So the .ack pointer is filled with ack_ioasic_irq, right ?
The ack used to be made in clear_ioasic_irq(), that was called from
end_ioasic_dma_irq(), that was used as the .end handler. This semantics
has to be preserved or hardware won't work anymore as expected. This is a
> So I did:
> -#define ack_ioasic_dma_irq ack_ioasic_irq
> + .irq_ack = ack_ioasic_irq,
> Pretty identical as far as I can tell. The define is rather pointless,
> isn't it ?
Yes, but it's not the .ack handler I'm concerned about, but the hardware
ack that has to be made once higher-level processing has finished.
> > The rest is probably OK, but why has the inline hint been removed?
> > These functions are simple, worth a couple of assembly instructions at
> > most and used throughout these files, so it's good to ask GCC to inline
> > them if worthwhile even if -fno-unit-at-a-time has been requested for
> > whatever reason.
> The only use of these functions is in the chip pointers, so the inline
> is pointless. But I really dont care.
mask_ioasic_irq() is called from ack_ioasic_irq() for one.