On Mon, 3 Aug 2009, Lohithakshan, Ranjith wrote: > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Paul Walmsley > > Sent: Monday, August 03, 2009 5:04 AM > > To: Pandita, Vikram > > Cc: Mike Chan; Kevin Hilman; [email protected] > > Subject: RE: drivers that require headers in mach-omap > > > > On Fri, 31 Jul 2009, Pandita, Vikram wrote: > > > > > >-----Original Message----- > > > >From: Mike Chan [mailto:[email protected]] > > > >Sent: Thursday, July 30, 2009 6:20 PM > > > >To: Pandita, Vikram > > > >Cc: Kevin Hilman; [email protected] > > > >Subject: Re: drivers that require headers in mach-omap > > > > > > > >On Thu, Jul 30, 2009 at 8:44 AM, Pandita, > > Vikram<[email protected]> wrote: > > > >> > > > >>>-----Original Message----- > > > >>>From: [email protected] > > > >>>[mailto:[email protected]] On Behalf Of Mike Chan > > > >>>Sent: Tuesday, July 28, 2009 8:49 PM > > > >>>To: Kevin Hilman; [email protected] > > > >>>Subject: drivers that require headers in mach-omap > > > >>> > > > >>>Omap folks, how are drivers that require access to prm and cm > > > >>>registers via cm_read_mod_reg() etc... suppose to access these? > > > >>> > > > >>>For example if drivers/usb/host/ohci-omap.c wanted to call: > > > >>>cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST); > > > >> > > > >> The design was supposed to encapsulate the PRCM API's > > from drivers. > > > >> Driver has control over the iclk and fclk and the clock > > framework > > > >> would take care of any CM/PRM > > > >register settings. > > > >> > > > >> Accessing these registers in drivers would make the > > driver non-compatible for non-omap platforms. > > > >> > > > > > > > >Are drivers such as > > > > > > > >drivers/usb/host/ohci-omap.c > > > >drivers/usb/musb/omap2430.c > > > > > > > >suppose to be compatible for non-omap platforms? > > > > > > As you put it, no they are not. > > > All PRM/CM register accesses have been restricted to > > mach-omap2/plat-omap parts till now. > > > The question to ask is, what functionality is missing on > > enabling say the usbhost clock that clock framework is not > > doing, that driver has a need to do. > > > > Just to follow up on this: the plan should be to remove all > > PRM and CM references from those drivers. Some of those can > > be replaced with clock framework calls, others may need > > platform_data function pointers. > > To add to the list, drivers/usb/host/ehci-omap.c need a similar re-work. At > the moment, > it does some amount of DPLL5 programming in itself before enabling the iclk > and fclk.
I think Vikram and a couple others are working on fixing this one. - Paul -- 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
