From owner-freebsd-hackers  Thu Jan  2 02:32:01 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id CAA27418
          for hackers-outgoing; Thu, 2 Jan 1997 02:32:01 -0800 (PST)
Received: from calvino.alaska.net (root@calvino.alaska.net [206.149.65.3])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA27402
          for <hackers@freebsd.org>; Thu, 2 Jan 1997 02:31:56 -0800 (PST)
Received: from calvino.alaska.net (hmmm@calvino.alaska.net [206.149.65.3]) by calvino.alaska.net (8.8.0/8.7.3) with SMTP 
	id BAA11849; Thu, 2 Jan 1997 01:31:45 -0900 (AKST)
Date: Thu, 2 Jan 1997 01:31:43 -0900 (AKST)
From: hmmm <hmmm@alaska.net>
Reply-To: hmmm <hmmm@alaska.net>
To: Michael Smith <msmith@atrad.adelaide.edu.au>
cc: freebsd-hackers <hackers@freebsd.org>
Subject: Re: Ints
In-Reply-To: <199701020235.NAA14968@genesis.atrad.adelaide.edu.au>
Message-ID: <Pine.GSO.3.93.970102010408.6300A-100000@calvino.alaska.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 2 Jan 1997, Michael Smith wrote:

> If you're operating in a polled environment, you're not using an IRQ.

if you POLL a device for a response received via interrupts, then you ARE
polling ... :)

> The highest pending interrupt status is presented in the IIR.  If you
> perform an action that clears an interrupt status, the IIR may change.

MAY change - or DOES change ?  is it usually a circuit outside of CPU
concerns?  do INT status flags change EXACTLY as the condition is removed?

> Merely responding to the interrupt does not alter the state of the IIR.
> ... controller presents a single interrupt signal to the PIC.  You

isn't the signal removed after the PIC responds to the device ?
... so that the IRQ line is now "free" again - and may be interrupted
by the same device with its own higher priority interrupt ?

> must clear all the enabled internal interrupt states within the UART
> in order to clear the interrupt output and thus allow the PIC to detect
> a new interrupt.

but the device HAS to ASSERT its IRQ again in order to have another of its
interrupts served - so it must DE-ACTIVATE the IRQ line at some time - and
i'm pretty sure it's right after the PIC acknowledges the devices
request - so that it can interrupt one of its own ISRs by one of its own
higher priority interrupts ... ???  i'm probably wrong! :(
maybe i've been working with the SCC too long ...