Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1364116 > unrolled thread

[PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Started byBaolin Wang <baolin.wang@linaro.org>
First post2016-03-24 13:40 +0100
Last post2016-03-31 10:30 +0200
Articles 17 on this page of 37 — 7 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-24 13:40 +0100
    [PATCH v8 2/4] gadget: Support for the usb charger framework Baolin Wang <baolin.wang@linaro.org> - 2016-03-24 13:40 +0100
    [PATCH v8 1/4] gadget: Introduce the usb charger framework Baolin Wang <baolin.wang@linaro.org> - 2016-03-24 13:40 +0100
    [PATCH v8 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang <baolin.wang@linaro.org> - 2016-03-24 13:40 +0100
      Re: [PATCH v8 4/4] power: wm831x_power: Support USB charger current  limit management Geert Uytterhoeven <geert@linux-m68k.org> - 2016-03-27 10:30 +0200
        Re: [PATCH v8 4/4] power: wm831x_power: Support USB charger current  limit management Baolin Wang <baolin.wang@linaro.org> - 2016-03-28 08:50 +0200
    [PATCH v8 3/4] gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang <baolin.wang@linaro.org> - 2016-03-24 13:40 +0100
    Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Peter Chen <hzpeterchen@gmail.com> - 2016-03-25 08:20 +0100
      Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-28 09:00 +0200
        Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Peter Chen <hzpeterchen@gmail.com> - 2016-03-28 09:20 +0200
          Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-28 11:20 +0200
            RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Peter Chen <peter.chen@nxp.com> - 2016-03-29 02:50 +0200
              Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-29 04:10 +0200
                Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-03-29 19:20 +0200
          Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-03-29 19:30 +0200
            Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Peter Chen <hzpeterchen@gmail.com> - 2016-03-30 04:10 +0200
              Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-30 09:10 +0200
                Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Peter Chen <hzpeterchen@gmail.com> - 2016-03-30 09:50 +0200
                  Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-30 10:50 +0200
                    Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Peter Chen <hzpeterchen@gmail.com> - 2016-03-30 11:30 +0200
                      Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-30 11:40 +0200
        RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Jun Li <jun.li@nxp.com> - 2016-03-29 11:20 +0200
          Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-29 11:50 +0200
            RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Jun Li <jun.li@nxp.com> - 2016-03-30 05:00 +0200
              Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-30 08:20 +0200
                RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Jun Li <jun.li@nxp.com> - 2016-03-30 10:50 +0200
                  Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-30 11:40 +0200
                    RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Jun Li <jun.li@nxp.com> - 2016-03-30 13:00 +0200
                      RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Felipe Balbi <balbi@kernel.org> - 2016-03-30 13:30 +0200
                        Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-31 07:40 +0200
                          Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Felipe Balbi <balbi@kernel.org> - 2016-03-31 08:30 +0200
                            Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-31 08:40 +0200
                      Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-31 07:30 +0200
                        RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Jun Li <jun.li@nxp.com> - 2016-03-31 08:20 +0200
                          Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-31 08:40 +0200
                            Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Felipe Balbi <balbi@kernel.org> - 2016-03-31 10:20 +0200
                              Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Baolin Wang <baolin.wang@linaro.org> - 2016-03-31 10:30 +0200

Page 2 of 2 — ← Prev page 1 [2]


#1367041 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-30 11:40 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rikLx-3iV-13@gated-at.bofh.it>
In reply to#1367034
On 30 March 2016 at 17:19, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Wed, Mar 30, 2016 at 04:40:31PM +0800, Baolin Wang wrote:
>> >> > - Third, since composite driver covers 500mA (and more for CDP) after set
>> >> > configuration and 2mA after suspend, and vbus handler covers connect
>> >> > and disconnect. I can't see any reasons we need to notify gadget state
>> >> > for power driver, do we really need to have usb_charger_plug_by_gadget?
>> >>
>> >> In some solutions, gadget does not negotiate with the current. They
>> >> just send out one signal to power driver to set the current when the
>> >> gadget state is changed (plugin or not). So we need to check the
>> >> charger state by the gadget state to notify the charger IC to set
>> >> current.
>> >>
>> >
>> > Would you give some examples?
>>
>> OK. I explain it in detail. Now charger detection can be from gadget
>> itself or PMIC, and we focus on gadget detection. Charger IC (charger
>> driver) is separate with gadget.
>> When the usb cable is plugin, we need to report the plugin event to
>> charger driver to set current after setting configuration for gadget.
>> The usb charger is responsible for reporting plugin event to charger
>> driver. But how usb charger get the plugin event? It can get the
>> plugin event from gadget state (if the gadget state is more than
>> 'USB_STATE_ATTACHED', it means one cable plugin). So we need notify
>> gadget state to usb charger.
>>
>
> Ok, I see, it only changes current limit at function usb_gadget_vbus_draw
> in your patch 2/4. Then, we need to make sure usb_charger_set_cur_limit_by_type
> is called before calling usb_gadget_set_state(gadget, USB_STATE_CONFIGURED).

That's right.

>
> It seems you have not implemented usb_charger_plug_by_gadget in your patch set.

It is implemented in patch 3/4.

>
> --
> Best Regards,
> Peter Chen



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1366043 — RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromJun Li <jun.li@nxp.com>
Date2016-03-29 11:20 +0200
SubjectRE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rhXYC-3S8-27@gated-at.bofh.it>
In reply to#1365371

> -----Original Message-----
> From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-
> owner@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, March 28, 2016 2:52 PM
> To: Peter Chen <hzpeterchen@gmail.com>
> 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 v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 25 March 2016 at 15:09, Peter Chen <hzpeterchen@gmail.com> wrote:
> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> >> charger, which is pending testing. Moreover there may be other
> >> potential users will use it in future.
> >>
> >
> > I am afraid I still not find the user (udc driver) for this framework,
> > I would like to see how udc driver block the enumeration until the
> > charger detection has finished, or am I missing something?
> 
> It is not for udc driver but for power users who want to negotiate with
> USB subsystem.
> 

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.

Li Jun  
> >
> > --
> > Best Regards,
> > Peter Chen
> 
> 
> 
> --
> Baolin.wang
> Best Regards
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]


#1366079 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-29 11:50 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rhYrE-46p-11@gated-at.bofh.it>
In reply to#1366043
On 29 March 2016 at 16:45, Jun Li <jun.li@nxp.com> wrote:
>
>
>> -----Original Message-----
>> From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-
>> owner@vger.kernel.org] On Behalf Of Baolin Wang
>> Sent: Monday, March 28, 2016 2:52 PM
>> To: Peter Chen <hzpeterchen@gmail.com>
>> 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 v8 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 25 March 2016 at 15:09, Peter Chen <hzpeterchen@gmail.com> wrote:
>> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
>> >> Currently the Linux kernel does not provide any standard integration
>> >> of this feature that integrates the USB subsystem with the system
>> >> power regulation provided by PMICs meaning that either vendors must
>> >> add this in their kernels or USB gadget devices based on Linux (such
>> >> as mobile phones) may not behave as they should. Thus provide a
>> standard framework for doing this in kernel.
>> >>
>> >> Now introduce one user with wm831x_power to support and test the usb
>> >> charger, which is pending testing. Moreover there may be other
>> >> potential users will use it in future.
>> >>
>> >
>> > I am afraid I still not find the user (udc driver) for this framework,
>> > I would like to see how udc driver block the enumeration until the
>> > charger detection has finished, or am I missing something?
>>
>> It is not for udc driver but for power users who want to negotiate with
>> USB subsystem.
>>
>
> 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.

