[linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver

[Tony Lindgren]

* Kevin Hilman <khilman at ti.com> [120601 07:11]:
> Tony Lindgren <tony at atomide.com> writes:
> 
> > * Tony Lindgren <tony at atomide.com> [120601 04:43]:
> >> * Eduardo Valentin <eduardo.valentin at ti.com> [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