This message is from the T13 list server.
Last time I checked, the ATA standard did not mention supporting
"a host that only performs 16-bit register accesses".
There IS mention of support for CFA where the DATA register is only
8-bits....
but no mention of a 16-bit-only host interface.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
e-mail: [EMAIL PROTECTED]
s-mail: 389 Disc Drive; Longmont, CO 80503 USA
voice: 720-684-2120
fax....: 720-684-2711
==========================================
"Evans, Mark"
<[EMAIL PROTECTED]
r.com> To
Sent by: "Elliott, Robert \(Server
[EMAIL PROTECTED] Storage\)" <[EMAIL PROTECTED]>,
rg <[email protected]>
No Phone Info cc
Available
Subject
RE: [t13] ATA8-ACS NOP proposals
04/06/2006 08:19
AM
This message is from the T13 list server.
Hi Rob,
I was reviewing your proposal (e06126r0) and have a serious issue (I won't
go into the editorial issues I have with the proposal here). In the
overview of your proposal you write, "However, since NOP with subcommand
00h returns the same result as an unsupported opcode, it doesn't matter if
it is 'supported' or not." This isn't all NOP does. It DOES matter
whether a device reports that the command is supported or not. You have to
go back to what NOP was originally intended to do. The last place this is
hinted at is in the description of NOP in ATA/ATAPI-4 rev 16, "This command
enables a host, that only performs 16-bit register accesses, to check
device status." It seems that Pete McLean removed this when he added in
Tony Goodfellow's proposal for NOP auto poll (d97142r1) during A/A-4 letter
ballot resolution.
If you go back farther to earlier standards, you'll see that "...when a
host performing 16-bit register accesses writes to the Drive Head Register,
one byte contains the Command Register, so the drive sees a new command
when the intended purpose is only to select a drive. Both drives may be
Busy but not necessarily Ready i.e., Drive 0 may be ready, but not drive
1."
So, there is a unique meaning to saying that a device supports NOP just as
it is. This meaning can't be muddied by adding additional requirements.
If you want additional requirements, you'll have to find a new bit in
IDENTIFY DEVICE data.
Regards,
Mark Evans
Maxtor Corporation
500 McCarthy Boulevard
Milpitas, CA 95035
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Elliott, Robert (Server Storage)
Sent: Monday, April 03, 2006 11:37 AM
To: [email protected]
Subject: [t13] ATA8-ACS NOP proposals
This message is from the T13 list server.
Stemming from some SCSI to ATA Translation (SAT) letter ballot discussions
on the behavior of the NOP command, I've prepared two proposals for T13 to
discuss at the April meeting (posted on
http://www.t13.org):
e06125r0-ATA8-ACS_IDENTIFY_PACKET_DEVICE_supported_features.pdf
IDENTIFY PACKET DEVICE must return specific values for feature
sets/commands that are mandatory or prohibited in packet devices (e.g.
NOP is mandatory).
e06126r0-ATA8-ACS_NOP_clarifications.pdf
Since NOP with subcommand 00h behaves the same as an unsupported command,
there is no reason for IDENTIFY DEVICE to include NOP Supported/Enabled
bits except for subcommands 01h-FFh. Those subcommands have different
behavior for devices supporting the Overlapped and Queued feature sets.
So, this proposal adds a sentence noting that, for devices supporting the
Overlapped feature set, the IDENTIFY DEVICE data bits indicating NOP
support also imply that NOP subcommands 01h-FFh are supported.
Also, the NOP Auto Poll model discusses how host adapters might complete
the command with ERR=0, which the NOP command description doesn't mention
at all. Based on d97142r1, the proposal that added the feature, changes
are suggested to mention this exception in the NOP command description.
--
Rob Elliott, [EMAIL PROTECTED]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
