[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150114012653.GB14944@shlinux2>
Date: Wed, 14 Jan 2015 09:26:54 +0800
From: Peter Chen <peter.chen@...escale.com>
To: Felipe Balbi <balbi@...com>
CC: Kiran Raparthy <kiran.kumar@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
Android Kernel Team <kernel-team@...roid.com>,
Arve Hjønnevåg <arve@...roid.com>,
Benoit Goby <benoit@...roid.com>,
Todd Poynor <toddpoynor@...gle.com>
Subject: Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is
enumerated in peripheral mode
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@...aro.org> wrote:
> > > Hi Felipe,
> > >
> > > On 25 November 2014 at 20:15, Felipe Balbi <balbi@...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.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists