opp.txt 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395
  1. Operating Performance Points (OPP) Library
  2. ==========================================
  3. (C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
  4. Contents
  5. --------
  6. 1. Introduction
  7. 2. Initial OPP List Registration
  8. 3. OPP Search Functions
  9. 4. OPP Availability Control Functions
  10. 5. OPP Data Retrieval Functions
  11. 6. Cpufreq Table Generation
  12. 7. Data Structures
  13. 1. Introduction
  14. ===============
  15. 1.1 What is an Operating Performance Point (OPP)?
  16. Complex SoCs of today consists of a multiple sub-modules working in conjunction.
  17. In an operational system executing varied use cases, not all modules in the SoC
  18. need to function at their highest performing frequency all the time. To
  19. facilitate this, sub-modules in a SoC are grouped into domains, allowing some
  20. domains to run at lower voltage and frequency while other domains run at
  21. voltage/frequency pairs that are higher.
  22. The set of discrete tuples consisting of frequency and voltage pairs that
  23. the device will support per domain are called Operating Performance Points or
  24. OPPs.
  25. As an example:
  26. Let us consider an MPU device which supports the following:
  27. {300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V},
  28. {1GHz at minimum voltage of 1.3V}
  29. We can represent these as three OPPs as the following {Hz, uV} tuples:
  30. {300000000, 1000000}
  31. {800000000, 1200000}
  32. {1000000000, 1300000}
  33. 1.2 Operating Performance Points Library
  34. OPP library provides a set of helper functions to organize and query the OPP
  35. information. The library is located in drivers/base/power/opp.c and the header
  36. is located in include/linux/opp.h. OPP library can be enabled by enabling
  37. CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
  38. CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
  39. optionally boot at a certain OPP without needing cpufreq.
  40. Typical usage of the OPP library is as follows:
  41. (users) -> registers a set of default OPPs -> (library)
  42. SoC framework -> modifies on required cases certain OPPs -> OPP layer
  43. -> queries to search/retrieve information ->
  44. Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP
  45. to make the OPP layer available.
  46. OPP layer expects each domain to be represented by a unique device pointer. SoC
  47. framework registers a set of initial OPPs per device with the OPP layer. This
  48. list is expected to be an optimally small number typically around 5 per device.
  49. This initial list contains a set of OPPs that the framework expects to be safely
  50. enabled by default in the system.
  51. Note on OPP Availability:
  52. ------------------------
  53. As the system proceeds to operate, SoC framework may choose to make certain
  54. OPPs available or not available on each device based on various external
  55. factors. Example usage: Thermal management or other exceptional situations where
  56. SoC framework might choose to disable a higher frequency OPP to safely continue
  57. operations until that OPP could be re-enabled if possible.
  58. OPP library facilitates this concept in it's implementation. The following
  59. operational functions operate only on available opps:
  60. opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count
  61. and opp_init_cpufreq_table
  62. opp_find_freq_exact is meant to be used to find the opp pointer which can then
  63. be used for opp_enable/disable functions to make an opp available as required.
  64. WARNING: Users of OPP library should refresh their availability count using
  65. get_opp_count if opp_enable/disable functions are invoked for a device, the
  66. exact mechanism to trigger these or the notification mechanism to other
  67. dependent subsystems such as cpufreq are left to the discretion of the SoC
  68. specific framework which uses the OPP library. Similar care needs to be taken
  69. care to refresh the cpufreq table in cases of these operations.
  70. WARNING on OPP List locking mechanism:
  71. -------------------------------------------------
  72. OPP library uses RCU for exclusivity. RCU allows the query functions to operate
  73. in multiple contexts and this synchronization mechanism is optimal for a read
  74. intensive operations on data structure as the OPP library caters to.
  75. To ensure that the data retrieved are sane, the users such as SoC framework
  76. should ensure that the section of code operating on OPP queries are locked
  77. using RCU read locks. The opp_find_freq_{exact,ceil,floor},
  78. opp_get_{voltage, freq, opp_count} fall into this category.
  79. opp_{add,enable,disable} are updaters which use mutex and implement it's own
  80. RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses
  81. mutex to implment RCU updater strategy. These functions should *NOT* be called
  82. under RCU locks and other contexts that prevent blocking functions in RCU or
  83. mutex operations from working.
  84. 2. Initial OPP List Registration
  85. ================================
  86. The SoC implementation calls opp_add function iteratively to add OPPs per
  87. device. It is expected that the SoC framework will register the OPP entries
  88. optimally- typical numbers range to be less than 5. The list generated by
  89. registering the OPPs is maintained by OPP library throughout the device
  90. operation. The SoC framework can subsequently control the availability of the
  91. OPPs dynamically using the opp_enable / disable functions.
  92. opp_add - Add a new OPP for a specific domain represented by the device pointer.
  93. The OPP is defined using the frequency and voltage. Once added, the OPP
  94. is assumed to be available and control of it's availability can be done
  95. with the opp_enable/disable functions. OPP library internally stores
  96. and manages this information in the opp struct. This function may be
  97. used by SoC framework to define a optimal list as per the demands of
  98. SoC usage environment.
  99. WARNING: Do not use this function in interrupt context.
  100. Example:
  101. soc_pm_init()
  102. {
  103. /* Do things */
  104. r = opp_add(mpu_dev, 1000000, 900000);
  105. if (!r) {
  106. pr_err("%s: unable to register mpu opp(%d)\n", r);
  107. goto no_cpufreq;
  108. }
  109. /* Do cpufreq things */
  110. no_cpufreq:
  111. /* Do remaining things */
  112. }
  113. 3. OPP Search Functions
  114. =======================
  115. High level framework such as cpufreq operates on frequencies. To map the
  116. frequency back to the corresponding OPP, OPP library provides handy functions
  117. to search the OPP list that OPP library internally manages. These search
  118. functions return the matching pointer representing the opp if a match is
  119. found, else returns error. These errors are expected to be handled by standard
  120. error checks such as IS_ERR() and appropriate actions taken by the caller.
  121. opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
  122. availability. This function is especially useful to enable an OPP which
  123. is not available by default.
  124. Example: In a case when SoC framework detects a situation where a
  125. higher frequency could be made available, it can use this function to
  126. find the OPP prior to call the opp_enable to actually make it available.
  127. rcu_read_lock();
  128. opp = opp_find_freq_exact(dev, 1000000000, false);
  129. rcu_read_unlock();
  130. /* dont operate on the pointer.. just do a sanity check.. */
  131. if (IS_ERR(opp)) {
  132. pr_err("frequency not disabled!\n");
  133. /* trigger appropriate actions.. */
  134. } else {
  135. opp_enable(dev,1000000000);
  136. }
  137. NOTE: This is the only search function that operates on OPPs which are
  138. not available.
  139. opp_find_freq_floor - Search for an available OPP which is *at most* the
  140. provided frequency. This function is useful while searching for a lesser
  141. match OR operating on OPP information in the order of decreasing
  142. frequency.
  143. Example: To find the highest opp for a device:
  144. freq = ULONG_MAX;
  145. rcu_read_lock();
  146. opp_find_freq_floor(dev, &freq);
  147. rcu_read_unlock();
  148. opp_find_freq_ceil - Search for an available OPP which is *at least* the
  149. provided frequency. This function is useful while searching for a
  150. higher match OR operating on OPP information in the order of increasing
  151. frequency.
  152. Example 1: To find the lowest opp for a device:
  153. freq = 0;
  154. rcu_read_lock();
  155. opp_find_freq_ceil(dev, &freq);
  156. rcu_read_unlock();
  157. Example 2: A simplified implementation of a SoC cpufreq_driver->target:
  158. soc_cpufreq_target(..)
  159. {
  160. /* Do stuff like policy checks etc. */
  161. /* Find the best frequency match for the req */
  162. rcu_read_lock();
  163. opp = opp_find_freq_ceil(dev, &freq);
  164. rcu_read_unlock();
  165. if (!IS_ERR(opp))
  166. soc_switch_to_freq_voltage(freq);
  167. else
  168. /* do something when we can't satisfy the req */
  169. /* do other stuff */
  170. }
  171. 4. OPP Availability Control Functions
  172. =====================================
  173. A default OPP list registered with the OPP library may not cater to all possible
  174. situation. The OPP library provides a set of functions to modify the
  175. availability of a OPP within the OPP list. This allows SoC frameworks to have
  176. fine grained dynamic control of which sets of OPPs are operationally available.
  177. These functions are intended to *temporarily* remove an OPP in conditions such
  178. as thermal considerations (e.g. don't use OPPx until the temperature drops).
  179. WARNING: Do not use these functions in interrupt context.
  180. opp_enable - Make a OPP available for operation.
  181. Example: Lets say that 1GHz OPP is to be made available only if the
  182. SoC temperature is lower than a certain threshold. The SoC framework
  183. implementation might choose to do something as follows:
  184. if (cur_temp < temp_low_thresh) {
  185. /* Enable 1GHz if it was disabled */
  186. rcu_read_lock();
  187. opp = opp_find_freq_exact(dev, 1000000000, false);
  188. rcu_read_unlock();
  189. /* just error check */
  190. if (!IS_ERR(opp))
  191. ret = opp_enable(dev, 1000000000);
  192. else
  193. goto try_something_else;
  194. }
  195. opp_disable - Make an OPP to be not available for operation
  196. Example: Lets say that 1GHz OPP is to be disabled if the temperature
  197. exceeds a threshold value. The SoC framework implementation might
  198. choose to do something as follows:
  199. if (cur_temp > temp_high_thresh) {
  200. /* Disable 1GHz if it was enabled */
  201. rcu_read_lock();
  202. opp = opp_find_freq_exact(dev, 1000000000, true);
  203. rcu_read_unlock();
  204. /* just error check */
  205. if (!IS_ERR(opp))
  206. ret = opp_disable(dev, 1000000000);
  207. else
  208. goto try_something_else;
  209. }
  210. 5. OPP Data Retrieval Functions
  211. ===============================
  212. Since OPP library abstracts away the OPP information, a set of functions to pull
  213. information from the OPP structure is necessary. Once an OPP pointer is
  214. retrieved using the search functions, the following functions can be used by SoC
  215. framework to retrieve the information represented inside the OPP layer.
  216. opp_get_voltage - Retrieve the voltage represented by the opp pointer.
  217. Example: At a cpufreq transition to a different frequency, SoC
  218. framework requires to set the voltage represented by the OPP using
  219. the regulator framework to the Power Management chip providing the
  220. voltage.
  221. soc_switch_to_freq_voltage(freq)
  222. {
  223. /* do things */
  224. rcu_read_lock();
  225. opp = opp_find_freq_ceil(dev, &freq);
  226. v = opp_get_voltage(opp);
  227. rcu_read_unlock();
  228. if (v)
  229. regulator_set_voltage(.., v);
  230. /* do other things */
  231. }
  232. opp_get_freq - Retrieve the freq represented by the opp pointer.
  233. Example: Lets say the SoC framework uses a couple of helper functions
  234. we could pass opp pointers instead of doing additional parameters to
  235. handle quiet a bit of data parameters.
  236. soc_cpufreq_target(..)
  237. {
  238. /* do things.. */
  239. max_freq = ULONG_MAX;
  240. rcu_read_lock();
  241. max_opp = opp_find_freq_floor(dev,&max_freq);
  242. requested_opp = opp_find_freq_ceil(dev,&freq);
  243. if (!IS_ERR(max_opp) && !IS_ERR(requested_opp))
  244. r = soc_test_validity(max_opp, requested_opp);
  245. rcu_read_unlock();
  246. /* do other things */
  247. }
  248. soc_test_validity(..)
  249. {
  250. if(opp_get_voltage(max_opp) < opp_get_voltage(requested_opp))
  251. return -EINVAL;
  252. if(opp_get_freq(max_opp) < opp_get_freq(requested_opp))
  253. return -EINVAL;
  254. /* do things.. */
  255. }
  256. opp_get_opp_count - Retrieve the number of available opps for a device
  257. Example: Lets say a co-processor in the SoC needs to know the available
  258. frequencies in a table, the main processor can notify as following:
  259. soc_notify_coproc_available_frequencies()
  260. {
  261. /* Do things */
  262. rcu_read_lock();
  263. num_available = opp_get_opp_count(dev);
  264. speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL);
  265. /* populate the table in increasing order */
  266. freq = 0;
  267. while (!IS_ERR(opp = opp_find_freq_ceil(dev, &freq))) {
  268. speeds[i] = freq;
  269. freq++;
  270. i++;
  271. }
  272. rcu_read_unlock();
  273. soc_notify_coproc(AVAILABLE_FREQs, speeds, num_available);
  274. /* Do other things */
  275. }
  276. 6. Cpufreq Table Generation
  277. ===========================
  278. opp_init_cpufreq_table - cpufreq framework typically is initialized with
  279. cpufreq_frequency_table_cpuinfo which is provided with the list of
  280. frequencies that are available for operation. This function provides
  281. a ready to use conversion routine to translate the OPP layer's internal
  282. information about the available frequencies into a format readily
  283. providable to cpufreq.
  284. WARNING: Do not use this function in interrupt context.
  285. Example:
  286. soc_pm_init()
  287. {
  288. /* Do things */
  289. r = opp_init_cpufreq_table(dev, &freq_table);
  290. if (!r)
  291. cpufreq_frequency_table_cpuinfo(policy, freq_table);
  292. /* Do other things */
  293. }
  294. NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
  295. addition to CONFIG_PM as power management feature is required to
  296. dynamically scale voltage and frequency in a system.
  297. opp_free_cpufreq_table - Free up the table allocated by opp_init_cpufreq_table
  298. 7. Data Structures
  299. ==================
  300. Typically an SoC contains multiple voltage domains which are variable. Each
  301. domain is represented by a device pointer. The relationship to OPP can be
  302. represented as follows:
  303. SoC
  304. |- device 1
  305. | |- opp 1 (availability, freq, voltage)
  306. | |- opp 2 ..
  307. ... ...
  308. | `- opp n ..
  309. |- device 2
  310. ...
  311. `- device m
  312. OPP library maintains a internal list that the SoC framework populates and
  313. accessed by various functions as described above. However, the structures
  314. representing the actual OPPs and domains are internal to the OPP library itself
  315. to allow for suitable abstraction reusable across systems.
  316. struct opp - The internal data structure of OPP library which is used to
  317. represent an OPP. In addition to the freq, voltage, availability
  318. information, it also contains internal book keeping information required
  319. for the OPP library to operate on. Pointer to this structure is
  320. provided back to the users such as SoC framework to be used as a
  321. identifier for OPP in the interactions with OPP layer.
  322. WARNING: The struct opp pointer should not be parsed or modified by the
  323. users. The defaults of for an instance is populated by opp_add, but the
  324. availability of the OPP can be modified by opp_enable/disable functions.
  325. struct device - This is used to identify a domain to the OPP layer. The
  326. nature of the device and it's implementation is left to the user of
  327. OPP library such as the SoC framework.
  328. Overall, in a simplistic view, the data structure operations is represented as
  329. following:
  330. Initialization / modification:
  331. +-----+ /- opp_enable
  332. opp_add --> | opp | <-------
  333. | +-----+ \- opp_disable
  334. \-------> domain_info(device)
  335. Search functions:
  336. /-- opp_find_freq_ceil ---\ +-----+
  337. domain_info<---- opp_find_freq_exact -----> | opp |
  338. \-- opp_find_freq_floor ---/ +-----+
  339. Retrieval functions:
  340. +-----+ /- opp_get_voltage
  341. | opp | <---
  342. +-----+ \- opp_get_freq
  343. domain_info <- opp_get_opp_count