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.)
Kevin
--
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
