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.

 oh.

 ah.

 wait - this might be the bit i don't get 

 when you say poll again, do you mean poll again inside the ISR?

 so:
 
 * we do the read (which creates the interrupt to the PIC) and
   then sit there polling the level-driven interrupt status
   register
 
 * the PIC, having no more bytes to write, clears the ARM
   level-driven interrupt.

 * the ARM detects the change of the level-driven interrupt
   status register

 * the ARM pauses for, oh, i dunno... mmm... 6mhz equals 166ns
   so we call udelay(10) or something ridiculously long...

 * the ARM then checks the level-driven interrupt status register
   AGAIN, and if it's clear, goes "oh, we ain't gonna get no
   more data".

 something like that? [am trying it now, anyway - on the basis that it
 can't hurt :)]

 i'm not being deliberately thick - honest - i've just never had to
 do this sort of thing before.

 btw alan where would you recommend i read up on this type of thing?
 [_please_ don't say "on the inside of my skull" i'll be tempted to
 go get a saw and a spoon i've _so_ got to get this to work...]
 

> >  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.. ?
 
 tried that last month [i'm not sending to lkml about this as a first
 resort - honest!]
 
 the baud rate from the GPS is 4800 baud, so that's 600 chars/sec.

 the jiffies timer on the ARM is ... er... 250? per second?

 so ... hey, yeh, that would explain why i saw about 1
 character in 3 :)



> >  ... so - in your opinion, alan, is the old approach we had
> >  actually _on_ the right lines?
> 
> level triggered IRQ does sort of expect the other end responds promptly
> to be efficient as opposed to merely reliable.

 ... and a 6mhz processor vs a 90mhz processor... 

> >  also, are you going to ukuug in august, it being _in_
> >  aberystwyth and all :)
> 
> Its not in Aberystwyth, but I might be. Its in Swansea 8)

 ahhh :)

 glad i checked then, 'cos up until 30 seconds ago i was gonna
 drive to aber.

 *wonders why the hell i've been let loose on this project...*

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/