Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755323AbbGTNIT (ORCPT ); Mon, 20 Jul 2015 09:08:19 -0400 Received: from mail-pd0-f181.google.com ([209.85.192.181]:36540 "EHLO mail-pd0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753935AbbGTNIR (ORCPT ); Mon, 20 Jul 2015 09:08:17 -0400 MIME-Version: 1.0 In-Reply-To: <20150720071555.GA5715@shlinux2> References: <20141125144544.GC6360@saruman>

<20150113161802.GD16533@saruman> <20150114012653.GB14944@shlinux2> <20150608083152.GB6743@shlinux2> <20150713070002.GA12197@shlinux2> <20150720071555.GA5715@shlinux2> From: Sumit Semwal Date: Mon, 20 Jul 2015 18:37:57 +0530 Message-ID: Subject: Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode To: Peter Chen Cc: Felipe Balbi , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , "linux-usb@vger.kernel.org" , Android Kernel Team , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Benoit Goby , Todd Poynor Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5505 Lines: 126 Hi Peter, On 20 July 2015 at 12:45, Peter Chen wrote: > On Mon, Jul 20, 2015 at 01:18:35PM +0530, Sumit Semwal wrote: >> On 13 July 2015 at 12:30, Peter Chen wrote: >> > On Mon, Jul 13, 2015 at 01:26:23PM +0530, Sumit Semwal wrote: >> >> Hi Peter, >> >> >> >> On 8 June 2015 at 14:02, Peter Chen wrote: >> >> > 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 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 wrote: >> >> >> >> > > Hi Felipe, >> >> >> >> > > >> >> >> >> > > On 25 November 2014 at 20:15, Felipe Balbi 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. >> >> >> >> > >>> > >> >> >> >> > >>> >> >> >> >> >> >> >> >> 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. >> >> > >> >> Thanks very much for your suggestion, and apologies in the delay in response. >> >> >> >> I tried to study your suggestion and the code a little bit more, and >> >> while I liked your idea quite a bit, I also realised that for the case >> >> of letting the USB charger use cases, in gadget framework, there >> >> doesn't seem to be a way to get the USB_EVENT_CHARGER, since charger >> >> would likely not be a gadget. >> >> >> >> In this case, how'd we be able to enable / disable wakeup_source for >> >> charger events? >> > >> > We may not prevent the system entering system if it is a charger, isn't >> > it, so don't need to consider USB charger. >> > >> Thanks for your comments, Peter! >> From the Android code that I see, it seems that for a charger >> connect/disconnect, some systems might require some time to react to >> the change in power, and hence there's a timed-out wakeup event for >> USB charger cases. That;s where the consideration for USB chargers >> came from. > > Current udc core has an API usb_gadget_set_state set its state > according to usb ch9. For this wakeup source case, if the peripheral > has been configured, it can hold wakeup source. Otherise, just have > a timeout wake lock. Thank you for your kind hint. Let me toy with this change and update. > Below are some reference code: > > diff --git a/drivers/usb/gadget/udc/udc-core.c > b/drivers/usb/gadget/udc/udc-core.c > index d69c355..018f534 100644 > --- a/drivers/usb/gadget/udc/udc-core.c > +++ b/drivers/usb/gadget/udc/udc-core.c > > @@ -136,6 +138,16 @@ static void usb_gadget_state_work(struct > work_struct *work) > > if (udc) { > sysfs_notify(&udc->dev.kobj, NULL, "state"); > switch (gadget->state) { > case USB_STATE_CONFIGURED: > __pm_stay_awake(&x->wsource); > break; > default: > __pm_wakeup_event(&x->wsource, > USB_DEFAULT_WAKEUP_SRC_TIMEOUT); > break; > } > } > > > -- > > Best Regards, > Peter Chen Best regards, Sumit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/