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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
