On Wed, Mar 13, 2002 at 11:42:26PM +0000, David Laight wrote:
> On Wed, Mar 13, 2002 at 10:36:31PM +0100, Manuel Bouyer wrote:
> > On Tue, Mar 12, 2002 at 11:41:00PM +0000, David Laight wrote:
> > > I think it is possible to detect a value it the status register
> > > that can only have happened if the command has completed.
> > > (This may require sending an illegal commands to get an error
> > > status set first).
> > 
> > Well, we're talking about a test needed for all interrupts here
> 
> Not really, you just need to write the device driver such that
> its ISR can be entered at any time, and it decides what to do
> given the contents of the STATUS register and the last command
> issued.

I meant "all interrupt on the same line". Remember this started with a problem
about shared interrupts.

> 
> I've just been reading T13/1153D revsion 18 (again)....
> 
> I would ensure that the ISR:
> 1) always reads STATUS to ensure the hardware IRQ is removed
> 2) if BUSY set, return
> 3) if DRQ set request data xfer (unless dma active) and return
> 4) if no command active, return
> 5) if ERR set, report error and/or retry
> 6) if < 400ns since command issued, wait on short timer

And how do you know how many time ago the interrupt has been issued, especially
with such a higth resolution, without performances penalty ?

Also I've seen weird things with some controllers when reading status before
it's time. From data corruption to machine wedge.

When I got my first PCI-native PCIIDE controlers I tried to find a generic
way of sharing interrupts. After a lot of experiments, I conclued that
interrupt sharing support was not possible without support at the controller
level (i.e. a controller register that can tell us if interrupt occured).
Maybe this is controller dependant.

> 7) report command complete
> 
> IRQ is 'taken' if you return at 3, 5 or 7.
> 
> For most systems the system interrupt entry sequence is
> probably longer than 400ns!  (you only need to wait 400ns
> to ensure the contents of STATUS is valid, reading it
> earlier isn't a problem).

Not if you already have a pending interrupt on this line. You'll enter
the interrupt routine at the first splx(). Again think shared interrupts.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--