omap4: opp: add OPP table data
[deliverable/linux.git] / arch / arm / plat-omap / include / plat / omap-pm.h
CommitLineData
c0407a96
PW
1/*
2 * omap-pm.h - OMAP power management interface
3 *
564889c1
PW
4 * Copyright (C) 2008-2010 Texas Instruments, Inc.
5 * Copyright (C) 2008-2010 Nokia Corporation
c0407a96
PW
6 * Paul Walmsley
7 *
8 * Interface developed by (in alphabetical order): Karthik Dasu, Jouni
9 * Högander, Tony Lindgren, Rajendra Nayak, Sakari Poussa,
10 * Veeramanikandan Raju, Anand Sawant, Igor Stoppa, Paul Walmsley,
11 * Richard Woodruff
12 */
13
14#ifndef ASM_ARM_ARCH_OMAP_OMAP_PM_H
15#define ASM_ARM_ARCH_OMAP_OMAP_PM_H
16
17#include <linux/device.h>
18#include <linux/cpufreq.h>
fb8ce14c 19#include <linux/clk.h>
c0407a96
PW
20
21#include "powerdomain.h"
22
23/**
24 * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
25 * @rate: target clock rate
26 * @opp_id: OPP ID
27 * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
28 *
29 * Operating performance point data. Can vary by OMAP chip and board.
30 */
31struct omap_opp {
32 unsigned long rate;
33 u8 opp_id;
34 u16 min_vdd;
35};
36
37extern struct omap_opp *mpu_opps;
38extern struct omap_opp *dsp_opps;
39extern struct omap_opp *l3_opps;
40
41/*
42 * agent_id values for use with omap_pm_set_min_bus_tput():
43 *
44 * OCP_INITIATOR_AGENT is only valid for devices that can act as
45 * initiators -- it represents the device's L3 interconnect
46 * connection. OCP_TARGET_AGENT represents the device's L4
47 * interconnect connection.
48 */
49#define OCP_TARGET_AGENT 1
50#define OCP_INITIATOR_AGENT 2
51
52/**
53 * omap_pm_if_early_init - OMAP PM init code called before clock fw init
54 * @mpu_opp_table: array ptr to struct omap_opp for MPU
55 * @dsp_opp_table: array ptr to struct omap_opp for DSP
56 * @l3_opp_table : array ptr to struct omap_opp for CORE
57 *
58 * Initialize anything that must be configured before the clock
59 * framework starts. The "_if_" is to avoid name collisions with the
60 * PM idle-loop code.
61 */
62int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
63 struct omap_opp *dsp_opp_table,
64 struct omap_opp *l3_opp_table);
65
66/**
67 * omap_pm_if_init - OMAP PM init code called after clock fw init
68 *
69 * The main initialization code. OPP tables are passed in here. The
70 * "_if_" is to avoid name collisions with the PM idle-loop code.
71 */
72int __init omap_pm_if_init(void);
73
74/**
75 * omap_pm_if_exit - OMAP PM exit code
76 *
77 * Exit code; currently unused. The "_if_" is to avoid name
78 * collisions with the PM idle-loop code.
79 */
80void omap_pm_if_exit(void);
81
82/*
83 * Device-driver-originated constraints (via board-*.c files, platform_data)
84 */
85
86
87/**
88 * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
89 * @dev: struct device * requesting the constraint
90 * @t: maximum MPU wakeup latency in microseconds
91 *
92 * Request that the maximum interrupt latency for the MPU to be no
564889c1 93 * greater than @t microseconds. "Interrupt latency" in this case is
c0407a96
PW
94 * defined as the elapsed time from the occurrence of a hardware or
95 * timer interrupt to the time when the device driver's interrupt
96 * service routine has been entered by the MPU.
97 *
98 * It is intended that underlying PM code will use this information to
99 * determine what power state to put the MPU powerdomain into, and
100 * possibly the CORE powerdomain as well, since interrupt handling
101 * code currently runs from SDRAM. Advanced PM or board*.c code may
102 * also configure interrupt controller priorities, OCP bus priorities,
103 * CPU speed(s), etc.
104 *
105 * This function will not affect device wakeup latency, e.g., time
106 * elapsed from when a device driver enables a hardware device with
107 * clk_enable(), to when the device is ready for register access or
108 * other use. To control this device wakeup latency, use
564889c1 109 * omap_pm_set_max_dev_wakeup_lat()
c0407a96 110 *
564889c1 111 * Multiple calls to omap_pm_set_max_mpu_wakeup_lat() will replace the
c0407a96
PW
112 * previous t value. To remove the latency target for the MPU, call
113 * with t = -1.
114 *
564889c1
PW
115 * XXX This constraint will be deprecated soon in favor of the more
116 * general omap_pm_set_max_dev_wakeup_lat()
117 *
118 * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
119 * is not satisfiable, or 0 upon success.
c0407a96 120 */
564889c1 121int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
c0407a96
PW
122
123
124/**
125 * omap_pm_set_min_bus_tput - set minimum bus throughput needed by device
126 * @dev: struct device * requesting the constraint
127 * @tbus_id: interconnect to operate on (OCP_{INITIATOR,TARGET}_AGENT)
128 * @r: minimum throughput (in KiB/s)
129 *
130 * Request that the minimum data throughput on the OCP interconnect
564889c1
PW
131 * attached to device @dev interconnect agent @tbus_id be no less
132 * than @r KiB/s.
c0407a96
PW
133 *
134 * It is expected that the OMAP PM or bus code will use this
135 * information to set the interconnect clock to run at the lowest
136 * possible speed that satisfies all current system users. The PM or
137 * bus code will adjust the estimate based on its model of the bus, so
138 * device driver authors should attempt to specify an accurate
139 * quantity for their device use case, and let the PM or bus code
140 * overestimate the numbers as necessary to handle request/response
141 * latency, other competing users on the system, etc. On OMAP2/3, if
142 * a driver requests a minimum L4 interconnect speed constraint, the
143 * code will also need to add an minimum L3 interconnect speed
144 * constraint,
145 *
564889c1
PW
146 * Multiple calls to omap_pm_set_min_bus_tput() will replace the
147 * previous rate value for this device. To remove the interconnect
148 * throughput restriction for this device, call with r = 0.
c0407a96 149 *
564889c1
PW
150 * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
151 * is not satisfiable, or 0 upon success.
c0407a96 152 */
564889c1 153int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r);
c0407a96
PW
154
155
156/**
157 * omap_pm_set_max_dev_wakeup_lat - set the maximum device enable latency
564889c1
PW
158 * @req_dev: struct device * requesting the constraint, or NULL if none
159 * @dev: struct device * to set the constraint one
c0407a96
PW
160 * @t: maximum device wakeup latency in microseconds
161 *
564889c1
PW
162 * Request that the maximum amount of time necessary for a device @dev
163 * to become accessible after its clocks are enabled should be no
164 * greater than @t microseconds. Specifically, this represents the
165 * time from when a device driver enables device clocks with
166 * clk_enable(), to when the register reads and writes on the device
167 * will succeed. This function should be called before clk_disable()
168 * is called, since the power state transition decision may be made
169 * during clk_disable().
c0407a96
PW
170 *
171 * It is intended that underlying PM code will use this information to
172 * determine what power state to put the powerdomain enclosing this
173 * device into.
174 *
564889c1
PW
175 * Multiple calls to omap_pm_set_max_dev_wakeup_lat() will replace the
176 * previous wakeup latency values for this device. To remove the
177 * wakeup latency restriction for this device, call with t = -1.
c0407a96 178 *
564889c1
PW
179 * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
180 * is not satisfiable, or 0 upon success.
c0407a96 181 */
564889c1
PW
182int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
183 long t);
c0407a96
PW
184
185
186/**
187 * omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start latency
188 * @dev: struct device *
189 * @t: maximum DMA transfer start latency in microseconds
190 *
191 * Request that the maximum system DMA transfer start latency for this
192 * device 'dev' should be no greater than 't' microseconds. "DMA
193 * transfer start latency" here is defined as the elapsed time from
194 * when a device (e.g., McBSP) requests that a system DMA transfer
195 * start or continue, to the time at which data starts to flow into
196 * that device from the system DMA controller.
197 *
198 * It is intended that underlying PM code will use this information to
199 * determine what power state to put the CORE powerdomain into.
200 *
201 * Since system DMA transfers may not involve the MPU, this function
202 * will not affect MPU wakeup latency. Use set_max_cpu_lat() to do
203 * so. Similarly, this function will not affect device wakeup latency
204 * -- use set_max_dev_wakeup_lat() to affect that.
205 *
206 * Multiple calls to set_max_sdma_lat() will replace the previous t
207 * value for this device. To remove the maximum DMA latency for this
208 * device, call with t = -1.
209 *
564889c1
PW
210 * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
211 * is not satisfiable, or 0 upon success.
c0407a96 212 */
564889c1 213int omap_pm_set_max_sdma_lat(struct device *dev, long t);
c0407a96
PW
214
215
fb8ce14c
PW
216/**
217 * omap_pm_set_min_clk_rate - set minimum clock rate requested by @dev
218 * @dev: struct device * requesting the constraint
219 * @clk: struct clk * to set the minimum rate constraint on
220 * @r: minimum rate in Hz
221 *
222 * Request that the minimum clock rate on the device @dev's clk @clk
223 * be no less than @r Hz.
224 *
225 * It is expected that the OMAP PM code will use this information to
226 * find an OPP or clock setting that will satisfy this clock rate
227 * constraint, along with any other applicable system constraints on
228 * the clock rate or corresponding voltage, etc.
229 *
230 * omap_pm_set_min_clk_rate() differs from the clock code's
231 * clk_set_rate() in that it considers other constraints before taking
232 * any hardware action, and may change a system OPP rather than just a
233 * clock rate. clk_set_rate() is intended to be a low-level
234 * interface.
235 *
236 * omap_pm_set_min_clk_rate() is easily open to abuse. A better API
237 * would be something like "omap_pm_set_min_dev_performance()";
238 * however, there is no easily-generalizable concept of performance
239 * that applies to all devices. Only a device (and possibly the
240 * device subsystem) has both the subsystem-specific knowledge, and
241 * the hardware IP block-specific knowledge, to translate a constraint
242 * on "touchscreen sampling accuracy" or "number of pixels or polygons
243 * rendered per second" to a clock rate. This translation can be
244 * dependent on the hardware IP block's revision, or firmware version,
245 * and the driver is the only code on the system that has this
246 * information and can know how to translate that into a clock rate.
247 *
248 * The intended use-case for this function is for userspace or other
249 * kernel code to communicate a particular performance requirement to
250 * a subsystem; then for the subsystem to communicate that requirement
251 * to something that is meaningful to the device driver; then for the
252 * device driver to convert that requirement to a clock rate, and to
253 * then call omap_pm_set_min_clk_rate().
254 *
255 * Users of this function (such as device drivers) should not simply
256 * call this function with some high clock rate to ensure "high
257 * performance." Rather, the device driver should take a performance
258 * constraint from its subsystem, such as "render at least X polygons
259 * per second," and use some formula or table to convert that into a
260 * clock rate constraint given the hardware type and hardware
261 * revision. Device drivers or subsystems should not assume that they
262 * know how to make a power/performance tradeoff - some device use
263 * cases may tolerate a lower-fidelity device function for lower power
264 * consumption; others may demand a higher-fidelity device function,
265 * no matter what the power consumption.
266 *
267 * Multiple calls to omap_pm_set_min_clk_rate() will replace the
268 * previous rate value for the device @dev. To remove the minimum clock
269 * rate constraint for the device, call with r = 0.
270 *
271 * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
272 * is not satisfiable, or 0 upon success.
273 */
274int omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r);
275
c0407a96
PW
276/*
277 * DSP Bridge-specific constraints
278 */
279
280/**
281 * omap_pm_dsp_get_opp_table - get OPP->DSP clock frequency table
282 *
283 * Intended for use by DSPBridge. Returns an array of OPP->DSP clock
284 * frequency entries. The final item in the array should have .rate =
285 * .opp_id = 0.
286 */
287const struct omap_opp *omap_pm_dsp_get_opp_table(void);
288
289/**
290 * omap_pm_dsp_set_min_opp - receive desired OPP target ID from DSP Bridge
291 * @opp_id: target DSP OPP ID
292 *
293 * Set a minimum OPP ID for the DSP. This is intended to be called
294 * only from the DSP Bridge MPU-side driver. Unfortunately, the only
295 * information that code receives from the DSP/BIOS load estimator is the
296 * target OPP ID; hence, this interface. No return value.
297 */
298void omap_pm_dsp_set_min_opp(u8 opp_id);
299
300/**
301 * omap_pm_dsp_get_opp - report the current DSP OPP ID
302 *
303 * Report the current OPP for the DSP. Since on OMAP3, the DSP and
304 * MPU share a single voltage domain, the OPP ID returned back may
305 * represent a higher DSP speed than the OPP requested via
306 * omap_pm_dsp_set_min_opp().
307 *
308 * Returns the current VDD1 OPP ID, or 0 upon error.
309 */
310u8 omap_pm_dsp_get_opp(void);
311
312
313/*
314 * CPUFreq-originated constraint
315 *
316 * In the future, this should be handled by custom OPP clocktype
317 * functions.
318 */
319
320/**
321 * omap_pm_cpu_get_freq_table - return a cpufreq_frequency_table array ptr
322 *
323 * Provide a frequency table usable by CPUFreq for the current chip/board.
324 * Returns a pointer to a struct cpufreq_frequency_table array or NULL
325 * upon error.
326 */
327struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void);
328
329/**
330 * omap_pm_cpu_set_freq - set the current minimum MPU frequency
331 * @f: MPU frequency in Hz
332 *
333 * Set the current minimum CPU frequency. The actual CPU frequency
334 * used could end up higher if the DSP requested a higher OPP.
335 * Intended to be called by plat-omap/cpu_omap.c:omap_target(). No
336 * return value.
337 */
338void omap_pm_cpu_set_freq(unsigned long f);
339
340/**
341 * omap_pm_cpu_get_freq - report the current CPU frequency
342 *
343 * Returns the current MPU frequency, or 0 upon error.
344 */
345unsigned long omap_pm_cpu_get_freq(void);
346
347
348/*
349 * Device context loss tracking
350 */
351
352/**
353 * omap_pm_get_dev_context_loss_count - return count of times dev has lost ctx
354 * @dev: struct device *
355 *
356 * This function returns the number of times that the device @dev has
357 * lost its internal context. This generally occurs on a powerdomain
358 * transition to OFF. Drivers use this as an optimization to avoid restoring
359 * context if the device hasn't lost it. To use, drivers should initially
360 * call this in their context save functions and store the result. Early in
361 * the driver's context restore function, the driver should call this function
362 * again, and compare the result to the stored counter. If they differ, the
363 * driver must restore device context. If the number of context losses
364 * exceeds the maximum positive integer, the function will wrap to 0 and
365 * continue counting. Returns the number of context losses for this device,
366 * or -EINVAL upon error.
367 */
368int omap_pm_get_dev_context_loss_count(struct device *dev);
369
370
371#endif
This page took 0.111549 seconds and 5 git commands to generate.