>
> Li Jun
>> >
>> > --
>> > Best Regards,
>> > Peter Chen
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1366878 — RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromJun Li <jun.li@nxp.com>
Date2016-03-30 05:00 +0200
SubjectRE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riewp-7nA-7@gated-at.bofh.it>
In reply to#1366079

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Tuesday, March 29, 2016 5:49 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: Peter Chen <hzpeterchen@gmail.com>; 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 v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 29 March 2016 at 16:45, Jun Li <jun.li@nxp.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-
> >> owner@vger.kernel.org] On Behalf Of Baolin Wang
> >> Sent: Monday, March 28, 2016 2:52 PM
> >> To: Peter Chen <hzpeterchen@gmail.com>
> >> 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 v8 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 25 March 2016 at 15:09, Peter Chen <hzpeterchen@gmail.com> wrote:
> >> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb charger, which is pending testing. Moreover there may be other
> >> >> potential users will use it in future.
> >> >>
> >> >
> >> > I am afraid I still not find the user (udc driver) for this
> >> > framework, I would like to see how udc driver block the enumeration
> >> > until the charger detection has finished, or am I missing something?
> >>
> >> It is not for udc driver but for power users who want to negotiate
> >> with USB subsystem.
> >>
> >
> > 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
think it's necessary to check charger type at every event from usb gadget.
Something in gadget driver you can utilize is only vbus detection, and
report diff current by diff usb state if it's a SDP.

