SATA Framework Port Multiplier Support resubmit [PSARC/2009/394 Fast-track]

2009-09-17 Thread Alan Perry

I am sponsoring the resubmission of this case.  The timer expires on 
9/24/2009.

This fast-track was approved back in July.  However, after the 
associated code
changes were integrated into Nevada, some issues were discovered and the 
sata
team decided to rework the case.

Here are the changes relative to the case that was approved in July:

1. Eliminate a change to the sata framework's existing sata_device 
structure.
2. Add a definition for an additional port multiplier "qualifier".
3. Add a field to one of the new data structure for future expansion.
4. Rename the function sata_check_pmult_blacklist to sata_register_pmult and
   use it in a somewhat different manner than in the original case.


1. Introduction
===
   1.1. Project/Component Working Name:
SATA Framework Port Multiplier Support

   1.2. Name of Document Author/Supplier:
Author: Xiao-Yu Zhang

   1.3. Date of This Document:
9/17/2009
   
4. Technical Description


4.1. Background
---
PSARC/2004/779 [1] established the SATA HBA Framework interface.
PSARC/2005/679 [2] expanded this interface as needed to support the
marvell88sx and si3124 SATA HBA drivers. PSARC 2007/274 [3] expanded the
interface further to support Native Command Queuing (NCQ) and ATAPI
devices. PSARC/2007/448 [4] expanded the interface again to support
releasing DMA framework-allocated resources associated with a command's
buffer.

This fast-track describes further interface changes required to support SATA
port multipliers.

4.2. The Problem


4.2.1. Required to support READ/WRITE PORTMULT command
--
According to the SATA Specification 2.6 [5] and the Port Multiplier
Specification [6], READ PORT MULTIPLIER and WRITE PORT MULTIPLIER are 
used to
access the registers of the port multiplier.  These two commands are 
necessary
to the successful enumeration of the the port multiplier.

Both SATA HBA drivers as well as the SATA module have internal functions
operating on sata_pkt rather than isolated SATA commands.  Therefore,
READ/WRITE PORTMULT commands should be delivered to SATA HBA drivers in
sata_pkt structures.

4.2.2. Required to retrieve port multiplier information
---
Existing HBA implementations update only SATA Control Registers values in
response to probe port operation.  The port multiplier has its own Global
Status & Control Registers, in which the parameters and status of the port
multiplier itself are stored.  The sata module needs the register 
information,
so there needs to be a method for the SATA HBA driver to transfer the GSCR
information to the sata module.

4.2.3. Required to handle port multiplier quirks

The SATA specification 2.6 [5] defines the registers and enumeration process
for port multipliers, however, some existing port multiplier models have 
quirks
and might break the general enumeration or initialization process.  The HBA
driver should have idea of these quirks and determine its reaction.  
Additions
to the interface are required to handle Port Multiplier behavior that is
different from the specification.


4.3. The Proposal
-

4.3.1. Summary
--
Revise the SATA interface to support port multiplier.  Port multiplier 
support
was partially designed and implemented inside SATA module.  The proposal
defines new interface functions necessary to support new SATA commands.  
A new
structure is defined to store GSCR register of the port multiplier 
device and
a new interface function for the HBA driver to transfer the GSCR information
to sata module and retrieve the necessary information of the port multiplier
discrepancies from the SATA specification.

The initial consumer of the modified interface will be AHCI driver
implementing SATA port multiplier support.

Since the existing SATA HBA drivers and SATA module do not currently 
implement
the structure version checking (except for sata_hba_tran structure), the
proposed change will maintain the binary compatibility.

A SATA module supporting these interface changes will operate with SATA HBA
drivers using the unmodified interface as well as SATA HBA drivers using the
modified interface.

4.3.2. Interface Modifications
--
a) Add a new structure sata_pmult_gscr.
   (See section 5.2.1 for more details)

b) Add a new qualifier SATA_ADDR_PMULT_SPEC
   (See section 5.3.1 for more details).

c) The sata_hba_tran structure version (SATA_TRAN_HBA_REV) will be increased
   to 3 to indicate new functionality level of the entire SATA framework
   interface.
   (See section 5.3.2 for more details)

d) Add three new SATA module interface functions.
   + sata_get_rdwr_pmult_pkt();
   + sata_free_rdwr_pmult_pkt();
   + sata_register_pmult();
   (See section 5.4 for more details)

4.5. Stability level
-

SATA Framework Port Multiplier Support resubmit [PSARC/2009/394 Fast-track]

2009-09-23 Thread Rick Matthews
+1 on the resubmitted case

On 09/17/09 17:48, Alan Perry wrote:
>
> I am sponsoring the resubmission of this case.  The timer expires on 
> 9/24/2009.
>
> This fast-track was approved back in July.  However, after the 
> associated code
> changes were integrated into Nevada, some issues were discovered and 
> the sata
> team decided to rework the case.
>

