Hi,
On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
> >> > >> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
> >> > >> >> +{
> >> > >> >> + if (!x || !x->dev) {
> >> > >> >> + dev_err(x->dev, "no PHY or attached device available\n");
> >> > >> >> + return;
> >> > >> >> + }
> >> > >> >> +
> >> > >> >> + pm_runtime_enable(x->dev);
> >> > >> >> +}
> >> > >> >
> >> > >> >
> >> > >> > IMO we need not have wrapper APIs for runtime_enable and runtime_disable
> >> > >> > here. Generally runtime_enable and runtime_disable is done in probe and
> >> > >> > remove of a driver respectively. So it's better to leave the
> >> > >> > runtime_enable/runtime_disable to be done in *phy provider* driver than
> >> > >> > having an API for it to be done by *phy user* driver. Felipe, what do you
> >> > >> > think?
> >> > >>
> >> > >> Thanks!!
> >> > >> That's very true, runtime_enable() and runtime_disable() calls are made by
> >> > >> *phy_provider* only. But a querry here.
> >> > >> Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
> >> > >> Say, when consumer failed to suspend the PHY properly
> >> > >> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
> >> > >> state of PHY ?
> >> > >
> >> > > no no, wait a minute. We might not want to enable runtime pm for the PHY
> >> > > until the UDC says it can handle runtime pm, no ? I guess this makes a
> >> > > bit of sense (at least in my head :-p).
> >> > >
> >> > > Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
> >> > > enabled... Does it make sense to leave that control to the USB
> >> > > controller drivers ?
> >> > >
> >> > > I'm open for suggestions
> >> >
> >> > Of course unless the PHY consumer can handle runtime PM for PHY,
> >> > PHY should not ideally be going into runtime_suspend.
> >> >
> >> > Actually trying out few things, here are my observations
> >> >
> >> > Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
> >> > But a device detection wakes up DWC3 controller, and if i don't wake
> >> > up PHY (using get_sync(phy->dev)) here
> >> > in runtime_resume() callback of DWC3, i don't get PHY back in active state.
> >> > So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
> >> > Thereby it becomes logical that DWC3 controller has the right to
> >> > enable runtime_pm
> >> > of PHY.
> >> >
> >> > But there's a catch here. if there are multiple consumers of PHY (like
> >> > USB2 type PHY can
> >> > have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
> >> > only one of the consumer can enable runtime_pm on PHY. So who decides this.
> >> >
> >> > Aargh!! lot of confusion here :-(
> >>
> >>
> >> hmmm, maybe add a flag to struct usb_phy and check it on
> >> usb_phy_autopm_enable() ??
> >>
> >> How does usbcore handle it ? They request class drivers to pass
> >> supports_autosuspend, but while we should have a similar flag, that's
> >> not enough. We also need a flag to tell us when pm_runtime has already
> >> been enabled.
>
> True
>
> >>
> >> So how about:
> >>
> >> usb_phy_autopm_enable()
> >> {
> >> if (!phy->suports_autosuspend)
> >> return -ENOSYS;
> >>
> >> if (phy->autosuspend_enabled)
> >> return 0;
> >>
> >> phy->autosuspend_enabled = true;
> >> return pm_runtime_enable(phy->dev);
> >> }
> >>
> >> ???
>
> Great
>
> >
> > and of course I missed the fact that pm_runtime_enable returns nothing
> > :-) But you got my point.
>
> Yea, this is a way around this. :-)
>
> Just one more query :-)
>
> Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
> it will try to go into suspend state and thereby call runtime_suspend(), if any.
> And PHY will come to active state only when its consumer wakes it up,
> and this consumer is operational
> only when its related PHY is in fully functional state.
> So do we have a situation in which this PHY goes into low power state
> in its runtime_suspend(),
> resulting in non-detection of devices on further attach (since PHY is
> in low power state) ?
>
> Will the controller (like EHCI/OHCI) be functional now ?
ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
right ? (so does DWC3 :-)
--
balbi
Attachment:
signature.asc
Description: Digital signature
