Hello,
saeed bishara wrote:
> Is power always active in this infrastructure, and will the host
> respond to COMINIT with either a COMRESET or a COMWAKE? If so, I'd
> just wait for the FIS34. If you don't see a FIS34 within say 10
> seconds, I'd hit the drive with a COMRESET.
I have seen some SATA drives that sends their FIS34 only after 16 seconds.
I heard that some external storage products which emulate SATA interface
take pretty long time to get ready after power-on.
[--snip--]
I'm getting a lot of timeouts on the first reset after hotplug and still
diddling with delays. Any thoughts on how this should be solved? Can
drives handle SRST before it enters idle state after POR?
yes, this is quoted from the ATA-6 standard , section 9.2 (Software
reset protocol)
"If the host sets the SRST bit in the Device Control register to one
before devices have completed execution of the software reset
protocol, then the devices shall restart execution of the software
reset protocol from the beginning."
Yes, I've checked that clause too, but it only applies to SRST - if SRST
is issued before the previous SRST isn't finished, honor the second SRST.
And the same document says, in section 9.1 (Power-on and hardware reset
protocol).
"The host should not set the SRST bit to one in the Device Control
register or issue a DEVICE RESET command while the BSY bit is set to one
in either Device Status register as a result of executing the power-on
or hardware reset protocol. If the host sets the SRST bit in the Device
Control register to one or issues a DEVICE RESET command before devices
have completed execution of the power-on or hardware reset protocol,
then the devices shall ignore the software reset or DEVICE RESET command."
So, the standard specifically forbids it. The second half is a bit
comforting though.
I've been dealing with Sata drives for along time, and alwasy I sent
sw reset immediatly after OOB sequence (in order to detect PM), all
drives did ok with that, except for one single model, and that was
decalred as bug of the drive and fixed in updated firmware.
Hmmm.. weird. That's not what I'm seeing. AHCI reports command issue
failure if something goes wrong while transmitting D2H fis for a command
(probably when it sees R_ERR). If I issue SRST shortly after power-on,
AHCI fails SRST due to command issue failure. So, it seems that the
device rejects SRST before it transmits the first FIS34.
If I put the same device on sil3124/32 and perform HRST then SRST in a
few secs, about the same thing seems to happen but sil3124/32 times out
rather than reporting error immediately.
BTW, how do distenguesh between PM and ATAPI device? both of them have
the same signature?
This is the relevant comment.
/* Apple's open source Darwin code hints that some devices only
* put a proper signature into the LBA mid/high registers,
* So, we only check those. It's sufficient for uniqueness.
*
* ATA/ATAPI-7 (d1532v1r1: Feb. 19, 2003) specified separate
* signatures for ATA and ATAPI devices attached on SerialATA,
* 0x3c/0xc3 and 0x69/0x96 respectively. However, SerialATA
* spec has never mentioned about using different signatures
* for ATA/ATAPI devices. Then, Serial ATA II: Port
* Multiplier specification began to use 0x69/0x96 to identify
* port multpliers. ATA/ATAPI-7 dropped descriptions about
* 0x3c/0xc3 and 0x69/0x96 shortly and described them as
* reserved for SerialATA.
*
* We follow the current spec and consider that 0x69/0x96
* identifies a port multiplier. If there is an ATAPI device
* which returns 0x69/0x96 as its signature, we'll have to
* implement 'try PM, then try ATAPI' logic.
*/
--
tejun
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
