Hello Holger,
It might make a difference when clearing the irq bit signals the hardware that it can continue doing something or start some transaction before we are able to process the irq trown by this transaction.IMHO it does not make any difference. The irq handler is not called directly, but through Linux' irq subsystem.
As long as we are in the irq handler, new interrupts are not delivered. If an irq is raised, it will be handled within a new call to the irq handler.
To proove this, I added the following lines to the cvs driver's irq handler:
------------------------------------------------------
if(fakeme == 0) {
printk("faking irq\n");
fakeme=1;
IER_ENABLE(dev, MASK_12);
saa7146_write(dev, PSR, MASK_12);
}
-------------------------------------------------------
Writing to the PSR with the corresponding interrupt enabled will cause the interrupt to be generated. (data sheet, page 45)
-------------------------------------------------------
Jan 2 11:41:43 michael kernel: saa7146: interrupt_hw(): 0x00020000
Jan 2 11:41:43 michael kernel: faking irq
Jan 2 11:41:43 michael kernel: irq out
Jan 2 11:41:43 michael kernel: saa7146: interrupt_hw(): 0x00001000
Jan 2 11:41:43 michael kernel: saa7146: interrupt_hw(): warning: interrupt enabled, but not handled properly.(0x00001000)
Jan 2 11:41:43 michael kernel: saa7146: interrupt_hw(): disabling interrupt source(s)!
Jan 2 11:41:43 michael kernel: irq out
-------------------------------------------------------
You can see that the irq handler is left before the new irq is handled.
Holger
CU Michael.
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
