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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.