> >
> > Li Jun
> >> >
> >> > --
> >> > Best Regards,
> >> > Peter Chen
> >>
> >>
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> >> in the body of a message to majordomo@vger.kernel.org More majordomo
> >> info at http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> --
> Baolin.wang
> Best Regards

[toc] | [prev] | [next] | [standalone]


#1366905 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-30 08:20 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rihDX-1hu-3@gated-at.bofh.it>
In reply to#1366878
On 30 March 2016 at 10:54, Jun Li <jun.li@nxp.com> wrote:
>> >> It is not for udc driver but for power users who want to negotiate
>> >> with USB subsystem.
>> >>
>> >
>> > 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.

> think it's necessary to check charger type at every event from usb gadget.

My meaning is not every event from usb gadget. When the usb gadget
state changes or the extcon device (maybe GPIO detection) state
changes, which means charger plugin or pullup, we need to check the
charger type to set current.

> Something in gadget driver you can utilize is only vbus detection, and
> report diff current by diff usb state if it's a SDP.

-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1367015 — RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromJun Li <jun.li@nxp.com>
Date2016-03-30 10:50 +0200
SubjectRE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rijZa-2KA-37@gated-at.bofh.it>
In reply to#1366905
Hi

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Wednesday, March 30, 2016 2:15 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: Peter Chen <hzpeterchen@gmail.com>; 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 v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 30 March 2016 at 10:54, Jun Li <jun.li@nxp.com> wrote:
> >> >> It is not for udc driver but for power users who want to negotiate
> >> >> with USB subsystem.
> >> >>
> >> >
> >> > 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.

Li Jun
 
> 
> > think it's necessary to check charger type at every event from usb
> gadget.
> 
> My meaning is not every event from usb gadget. When the usb gadget state
> changes or the extcon device (maybe GPIO detection) state changes, which
> means charger plugin or pullup, we need to check the charger type to set
> current.

From your below code, you call usb_charger_notify_others() in
every state change.

if (uchger->old_gadget_state != state) {
	uchger->old_gadget_state = state;

	if (state >= USB_STATE_ATTACHED)
		uchger_state = USB_CHARGER_PRESENT;
	else if (state == USB_STATE_NOTATTACHED)
		uchger_state = USB_CHARGER_REMOVE;
	else
/* this else will never happen */
		uchger_state = USB_CHARGER_DEFAULT;

	usb_charger_notify_others(uchger, uchger_state);
}

> 
> > Something in gadget driver you can utilize is only vbus detection, and
> > report diff current by diff usb state if it's a SDP.
> 
> --
> Baolin.wang
> Best Regards