-- 
-
Rick Matthews   email: Rick.Matthews at sun.com
Sun Microsystems, Inc.  phone:+1(651) 554-1518
1270 Eagan Industrial Road  phone(internal): 54418
Suite 160   fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USAmain: +1(651) 554-1500  
-



SATA Framework Port Multiplier Support resubmit [PSARC/2009/394 Fast-track]

2009-09-24 Thread Alan Perry
This was approved at the PSARC meeting yesterday.

alan

Alan Perry wrote:
>
> I am sponsoring the resubmission of this case.  The timer expires on 
> 9/24/2009.
>
> This fast-track was approved back in July.  However, after the 
> associated code
> changes were integrated into Nevada, some issues were discovered and 
> the sata
> team decided to rework the case.
>
> Here are the changes relative to the case that was approved in July:
>
> 1. Eliminate a change to the sata framework's existing sata_device 
> structure.
> 2. Add a definition for an additional port multiplier "qualifier".
> 3. Add a field to one of the new data structure for future expansion.
> 4. Rename the function sata_check_pmult_blacklist to 
> sata_register_pmult and
>   use it in a somewhat different manner than in the original case.
>
>
> 1. Introduction
> ===
>   1.1. Project/Component Working Name:
>SATA Framework Port Multiplier Support
>
>   1.2. Name of Document Author/Supplier:
>Author: Xiao-Yu Zhang
>
>   1.3. Date of This Document:
>9/17/2009
>   4. Technical Description
> 
>
> 4.1. Background
> ---
> PSARC/2004/779 [1] established the SATA HBA Framework interface.
> PSARC/2005/679 [2] expanded this interface as needed to support the
> marvell88sx and si3124 SATA HBA drivers. PSARC 2007/274 [3] expanded the
> interface further to support Native Command Queuing (NCQ) and ATAPI
> devices. PSARC/2007/448 [4] expanded the interface again to support
> releasing DMA framework-allocated resources associated with a command's
> buffer.
>
> This fast-track describes further interface changes required to 
> support SATA
> port multipliers.
>
> 4.2. The Problem
> 
>
> 4.2.1. Required to support READ/WRITE PORTMULT command
> --
> According to the SATA Specification 2.6 [5] and the Port Multiplier
> Specification [6], READ PORT MULTIPLIER and WRITE PORT MULTIPLIER are 
> used to
> access the registers of the port multiplier.  These two commands are 
> necessary
> to the successful enumeration of the the port multiplier.
>
> Both SATA HBA drivers as well as the SATA module have internal functions
> operating on sata_pkt rather than isolated SATA commands.  Therefore,
> READ/WRITE PORTMULT commands should be delivered to SATA HBA drivers in
> sata_pkt structures.
>
> 4.2.2. Required to retrieve port multiplier information
> ---
> Existing HBA implementations update only SATA Control Registers values in
> response to probe port operation.  The port multiplier has its own Global
> Status & Control Registers, in which the parameters and status of the 
> port
> multiplier itself are stored.  The sata module needs the register 
> information,
> so there needs to be a method for the SATA HBA driver to transfer the 
> GSCR
> information to the sata module.
>
> 4.2.3. Required to handle port multiplier quirks
> 
> The SATA specification 2.6 [5] defines the registers and enumeration 
> process
> for port multipliers, however, some existing port multiplier models 
> have quirks
> and might break the general enumeration or initialization process.  
> The HBA
> driver should have idea of these quirks and determine its reaction.  
> Additions
> to the interface are required to handle Port Multiplier behavior that is
> different from the specification.
>
>
> 4.3. The Proposal
> -
>
> 4.3.1. Summary
> --
> Revise the SATA interface to support port multiplier.  Port multiplier 
> support
> was partially designed and implemented inside SATA module.  The proposal
> defines new interface functions necessary to support new SATA 
> commands.  A new
> structure is defined to store GSCR register of the port multiplier 
> device and
> a new interface function for the HBA driver to transfer the GSCR 
> information
> to sata module and retrieve the necessary information of the port 
> multiplier
> discrepancies from the SATA specification.
>
> The initial consumer of the modified interface will be AHCI driver
> implementing SATA port multiplier support.
>
> Since the existing SATA HBA drivers and SATA module do not currently 
> implement
> the structure version checking (except for sata_hba_tran structure), the
> proposed change will maintain the binary compatibility.
>
> A SATA module supporting these interface changes will operate with 
> SATA HBA
> drivers using the unmodified interface as well as SATA HBA drivers 
> using the
> modified interface.
>
> 4.3.2. Interface Modifications
> --
> a) Add a new structure sata_pmult_gscr.
>   (See section 5.2.1 for more details)
>
> b) Add a new qualifier SATA_ADDR_PMULT_SPEC
>   (See section 5.3.1 for more details).
>
> c) The sata_hba_tran structure version (SATA_TRAN_HBA_REV) will be 
> increased
>   to 3 to indicate new functi