Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752368AbcCaGMn (ORCPT ); Thu, 31 Mar 2016 02:12:43 -0400 Received: from mail-am1on0080.outbound.protection.outlook.com ([157.56.112.80]:13664 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750938AbcCaGMk (ORCPT ); Thu, 31 Mar 2016 02:12:40 -0400 X-Greylist: delayed 79486 seconds by postgrey-1.27 at vger.kernel.org; Thu, 31 Mar 2016 02:12:39 EDT From: Jun Li To: Baolin Wang CC: Peter Chen , Felipe Balbi , "Greg KH" , Sebastian Reichel , "Dmitry Eremin-Solenikov" , David Woodhouse , Peter Chen , Alan Stern , "r.baldyga@samsung.com" , Yoshihiro Shimoda , Lee Jones , Mark Brown , Charles Keepax , "patches@opensource.wolfsonmicro.com" , Linux PM list , USB , "device-mainlining@lists.linuxfoundation.org" , LKML Subject: RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Thread-Topic: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Thread-Index: AQHRhcncDPeno7bqik6en7wacMJBHJ9pvwGAgASx+gCAAa8+QIAAFJIAgAEXTJCAAD9RgIAAF0AwgAAfdQCAAAKJQIABSnQAgAAIK/A= Date: Thu, 31 Mar 2016 06:12:36 +0000 Message-ID: References: <20160325070937.GA22398@peterchendt> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=nxp.com; x-originating-ip: [123.151.195.51] x-ms-office365-filtering-correlation-id: e91a1762-fa43-47e2-303b-08d3592b74c2 x-microsoft-exchange-diagnostics: 1;HE1PR04MB1676;5:kyLDiPdO6s/Aj8H/lz4PC/LYgaXeAzHZh0J1y93CcdeC/WHpkXAthHtL6OFHmoF5PA+kEGPnR/FeWfrgzZfHXeyewAfZRQpF3s+n/v5yUr/96NC9i6T6pT2VrYLA/eMp1sOqE784n4+7R4EZThh33A==;24:MUwolKsiwud3oPgJJStzkoh1VZ/8yHlIRrRCbeoTmg80hscp5KgwocH0Fq4gYUbdU+rbMBzlFch9FXwb8tDgKFrzVA/h6GwN0VVeYusOXxA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1676; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:HE1PR04MB1676;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1676; x-forefront-prvs: 0898A6E028 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(13464003)(377454003)(24454002)(3660700001)(33656002)(1220700001)(106116001)(1096002)(5003600100002)(10400500002)(74316001)(3280700002)(5004730100002)(2950100001)(2900100001)(66066001)(92566002)(5008740100001)(19580395003)(19580405001)(76576001)(5002640100001)(81166005)(87936001)(189998001)(93886004)(76176999)(54356999)(5890100001)(110136002)(102836003)(6116002)(3846002)(50986999)(586003)(122556002)(2906002)(86362001)(77096005)(11100500001)(7059030);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR04MB1676;H:HE1PR04MB1674.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 06:12:36.5002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1676 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u2V6Cn4T027820 Content-Length: 3614 Lines: 77 Hi > -----Original Message----- > From: Baolin Wang [mailto:baolin.wang@linaro.org] > Sent: Thursday, March 31, 2016 1:23 PM > To: Jun Li > Cc: Peter Chen ; Felipe Balbi ; > Greg KH ; Sebastian Reichel ; > Dmitry Eremin-Solenikov ; David Woodhouse > ; Peter Chen ; Alan Stern > ; r.baldyga@samsung.com; Yoshihiro Shimoda > ; Lee Jones ; Mark > Brown ; Charles Keepax > ; patches@opensource.wolfsonmicro.com; > Linux PM list ; USB ; > device-mainlining@lists.linuxfoundation.org; LKML kernel@vger.kernel.org> > Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with > the usb gadget power negotation > > On 30 March 2016 at 18:58, Jun Li wrote: > >> >> >> > Seems you don't want to guarantee charger type detection is > >> >> >> > done before gadget connection(pullup DP), right? > >> >> >> > I see you call usb_charger_detect_type() in each gadget usb > >> >> >> > state > >> >> >> changes. > >> >> >> > >> >> >> I am not sure I get your point correctly, please correct me if > >> >> >> I misunderstand you. > >> >> >> We need to check the charger type at every event comes from the > >> >> >> usb gadget state changes or the extcon device state changes, > >> >> >> which means a new charger plugin or pullup. > >> >> >> > >> >> > > >> >> > According to usb charger spec, my understanding is you can't do > >> >> > real charger detection procedure *after* gadget > >> >> > _connection_(pullup DP), also I don't > >> >> > >> >> Why can not? Charger detection is usually from PMIC. > >> > > >> > Charger detection process will impact DP/DM line state, see usb > >> > charger spec v1.2 for detail detection process, section 4.6.3 says: > >> > > >> > "A PD is allowed to *disconnect* and repeat the charger detection > >> > process multiple times while attached. The PD is required to wait > >> > for a time of at least TCP_VDM_EN max between disconnecting and > >> > restarting the charger detection process." > >> > > >> > As Peter mentioned, the charger detection should happen between > >> > VBUS detection and gadget pull up DP for first plug in case. So > >> > when&after gadget connect (pullup DP), you should already know the > charger type. > >> > >> Make sense. In our company's solution, charger detection can be done > >> by hardware from PMIC at first, then it will not affect the DP/DM > >> line when gadget starts to enumeration. > > > > I see, charger type detection is done automatically by PMIC when VBUS > > is detected in your case, you just assume the process is complete > > before SW do gadget connect. To make the framework common, you may do > one time charger type check when vbus is on, and save it to avoid repeat > charger type check. > > OK. I'll add one judgement to check if the charger type is set in > 'usb_charger_detect_type()' function. Just adding a judgement isn't enough here, your framework should make sure usb_charger_detect_type() is called before gadget connect, with that, the existing caller place just gets the charger type from the saved value. The real charger type detection done by usb_charger_detect_type() can be called only when vbus is on. e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control(). > > -- > Baolin.wang > Best Regards