Thanks for the input guys, Another case (currently not in omap-linux), if when the ohci-omap.c driver needs to check,
val = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST) if (val & OMAP3430ES2_ST_USBHOST_STDBY_MASK) when putting the ohci bus into suspend (which I don't think the current ohci-omap.c currently supports) currently we just have a platform_data callback into the board file, but this really feels like omap specific and would be silly for every board file to implement this if they wanted ohci bus suspend. -- Mike On Mon, Aug 3, 2009 at 3:49 AM, Lohithakshan, Ranjith<[email protected]> 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. > >> >> >> - 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 >> >> -- 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
