public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
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: Wed, 04 May 2005 02:50:01 +0100	[thread overview]
Message-ID: <1115171395.14869.147.camel@localhost.localdomain> (raw)
In-Reply-To: <20050503215634.GH8079@lkcl.net>

On Maw, 2005-05-03 at 22:56, Luke Kenneth Casson Leighton wrote:
> it only does level-based interrupts and i need to create a driver
> that does two-way 8-bit data communication.

Level triggered is generally considered a feature by people less than
200 years old 8)

> i would genuinely appreciate some advice from people with
> more experience than i on how to go about getting round
> this stupid hardware design - in order to make a RELIABLE,
> non-race-conditioned kernel driver.

Assuming you are using the core Linux IRQ code then you shouldn't have
any great problem. The basic rules with level triggered IRQ are that 

- You must ack the IRQ on the device to clear it either specifically or
as part of some other process.
- The device must raise the IRQ again if the irq condition is present
*at* or after the point of the IRQ ack (or in many implementations 'just
before' in fact)

the core Linux code deals with masking on the controller to ensure IRQ's
dont get called recursively, and ensuring an IRQ gets rechecked/recalled
on the unmask/exit path if it is still asserted.

So an implementation is much like a serial port fifo, assert the IRQ
until the PC has fetched all the bits. In fact the IRQ line is
essentially "NOT(fifo_empty)" and rechecked each time a byte is fetched.

*WAY* simpler than nasty edge triggered stuff 8)

Alan


  reply	other threads:[~2005-05-04  1:51 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 [this message]
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
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=1115171395.14869.147.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkcl@lkcl.net \
    /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