diff options
Diffstat (limited to 'recipes/linux/linux-omap2-git/beagleboard/07-omappm-srf-updates.eml')
| -rw-r--r-- | recipes/linux/linux-omap2-git/beagleboard/07-omappm-srf-updates.eml | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/recipes/linux/linux-omap2-git/beagleboard/07-omappm-srf-updates.eml b/recipes/linux/linux-omap2-git/beagleboard/07-omappm-srf-updates.eml new file mode 100644 index 0000000000..735e991298 --- /dev/null +++ b/recipes/linux/linux-omap2-git/beagleboard/07-omappm-srf-updates.eml @@ -0,0 +1,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 |