On Tue, May 24, 2011 at 17:01, Kevin Hilman <khilman@xxxxxx> wrote: > "Menon, Nishanth" <nm@xxxxxx> writes: > >> On Thu, May 19, 2011 at 08:12, Kevin Hilman <khilman@xxxxxx> wrote: >>> Nishanth Menon <nm@xxxxxx> 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 <nm@xxxxxx> >>> >>> 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. yes, I have isolated the code to do that earlier today.. hopefully I should get time to post this out asap. 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
