Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode

[Peter Chen <peter.chen@freescale.com>]

On Mon, Jun 08, 2015 at 12:37:00PM +0530, Sumit Semwal wrote:
> H Peter, Felipe,
> 
> On 14 January 2015 at 06:56, Peter Chen <peter.chen@freescale.com> wrote:
> > On Tue, Jan 13, 2015 at 10:18:02AM -0600, Felipe Balbi wrote:
> >> On Tue, Jan 13, 2015 at 04:02:20PM +0530, Kiran Raparthy wrote:
> >> > Hi Felipe,
> >> >
> >> > On 1 December 2014 at 11:09, Kiran Raparthy <kiran.kumar@linaro.org> wrote:
> >> > > Hi Felipe,
> >> > >
> >> > > On 25 November 2014 at 20:15, Felipe Balbi <balbi@ti.com> wrote:
> >> > >> On Tue, Nov 25, 2014 at 07:06:18AM +0000, Peter Chen wrote:
> >> > >>>
> >> > >>> >
> >> > >>> > usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
> >> > >>> >
> >> > >>> > Some systems require a mechanism to prevent system to enter into suspend
> >> > >>> > state when USB is connected and enumerated in peripheral mode.
> >> > >>> >
> >> > >>> > This patch provides an interface to hold a wakeupsource to prevent suspend.
> >> > >>> > PHY drivers can use this interface when USB is connected and enumerated in
> >> > >>> > peripheral mode.
> >> > >>> >
> >> > >>> > A timed wakeupsource is temporarily held on USB disconnect events, to allow
> >> > >>> > the rest of the system to react to the USB disconnection (dropping host
> >> > >>> > sessions, updating charger status, etc.) prior to re-allowing suspend.
> >> > >>> >
> >> > >>>
> >> > >>> Hi Kiran & Felipe,
> >> > >>>
> >> > >>> Just two questions for this series
> >> > >>>
> >> > >>> - Will it be the default behavior for all peripheral drivers?
> >> > >>> - If the peripheral driver's PHY driver does not vbus event, how to
> >> > >>> support it?
> >> > >>> For example, chipidea udc driver has its vbus interface at its
> >> > >>> controller register.
> >> > >>
> >> > >> hmm, good point. Since it's so late, I'll just go ahead and drop
> >> > >> $subject from v3.20. Let's delay only $subject to v3.20 merge window so
> >> > >> we have some more time to discuss these details.
> >> > >
> >> > > I am just curious to know/understand why this feature needs to be
> >> > > default behavior for all peripheral drivers?
> >> > > If this needs to be default behavior, could you please suggest any
> >> > > alternate plan/design for this feature so that i can incorporate them
> >> > > in new patch.
> >> > > Regards,
> >> > > Kiran
> >> >
> >> > Just a gentle reminder to consider the patch.
> >>
> >> sorry, for the delay... man this release round has been hectic. We still
> >> haven't sorted out what should be the default behavior here, considering
> >> some PHYs will not be able to report VBUS levels, I'm not sure what we
> >> should do here.
> >>
> >
> > My opinion is: if we need this feature, we should depend on gadget's
> > state, eg 'configured', not vbus level. The system suspend should be
> > allowed if the gadget state is 'suspended' which vbus is still there.
> >
> 
> Kiran is unable to continue on this patch anymore, so despite my very
> limited usb experience, I would like to take this over and with your
> help, take it to closure.
> 
> From what I understand, it might be possible to do this either at the
> usb controller driver (where it detects if it has enumerated in host
> mode or device mode) or in the extcon driver (where it detects VBUS
> etc..) -  which would be a cleaner / more logical way to do it?
> 
> Thanks for all your help!

I added my suggestions below:

My opinion is: if we need this feature, we should depend on gadget's
state, eg 'configured', not vbus level. The system suspend should be
allowed if the gadget state is 'suspended' even vbus is still there.

And when the gadget goes to suspend or reset or disconnect state, we can
go to disable this wakeup source.

At drivers/usb/gadget/composite.c, we can know the gadget's state.

-- 

Best Regards,
Peter Chen