The following automatic case addresses a need for a pair of new functions
required to fix a suspend/resume bug in the SDcard framework.  If anyone
has any questions, or feels the case should be "promoted" to a fast track
or (heaven forbid!) a full case, please don't hesitate to ask.

Note that case seeks patch binding for SDcard, and that the affected
interfaces are Consolidation Private.

        -- Garrett

Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
         SDcard Framework Suspend & Resume
    1.2. Name of Document Author/Supplier:
         Author:  Garrett D'Amore
    1.3  Date of This Document:
        01 December, 2008
4. Technical Description

SDcard Framework Suspend & Resume

Problem:

The SDcard framework (PSARC 2007/659 and PSARC 2008/001) needs to handle
DDI_SUSPEND and DDI_RESUME events within the framework, in order to ensure
that background kernel threads (specifically the master slot processing
thread) does not wind up getting dispatched while the the host adapter is
suspended.  (Note that kernel threads, unlike user threads, are suspended
*after* devices, and resumed *before* devices.)


Solution:

We add two new functions for SDcard adapters to call:

void sda_host_suspend(sda_host_t *);
void sda_host_resume(sda_host_t *);

The physical driver will call these functions before suspending, and after
resuming (respectively) the underlying hardware.  The SDA framework guarantees
that none of the driver's entry points (at least the ones registered with
the SDA framework) will be called in between sda_host_suspend() and the
sda_host_resume() calls.

As with the other SDA support routines, these are Consolidation Private.

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


Reply via email to