Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933413AbdCMBJh (ORCPT ); Sun, 12 Mar 2017 21:09:37 -0400 Received: from mail-eopbgr20086.outbound.protection.outlook.com ([40.107.2.86]:38880 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755805AbdCMBJ1 (ORCPT ); Sun, 12 Mar 2017 21:09:27 -0400 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+GrQgABUz4CAAAzoUIAAL7wAgAKLhRA= Date: Mon, 13 Mar 2017 01:09:21 +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: [192.158.241.86] x-ms-office365-filtering-correlation-id: 4f449e98-4860-400d-66b5-08d469ad9536 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081);SRVR:AM5PR04MB2962; x-microsoft-exchange-diagnostics: 1;AM5PR04MB2962;7:eULGxKv/vt6K6EKL+KZ5dqgp1ObfLyDFbvM8OIjf6WGmV67WfBu403uf50vU2SnJ+YA7Uo1YDHyRbIBU77kQ1binN16qvuKgqg+fHM2mq8I/FrU06KbeO4bf2yfn9C3BqPKIsb6wKmHsRyeHUBWCj5QR8yhzcVaWBZx6bPyRbIZe4k9gNc8GjgVv4LzbjhuuXxJEQC5rB+hKDoBQA9+SN2y0uNHJQYBr5PWJBpqTxnbWfcIgq9H2aM3S+eCVhKCwNuYAq+y/xsqr3o4B5WVmVqYdxVAvZRUm6uR4eNPAJ+sp5LcXBEo/bvuTB176Ho//gXxFE+jLhhFN75jO9YcDRg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31051911155226)(9452136761055)(35073007944872)(185117386973197)(101931422205132)(35762410373642)(21532816269658)(7411616537696); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148);SRVR:AM5PR04MB2962;BCL:0;PCL:0;RULEID:;SRVR:AM5PR04MB2962; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(377454003)(24454002)(13464003)(76104003)(102836003)(3846002)(6116002)(5660300001)(2906002)(93886004)(66066001)(4326008)(2900100001)(122556002)(6916009)(2950100002)(7696004)(7416002)(106116001)(53936002)(86362001)(53546006)(6246003)(76176999)(54356999)(110136004)(38730400002)(99286003)(55016002)(54906002)(8936002)(9686003)(3280700002)(305945005)(229853002)(39060400002)(8676002)(50986999)(3660700001)(81166006)(33656002)(97736004)(77096006)(7736002)(189998001)(6506006)(74316002)(25786008)(6436002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR04MB2962;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: 13 Mar 2017 01:09:21.8774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR04MB2962 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 v2D19nQX009061 Content-Length: 8285 Lines: 192 Hi, > -----Original Message----- > From: Baolin Wang [mailto:baolin.wang@linaro.org] > Sent: Friday, March 10, 2017 6:52 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 10 March 2017 at 16:27, Jun Li wrote: > > Hi > > > >> -----Original Message----- > >> From: Baolin Wang [mailto:baolin.wang@linaro.org] > >> Sent: Friday, March 10, 2017 3:15 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 10 March 2017 at 14:30, Jun Li wrote: > >> >> >> > > >> >> >> > 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). > >> > >> That will include these implementation when adding extcon_dev. > >> > > > > OK, thanks. > > > >> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs > >> > some > >> API to findup it. > >> > >> PMIC can find extcon device by phandle. > > > > extcon_dev(not a reference pointer) is directly added in usb_phy/phy, > > not via devicetree, how PMIC find it by phandle? > > From my understanding, here we should add one pointer (extcon_dev *), > since usb phy is not one external connect device. Agreed. > > > > >> > >> > > >> >> 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? > >> > >> From Neil's suggestion, we only have one place to send out current > >> information from usb phy, so I have this concern and doubt if we > >> still need the USB charger framework. > > > > So if put it in phy/usb_phy, this is a problem, that only one place > > should have the infor of both speed and usb state, how about put it at > > usb_gadget, then, e.g. send the notification in > usb_gadget_vbus_connect()? > > That is same what USB charger did, from this point, we need USB charger to > send out vbus draw information according to speed and usb state. But I > should listen to other guys suggestion. Peter and Felipe, what do you think? So now the only to do work is to find a common place to send the notification out (based on gadget speed and sate). Li Jun > > -- > Baolin.wang > Best Regards