Hi,
> On Wed, Feb 08, 2012 at 11:46:00AM +0530, Shubhrajyoti wrote:
> > On Wednesday 08 February 2012 09:56 AM, Ajay Kumar Gupta wrote:
> > > +static int dsps_musb_init(struct musb *musb) {
> > > + struct device *dev = musb->controller;
> > > + struct musb_hdrc_platform_data *plat = dev->platform_data;
> > > + struct platform_device *pdev = to_platform_device(dev->parent);
> > > + struct dsps_glue *glue = platform_get_drvdata(pdev);
> > > + const struct dsps_musb_wrapper *wrp = glue->wrp;
> > > + struct omap_musb_board_data *data = plat->board_data;
> > > + void __iomem *reg_base = musb->ctrl_base;
> > > + u32 rev, val;
> > > + int status;
> > > +
> > > + /* mentor core register starts at offset of 0x400 from musb base
> */
> > > + musb->mregs += wrp->musb_core_offset;
> > > +
> > > + /* NOP driver needs change if supporting dual instance */
> > > + usb_nop_xceiv_register();
> > > + musb->xceiv = otg_get_transceiver();
> > > + if (!musb->xceiv)
> > > + return -ENODEV;
> > > +
> > > + status = pm_runtime_get_sync(dev);
> > > + if (status < 0) {
> > > + dev_err(dev, "pm_runtime_get_sync FAILED");
> > > + goto err0;
> > > + }
> > So you are doing a get_sync at init and you cut the clocks at exit
> only.
> > Any particular reason for that.
This is a platform glue layer and main io paths are in musb_core.c/musb_host.c
and musb_gadget.c. Host controller driver's bus_suspend/resume are in
musb_host.c.
What specific pm implementation are you looking for?
Ajay
>
> that's a very good question. We're just adding a brand new file, which
> is clean and stuff... so we might as well start with good PM
> capabilities.
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
