From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754837AbcIFHmj (ORCPT ); Tue, 6 Sep 2016 03:42:39 -0400 Received: from mga14.intel.com ([192.55.52.115]:15438 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752338AbcIFHmd (ORCPT ); Tue, 6 Sep 2016 03:42:33 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,291,1470726000"; d="asc'?scan'208";a="1046152503" From: Felipe Balbi To: NeilBrown , Baolin Wang , Greg KH , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse Cc: 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, Baolin Wang , Linux PM list , USB , device-mainlining@lists.linuxfoundation.org, LKML Subject: Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation In-Reply-To: <8760q9a8m6.fsf@notabene.neil.brown.name> References: <8760q9a8m6.fsf@notabene.neil.brown.name> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Tue, 06 Sep 2016 10:40:48 +0300 Message-ID: <87poohmq67.fsf@linux.intel.com> 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 Content-Transfer-Encoding: quoted-printable Hi, NeilBrown writes: > Firstly, you have made the current limit associated with each cable type > configurable (__usb_charger_set_cur_limit_by_type). This is nonsense. > The standard (e.g. BC-1.2) declares what the current limits are. There > is no reason for those not to be hard coded. I had raised the same concern WRT configuration current limits. > Secondly, you treat each charger type as having a single "cur_limit" and > utilize that limit by telling the PMIC to draw that much current. > Again, this is inconsistent with the specification. > BC-1.2 defines, for each charger type, a minimum and maximum current > level. > The minimum should always be available. Attempting to draw more than > that (but less that the max) might work or might cause the charger > to shut down, but you can be sure that the charger will respond to the > increased load by first reducing the voltage, and will not shut down > until the voltage has dropped below 2V. > If you try to draw more current than the maximum, then the charger might > shut down before the voltage drops below 2V. Very well put :-) > Given this understanding of the current available from the charger, > there are two approaches the PMIC might take. > 1/ if the PMIC is able to exercise fine control over the current it > draws, and if it can monitor the voltage on the charger, then it > could gradually increase the power being requested until the voltage > drops below some threshold (e.g. 4.75V), and then (probably) back off > a little. It should only increase at most up to the maximum, even if > the voltage remains high. It should probably start at zero rather > than at the minimum. This allows for lossage elsewhere. That's what most charging control SW I've seen in the past ends up doing. Correct > 2/ If the PMIC cannot measure voltage, or doesn't have sufficiently fine > control of the current requested, then it should request only the > minimum available current. Any more is not safe. correct =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXznMAAAoJEMy+uJnhGpkGgLkP/20Tgt73necOGMLB0R6fgJq8 OGJFz/RnmDyoXLDMWjWM3vOAxUUvKvMkhNgiaJlNTCB3RYHhX+SrsIyl5o7Rr051 MFn1Gci/7KpzpLf3bq6b7kO1X9IRdhdv2ENEZLA0sX2N4PlP4wtMeKOtzrzKZfqN hv9sKaIcgxj2Y1l8dd8+9nsB9pnit/9uKIGwCFxoSTv54elLB6ZLYzm9dVNwqSRc 6y30yJ9yjYiO2ymGmE8m08vovYBn5nfGQYhPl8U0fjAHKDAU/pfpIaaLXB9qyVQd cgsZKGkZyOkyVdzg+uu6TGP1jZSIIn0ErFbp6g0Sa06r3HaVrt3MR3FqnSoUU/OS LAz3ygBBaZwMjD02DC9H5bewiwT808RHAGHrt5HpEdzxk7G83Oo10ja5d3KpcyS0 xUTbjm32TMnB8EKh+pgbCL+6ZGiMTTsUsQO+NORRn3OlcD5Nprz1f6erpyra5kiO fTDEkJ3oPLnjgH5C3DChW/oMsZIut++KB5JD89fmXiGzjnXqgMQQhqp02Fd3WrKg wChz5/Xv1qzI+N66qZqVT9yD/DkiCjbB/9jnifJ39WFENz78IlRo10ECayZFC3gQ xlouNFMj8sJFa60GFdiljq0Wo7kdp7V5o6goatMDKv/jTT6iBulfQXZ+7lnt2hzi 4PjS6mccfmAXBHKaOTr5 =r/Fs -----END PGP SIGNATURE----- --=-=-=--