Fedora kernel-2.6.17-1.2142_FC4 patched with stable patch-2.6.17.4-vs2.0.2-rc26.diff

[linux-2.6.git] / Documentation / pm.txt

diff --git a/Documentation/pm.txt b/Documentation/pm.txt
index 483d2a5..79c0f32 100644 (file)
--- a/Documentation/pm.txt
+++ b/Documentation/pm.txt
@@ -36,8 +36,14 @@ system the associated daemon will exit gracefully.
   apmd:   http://worldvisions.ca/~apenwarr/apmd/
   acpid:  http://acpid.sf.net/
 
   apmd:   http://worldvisions.ca/~apenwarr/apmd/
   acpid:  http://acpid.sf.net/
 

-Driver Interface
-----------------
+Driver Interface -- OBSOLETE, DO NOT USE!
+----------------*************************
+
+Note: pm_register(), pm_access(), pm_dev_idle() and friends are
+obsolete. Please do not use them. Instead you should properly hook
+your driver into the driver model, and use its suspend()/resume()
+callbacks to do this kind of stuff.
+

 If you are writing a new driver or maintaining an old driver, it
 should include power management support.  Without power management
 support, a single driver may prevent a system with power management
 If you are writing a new driver or maintaining an old driver, it
 should include power management support.  Without power management
 support, a single driver may prevent a system with power management


@@ -90,54 +96,6 @@ void pm_unregister(struct pm_dev *dev);
  */
 void pm_unregister_all(pm_callback cback);
 
  */
 void pm_unregister_all(pm_callback cback);
 

-/*
- * Device idle/use detection
- *
- * In general, drivers for all devices should call "pm_access"
- * before accessing the hardware (ie. before reading or modifying
- * a hardware register).  Request or packet-driven drivers should
- * additionally call "pm_dev_idle" when a device is not being used.
- *
- * Examples:
- * 1) A keyboard driver would call pm_access whenever a key is pressed
- * 2) A network driver would call pm_access before submitting
- *    a packet for transmit or receive and pm_dev_idle when its
- *    transfer and receive queues are empty.
- * 3) A VGA driver would call pm_access before it accesses any
- *    of the video controller registers
- *
- * Ultimately, the PM policy manager uses the access and idle
- * information to decide when to suspend individual devices
- * or when to suspend the entire system
- */
-
-/*
- * Description: Update device access time and wake up device, if necessary
- *
- * Parameters:
- *   dev - PM device previously returned from pm_register
- *
- * Details: If called from an interrupt handler pm_access updates
- *          access time but should never need to wake up the device
- *          (if device is generating interrupts, it should be awake
- *          already)  This is important as we can not wake up
- *          devices from an interrupt handler.
- */
-void pm_access(struct pm_dev *dev);
-
-/*
- * Description: Identify device as currently being idle
- *
- * Parameters:
- *   dev - PM device previously returned from pm_register
- *
- * Details: A call to pm_dev_idle might signal to the policy manager
- *          to put a device to sleep.  If a new device request arrives
- *          between the call to pm_dev_idle and the pm_callback
- *          callback, the driver should fail the pm_callback request.
- */
-void pm_dev_idle(struct pm_dev *dev);
-

 /*
  * Power management request callback
  *
 /*
  * Power management request callback
  *


@@ -260,32 +218,15 @@ proceed in the opposite direction.
 Q: Who do I contact for additional information about
    enabling power management for my specific driver/device?
 
 Q: Who do I contact for additional information about
    enabling power management for my specific driver/device?
 

-ACPI Development mailing list: acpi-devel@lists.sourceforge.net
+ACPI Development mailing list: linux-acpi@vger.kernel.org

 
 

-System Interface
-----------------
+System Interface -- OBSOLETE, DO NOT USE!
+----------------*************************

 If you are providing new power management support to Linux (ie.
 adding support for something like APM or ACPI), you should
 communicate with drivers through the existing generic power
 management interface.
 
 If you are providing new power management support to Linux (ie.
 adding support for something like APM or ACPI), you should
 communicate with drivers through the existing generic power
 management interface.
 

-/*
- * Send a request to a single device
- *
- * Parameters:
- *   dev - PM device previously returned from pm_register or pm_find
- *   rqst - request type
- *   data - data, if any, associated with the request
- *
- * Returns: 0 if the request is successful
- *          See "pm_callback" return for errors
- *
- * Details: Forward request to device callback and, if a suspend
- *          or resume request, update the pm_dev "state" field
- *          appropriately
- */
-int pm_send(struct pm_dev *dev, pm_request_t rqst, void *data);
-

 /*
  * Send a request to all devices
  *
 /*
  * Send a request to all devices
  *