From: Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: NeilBrown <nfbrown-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>,
Greg KH
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Dmitry Eremin-Solenikov
<dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Jun Li <jun.li-3arQi8VN3Tc@public.gmane.org>,
Marek Szyprowski
<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Ruslan Bilovol
<ruslan.bilovol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Alan Stern
<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
r.baldyga-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
grygorii.strashko-l0cyMroinI0@public.gmane.org,
Yoshihiro Shimoda
<yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Charles Keepax
<ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org,
Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Linux PM list <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
device-mainlining-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Tue, 06 Sep 2016 10:40:48 +0300 [thread overview]
Message-ID: <87poohmq67.fsf@linux.intel.com> (raw)
In-Reply-To: <8760q9a8m6.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Hi,
NeilBrown <nfbrown-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> 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
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: NeilBrown <nfbrown@novell.com>,
Baolin Wang <baolin.wang@linaro.org>,
Greg KH <gregkh@linuxfoundation.org>,
Sebastian Reichel <sre@kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Cc: robh@kernel.org, Jun Li <jun.li@nxp.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Ruslan Bilovol <ruslan.bilovol@gmail.com>,
Peter Chen <peter.chen@freescale.com>,
Alan Stern <stern@rowland.harvard.edu>,
r.baldyga@samsung.com, grygorii.strashko@ti.com,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Lee Jones <lee.jones@linaro.org>, Mark Brown <broonie@kernel.org>,
Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
patches@opensource.wolfsonmicro.com,
Baolin Wang <baolin.wang@linaro.org>,
Linux PM list <linux-pm@vger.kernel.org>,
USB <linux-usb@vger.kernel.org>,
device-mainlining@lists.linuxfoundation.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Tue, 06 Sep 2016 10:40:48 +0300 [thread overview]
Message-ID: <87poohmq67.fsf@linux.intel.com> (raw)
In-Reply-To: <8760q9a8m6.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]
Hi,
NeilBrown <nfbrown@novell.com> 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
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
next prev parent reply other threads:[~2016-09-06 7:40 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-01 7:09 [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2016-08-01 7:09 ` [PATCH v16 1/4] usb: gadget: Introduce the usb charger framework Baolin Wang
2016-08-01 7:09 ` [PATCH v16 2/4] usb: gadget: Support for " Baolin Wang
2016-08-01 7:09 ` [PATCH v16 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2016-08-01 7:09 ` [PATCH v16 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang
[not found] ` <cover.1470034830.git.baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-11 3:14 ` [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2016-08-11 3:14 ` Baolin Wang
2016-08-29 9:02 ` Baolin Wang
2016-09-06 5:40 ` NeilBrown
2016-09-06 5:40 ` NeilBrown
[not found] ` <8760q9a8m6.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2016-09-06 7:40 ` Felipe Balbi [this message]
2016-09-06 7:40 ` Felipe Balbi
2016-09-08 6:55 ` Baolin Wang
2016-09-08 6:55 ` Baolin Wang
2016-09-08 7:31 ` NeilBrown
2016-09-08 7:31 ` NeilBrown
2016-09-08 8:12 ` Baolin Wang
2016-09-08 8:12 ` Baolin Wang
2016-09-08 23:13 ` NeilBrown
2016-09-08 23:13 ` NeilBrown
2016-09-09 6:46 ` Baolin Wang
2016-09-09 6:46 ` Baolin Wang
2016-09-09 21:19 ` NeilBrown
2016-09-09 21:19 ` NeilBrown
2016-09-18 9:39 ` Baolin Wang
2016-09-18 9:39 ` Baolin Wang
2016-10-05 7:26 ` Baolin Wang
2016-10-05 7:26 ` Baolin Wang
2016-10-05 7:47 ` Felipe Balbi
2016-10-05 7:47 ` Felipe Balbi
[not found] ` <878tu3p78u.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-10-05 7:57 ` Baolin Wang
2016-10-05 7:57 ` Baolin Wang
2016-10-05 10:44 ` NeilBrown
2016-10-05 10:44 ` NeilBrown
2016-10-08 3:18 ` Baolin Wang
2016-10-08 3:18 ` Baolin Wang
2016-09-09 11:07 ` Mark Brown
2016-09-09 11:07 ` Mark Brown
2016-09-09 21:57 ` NeilBrown
2016-09-09 21:57 ` NeilBrown
2016-09-12 12:25 ` Mark Brown
2016-09-12 12:25 ` Mark Brown
[not found] ` <20160912122549.GZ27946-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-12 13:27 ` NeilBrown
2016-09-12 13:27 ` NeilBrown
[not found] ` <87inu11c5l.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2016-09-12 15:26 ` Mark Brown
2016-09-12 15:26 ` Mark Brown
2016-09-13 8:00 ` NeilBrown
2016-09-13 8:00 ` NeilBrown
2016-09-14 11:16 ` Mark Brown
2016-09-14 11:16 ` Mark Brown
2016-09-14 14:11 ` NeilBrown
2016-09-14 14:11 ` NeilBrown
2016-09-14 14:57 ` Mark Brown
2016-09-14 14:57 ` Mark Brown
2016-09-14 17:50 ` NeilBrown
2016-09-14 17:50 ` NeilBrown
2016-09-14 18:02 ` Mark Brown
2016-09-14 18:02 ` Mark Brown
2016-09-15 10:33 ` Pavel Machek
2016-09-15 10:33 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87poohmq67.fsf@linux.intel.com \
--to=balbi-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=device-mainlining-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \
--cc=jun.li-3arQi8VN3Tc@public.gmane.org \
--cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=nfbrown-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org \
--cc=patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=r.baldyga-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=ruslan.bilovol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
--cc=yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.