Re: tricky challenge for getting round level-driven interrupt problem: help!

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Wed, May 04, 2005 at 10:43:35PM +0100, Alan Cox wrote:

> On Mer, 2005-05-04 at 21:58, Luke Kenneth Casson Leighton wrote:
> >  i believe i get it: you raise a level-triggered interrupt which _stays_
> >  raised until such time as your fifo is empty.
> 
> Bingo. It only goes away when the chip really has nothing left to say.
> 
> >  all - that sometimes (frequently, in fact - about 1 in every
> >  50 times) it hasn't got round to clearing the level-driven
> >  interrupt by the time we come out of the ARM ISR (!)
> 
> So you'll poll again and find there is no pending work to do.
> 
> >  hence the redesign to do alternate read-write-read-write, and making
> >  reads exclusive of writes, etc.
> 
> and maybe even turn the IRQ off and use a timer if its slow and not
> sensitive to latency.. ?

 okay.

 you will be pleased to know that the switch-off-irqs-in-the-isr
 and then switch-it-back-on-in-the-FIQ approach works.

 *gibber*

 basically i am doing this:

 * in the ARM interrupt read routine, first thing i do is mask
   read interrupts.

 * i then set up the ARM port for "read", including disabling the
   keyboard which shares some of the port lines.

 * i then read the byte (which causes an edge-triggered interrupt
   to the PIC, which then sets about clearing the interrupt).
 
 * i then re-enable the keyboard.

 * at the end of the routine, i then set a flag.


 some time later, within 1/8000th of a second, this flag is checked.
 if it's set, read interrupts are unmasked.

 
 ... btw when you say "using the linux interrupt management" routines,
 what exactly do you mean?

 at the moment (because that's what was done when i stepped in
 to sort out this code) i am directly accessing the INTMR1 and
 INTSR1 registers - _not_ calling enable_irq() or disable_irq()
 or other)

 (and in the FIQ handler of course i _can't_ call those functions).

 is that a problem?

 l.