I'm submitting the following on my own behalf. It is a simplification of
the SDcard stack. As the stack has yet to be delivered (and hence there are
no consumers), I believe it qualifies for automatic approval. Please let me
know if anyone disagrees.
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
SDcard Simplified Synchronous Command Processing
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
01 January, 2008
4. Technical Description
SDcard Simplified Synchronous Command Processing
Garrett D'Amore
January 1, 2008
Executive Summary
-----------------
This case proposes to alter the API specified by PSARC 2007/659 to eliminate
the separate asynchronous completion event for SD/MMC command completion.
It also proposes to rename one function for consistency.
Note that the data phase remains asynchronous.
Details
-------
1) The sda_cmd_done() function is eliminated.
2) The so_cmd() member of the sda_ops_t function is now considered synhronous.
That is to say, it will not return to its caller until the command is complete
and the sc_response field of the sda_cmd_t is valid. (Unless it returns a
non-zero errno.) Host drivers may elect to use an interrupt internally
if necessary. (Note that the so_poll() function overrides that.)
3) The sda_transfer_done() function is renamed to sda_host_transfer(), but
is otherwise unchanged. (This is done for consistency... all of the host
APIs are called "sda_host_xxx".)
Rationale
--------
SD/MMC exchanges are made of either one or two phases, a command phase and
an optional data transfer phase. It turns out that the
command phase takes at most 200 cycles of the SD clock, which for most
controllers is always at least 375 kHz (and indeed, the spec requires at least
a 100 kHz clock) and is much more commonly at least 16 MHz after the card has
been identified and initialized. (All SD and MMC cards which the project
team has found support clock rates of at least 12 MHz.)
This fact (the 200 cycle worst case time) was discovered after PSARC 2007/659
was finalized.
In other words, the longest it can take for the command (and response) phase
to complete is 2 msec. (And for all controllers with which the project team
has experience, the worst case time is 533 usec, and the typical completion
time is usually less than 12.5 usec. This begins to be comparable to the
times associated with the interrupt processing time and context switch.)
Hence, a separate command submission, and completion callback phase seems
unnecessarily complex. And for hosts like those from WinBond, it turns
out that the driver must poll for command completion anyway. Hence the
asynchronous API specified by 2007/659 adds a bit of undue complexity, and
we can simplify life for host drivers by simply making the API synchronous.
Further, the host driver which desires to improve performance by using an
interrupt driven completion architecture can do so, without forcing the
complexity up into the higher levels of the SDA framework.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: Automatic
6.6. ARC Exposure: open
