> 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. Thank you, Best regards, Hari > -----Original Message----- > From: Trilok Soni [mailto:soni.trilok@xxxxxxxxx] > Sent: Monday, August 18, 2008 12:17 PM > To: Kanigeri, Hari > Cc: Pasam, Vijay; Hiroshi DOYU; linux-omap@xxxxxxxxxxxxxxx; Woodruff, > Richard; felipe.contreras@xxxxxxxxx; siarhei.siamashka@xxxxxxxxx; Ramirez > Luna, Omar; Gupta, Ramesh; tony@xxxxxxxxxxx > Subject: Re: [RFC][DRAFT] TODO list for TI DSP BRIDGE > > 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
