From ap25164@groomlake.sfbay.sun.com Mon Jul 19 14:56:57 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6JLuvkg008076 for ; Mon, 19 Jul 2010 14:56:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6JLuv8P024832 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 19 Jul 2010 14:56:57 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5T00003RMX7T00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 19 Jul 2010 15:56:57 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5T00CY8RMWS690@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 19 Jul 2010 15:56:56 -0600 (MDT) Received: from groomlake.sfbay.sun.com (groomlake.SFBay.Sun.COM [192.29.77.113]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6JLuuiL027698 for ; Mon, 19 Jul 2010 14:56:56 -0700 (PDT) Received: from groomlake.sfbay.sun.com (localhost [127.0.0.1]) by groomlake.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o6JLfXtg029027; Mon, 19 Jul 2010 14:41:33 -0700 (PDT) Received: (from ap25164@localhost) by groomlake.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id o6JLfWXT029023; Mon, 19 Jul 2010 14:41:32 -0700 (PDT) Date: Mon, 19 Jul 2010 14:41:32 -0700 (PDT) From: Alan Perry Subject: SATA Interface Addition for PIO [PSARC/2010/275 FastTrack] To: PSARC-ext@sun.com Cc: alan.perry@oracle.com Message-id: <201007192141.o6JLfWXT029023@groomlake.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4100 I think this qualifies for self-review (it has been reviewed by the SATA development team), but if anyone disagrees, let me know and I'll promote it to a fast track. Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: SATA Interface Addition for PIO 1.2. Name of Document Author/Supplier: Author: Alan Perry 1.3 Date of This Document: 19 July, 2010 4. Technical Description 4.1. Background Support for SATA devices is implemented through the sata common module (a SCSA hba module) and a number of SATA hba drivers. PSARC 2004/779 initially defined the interface between the sata common module and the hba drivers. There have been many PSARC cases adding to the interface. This is another one. 4.2. Problem Description The ATA/ATAPI command set specifications have defined protocols (PIO, DMA, No-data, etc.) used to transfer data to and from a device as a result of executing a command. Hardware vendors implement SATA controllers differently. Some of them fully expose the transfer protocol (such that the corresponding hba driver needs to know about the transfer protocol) and some of them hide the details and, as far as the controller interface is concerned, does all transfers in one manner. The hba drivers that handled commands differently based on the transfer protocol determined which transfer protocol to use based on the command code. However, this does not work now that support for the ATA Pass Through command has been added to the sata common module. The transfer protocol is specified by the caller. Besides, the hba drivers should have been getting the transfer protocol from the sata common module, not deciding for itself based on the command code. The code for determining the transfer protocol was replicated in at least two hba drivers. As the ATA command set specifications change over time, the same code changes would need to be made in multiple places. 4.3. Proposal This proposal is to add transfer protocol information to the sata_cmd structure. The sata_cmd structure is used to pass an ATA command from the sata common module to an hba driver (which will then pass it to a device for execution). The following illustrates the proposed change: struct sata_cmd { ... struct sata_cmd_flags { ... < uint32_t : 2; /* reserved */ /* 6-7 */ > uint32_t sata_protocol_pio : 1; /* 6 */ > uint32_t : 1; /* reserved */ /* 7 */ The sata_protocol_pio bit will be set to 1 when the data transfer associated with the command should be done with PIO (that is, the ATA Protocol is either PIO Data-in or PIO Data-out). Note that this does not mean that the hba driver must set up a PIO operation for the command. Some SATA controllers expose all transfers as DMA, even if the underlying operation is PIO. This proposed change is compatible with the existing sata_cmd structure and will not increment the version number for the sata_cmd structure. 4.4 Stability level This proposal will not change the stability level of the interface impacted by this proposal. It will remain Consolidation Private. The requested release binding is micro release and patch release. 4.5. References Information technology - AT Attachment with Packet Interface - 7: Volume 1 - Register Delivered Command Set, Logical Register Set, ANSI/INCITS T13. Information technology - AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS), ANSI/INCITS T13. Information technology - ATA/ATAPI Command Set - 2 (ACS-2) (Draft), ANSI/INCITS T13 4.6 Related PSARC Cases 1. PSARC/2004/779 - SATA Framework Support 2. PSARC/2005/679 - SATA Framework Support (Updated) 3. PSARC/2007/274 - SATA Framework Interface Revision 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open