* Kevin Hilman <[email protected]> [120601 07:11]: > Tony Lindgren <[email protected]> writes: > > > * Tony Lindgren <[email protected]> [120601 04:43]: > >> * Eduardo Valentin <[email protected]> [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? > > Handling this with parent/child relationships is the way to go for > runtime PM. > > In MFD, are all sub-devices always children of the core device in the > LDM? If so, it seems relatively easy to handle. If the parent/child > relationships are modeled correctly in the LDM, then the children do not > have to know anything about their parent, the runtime PM core will handle > this (parent will not be runtime suspended until all the children are.)
OK, so the parent-child relationship is there for DT case, but how do we set it for non-DT case? Call something like this from children: omap_scm_register(dev, OMAP_SCM_USB_PHY) that then does device_move? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
