aboutsummaryrefslogtreecommitdiffstats
path: root/packages/linux/linux-omap-2.6.26/beagleboard/07-omappm-srf-updates.eml
blob: 735e991298ac02e2e42afeb5dd9ef560b8d0d3c8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Updates the omap-pm apis with calls to SRF implementation

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/plat-omap/omap-pm-srf.c |   84 +++++++++------------------------------
 1 files changed, 20 insertions(+), 64 deletions(-)

Index: linux-omap-2.6/arch/arm/plat-omap/omap-pm-srf.c
===================================================================
--- linux-omap-2.6.orig/arch/arm/plat-omap/omap-pm-srf.c	2008-07-21
12:10:19.824596984 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/omap-pm-srf.c	2008-07-21
12:10:21.626540178 +0530
@@ -25,6 +25,7 @@
 #include <linux/init.h>
 #include <linux/cpufreq.h>
 #include <linux/device.h>
+#include <linux/module.h>

 /* Interface documentation is in asm/arch/omap-pm.h */
 #include <asm/arch/omap-pm.h>
@@ -121,6 +122,7 @@ void omap_pm_set_max_dev_wakeup_lat(stru
 		WARN_ON(1);
 		return;
 	};
+
 	/* Look for the devices Power Domain */
 	/* TODO: Put this back in once tiocp layer is available
 	tiocp_dev = container_of(dev, struct tiocp, dev);
@@ -138,19 +140,6 @@ void omap_pm_set_max_dev_wakeup_lat(stru
 		res_name = get_lat_res_name(pwrdm_dev->name);
 		resource_request(res_name, dev, t);
 	}
-
-	/*
-	 * For current Linux, this needs to map the device to a
-	 * powerdomain, then go through the list of current max lat
-	 * constraints on that powerdomain and find the smallest.  If
-	 * the latency constraint has changed, the code should
-	 * recompute the state to enter for the next powerdomain
-	 * state.  Conceivably, this code should also determine
-	 * whether to actually disable the device clocks or not,
-	 * depending on how long it takes to re-enable the clocks.
-	 *
-	 * TI CDP code can call constraint_set here.
-	 */
 }

 void omap_pm_set_max_sdma_lat(struct device *dev, long t)
@@ -169,21 +158,9 @@ void omap_pm_set_max_sdma_lat(struct dev
 			 "dev %s, t = %ld usec\n", dev_name(dev), t);
 		resource_request("core_latency", dev, t);
 	}
-
-	/*
-	 * For current Linux PM QOS params, this code should scan the
-	 * list of maximum CPU and DMA latencies and select the
-	 * smallest, then set cpu_dma_latency pm_qos_param
-	 * accordingly.
-	 *
-	 * For future Linux PM QOS params, with separate CPU and DMA
-	 * latency params, this code should just set the dma_latency param.
-	 *
-	 * TI CDP code can call constraint_set here.
-	 */
-
 }

+static struct device dummy_dsp_dev;

 /*
  * DSP Bridge-specific constraints
@@ -200,6 +177,7 @@ const struct omap_opp *omap_pm_dsp_get_o

 	return NULL;
 }
+EXPORT_SYMBOL(omap_pm_dsp_get_opp_table);

 void omap_pm_dsp_set_min_opp(u8 opp_id)
 {
@@ -210,36 +188,21 @@ void omap_pm_dsp_set_min_opp(u8 opp_id)

 	pr_debug("OMAP PM: DSP requests minimum VDD1 OPP to be %d\n", opp_id);

-	/*
-	 *
-	 * For l-o dev tree, our VDD1 clk is keyed on OPP ID, so we
-	 * can just test to see which is higher, the CPU's desired OPP
-	 * ID or the DSP's desired OPP ID, and use whichever is
-	 * highest.
-	 *
-	 * In CDP12.14+, the VDD1 OPP custom clock that controls the DSP
-	 * rate is keyed on MPU speed, not the OPP ID.  So we need to
-	 * map the OPP ID to the MPU speed for use with clk_set_rate()
-	 * if it is higher than the current OPP clock rate.
-	 *
-	 */
-}
+	/* For now pass a dummy_dev struct for SRF to identify the caller.
+	* Maybe its good to have DSP pass this as an argument
+	*/
+	resource_request("vdd1_opp", &dummy_dsp_dev, opp_id);
+	return;

+}
+EXPORT_SYMBOL(omap_pm_dsp_set_min_opp);

 u8 omap_pm_dsp_get_opp(void)
 {
 	pr_debug("OMAP PM: DSP requests current DSP OPP ID\n");
-
-	/*
-	 * For l-o dev tree, call clk_get_rate() on VDD1 OPP clock
-	 *
-	 * CDP12.14+:
-	 * Call clk_get_rate() on the OPP custom clock, map that to an
-	 * OPP ID using the tables defined in board-*.c/chip-*.c files.
-	 */
-
-	return 0;
+	return resource_get_level("vdd1_opp");
 }
+EXPORT_SYMBOL(omap_pm_dsp_get_opp);

 /*
  * CPUFreq-originated constraint
@@ -261,6 +224,8 @@ struct cpufreq_frequency_table **omap_pm
 	return NULL;
 }

+static struct device dummy_cpufreq_dev;
+
 void omap_pm_cpu_set_freq(unsigned long f)
 {
 	if (f == 0) {
@@ -271,26 +236,17 @@ void omap_pm_cpu_set_freq(unsigned long
 	pr_debug("OMAP PM: CPUFreq requests CPU frequency to be set to %lu\n",
 		 f);

-	/*
-	 * For l-o dev tree, determine whether MPU freq or DSP OPP id
-	 * freq is higher.  Find the OPP ID corresponding to the
-	 * higher frequency.  Call clk_round_rate() and clk_set_rate()
-	 * on the OPP custom clock.
-	 *
-	 * CDP should just be able to set the VDD1 OPP clock rate here.
-	 */
+	resource_request("mpu_freq", &dummy_cpufreq_dev, f);
+	return;
 }
+EXPORT_SYMBOL(omap_pm_cpu_set_freq);

 unsigned long omap_pm_cpu_get_freq(void)
 {
 	pr_debug("OMAP PM: CPUFreq requests current CPU frequency\n");
-
-	/*
-	 * Call clk_get_rate() on the mpu_ck.
-	 */
-
-	return 0;
+	return resource_get_level("mpu_freq");
 }
+EXPORT_SYMBOL(omap_pm_cpu_get_freq);

 struct device omap_pm_dev;



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html