* Kevin Hilman <khilman@xxxxxx> [120601 07:11]:
> Tony Lindgren <tony@xxxxxxxxxxx> writes:
>
> > * 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?
>
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
