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