a word about ATA interrupts, and SATA (was Re: [PATCH libata-dev-2.6:upstream 00/02] libata: race fixes)

[Jeff Garzik <jgarzik@pobox.com>]

BTW, here is food for thought:

In first generation SATA controllers, the host controller silicon 
emulates a set of PATA taskfile registers.  When you follow the ATA 
command protocols (host state machines), handling ATA commands in the 
specified manner, the host controller silicon is processing that stuff 
behind your back, silently converting your actions into other actions:

* storing data in a H2D Register FIS buffer, for eventually sending to 
the device
* storing data received from a D2H Register FIS or SDB FIS into the host 
controller taskfile registers.
* handling PIO Setup and Data FISes, for PIO data xfer and PACKET 
command protocol
* handling FIS's associated with DMA data transfer

I've never seen any documentation for any host controller, that 
describes how the emulation is implemented in silicon.  Probably nobody 
outside of the original VHDL designers for each chip know that.  All we 
know, we must figure out from inference:  we pretend a host chip is 
PATA, and the host chip turns our actions into a SATA FIS conversion.

Because of this, we can discern several unique SATA quirks:
(a) writing most ATA registers simply involves storing a data value into 
a buffer on the host controller
(b) writing to Device Control or Command registers causes a H2D Register 
FIS to be sent.
(c) [most important to this thread] the ATA INTRQ is signalled by 
setting the 'I' bit in certain FIS's.  It is no longer a pure indication 
of the INTRQ signal, as it was in PATA.

Due to the ramifications of (c), polling in general is possible but not 
the best idea.  libata currently uses polling for the IDENTIFY DEVICE 
command, and I have long been thinking about turning off polling for 
SATA controllers.  Some SATA controllers, such as Vitesse/Intel, simply 
do not support the ATA nIEN bit.  It is emulated in the driver.  Other 
controllers may not honor the nIEN bit correctly (due to bad emulation 
logic in silicon, probably).

Just factor this info into your decisions, when playing around with the 
interrupt delivery code.

	Jeff