Hi Hari, On Mon, Aug 18, 2008 at 9:57 PM, Kanigeri, Hari <h-kanigeri2@xxxxxx> wrote: > Hi, > >> Some of the above items are being looked at like replacing CSL, isr etc.. >> But there are no equivalent API's or functionality available in kernel for >> many of them. We should replace the API's with the avaolable kernel API's >> and the remaining need to be looked at from long term. >> > > -- I agree with Vijay. We can remove the simple wrapper functions like the ones in CSL and ISR, but some of the other modules in the services provide more functionality than just being the wrappers. We don't want to compromise on any current debugging features that are provided by these modules at the expense of replacing the services functions with direct kernel calls. This would require careful analysis. > > If any one has done any analysis on the services functions that can be removed without compromising the functionality and debugging feature, please share it on the mailing list. > > On the comment to remove clk.c, I don't agree with it. I think it provides an advantage of having a clk module in the DSP Bridge as all the calls to clock module are centralized in one location, which would aid in Bridge debugging. > 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. Richard and Paul can probably explain more about OMAP clock framework and why it has to be used by DSPBridge too. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- 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
