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<ranjithl@xxxxxx> wrote: > > >> -----Original Message----- >> From: linux-omap-owner@xxxxxxxxxxxxxxx >> [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley >> Sent: Monday, August 03, 2009 5:04 AM >> To: Pandita, Vikram >> Cc: Mike Chan; Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx >> Subject: RE: drivers that require headers in mach-omap >> >> On Fri, 31 Jul 2009, Pandita, Vikram wrote: >> >> > >-----Original Message----- >> > >From: Mike Chan [mailto:mike@xxxxxxxxxxx] >> > >Sent: Thursday, July 30, 2009 6:20 PM >> > >To: Pandita, Vikram >> > >Cc: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx >> > >Subject: Re: drivers that require headers in mach-omap >> > > >> > >On Thu, Jul 30, 2009 at 8:44 AM, Pandita, >> Vikram<vikram.pandita@xxxxxx> wrote: >> > >> >> > >>>-----Original Message----- >> > >>>From: linux-omap-owner@xxxxxxxxxxxxxxx >> > >>>[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Mike Chan >> > >>>Sent: Tuesday, July 28, 2009 8:49 PM >> > >>>To: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx >> > >>>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 >> majordomo@xxxxxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