[toc] | [prev] | [next] | [standalone]


#1367042 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-30 11:40 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rikLx-3iV-17@gated-at.bofh.it>
In reply to#1367015
On 30 March 2016 at 16:07, Jun Li <jun.li@nxp.com> wrote:
> Hi

>> On 30 March 2016 at 10:54, Jun Li <jun.li@nxp.com> wrote:
>> >> >> It is not for udc driver but for power users who want to negotiate
>> >> >> with USB subsystem.
>> >> >>
>> >> >
>> >> > 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. In the 'usb_charger_detect_type()',
it usually get the charger type from type registers has been done by
hardware from PMIC, which can not affect the DP/DM line.

>
> Li Jun
>
>>
>> > think it's necessary to check charger type at every event from usb
>> gadget.
>>
>> My meaning is not every event from usb gadget. When the usb gadget state
>> changes or the extcon device (maybe GPIO detection) state changes, which
>> means charger plugin or pullup, we need to check the charger type to set
>> current.
>
> From your below code, you call usb_charger_notify_others() in
> every state change.

I think it does not matter. In case the usb charger missed some gadget
state changes. Or I replace it with 'USB_STATE_CONFIGURED' state.
Thanks.

>
> if (uchger->old_gadget_state != state) {
>         uchger->old_gadget_state = state;
>
>         if (state >= USB_STATE_ATTACHED)
>                 uchger_state = USB_CHARGER_PRESENT;
>         else if (state == USB_STATE_NOTATTACHED)
>                 uchger_state = USB_CHARGER_REMOVE;
>         else
> /* this else will never happen */
>                 uchger_state = USB_CHARGER_DEFAULT;
>
>         usb_charger_notify_others(uchger, uchger_state);
> }
>
>>
>> > Something in gadget driver you can utilize is only vbus detection, and
>> > report diff current by diff usb state if it's a SDP.
>>
>> --
>> Baolin.wang
>> Best Regards



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1367100 — RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromJun Li <jun.li@nxp.com>
Date2016-03-30 13:00 +0200
SubjectRE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<rim0W-44B-19@gated-at.bofh.it>
In reply to#1367042

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Wednesday, March 30, 2016 5:31 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: Peter Chen <hzpeterchen@gmail.com>; 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 v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 30 March 2016 at 16:07, Jun Li <jun.li@nxp.com> wrote:
> > Hi
> 
> >> On 30 March 2016 at 10:54, Jun Li <jun.li@nxp.com> wrote:
> >> >> >> It is not for udc driver but for power users who want to
> >> >> >> negotiate with USB subsystem.
> >> >> >>
> >> >> >
> >> >> > 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 before SW
do gadget connect. To make the framework common, you may do one time charger type check when vbus is on, and save it to avoid repeat charger type check.

> In the 'usb_charger_detect_type()', it
> usually get the charger type from type registers has been done by hardware
> from PMIC, which can not affect the DP/DM line.
> 
> >
> > Li Jun
> >
> >>
> >> > think it's necessary to check charger type at every event from usb
> >> gadget.
> >>
> >> My meaning is not every event from usb gadget. When the usb gadget
> >> state changes or the extcon device (maybe GPIO detection) state
> >> changes, which means charger plugin or pullup, we need to check the
> >> charger type to set current.
> >
> > From your below code, you call usb_charger_notify_others() in every
> > state change.
> 
> I think it does not matter. In case the usb charger missed some gadget
> state changes. Or I replace it with 'USB_STATE_CONFIGURED' state.
> Thanks.
> 
> >
> > if (uchger->old_gadget_state != state) {
> >         uchger->old_gadget_state = state;
> >
> >         if (state >= USB_STATE_ATTACHED)
> >                 uchger_state = USB_CHARGER_PRESENT;
> >         else if (state == USB_STATE_NOTATTACHED)
> >                 uchger_state = USB_CHARGER_REMOVE;
> >         else
> > /* this else will never happen */
> >                 uchger_state = USB_CHARGER_DEFAULT;
> >
> >         usb_charger_notify_others(uchger, uchger_state); }
> >
> >>
> >> > Something in gadget driver you can utilize is only vbus detection,
> >> > and report diff current by diff usb state if it's a SDP.
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
> 
> 
> 
> --
> Baolin.wang
> Best Regards

