public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux ARM Kernel list  <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: tricky challenge for getting round level-driven interrupt problem: help!
Date: Thu, 5 May 2005 00:20:24 +0100	[thread overview]
Message-ID: <20050504232024.GH8537@lkcl.net> (raw)
In-Reply-To: <1115243014.19844.62.camel@localhost.localdomain>

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...*


  reply	other threads:[~2005-05-04 23:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-03 21:56 tricky challenge for getting round level-driven interrupt problem: help! Luke Kenneth Casson Leighton
2005-05-04  1:50 ` Alan Cox
2005-05-04 20:58   ` Luke Kenneth Casson Leighton
2005-05-04 21:43     ` Alan Cox
2005-05-04 23:20       ` Luke Kenneth Casson Leighton [this message]
2005-05-05 11:32       ` Luke Kenneth Casson Leighton
2005-05-06 10:57       ` Luke Kenneth Casson Leighton
2005-05-08 12:32     ` Luke Kenneth Casson Leighton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050504232024.GH8537@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox