Date: Thu, 2 Jan 1997 01:31:43 -0900 (AKST) From: hmmm <hmmm@alaska.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: freebsd-hackers <hackers@freebsd.org> Subject: Re: Ints Message-ID: <Pine.GSO.3.93.970102010408.6300A-100000@calvino.alaska.net> In-Reply-To: <199701020235.NAA14968@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.93.970102010408.6300A-100000>