On Wed, Apr 3, 2013 at 7:48 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> 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 :-)
Yes ofcourse.
So PHYs (in their runtime_suspend) should not be pulled into a state
wherein even the controllers become in-operational.
Thereby no attach-detection, and controller doesn't wake up to be able
to usb_phy_autopm_get_sync()
Sorry for so much noise, i am acting like slow study ;-)
>
> --
> balbi
--
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
