* Tony Lindgren <tony@xxxxxxxxxxx> [120601 04:43]: > * Eduardo Valentin <eduardo.valentin@xxxxxx> [120525 01:31]: > > +int omap4_usb_phy_power(struct device *dev, int on) > > +{ > > + u32 val; > > + int ret; > > + > > + if (on) { > > + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val); > > + if (!ret && (val & PHY_PD)) { > > + ret = omap_control_writel(dev, ~PHY_PD, > > + CONTROL_DEV_CONF); > > + /* XXX: add proper documentation for this delay */ > > + mdelay(200); > > + } > > + } else { > > + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF); > > + } > > + > > + return ret; > > +} > > +EXPORT_SYMBOL_GPL(omap4_usb_phy_power); > > I'm not quite convinced that we should export omap_control_read/write > to drivers. If there's a clear register area this USB phy driver can > manage, then ioremaping it separately makes sense. If it's just one > register, then exporting something like omap_control_usb_phy_set() > might be better for ensuring that drivers don't mess up things for > other drivers. After chatting with Benoit a bit we came to the conclusion that the clock and powerdomain state needs to be managed for the children by the SCM core driver so the children can't be completely independent. But rather than exporting omap_control_read/write, maybe you can register the usb/bandgap whatever children with SCM core driver, then have the runtime PM calls from children be passthrough calls to the parent? Maybe Kevin has some better ideas here? Regards, Tony -- 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