Updates the omap-pm apis with calls to SRF implementation
Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
---
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html