From: Peter Chen <hzpeterchen@gmail.com>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: Felipe Balbi <balbi@kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
Sebastian Reichel <sre@kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Peter Chen <peter.chen@freescale.com>,
Alan Stern <stern@rowland.harvard.edu>,
r.baldyga@samsung.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,
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 v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Tue, 5 Apr 2016 16:12:22 +0800 [thread overview]
Message-ID: <20160405081222.GC31351@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <CAMz4kuKWpFLbYJM+m3syT+aMNVxjBipU_3=qwz=X0L_oB5bR0w@mail.gmail.com>
On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> Hi Peter,
>
> On 5 April 2016 at 14:46, Peter Chen <hzpeterchen@gmail.com> wrote:
> >
> > We are thinking USB charger framework for Freescale i.mx SoC series,
> > since our internal framework is not good enough.
> > So I have more questions for your framework since there are many
> > different USB charger designs, and I hope it is universal.
>
> Great, thanks for your attention and suggestions.
>
> >
> > - I would like to see your all code to let the charger work, eg
> > you have said the charger detection is done by PMIC automatically,
> > but I did not find your PMIC code to read charger type.
>
> Yeah, this patchset did not give an example to read charger type from
> PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
> But I think user can get it easily by implementing below callbacks.
> (1) gadget->ops->get_charger_type();
> (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, &val);
> (3) uchger->get_charger_type();
>
I just would like if you can have this, then, we (you) can test it, eg,
you can test if the wm831x can charge more than 1500mA for DCP.
> In some solutions, when one cable is plugin, the PMIC will detect the
> charger type automatically and you can read it from PMIC registers
> then. Then maybe one interrupt or other ways to report to gadget to do
> enumeration. So user can read the PMIC registers to get charger type
> by implementing any above methods.
>
Wait. When the USB cable is plugging in, which module will get
interrupt? Only PMIC or Both PMIC and USB (or extcon)? If PMIC
can trigger USB "connect" interrupt, then it is ok.
> >
> > Besides, how you can make sure the charger detection has finished
> > before the framework handles USB_CHARGER_PRESENT event?
>
> I think we don't need to care about this situation. If the charger
> type is 'UNKNOWN_TYPE' (maybe charger detection is not finished yet),
> the charger framework will not set current (current is 0) for power
> driver.
Then, when we notify the charger IC for larger current, eg, for DCP.
>
> >
> > - I commented the current limit at different situations for USB
> > charger last time, but I have not seen your further comments.
> > I would like give it again. For DCP, you can notify charger IC
> > once you get the charger type. But for CDP/SDP, you need to
> > notify charger IC after set configuration has finished, since
> > the host may still not be ready to give high current.
>
> As my understanding, if the usb charger framework get the charger
> type, it means we can notify the power driver to set the current. If
> you don't ready for setting current, please don't give the charger
> type to usb charger framework.
>
> The framework does not want to focus on charger detection too much,
> and just supplies one callback '->charger_detect()' for user to be
> implemented if they ensure they need to do the SW charger detection
> manually (Note: must at the right time to do the SW detection.). So
> the usb charger just focus on dealing with the usb gadget power
> negotiation, and it does not need to care much how to do charger
> detection on your platform.
No, this comment is common one, but only for SW detection. Eg, when
the PMIC tells you it is a SDP, you can't notify to charger IC about
500mA at once, you need to do it after host allows you to do it.
--
Best Regards,
Peter Chen
next prev parent reply other threads:[~2016-04-05 8:12 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 7:21 [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
[not found] ` <cover.1459494743.git.baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-04-01 7:21 ` [PATCH v9 1/4] gadget: Introduce the usb charger framework Baolin Wang
2016-04-05 7:56 ` Peter Chen
[not found] ` <20160405075612.GB31351-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2016-04-05 9:41 ` Baolin Wang
2016-04-06 7:25 ` Peter Chen
2016-04-06 7:38 ` Felipe Balbi
2016-04-06 7:43 ` Peter Chen
2016-04-06 8:05 ` Felipe Balbi
2016-04-06 8:10 ` Peter Chen
2016-04-06 10:25 ` Felipe Balbi
2016-04-07 2:39 ` Peter Chen
2016-04-07 4:56 ` Felipe Balbi
2016-04-07 6:11 ` Baolin Wang
2016-04-06 8:11 ` Peter Chen
2016-04-06 10:25 ` Felipe Balbi
2016-04-06 8:26 ` Jun Li
2016-04-06 11:31 ` Baolin Wang
2016-04-06 11:55 ` Jun Li
2016-04-01 7:21 ` [PATCH v9 3/4] gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2016-04-01 7:21 ` [PATCH v9 2/4] gadget: Support for the usb charger framework Baolin Wang
2016-04-06 7:19 ` Peter Chen
2016-04-06 10:46 ` Baolin Wang
2016-04-06 12:03 ` Jun Li
[not found] ` <AM4PR04MB2130F58AA1018FFD367C89E0899F0-WOempg8NbQQzjTQnahXoOs9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2016-04-06 12:21 ` Felipe Balbi
2016-04-06 12:51 ` Jun Li
[not found] ` <AM4PR04MB213054CF3F597CE2E6FE976F899F0-WOempg8NbQQzjTQnahXoOs9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2016-04-06 12:55 ` Felipe Balbi
[not found] ` <87oa9m28x0.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-04-06 13:49 ` Jun Li
2016-04-06 13:58 ` Felipe Balbi
2016-04-07 3:03 ` Peter Chen
2016-04-07 4:58 ` Felipe Balbi
2016-04-01 7:21 ` [PATCH v9 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang
2016-04-05 6:46 ` [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Peter Chen
2016-04-05 7:54 ` Baolin Wang
2016-04-05 8:12 ` Peter Chen [this message]
2016-04-05 9:34 ` Baolin Wang
2016-04-05 9:43 ` Peter Chen
2016-04-05 11:06 ` Baolin Wang
2016-04-05 17:01 ` Mark Brown
2016-04-05 16:53 ` Mark Brown
2016-04-06 1:15 ` Peter Chen
2016-04-06 17:01 ` Mark Brown
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=20160405081222.GC31351@shlinux2.ap.freescale.net \
--to=hzpeterchen@gmail.com \
--cc=balbi@kernel.org \
--cc=baolin.wang@linaro.org \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=dbaryshkov@gmail.com \
--cc=device-mainlining@lists.linuxfoundation.org \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=peter.chen@freescale.com \
--cc=r.baldyga@samsung.com \
--cc=sre@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).