> -----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
