From: "ext Tony Lindgren" <[EMAIL PROTECTED]> Subject: Re: [RFC][DRAFT] TODO list for TI DSP BRIDGE Date: Tue, 19 Aug 2008 09:24:23 +0300
> * Felipe Contreras <[EMAIL PROTECTED]> [080818 23:09]: > > On Mon, Aug 18, 2008 at 10:28 PM, Kanigeri, Hari <[EMAIL PROTECTED]> wrote: > > >> If you mean there is separate clock infrastructure for DSPBridge other > > >> than clock framework we have for OMAP, then DSPBridge should convert > > >> to the one we have for OMAP. As recent work by Paul for clock > > >> framework on OMAP3 and Power domains we need centralized code for clk > > >> and power domains not separate clock infrastructure for DSPBridge. > > >> > > > --- Bridge is not implementing separate clock infrastructure. It is just > > > centralizing the calls to clk_enable in one location as this is called > > > from multiple files in Bridge code. This helps because one can then turn > > > on the traces only for clock module to check if the clocks that were > > > expected to be enabled are enabled or not. As I mentioned before, this > > > helps in debugging. > > > > That only makes the code harder to understand. > > > > #define clk_enable(...) my_debug_function(__VA_ARGS__) > > > > Achieves the same thing. > > We must use clk_enable() and clk_disable() in the drivers. That's the > Linux clock interface. Anything else won't get merged upstream. > > If you need to combine multiple clocks into a single virtual dsp > clock, please register a new custom clock using clk_register(). > > That allows you to do debugging in the custom clock functions too > if necessary. I sent some patches based on the above suggestion. http://marc.info/?l=linux-omap&m=121922597019873&w=2 http://marc.info/?l=linux-omap&m=121922593919766&w=2 I think that this virtual clock may allow any arbitrary combination of clocks and it may be possible to have multiple hierarchy of virtual clocks like: dsp_clocks | |-- peripheral_clocks | | | |-- gpt5 | | |- gpt5_ick | | `- gpt5_fck | |-- .... .. Any comments would be appreciated. Hiroshi DOYU -- 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
