All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Jun Li <jun.li-3arQi8VN3Tc@public.gmane.org>,
	Peter Chen <hzpeterchen-Re5JQEeQqe8AvxtiuMwx3w@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>,
	Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Alan Stern
	<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
	"r.baldyga@samsung.com"
	<r.baldyga-Sze3O3UU22JBDgjK7y7TUQ@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@opensource.wolfsonmicro.com"
	<patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	Linux PM list <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"device-mainlining@lists.linuxfoundation.org"
	<device-mainlining-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Thu, 31 Mar 2016 09:18:21 +0300	[thread overview]
Message-ID: <87y48zgogi.fsf@intel.com> (raw)
In-Reply-To: <CAMz4kuJhrfE_6s2y9Cdo8t3Z3mvKf9rYs-kkRfBFD_SNL7pv=g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]


Hi,

Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
> [ text/plain ]
> On 30 March 2016 at 19:24, Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> >> >> >
>>>> >> >> > Seems you don't want to guarantee charger type detection is done
>>>> >> >> > before gadget connection(pullup DP), right?
>>>> >> >> > I see you call usb_charger_detect_type() in each gadget usb
>>>> >> >> > state
>>>> >> >> changes.
>>>> >> >>
>>>> >> >> I am not sure I get your point correctly, please correct me if I
>>>> >> >> misunderstand you.
>>>> >> >> We need to check the charger type at every event comes from the
>>>> >> >> usb gadget state changes or the extcon device state changes, which
>>>> >> >> means a new charger plugin or pullup.
>>>> >> >>
>>>> >> >
>>>> >> > According to usb charger spec, my understanding is you can't do
>>>> >> > real charger detection procedure *after* gadget _connection_(pullup
>>>> >> > DP), also I don't
>>>> >>
>>>> >> Why can not? Charger detection is usually from PMIC.
>>>> >
>>>> > Charger detection process will impact DP/DM line state, see usb
>>>> > charger spec v1.2 for detail detection process, section 4.6.3 says:
>>>> >
>>>> > "A PD is allowed to *disconnect* and repeat the charger detection
>>>> > process multiple times while attached. The PD is required to wait for
>>>> > a time of at least TCP_VDM_EN max between disconnecting and restarting
>>>> > the charger detection process."
>>>> >
>>>> > As Peter mentioned, the charger detection should happen between VBUS
>>>> > detection and gadget pull up DP for first plug in case. So when&after
>>>> > gadget connect (pullup DP), you should already know the charger type.
>>>>
>>>> Make sense. In our company's solution, charger detection can be done by
>>>> hardware from PMIC at first, then it will not affect the DP/DM line when
>>>> gadget starts to enumeration.
>>>
>>> I see, charger type detection is done automatically by PMIC when VBUS
>>> is detected in your case, you just assume the process is complete
>>
>> assuming this finishes before gadget starts is a bad idea. It would've
>> been much more robust to delay usb_gadget_connect() until we KNOW
>> charger detection has completed.
>
> It is hardware action to detect the charger type quickly. It actually
> *gets* the charger type and does not means *detect* charger type in
> 'usb_charger_detect_type()' function. Maybe I need to change the
> function name as 'usb_charger_get_type()'.

yes.

> If some udc drivers want to detect charger type in
> 'gadget->ops->get_charger_type()' callback, they should avoid
> impacting DP/DM line state at the right gadget state. Thanks.

they shouldn't detect is get_type(), the semantics doesn't work. If, at
some point, we have to do SW detection of the charger, then a new
->charger_detect() method will have to be added.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: Jun Li <jun.li@nxp.com>, Peter Chen <hzpeterchen@gmail.com>,
	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" <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" 
	<patches@opensource.wolfsonmicro.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	USB <linux-usb@vger.kernel.org>,
	"device-mainlining\@lists.linuxfoundation.org" 
	<device-mainlining@lists.linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Thu, 31 Mar 2016 09:18:21 +0300	[thread overview]
Message-ID: <87y48zgogi.fsf@intel.com> (raw)
In-Reply-To: <CAMz4kuJhrfE_6s2y9Cdo8t3Z3mvKf9rYs-kkRfBFD_SNL7pv=g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]


Hi,

Baolin Wang <baolin.wang@linaro.org> writes:
> [ text/plain ]
> On 30 March 2016 at 19:24, Felipe Balbi <balbi@kernel.org> wrote:
>>>> >> >> >
>>>> >> >> > Seems you don't want to guarantee charger type detection is done
>>>> >> >> > before gadget connection(pullup DP), right?
>>>> >> >> > I see you call usb_charger_detect_type() in each gadget usb
>>>> >> >> > state
>>>> >> >> changes.
>>>> >> >>
>>>> >> >> I am not sure I get your point correctly, please correct me if I
>>>> >> >> misunderstand you.
>>>> >> >> We need to check the charger type at every event comes from the
>>>> >> >> usb gadget state changes or the extcon device state changes, which
>>>> >> >> means a new charger plugin or pullup.
>>>> >> >>
>>>> >> >
>>>> >> > According to usb charger spec, my understanding is you can't do
>>>> >> > real charger detection procedure *after* gadget _connection_(pullup
>>>> >> > DP), also I don't
>>>> >>
>>>> >> Why can not? Charger detection is usually from PMIC.
>>>> >
>>>> > Charger detection process will impact DP/DM line state, see usb
>>>> > charger spec v1.2 for detail detection process, section 4.6.3 says:
>>>> >
>>>> > "A PD is allowed to *disconnect* and repeat the charger detection
>>>> > process multiple times while attached. The PD is required to wait for
>>>> > a time of at least TCP_VDM_EN max between disconnecting and restarting
>>>> > the charger detection process."
>>>> >
>>>> > As Peter mentioned, the charger detection should happen between VBUS
>>>> > detection and gadget pull up DP for first plug in case. So when&after
>>>> > gadget connect (pullup DP), you should already know the charger type.
>>>>
>>>> Make sense. In our company's solution, charger detection can be done by
>>>> hardware from PMIC at first, then it will not affect the DP/DM line when
>>>> gadget starts to enumeration.
>>>
>>> I see, charger type detection is done automatically by PMIC when VBUS
>>> is detected in your case, you just assume the process is complete
>>
>> assuming this finishes before gadget starts is a bad idea. It would've
>> been much more robust to delay usb_gadget_connect() until we KNOW
>> charger detection has completed.
>
> It is hardware action to detect the charger type quickly. It actually
> *gets* the charger type and does not means *detect* charger type in
> 'usb_charger_detect_type()' function. Maybe I need to change the
> function name as 'usb_charger_get_type()'.

