Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753659AbdCJGbF (ORCPT ); Fri, 10 Mar 2017 01:31:05 -0500 Received: from mail-ve1eur01on0060.outbound.protection.outlook.com ([104.47.1.60]:60230 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750846AbdCJGbC (ORCPT ); Fri, 10 Mar 2017 01:31:02 -0500 From: Jun Li To: Baolin Wang CC: NeilBrown , Felipe Balbi , Greg KH , Sebastian Reichel , "Dmitry Eremin-Solenikov" , David Woodhouse , "robh@kernel.org" , Marek Szyprowski , Ruslan Bilovol , "Peter Chen" , Alan Stern , "grygorii.strashko@ti.com" , Yoshihiro Shimoda , Lee Jones , "Mark Brown" , John Stultz , "Charles Keepax" , "patches@opensource.wolfsonmicro.com" , Linux PM list , USB , "device-mainlining@lists.linuxfoundation.org" , LKML Subject: RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Thread-Topic: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Thread-Index: AQHSi1aOUyaKEwWPx0aHt9CEJ1a6daGCc4sAgAbC/YCAApaxcIAAU+eAgAAHFACAAFACAIAA+GrQ Date: Fri, 10 Mar 2017 06:30:57 +0000 Message-ID: References: <87zih3m73h.fsf@notabene.neil.brown.name> 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: [199.59.226.141] x-ms-office365-filtering-correlation-id: e88bc1c5-cede-4410-54a0-08d4677f0323 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081);SRVR:AM5PR04MB2961; x-microsoft-exchange-diagnostics: 1;AM5PR04MB2961;7:EyvG95jaBinV2vGtxhXUlGVSQ4B9BV5lOqnZHq3MHvQxt5BaI1Ea2vbmmKZVhn922FIO0zVM5tsq+5H8QEyOW2F/QKd+RI47OFpKnEkFWaivLUQ54iB4AmIbRbfb0YQ1Hloh+BEooboVvAqIfiRvCqEuTq9jNpVx8+RDkSJdvZQdEtamQ4LrWdoHTDvO850GlcnyTfm2+QJ2qxu/ZOM0o0S+MhIgq2IyA+tjn2c4v7foWegWiWqo6MgHepBhJIJUpbAfm2u1eer1lnD4rkhb4Kbgq5Rn5D7xOuPn7EDLeq778atoye87tpcM4I98xzycy7DGaZuKNbCRym74JUhEuQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31051911155226)(9452136761055)(35073007944872)(185117386973197)(101931422205132)(35762410373642)(7411616537696); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148);SRVR:AM5PR04MB2961;BCL:0;PCL:0;RULEID:;SRVR:AM5PR04MB2961; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(377454003)(13464003)(24454002)(189998001)(74316002)(33656002)(2906002)(106116001)(76176999)(5660300001)(54356999)(50986999)(93886004)(122556002)(7696004)(2900100001)(2950100002)(6436002)(6916009)(8936002)(6116002)(3846002)(305945005)(7736002)(102836003)(38730400002)(54906002)(55016002)(229853002)(8676002)(3280700002)(99286003)(6306002)(81166006)(9686003)(3660700001)(7416002)(110136004)(86362001)(77096006)(6506006)(66066001)(39060400002)(53546006)(6246003)(25786008)(4326008)(53936002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR04MB2961;H:AM5PR04MB2961.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 06:30:57.5049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR04MB2961 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 v2A6VAGn007383 Content-Length: 11242 Lines: 231 > -----Original Message----- > From: Baolin Wang [mailto:baolin.wang@linaro.org] > Sent: Thursday, March 09, 2017 7:23 PM > To: Jun Li > Cc: NeilBrown ; Felipe Balbi ; Greg KH > ; Sebastian Reichel ; Dmitry > Eremin-Solenikov ; David Woodhouse > ; robh@kernel.org; Marek Szyprowski > ; Ruslan Bilovol ; > Peter Chen ; Alan Stern > ; grygorii.strashko@ti.com; Yoshihiro Shimoda > ; Lee Jones ; > Mark Brown ; John Stultz ; > Charles Keepax ; > patches@opensource.wolfsonmicro.com; Linux PM list pm@vger.kernel.org>; USB ; device- > mainlining@lists.linuxfoundation.org; LKML > Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with > the usb gadget power negotation > > On 9 March 2017 at 18:34, Jun Li wrote: > > > > > >> -----Original Message----- > >> From: Baolin Wang [mailto:baolin.wang@linaro.org] > >> Sent: Thursday, March 09, 2017 2:11 PM > >> To: Jun Li > >> Cc: NeilBrown ; Felipe Balbi ; Greg > >> KH ; Sebastian Reichel ; > >> Dmitry Eremin-Solenikov ; David Woodhouse > >> ; robh@kernel.org; Marek Szyprowski > >> ; Ruslan Bilovol > >> ; Peter Chen ; > >> Alan Stern ; grygorii.strashko@ti.com; > >> Yoshihiro Shimoda ; Lee Jones > >> ; Mark Brown ; John Stultz > >> ; Charles Keepax > >> ; > >> patches@opensource.wolfsonmicro.com; Linux PM list >> pm@vger.kernel.org>; USB ; device- > >> mainlining@lists.linuxfoundation.org; LKML > >> > >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal > >> with the usb gadget power negotation > >> > >> Hi, > >> > >> On 9 March 2017 at 09:50, Jun Li wrote: > >> > Hi, > >> > > >> >> -----Original Message----- > >> >> From: Baolin Wang [mailto:baolin.wang@linaro.org] > >> >> Sent: Tuesday, March 07, 2017 5:39 PM > >> >> To: NeilBrown > >> >> Cc: Felipe Balbi ; Greg KH > >> >> ; Sebastian Reichel ; > >> >> Dmitry Eremin-Solenikov ; David > Woodhouse > >> >> ; robh@kernel.org; Jun Li ; > >> >> Marek Szyprowski ; Ruslan Bilovol > >> >> ; Peter Chen > ; > >> >> Alan Stern ; grygorii.strashko@ti.com; > >> >> Yoshihiro Shimoda ; Lee Jones > >> >> ; Mark Brown ; John > >> >> Stultz ; Charles Keepax > >> >> ; > >> >> patches@opensource.wolfsonmicro.com; Linux PM list >> >> pm@vger.kernel.org>; USB ; device- > >> >> mainlining@lists.linuxfoundation.org; LKML > >> >> > >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to > >> >> deal with the usb gadget power negotation > >> >> > >> >> On 3 March 2017 at 10:23, NeilBrown wrote: > >> >> > On Mon, Feb 20 2017, Baolin Wang wrote: > >> >> > > >> >> >> Currently the Linux kernel does not provide any standard > >> >> >> integration of this feature that integrates the USB subsystem > >> >> >> with the system power regulation provided by PMICs meaning that > >> >> >> either vendors must add this in their kernels or USB gadget > >> >> >> devices based on Linux (such as mobile phones) may not behave as > they should. > >> >> >> Thus provide a > >> >> standard framework for doing this in kernel. > >> >> >> > >> >> >> Now introduce one user with wm831x_power to support and test > >> >> >> the usb > >> >> charger. > >> >> >> Another user introduced to support charger detection by Jun Li: > >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html > >> >> >> Moreover there may be other potential users will use it in future. > >> >> >> > >> >> >> 1. Before v19 patchset we've fixed below issues in extcon > >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for > >> >> >> Neil's > >> >> >> suggestion) > >> >> >> (1) Have fixed the inconsistencies with USB connector types in > >> >> >> extcon subsystem by following links: > >> >> >> https://lkml.org/lkml/2016/12/21/13 > >> >> >> https://lkml.org/lkml/2016/12/21/15 > >> >> >> https://lkml.org/lkml/2016/12/21/79 > >> >> >> https://lkml.org/lkml/2017/1/3/13 > >> >> >> > >> >> >> (2) Instead of using 'set_power' callback in phy drivers, we > >> >> >> will introduce USB charger to set PMIC current drawn from USB > >> >> >> configuration, moreover some 'set_power' callbacks did not > >> >> >> implement anything to set PMIC current, thus remove them by > >> following links: > >> >> >> https://lkml.org/lkml/2017/1/18/436 > >> >> >> https://lkml.org/lkml/2017/1/18/439 > >> >> >> https://lkml.org/lkml/2017/1/18/438 > >> >> >> Now only two phy drivers (phy-isp1301-omap.c and > >> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set > >> >> >> current, we can remove them in future. (I have no platform with > >> >> >> enabling these two phy drivers, so I can not test them if I > >> >> >> converted 'set_power' callback to USB > >> >> >> charger.) > >> >> >> > >> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19 > >> >> >> patchset, and I expalined each issue and may be need discuss again: > >> >> >> (1) Change all usb phys to register an extcon and to send > >> >> >> appropriate > >> >> notifications. > >> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, > >> >> >> phy-omap-otg.c and > >> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can > >> >> >> not change all usb phys to register an extcon, since there are > >> >> >> no extcon device to register for these different phy drivers. > >> >> > > >> >> > You don't have to change every driver. You just need to make it > >> >> > easy and obvious how to change drivers in a consistent coherent way. > >> >> > For a start you would add a 'struct extcon_dev' to 'struct > >> >> > usb_phy', and possibly add or extend some 'static inline's in > >> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL). > >> >> > e.g. usb_phy_vbus_on() could send an extcon notification. > >> >> > > >> >> > Then any phy driver which adds support for setting > >> >> > phy->extcon_dev appropriately, immediately gets the relevant > notifications sent. > >> >> > >> >> OK. We can make these extcon related code into phy common part. > >> >> > >> > > >> > Will generic phy need add extcon as well? > >> > >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will > >> be common code. > >> > > > > I mean the common code need add 'struct extcon_dev' into both 'struct > > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy > driver. > > Ah, you remind me. Seems we need also add one 'struct extcon_dev' into > 'struct phy'. > > >> > > >> >> > > >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY > >> >> >> to register an extcon, but also for the drivers which can > >> >> >> detect USB charger type, it may be USB controller driver, USB > >> >> >> type-c driver, pmic driver, and these drivers may not have an > >> >> >> extcon device since the internal part can finish the vbus detect. > >> >> > > >> >> > Whichever part can detect vbus, the driver for that part must be > >> >> > able to find the extcon and trigger a notification. > >> >> > Maybe one part can detect VBUS, another can measure the > >> >> > resistance on ID and a third can work through the state machine > >> >> > to determine if D+ and D- are shorted together. > >> >> > Somehow these three need to work together to determine what is > >> >> plugged > >> >> > in to the external connection port. Somewhere there much an > 'extcon' > >> >> > device which represents that port and which the three devices > >> >> > can find and can interact with. > >> >> > I think it makes sense for the usb_phy to be the connection point. > >> >> > Each of the devices can get to the phy, and the phy can get to > >> >> > the > >> extcon. > >> >> > It doesn't matter very much if the usb phy driver creates the > >> >> > extcon, or if something else creates the extcon and the phy > >> >> > driver performs a lookup to find it (e.g. based on devicetree info). > >> >> > > >> >> > The point is that there is obviously an external physical > >> >> > connection, and so there should be an 'extcon' device that > represents it. > >> >> > >> >> Peter & Jun, is it OK for you every phy has one extcon device to > >> >> receive VBUS notification, especially for detecting the charger > >> >> type by > >> software? > >> >> > >> > > >> > My understanding is phy/usb_phy as the connection point, will send > >> > the notification to PMIC driver which actually control the charge > >> > current, also this will be done in your common framework, right? > >> > >> Not in USB charger framework. If we are all agree every usb_phy can > >> register one extcon device, can get correct charger type and send out > >> correct vbus_draw information, then we don't need USB charger > >> framework as Neil suggested. So this will be okay for your case > >> (especially for detecting the charger type by software) ? > > > > In my case, charger detection is done by controller driver and I need > > do charger type detection internally, and only pass the current draw > > info via phy which will send out, this seems ok for me, but I think it > > will be good if you or someone can show us an example user based on the > design Neil suggested. > > Will you work out that common code if this USB charger framework is not > needed? > > I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. Others > are already ready if everyone has no complain about current design, except Only adding extcon_dev into usb_phy/phy and all others are ready? My understanding you will also do: - We need find a central place to send the notification(phy common part). - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to findup it. > my one concern. (I am afraid if it is enough to send out vbus draw > information from USB phy driver, for example you will miss super speed > (900mA), which need get the speed information from gadget driver.) > Can we handle this in USB(so has super speed information) and just send out 900mA directly? Li Jun