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...*
next prev parent 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