yes.

> If some udc drivers want to detect charger type in
> 'gadget->ops->get_charger_type()' callback, they should avoid
> impacting DP/DM line state at the right gadget state. Thanks.

they shouldn't detect is get_type(), the semantics doesn't work. If, at
some point, we have to do SW detection of the charger, then a new
->charger_detect() method will have to be added.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2016-03-31  6:18 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24 12:35 [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2016-03-24 12:35 ` [PATCH v8 1/4] gadget: Introduce the usb charger framework Baolin Wang
2016-04-23 19:53   ` Pavel Machek
2016-04-24  5:32     ` Baolin Wang
     [not found] ` <cover.1458822334.git.baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-03-24 12:35   ` [PATCH v8 2/4] gadget: Support for " Baolin Wang
2016-03-24 12:35     ` Baolin Wang
2016-03-27  1:29     ` kbuild test robot
2016-03-27  1:29       ` kbuild test robot
2016-03-25  7:09   ` [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Peter Chen
2016-03-25  7:09     ` Peter Chen
2016-03-28  6:51     ` Baolin Wang
2016-03-28  7:13       ` Peter Chen
2016-03-28  9:09         ` Baolin Wang
     [not found]           ` <CAMz4kuK33mfiO9OttbRF9yVbQE1DFeuOtwyUWkCa5iPYbE-H8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-29  0:32             ` Peter Chen
2016-03-29  0:32               ` Peter Chen
2016-03-29  2:05               ` Baolin Wang
2016-03-29 17:14                 ` Mark Brown
2016-03-29 17:23         ` Mark Brown
2016-03-30  2:05           ` Peter Chen
2016-03-30  7:07             ` Baolin Wang
2016-03-30  7:07               ` Baolin Wang
     [not found]               ` <CAMz4kuKkSt0xj_1jGC9d_yVpEX0krBB_M6x1C3ZR9bDGabQeLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-30  7:42                 ` Peter Chen
2016-03-30  7:42                   ` Peter Chen
2016-03-30  8:40                   ` Baolin Wang
2016-03-30  9:19                     ` Peter Chen
2016-03-30  9:32                       ` Baolin Wang
     [not found]       ` <CAMz4kuJYBg4eortA35Dhr4-jPVhLzu9XhjpOcu0hDWq6FV09mw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-29  8:45         ` Jun Li
2016-03-29  8:45           ` Jun Li
2016-03-29  9:48           ` Baolin Wang
2016-03-30  2:54             ` Jun Li
2016-03-30  6:15               ` Baolin Wang
2016-03-30  8:07                 ` Jun Li
2016-03-30  8:07                   ` Jun Li
2016-03-30  9:30                   ` Baolin Wang
     [not found]                     ` <CAMz4kuLY8vO5qnkuY+kv91zKpdxBBSDeLZXFvD1LjnS3R3UccA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-30 10:58                       ` Jun Li
2016-03-30 10:58                         ` Jun Li
2016-03-30 11:24                         ` Felipe Balbi
2016-03-30 11:24                           ` Felipe Balbi
2016-03-31  5:33                           ` Baolin Wang
2016-03-31  6:18                             ` Felipe Balbi [this message]
2016-03-31  6:18                               ` Felipe Balbi
     [not found]                               ` <87y48zgogi.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-03-31  6:35                                 ` Baolin Wang
2016-03-31  6:35                                   ` Baolin Wang
     [not found]                         ` <AM4PR04MB1665E85D823D5AB59B54B56D89980-WOempg8NbQQyfSGIpie7pc9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2016-03-31  5:22                           ` Baolin Wang
2016-03-31  5:22                             ` Baolin Wang
     [not found]                             ` <CAMz4kuLxfEr_cOa0F-Qh+Mo+dEVGWx+YPZ_=yb9FVwWdJd8viQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-31  6:12                               ` Jun Li
2016-03-31  6:12                                 ` Jun Li
2016-03-31  6:37                                 ` Baolin Wang
2016-03-31  8:15                                   ` Felipe Balbi
2016-03-31  8:15                                     ` Felipe Balbi
     [not found]                                     ` <87egargj1y.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-03-31  8:24                                       ` Baolin Wang
2016-03-31  8:24                                         ` Baolin Wang
2016-03-24 12:35 ` [PATCH v8 3/4] gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2016-03-24 12:35 ` [PATCH v8 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang
2016-03-27  2:08   ` kbuild test robot
2016-03-27  2:08     ` kbuild test robot
2016-03-27  8:22   ` Geert Uytterhoeven
2016-03-28  6:45     ` Baolin Wang

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=87y48zgogi.fsf@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=hzpeterchen-Re5JQEeQqe8AvxtiuMwx3w@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=patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=r.baldyga-Sze3O3UU22JBDgjK7y7TUQ@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.