"Menon, Nishanth" <[email protected]> writes: > On Thu, May 19, 2011 at 08:12, Kevin Hilman <[email protected]> wrote: >> Nishanth Menon <[email protected]> writes: >> >>> OMAP2 does not use OPP tables at the moment for DVFS. Currently, >>> we depend on opp table initialization to give us the freq_table, >>> which makes sense for OMAP3+. for OMAP2, we should be using >>> clk_init_cpufreq_table - so if the opp based frequency table >>> initilization fails, fall back to clk_init_cpufreq_table to give >>> us the table. >>> >>> Signed-off-by: Nishanth Menon <[email protected]> >> >> This is a good approach, but for readability, the OPP version and the >> clk version should probably be separated into separate functions, along >> with their error handling. > > Was thinking more of the lines of splitting the file up. OMAP3+ all > have OPPs defined. only one pending is OMAP2 > Either we introduce OPPs to OMAP2 OR we split it up and depend the OPP > based stuff on ARCH_HAS_OPP and CPUFREQ
Let's take the latter approach, and just focus on a single OPP-based driver. When someone wants to add DVFS for OMAP2, all that's necessary is to add the OPPs. Kevin -- 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
