Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755857AbbGTHs5 (ORCPT ); Mon, 20 Jul 2015 03:48:57 -0400 Received: from mail-pa0-f44.google.com ([209.85.220.44]:33917 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755047AbbGTHsz (ORCPT ); Mon, 20 Jul 2015 03:48:55 -0400 MIME-Version: 1.0 In-Reply-To: <20150713070002.GA12197@shlinux2> References: <1416849900-29959-3-git-send-email-kiran.kumar@linaro.org> <15cad5ef7627483cbba96e05fe180813@BN1PR0301MB0772.namprd03.prod.outlook.com> <20141125144544.GC6360@saruman>

<20150113161802.GD16533@saruman> <20150114012653.GB14944@shlinux2> <20150608083152.GB6743@shlinux2> <20150713070002.GA12197@shlinux2> From: Sumit Semwal Date: Mon, 20 Jul 2015 13:18:35 +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: 5020 Lines: 122 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. >> >> If indeed we can't handle charger events in the way suggested by you, >> may I propose the following: >> >> - implement this in USB-phy as proposed in Kiran's original patch, >> - keep it disabled by default, and add a module param to enable/disable it >> - for no vbus case, use another event (USB_EVENT_ENUMERATED / >> USB_EVENT_NONE? ) to identify connect / disconnect? >> (OR, maybe don't do anything for such cases, since most likely >> the chipidea kind of implementations would handle it themselves?) >> > > In my opinion, we can do noop for wakeup source if it is a USB charger. > I think I misunderstood your comment here - do you mean for 'no vbus case (like chipidea)' do a noop for wakeup source? In the gadget framework, there doesn't seem to be a way to get to know if a USB charger is connected. >> Of course these are based on my limited reading of the USB code, so >> I'd be grateful if you'd let me know of any obvious gaps in my >> understanding! >> >> > -- >> > >> > Best Regards, >> > Peter Chen >> >> >> Best regards, >> Sumit. > > -- > > 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/