From gd78059@sac.sfbay.sun.com Tue Jan 1 13:28:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m01LSdbN015367 for ; Tue, 1 Jan 2008 13:28:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m01LSb9q029192; Tue, 1 Jan 2008 21:28:38 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTZ00G07IBPAB00@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Jan 2008 13:28:37 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTZ0075RIBOKK90@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Jan 2008 13:28:36 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m01LSaAf061733; Tue, 01 Jan 2008 13:28:36 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m01LL5Qh015332; Tue, 01 Jan 2008 13:21:05 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m01LL5aZ015328; Tue, 01 Jan 2008 13:21:05 -0800 (PST) Date: Tue, 01 Jan 2008 13:21:05 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: SDcard Simplified Synchronous Command Processing [PSARC/2008/001 Self Review] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com Message-id: <200801012121.m01LL5aZ015328@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3356 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