Hi, Thanks for all the comments. Here is V4 of the patch series. What changed in V4 (or stage1 as discussed in l-o v3): * Search OPP APIs changed. * review comment incorporated History: V3: http://marc.info/?t=125912234200001&r=1&w=2 V2: http://marc.info/?l=linux-omap&m=125809232732700&w=2 V1: http://marc.info/?l=linux-omap&m=125800488923479&w=2 Ref: http://elinux.org/OMAP_Power_Management#Future_directions Also note that OMAP3630 is dependent on clk tree changes which needs to come in - but that is an independent parallel activity. NOTE: SR should be disabled for testing on 3630, there are deltas for OMAP3630 which are not in place in SR codebase and behavior is not trustworthy. TODO Cleanups: * Kevin's recommended cleanups in: http://marc.info/?l=linux-omap&m=125917007423545&w=2 (requesting this be posted once we get the initial set in..) * SRF cleanup in a detailed and to make it robust. * Smartreflex cleanups/refactor + support 3630 TODO items (other than cleanups): * Add on a dependency b/w vdd1 and vdd2 in a clean manner -> probably after we cleanup the resource34xx.c, all folks needing a quick hack can easily follow the following pseudo logic: resource34xx.c::set_opp: if (cpu_is_omap3630()) { vdd1_threshold_freq = 600mhz (opp2) vdd2_required_freq = 200Mhz } else { vdd1_threshold_freq = 500 Mhz (opp3) vdd2_required_freq = 100Mhz } if (vdd1_target < vdd1_threshold_freq) free_vdd2_dep_if_acquired(); /* Do other stuff */ if (vdd1_target_freq >= vdd1_threshold_freq) request_vdd2(at least vdd2_required_freq) The 3630 vdd1->vdd2 dependency comes from the OPP table dependency of OPP100 and above on VDD1 requires VDD2 to be OPP100. VDD2 is free to go as it pleases, but optimal is to be at OPP50 if VDD1 is at OPP50. Lots of possible hacks are possible, and I dont recommend any at the moment. * OMAP3630: Add speedbin detection and enable support for OPP-Turbo and OPP-SB Finally, NOTE: SDP3630 needs the patch for 8250 as discussed here: http://marc.info/?l=linux-omap&m=125873296522723&w=2 (pushed to l-o, will be available once pm is rebased) ==== This patch series is based on previous discussions: http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg17632.html I have modified the initial patch From Sanjeev: http://patchwork.kernel.org/patch/50998/ Other than these, we cannot use the old VDDx_MAX based usage anymore as 3630 OPPs are now different and runtime handling is a must-have, hence introducing these accessor functions is not avoidable. The changes are incremental and tries to avoid intrusive change as much as possible. The OPP accessor functions introduced in this series is hopefully a start for us to optimize this heavily used path. An alternate approach for detecting 3630 OPP is using FEATURES instead of detecting the cpu_type as I have implemented in this series. Testing: mostly on SDP3430 and SDP3630: using cpufreq-utils, sysfs vddx_lock, RET/OFF using shell scripts. Further testing requested. Most of the commands used documented here: http://elinux.org/OMAP_Power_Management Reposting the series for consistency as only 3 patches retained the v1 status due to change in accessor function names and nature. Nishanth Menon (10): Following are the OPP accessor function introduction: omap3: pm: introduce enabled flag to omap_opp omap3: pm: introduce opp accessor functions - v4 omap3: pm: use opp accessor functions for omap34xx - v4 The following are attempts to cleanup existing code from VDDx dep: omap3: pm: srf: use opp accessor functions - v4 omap3: pm: sr: replace get_opp with freq_to_opp - v4 omap3: pm: use opp accessor functions for omap-target - v4 omap3: clk: use pm accessor functions for cpufreq table - v4 omap3: pm: remove VDDx_MIN/MAX macros The following two introduce 3630 support: omap3: pm: introduce 3630 opps - v4 omap3: pm: omap3630 boards: enable 3630 opp tables arch/arm/mach-omap2/board-3430sdp.c | 1 + arch/arm/mach-omap2/board-3630sdp.c | 9 +- arch/arm/mach-omap2/board-omap3beagle.c | 1 + arch/arm/mach-omap2/board-omap3evm.c | 1 + arch/arm/mach-omap2/board-rx51.c | 1 + arch/arm/mach-omap2/board-zoom2.c | 2 + arch/arm/mach-omap2/board-zoom3.c | 9 +- arch/arm/mach-omap2/clock34xx.c | 40 +++-- arch/arm/mach-omap2/omap3-opp.h | 58 +------ arch/arm/mach-omap2/pm.h | 6 + arch/arm/mach-omap2/pm34xx.c | 106 +++++++++++ arch/arm/mach-omap2/resource34xx.c | 238 ++++++++++++++++++------- arch/arm/mach-omap2/smartreflex.c | 44 ++--- arch/arm/plat-omap/Makefile | 3 + arch/arm/plat-omap/cpu-omap.c | 12 +- arch/arm/plat-omap/include/plat/omap-pm.h | 15 +-- arch/arm/plat-omap/include/plat/omap34xx.h | 5 - arch/arm/plat-omap/include/plat/opp.h | 230 +++++++++++++++++++++++ arch/arm/plat-omap/opp.c | 271 ++++++++++++++++++++++++++++ 19 files changed, 863 insertions(+), 189 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/opp.h create mode 100644 arch/arm/plat-omap/opp.c Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
