jgarzik at pobox.com
Thu Aug 12 16:04:22 PDT 2004
This message is from the T13 list server.
Marushak, Nathan wrote:
> I'm not sure I follow the need to specify the protocol. The assumption
> is we are passing through an ATA command to an ATA controller. As such,
> the "cumbersome (and unneeded) table or switch statement" has always
> gone with the ATA controller. Somebody has to perform the lookup to go
> from command type to the sequence type (data protocol), whether it be at
> the highest level, lowest level, or somewhere in between.
Certainly. Otherwise it would be impossible to execute vendor-reserved
Given that the protocol is unknown for vendor-reserved commands, it
follows that one must specify the protocol for vendor-reserved commands.
If one must specify the protocol in some cases, it then follows that the
most efficient OS driver implementation is to require specification in
ALL cases, thereby avoiding the lookup table / switch statement completely.
> As far as vendor unique commands...good question. ATA Controllers have
> to understand that the command being passed to them is vendor unique.
> Understanding the command is vendor unique, then the controller won't
> make any assumptions about subsequent packets. Basically it will wait
> until it receives signals or FISes back from the target before
> understanding what the data protocol might be or what the next step is.
> I believe this is true in all cases.
> Suffice to say, I don't believe the existing ATA controllers on the
> market require knowledge of each and every vendor unique command for
> each and every target on the market, yet they do still allow for vendor
> unique commands.
> To summarize, I don't see the need to specify a data protocol since
> there currently is no need to specify data protocol in a SATA Register
Please look at how ultra-modern SATA controllers support vendor reserved
* Some vendors have a 'command protocol' field that must be filled in
for each command issued.
* Some vendors have special 'vendor command setup' commands, snooped by
the host controller, which specify this information to the host controller.
* A few vendors with bridged SATA implementations simply don't support
vendor reserved commands at all, because it is impossible to 'tell' the
controller the FIS protocol.
* The remaining vendors seem to have chosen to allow direct control over
FIS transmission/reception by the low-level driver, so that the driver
may ensure that the command protocol is followed for the cases where the
host controller silicon / firmware doesn't know how to handle the command.
The people actually making the controllers recognized the need to allow
the OS driver to specify the data protocol, precisely because it is
_impossible_ to know the protocol in all cases.
I have recognized this requirement, and have implemented this for the
following vendor's controllers, where possible: Intel, Silicon Image,
Marvell, Promise, Vitesse, VIA, SiS, and Broadcom/ServerWorks.
More information about the T10