charger-manager.txt 8.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186
  1. Charger Manager
  2. (C) 2011 MyungJoo Ham <myungjoo.ham@samsung.com>, GPL
  3. Charger Manager provides in-kernel battery charger management that
  4. requires temperature monitoring during suspend-to-RAM state
  5. and where each battery may have multiple chargers attached and the userland
  6. wants to look at the aggregated information of the multiple chargers.
  7. Charger Manager is a platform_driver with power-supply-class entries.
  8. An instance of Charger Manager (a platform-device created with Charger-Manager)
  9. represents an independent battery with chargers. If there are multiple
  10. batteries with their own chargers acting independently in a system,
  11. the system may need multiple instances of Charger Manager.
  12. 1. Introduction
  13. ===============
  14. Charger Manager supports the following:
  15. * Support for multiple chargers (e.g., a device with USB, AC, and solar panels)
  16. A system may have multiple chargers (or power sources) and some of
  17. they may be activated at the same time. Each charger may have its
  18. own power-supply-class and each power-supply-class can provide
  19. different information about the battery status. This framework
  20. aggregates charger-related information from multiple sources and
  21. shows combined information as a single power-supply-class.
  22. * Support for in suspend-to-RAM polling (with suspend_again callback)
  23. While the battery is being charged and the system is in suspend-to-RAM,
  24. we may need to monitor the battery health by looking at the ambient or
  25. battery temperature. We can accomplish this by waking up the system
  26. periodically. However, such a method wakes up devices unncessary for
  27. monitoring the battery health and tasks, and user processes that are
  28. supposed to be kept suspended. That, in turn, incurs unnecessary power
  29. consumption and slow down charging process. Or even, such peak power
  30. consumption can stop chargers in the middle of charging
  31. (external power input < device power consumption), which not
  32. only affects the charging time, but the lifespan of the battery.
  33. Charger Manager provides a function "cm_suspend_again" that can be
  34. used as suspend_again callback of platform_suspend_ops. If the platform
  35. requires tasks other than cm_suspend_again, it may implement its own
  36. suspend_again callback that calls cm_suspend_again in the middle.
  37. Normally, the platform will need to resume and suspend some devices
  38. that are used by Charger Manager.
  39. * Support for premature full-battery event handling
  40. If the battery voltage drops by "fullbatt_vchkdrop_uV" after
  41. "fullbatt_vchkdrop_ms" from the full-battery event, the framework
  42. restarts charging. This check is also performed while suspended by
  43. setting wakeup time accordingly and using suspend_again.
  44. 2. Global Charger-Manager Data related with suspend_again
  45. ========================================================
  46. In order to setup Charger Manager with suspend-again feature
  47. (in-suspend monitoring), the user should provide charger_global_desc
  48. with setup_charger_manager(struct charger_global_desc *).
  49. This charger_global_desc data for in-suspend monitoring is global
  50. as the name suggests. Thus, the user needs to provide only once even
  51. if there are multiple batteries. If there are multiple batteries, the
  52. multiple instances of Charger Manager share the same charger_global_desc
  53. and it will manage in-suspend monitoring for all instances of Charger Manager.
  54. The user needs to provide all the three entries properly in order to activate
  55. in-suspend monitoring:
  56. struct charger_global_desc {
  57. char *rtc_name;
  58. : The name of rtc (e.g., "rtc0") used to wakeup the system from
  59. suspend for Charger Manager. The alarm interrupt (AIE) of the rtc
  60. should be able to wake up the system from suspend. Charger Manager
  61. saves and restores the alarm value and use the previously-defined
  62. alarm if it is going to go off earlier than Charger Manager so that
  63. Charger Manager does not interfere with previously-defined alarms.
  64. bool (*rtc_only_wakeup)(void);
  65. : This callback should let CM know whether
  66. the wakeup-from-suspend is caused only by the alarm of "rtc" in the
  67. same struct. If there is any other wakeup source triggered the
  68. wakeup, it should return false. If the "rtc" is the only wakeup
  69. reason, it should return true.
  70. bool assume_timer_stops_in_suspend;
  71. : if true, Charger Manager assumes that
  72. the timer (CM uses jiffies as timer) stops during suspend. Then, CM
  73. assumes that the suspend-duration is same as the alarm length.
  74. };
  75. 3. How to setup suspend_again
  76. =============================
  77. Charger Manager provides a function "extern bool cm_suspend_again(void)".
  78. When cm_suspend_again is called, it monitors every battery. The suspend_ops
  79. callback of the system's platform_suspend_ops can call cm_suspend_again
  80. function to know whether Charger Manager wants to suspend again or not.
  81. If there are no other devices or tasks that want to use suspend_again
  82. feature, the platform_suspend_ops may directly refer to cm_suspend_again
  83. for its suspend_again callback.
  84. The cm_suspend_again() returns true (meaning "I want to suspend again")
  85. if the system was woken up by Charger Manager and the polling
  86. (in-suspend monitoring) results in "normal".
  87. 4. Charger-Manager Data (struct charger_desc)
  88. =============================================
  89. For each battery charged independently from other batteries (if a series of
  90. batteries are charged by a single charger, they are counted as one independent
  91. battery), an instance of Charger Manager is attached to it.
  92. struct charger_desc {
  93. char *psy_name;
  94. : The power-supply-class name of the battery. Default is
  95. "battery" if psy_name is NULL. Users can access the psy entries
  96. at "/sys/class/power_supply/[psy_name]/".
  97. enum polling_modes polling_mode;
  98. : CM_POLL_DISABLE: do not poll this battery.
  99. CM_POLL_ALWAYS: always poll this battery.
  100. CM_POLL_EXTERNAL_POWER_ONLY: poll this battery if and only if
  101. an external power source is attached.
  102. CM_POLL_CHARGING_ONLY: poll this battery if and only if the
  103. battery is being charged.
  104. unsigned int fullbatt_vchkdrop_ms;
  105. unsigned int fullbatt_vchkdrop_uV;
  106. : If both have non-zero values, Charger Manager will check the
  107. battery voltage drop fullbatt_vchkdrop_ms after the battery is fully
  108. charged. If the voltage drop is over fullbatt_vchkdrop_uV, Charger
  109. Manager will try to recharge the battery by disabling and enabling
  110. chargers. Recharge with voltage drop condition only (without delay
  111. condition) is needed to be implemented with hardware interrupts from
  112. fuel gauges or charger devices/chips.
  113. unsigned int fullbatt_uV;
  114. : If specified with a non-zero value, Charger Manager assumes
  115. that the battery is full (capacity = 100) if the battery is not being
  116. charged and the battery voltage is equal to or greater than
  117. fullbatt_uV.
  118. unsigned int polling_interval_ms;
  119. : Required polling interval in ms. Charger Manager will poll
  120. this battery every polling_interval_ms or more frequently.
  121. enum data_source battery_present;
  122. : CM_BATTERY_PRESENT: assume that the battery exists.
  123. CM_NO_BATTERY: assume that the battery does not exists.
  124. CM_FUEL_GAUGE: get battery presence information from fuel gauge.
  125. CM_CHARGER_STAT: get battery presence from chargers.
  126. char **psy_charger_stat;
  127. : An array ending with NULL that has power-supply-class names of
  128. chargers. Each power-supply-class should provide "PRESENT" (if
  129. battery_present is "CM_CHARGER_STAT"), "ONLINE" (shows whether an
  130. external power source is attached or not), and "STATUS" (shows whether
  131. the battery is {"FULL" or not FULL} or {"FULL", "Charging",
  132. "Discharging", "NotCharging"}).
  133. int num_charger_regulators;
  134. struct regulator_bulk_data *charger_regulators;
  135. : Regulators representing the chargers in the form for
  136. regulator framework's bulk functions.
  137. char *psy_fuel_gauge;
  138. : Power-supply-class name of the fuel gauge.
  139. int (*temperature_out_of_range)(int *mC);
  140. bool measure_battery_temp;
  141. : This callback returns 0 if the temperature is safe for charging,
  142. a positive number if it is too hot to charge, and a negative number
  143. if it is too cold to charge. With the variable mC, the callback returns
  144. the temperature in 1/1000 of centigrade.
  145. The source of temperature can be battery or ambient one according to
  146. the value of measure_battery_temp.
  147. };
  148. 5. Other Considerations
  149. =======================
  150. At the charger/battery-related events such as battery-pulled-out,
  151. charger-pulled-out, charger-inserted, DCIN-over/under-voltage, charger-stopped,
  152. and others critical to chargers, the system should be configured to wake up.
  153. At least the following should wake up the system from a suspend:
  154. a) charger-on/off b) external-power-in/out c) battery-in/out (while charging)
  155. It is usually accomplished by configuring the PMIC as a wakeup source.