Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management

[Vivek Gautam]

On Tue, Apr 23, 2013 at 11:42 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 23 Apr 2013, Vivek Gautam wrote:
>
>> Hi,
>>
>>
>> On Tue, Apr 23, 2013 at 10:23 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>> > On Tue, 23 Apr 2013, Vivek Gautam wrote:
>> >
>> >> >> Alright, so here's my understanding:
>> >> >>
>> >> >> I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said
>> >> >> that it could be done before that so that DWC3 sees an enabled PHY
>> >> >> during probe.
>> >> >
>> >> > Basically right.  Help me to understand the overall situation a little
>> >> > better:
>> >> >
>> >> >         What code registers the PHY initially?
>> >>            PHY is added to global list by PHY drivers (like
>> >> phy-samsung-usb2.c/phy-omap-usb2.c)
>> >>            by usb_add_phy() API
>> >
>> > Then this routine should initialize the PHY.  The initialized state
>> > could be either active or suspended, your choice.  Suspended would be
>> > best, in case the PHY never gets used.
>>
>> Fair enough.
>>
>> >
>> >> >         What routine does the DWC3 driver call to register itself
>> >> >         as a consumer of the PHY?
>> >>            I think DWC3 doesn't registers itself as consumer of PHY,
>> >> rather it gets that PHY from
>> >>            the list using devm_usb_get_phy()/devm_usb_get_phy_by_phandle() API.
>> >>            DWC3 can now call PHY's initialization sequence using usb_phy_init().
>> >>            So, before DWC3 initializes the PHY, PHYs should be in active state.
>> >
>> > Then usb_phy_init should make sure the PHY is in the active state.  If
>> > usb_add_phy() left the PHY suspended, then this routine should call
>> > pm_runtime_get_sync().
>>
>> Right
>>
>> >
>> > After DWC3 (or any other driver) has acquired the PHY, it can call
>> > pm_runtime_put/get() however it likes, so long as the calls balance
>> > properly.  If the driver isn't runtime-PM aware then it won't use any
>> > of these calls, and the PHY will remain active the entire time.
>>
>> Alright, so DWC3 (or any other consumer of PHY) should do minimal to
>> handle runtime state of PHYs; get() when accessing PHY and put() when it's done
>> with it.
>
> Yes.  The first operation will generally be a put, because
> usb_phy_init() will leave the PHY in an active state.

Alright.

>
>> >> >         Likewise, what routine does it call to unregister itself?
>> >>            Once DWC3's remove() is called PHYs are put.
>> >
>> > Is there a routine analogous to usb_phy_init() that gets called when
>> > PHY is released?  That routine would do the opposite of usb_phy_init(),
>> > putting the PHY back into its initialized state.
>>
>> Yes, ofcourse there's a routine usb_phy_shutdown(). So this will be
>> calling put_sync()
>> to put PHYs back to its initialized state. Right ?
>
> Correct.

Hmm.

Thanks for explaining things here and keeping patience to my queries :-)

Felipe, thanks to you too for the discussion :-)
I shall update the patchset asap.

-- 
Best Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/