[toc] | [prev] | [next] | [standalone]


#1367117

FromFelipe Balbi <balbi@kernel.org>
Date2016-03-30 13:30 +0200
Message-ID<rimtY-4Cw-23@gated-at.bofh.it>
In reply to#1367100

[Multipart message — attachments visible in raw view] — view raw

Hi,

Jun Li <jun.li@nxp.com> writes:
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Wednesday, March 30, 2016 5:31 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: Peter Chen <hzpeterchen@gmail.com>; 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 v8 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>> 
>> On 30 March 2016 at 16:07, Jun Li <jun.li@nxp.com> wrote:
>> > Hi
>> 
>> >> On 30 March 2016 at 10:54, Jun Li <jun.li@nxp.com> wrote:
>> >> >> >> It is not for udc driver but for power users who want to
>> >> >> >> negotiate with USB subsystem.
>> >> >> >>
>> >> >> >
>> >> >> > 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.

-- 
balbi

[toc] | [prev] | [next] | [standalone]


#1367816 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-31 07:40 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riDuN-92-5@gated-at.bofh.it>
In reply to#1367117
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()'.

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.

>
> --
> balbi



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1367844

FromFelipe Balbi <balbi@kernel.org>
Date2016-03-31 08:30 +0200
Message-ID<riEhd-JS-21@gated-at.bofh.it>
In reply to#1367816

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]


#1367857 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-31 08:40 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riEqT-P8-27@gated-at.bofh.it>
In reply to#1367844
On 31 March 2016 at 14:18, Felipe Balbi <balbi@kernel.org> wrote:
>
> 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.

Make sense.

>
> --
> balbi



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1367815 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-31 07:30 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riDl8-5t-3@gated-at.bofh.it>
In reply to#1367100
On 30 March 2016 at 18:58, Jun Li <jun.li@nxp.com> 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 before SW
> do gadget connect. To make the framework common, you may do one time charger type check when vbus is on, and save it to avoid repeat charger type check.

OK. I'll add one judgement to check if the charger type is set in
'usb_charger_detect_type()' function.

-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1367835 — RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromJun Li <jun.li@nxp.com>
Date2016-03-31 08:20 +0200
SubjectRE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riE7w-G2-15@gated-at.bofh.it>
In reply to#1367815
Hi

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Thursday, March 31, 2016 1:23 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: Peter Chen <hzpeterchen@gmail.com>; 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 v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 30 March 2016 at 18:58, Jun Li <jun.li@nxp.com> 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
> > before SW do gadget connect. To make the framework common, you may do
> one time charger type check when vbus is on, and save it to avoid repeat
> charger type check.
> 
> OK. I'll add one judgement to check if the charger type is set in
> 'usb_charger_detect_type()' function.

Just adding a judgement isn't enough here, your framework should make sure
usb_charger_detect_type() is called before gadget connect, with that, the
existing caller place just gets the charger type from the saved value.
The real charger type detection done by usb_charger_detect_type() can
be called only when vbus is on.
e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control().

> 
> --
> Baolin.wang
> Best Regards

[toc] | [prev] | [next] | [standalone]


