From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755204AbcIIVTx (ORCPT ); Fri, 9 Sep 2016 17:19:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:54813 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753269AbcIIVTw (ORCPT ); Fri, 9 Sep 2016 17:19:52 -0400 From: NeilBrown To: Baolin Wang Date: Sat, 10 Sep 2016 07:19:32 +1000 Cc: NeilBrown , Felipe Balbi , Greg KH , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , robh@kernel.org, Jun Li , Marek Szyprowski , Ruslan Bilovol , Peter Chen , Alan Stern , r.baldyga@samsung.com, grygorii.strashko@ti.com, Yoshihiro Shimoda , Lee Jones , Mark Brown , Charles Keepax , patches@opensource.wolfsonmicro.com, Linux PM list , USB , device-mainlining@lists.linuxfoundation.org, LKML , "Bird\, Timothy" Subject: Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation In-Reply-To: References: <8760q9a8m6.fsf@notabene.neil.brown.name> <878tv297a0.fsf@notabene.neil.brown.name> <87y4326l44.fsf@notabene.neil.brown.name> User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-suse-linux-gnu) Message-ID: <87twdo7ouz.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain On Fri, Sep 09 2016, Baolin Wang wrote: >> >> In practice, the USB PHY and the Power manager will often be in the same >> IC (the PMIC) so the driver for one could look at the registers for the >> other. >> But there is no guarantee that the hardware works like that. It is >> best to create a generally design. > > Yes, we hope to create one generally design, so we need to consider > this situation: the power supply getting the charger type by accessing > PMIC registers. The registers which save the charger type are not > always belong to the USB PHY, may be just some registers on PMIC. If the power_supply can directly detect the type of charger, then it doesn't need any usb-charger-infrastructure to tell it. It can handle current selection entirely internally. Surely the only interesting case for a framework to address is the one where the power_supply cannot directly detect the charger type. > > Now in mainline kernel, there are 3 methods can get the charger type > which need to integrate with USB charger framework: > 1. power supply > 2. extcon (need to add as you suggested) > 3. others (by 'get_charger_type' callback of USB charger) There is no "get_charger_type" now in the mainline kernel. >>> >>> Suppose the USB configuration requests 100mA, then we should set the >>> USB charger current is 100mA by __usb_charger_set_cur_limit_by_type() >>> funtion, then notify this to power driver. >> >> ahh.... I had missed something there. It's a while since I looked >> closely at these patches. >> >> Only.... this usage of usb_charger_set_cur_limit_by_type() is really >> nonsensical. >> >> If the cable is detected as being DCP or CDP or ACA (or ACA/DOCK) then >> the number negotiated with the USB configuration is not relevant and >> should be ignored. There is a guaranteed minimum which is at least the >> maximum that *can* be negotiated. > > Yes. If it is not relevant, we will no't set the current from USB > configuration. Just when your charger type is SDP and the USB > enumeration is done, we can get the USB configuration from host to set > current. But you do! The mA number from the USB configuration is passed to usb_gadget_vbus_draw. Your patch passes that to usb_charger_set_cur_limit_by_type() which calls __usb_charger_set_cur_limit_by_type() which will set the cur_limit for whichever type uchger->type currently is. So when it is not relevant, your code *does* set some current limit. NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX0ydkAAoJEDnsnt1WYoG5fJoP/1Ggy273jgWCzFBh0t+U94z0 9CE/vTsLu01vD7VIIZUkf/37dMmUjMfyxjTLSFFZKoqtx5KtkOVxmlQOrzdu8iP6 QxdUac47Lcz1B4rTmtNyqoarXBiJvTjgbKxRX/n4y3FQpdrlkYKDi0fnwTv80SaM Hx2MrHrCtHeamhH2pPY1R4cgN66OlQMVTk7gPzPTx3jX2lJ3UxcnJ0WX8Ov/sQCT G/CPZtFF8b87ZhpV3qfUke36U9UrjA38U0TJnIbQnWDlUqzIx+UXdk4aIQLCAx5A kyFCiWp4lf9EoAPd7WJMnuNit/gpUTghholf+LaiW0RsQnXHBc2uVdyw2iJP7c5T 50MC6ciK9bYCkwks6xy3qMXX+FywJeOE1g4pCK81CbRkyLx8UA3xHnyNKpkd5jmI LVCLuL6wbURh8KubsFtATUivd4S8Tz3/fJhk+5IDjYU4CPlBioaWrm8JkUfdOYMb JMgTTU/xUfNT7dV751UAmqqOY++3aYkJ84t1yY181FlMH9gj0d9abNO328yEGyn0 /8ENtaly6i48sBydnvbyGPDDqAhc18IHVVCimhTkKn1VrP2bXKKeX62VXtYNW8yn yO67aKftpRqsYECe/1Nivq5pYeInLWbeM56XQdCWZKEnkk43woHxdOrWgzLww69N epd+AscieuFt1J2Iptkh =mWMJ -----END PGP SIGNATURE----- --=-=-=--