Hi Paul, >From: Paul Walmsley [mailto:paul@xxxxxxxxx] >Sent: Tuesday, October 27, 2009 2:16 PM > >On Tue, 20 Oct 2009, Ramirez Luna, Omar wrote: > >> Also, DVFS Bridge feature won't compile if rebasing onto PM branch >> because it is missing clk notifier functions. > >This should not break compilation. The DSPBridge code must use >platform_data function pointers to call clock notifier functions. > Agree, we do use platform_data to call DVFS related functions: static struct dspbridge_platform_data dspbridge_pdata __initdata = { #ifdef CONFIG_BRIDGE_DVFS .dsp_set_min_opp = omap_pm_dsp_set_min_opp, .dsp_get_opp = omap_pm_dsp_get_opp, .cpu_set_freq = omap_pm_cpu_set_freq, .cpu_get_freq = omap_pm_cpu_get_freq, #endif }; What I meant is that I couldn't find clk_notifier_* functions in pm-branch others than 2.6.28 and 2.6.29, I'll retry looking for them though, I just assumed that they should be under plat-omap/clocks.c >Also, on a related note, I see that EXPORT_SYMBOL() entries have been >added for many OPP-related functions in plat-omap/omap-pm-*.c. This is >not the right way to do it. These also should be called via platform_data >function pointers. > >Then your code will compile no matter whether the OMAP clock notifier or >OMAP PM patches are present or not. The point here is to keep the device >drivers completely separate from architecture-level code, so you could, >for example, use DSPBridge on a DaVinci platform. > >I will post a patch to remove the EXPORT_SYMBOL() entries from the OMAP PM >code. > > >- Paul - omar -- 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