#1367859 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-31 08:40 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riEqT-P8-31@gated-at.bofh.it>
In reply to#1367835
On 31 March 2016 at 14:12, Jun Li <jun.li@nxp.com> wrote:
> Hi
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Thursday, March 31, 2016 1:23 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: Peter Chen <hzpeterchen@gmail.com>; 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 v8 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 30 March 2016 at 18:58, Jun Li <jun.li@nxp.com> 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
>> > before SW do gadget connect. To make the framework common, you may do
>> one time charger type check when vbus is on, and save it to avoid repeat
>> charger type check.
>>
>> OK. I'll add one judgement to check if the charger type is set in
>> 'usb_charger_detect_type()' function.
>
> Just adding a judgement isn't enough here, your framework should make sure
> usb_charger_detect_type() is called before gadget connect, with that, the
> existing caller place just gets the charger type from the saved value.
> The real charger type detection done by usb_charger_detect_type() can
> be called only when vbus is on.
> e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control().

Yeah, Like Felipe suggested, I think we need to introduce one
'charger_detect()' method to do the SW charger type detection at the
right gadget state. Thanks for your comments.

>>
>> --
>> Baolin.wang
>> Best Regards



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [next] | [standalone]


#1367947

FromFelipe Balbi <balbi@kernel.org>
Date2016-03-31 10:20 +0200
Message-ID<riFZD-24w-1@gated-at.bofh.it>
In reply to#1367859

[Multipart message — attachments visible in raw view] — view raw

Hi Baolin,

Baolin Wang <baolin.wang@linaro.org> writes:
>>> >> 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
>>> > before SW do gadget connect. To make the framework common, you may do
>>> one time charger type check when vbus is on, and save it to avoid repeat
>>> charger type check.
>>>
>>> OK. I'll add one judgement to check if the charger type is set in
>>> 'usb_charger_detect_type()' function.
>>
>> Just adding a judgement isn't enough here, your framework should make sure
>> usb_charger_detect_type() is called before gadget connect, with that, the
>> existing caller place just gets the charger type from the saved value.
>> The real charger type detection done by usb_charger_detect_type() can
>> be called only when vbus is on.
>> e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control().
>
> Yeah, Like Felipe suggested, I think we need to introduce one
> 'charger_detect()' method to do the SW charger type detection at the
> right gadget state. Thanks for your comments.

Just to be clear, we add ->charger_detect() when we know of a platform
which needs to manually detect the charger type. Until then, we ignore
that situation. It might be a good idea, however, do document this in
comments on your structure definition stating that if we need to detect
charger type, a new method should be added ;-)

cheers

-- 
balbi

[toc] | [prev] | [next] | [standalone]


#1367959 — Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

FromBaolin Wang <baolin.wang@linaro.org>
Date2016-03-31 10:30 +0200
SubjectRe: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Message-ID<riG9k-29W-7@gated-at.bofh.it>
In reply to#1367947
On 31 March 2016 at 16:15, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi Baolin,
>
> Baolin Wang <baolin.wang@linaro.org> writes:
>>>> >> 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
>>>> > before SW do gadget connect. To make the framework common, you may do
>>>> one time charger type check when vbus is on, and save it to avoid repeat
>>>> charger type check.
>>>>
>>>> OK. I'll add one judgement to check if the charger type is set in
>>>> 'usb_charger_detect_type()' function.
>>>
>>> Just adding a judgement isn't enough here, your framework should make sure
>>> usb_charger_detect_type() is called before gadget connect, with that, the
>>> existing caller place just gets the charger type from the saved value.
>>> The real charger type detection done by usb_charger_detect_type() can
>>> be called only when vbus is on.
>>> e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control().
>>
>> Yeah, Like Felipe suggested, I think we need to introduce one
>> 'charger_detect()' method to do the SW charger type detection at the
>> right gadget state. Thanks for your comments.
>
> Just to be clear, we add ->charger_detect() when we know of a platform
> which needs to manually detect the charger type. Until then, we ignore
> that situation. It might be a good idea, however, do document this in
> comments on your structure definition stating that if we need to detect
> charger type, a new method should be added ;-)

Make sense. Thanks.

>
> cheers
>
> --
> balbi



-- 
Baolin.wang
Best Regards

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web