All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Li <jun.li@nxp.com>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: NeilBrown <neilb@suse.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>,
	"robh@kernel.org" <robh@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Ruslan Bilovol <ruslan.bilovol@gmail.com>,
	"Peter Chen" <peter.chen@freescale.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	"grygorii.strashko@ti.com" <grygorii.strashko@ti.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Lee Jones <lee.jones@linaro.org>,
	"Mark Brown" <broonie@kernel.org>,
	John Stultz <john.stultz@linaro.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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Fri, 10 Mar 2017 08:27:45 +0000	[thread overview]
Message-ID: <AM5PR04MB29613EEC7C49426020A538B089200@AM5PR04MB2961.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAMz4kuLNa=sdYQrzXZspPd9ug-Opn2jfUCGHtq2qNT4Omax4Mw@mail.gmail.com>

Hi

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.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>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.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 v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port.  Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actually control the
> >> >> > charge current, also this will be done in your common framework,
> right?
> >> >>
> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> can register one extcon device, can get correct charger type and
> >> >> send out correct vbus_draw information, then we don't need USB
> >> >> charger framework as Neil suggested. So this will be okay for your
> >> >> case (especially for detecting the charger type by software) ?
> >> >
> >> > In my case, charger detection is done by controller driver and I
> >> > need do charger type detection internally, and only pass the
> >> > current draw info via phy which will send out, this seems ok for
> >> > me, but I think it will be good if you or someone can show us an
> >> > example user based on the
> >> design Neil suggested.
> >> > Will you work out that common code if this USB charger framework is
> >> > not
> >> needed?
> >>
> >> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> phy“. Others are already ready if everyone has no complain about
> >> current design, except
> >
> > Only adding extcon_dev into usb_phy/phy  and all others are ready?
> > My understanding you will also do:
> > - We need find a central place to send the notification(phy common part).
> 
> That will include these implementation when adding extcon_dev.
> 

OK, thanks.

> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
> API to findup it.
> 
> PMIC can find extcon device by phandle.

extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via devicetree,
how PMIC find it by phandle?
 
> 
> >
> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> information from USB phy driver, for example you will miss super
> >> speed (900mA), which need get the speed information from gadget
> >> driver.)
> >>
> >
> > Can we handle this in USB(so has super speed information) and just
> > send out 900mA directly?
> 
> From Neil's suggestion, we only have one place to send out current
> information from usb phy, so I have this concern and doubt if we still need
> the USB charger framework.

So if put it in phy/usb_phy, this is a problem, that only one place should have
the infor of both speed and usb state, how about put it at usb_gadget, then,
e.g. send the notification in usb_gadget_vbus_connect()?

Li Jun

> 
> --
> Baolin.wang
> Best Regards

WARNING: multiple messages have this Message-ID (diff)
From: Jun Li <jun.li@nxp.com>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: NeilBrown <neilb@suse.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>,
	"robh@kernel.org" <robh@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Ruslan Bilovol <ruslan.bilovol@gmail.com>,
	Peter Chen <peter.chen@freescale.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	"grygorii.strashko@ti.com" <grygorii.strashko@ti.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Lee Jones <lee.jones@linaro.org>, Mark Brown <broonie@kernel.org>,
	John Stultz <john.stultz@linaro.org>,
	Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
	"patches@opensource.wolfsonmicro.com" <patches@opensource>
Subject: RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Fri, 10 Mar 2017 08:27:45 +0000	[thread overview]
Message-ID: <AM5PR04MB29613EEC7C49426020A538B089200@AM5PR04MB2961.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAMz4kuLNa=sdYQrzXZspPd9ug-Opn2jfUCGHtq2qNT4Omax4Mw@mail.gmail.com>

Hi

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.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>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.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 v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port.  Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actually control the
> >> >> > charge current, also this will be done in your common framework,
> right?
> >> >>
> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> can register one extcon device, can get correct charger type and
> >> >> send out correct vbus_draw information, then we don't need USB
> >> >> charger framework as Neil suggested. So this will be okay for your
> >> >> case (especially for detecting the charger type by software) ?
> >> >
> >> > In my case, charger detection is done by controller driver and I
> >> > need do charger type detection internally, and only pass the
> >> > current draw info via phy which will send out, this seems ok for
> >> > me, but I think it will be good if you or someone can show us an
> >> > example user based on the
> >> design Neil suggested.
> >> > Will you work out that common code if this USB charger framework is
> >> > not
> >> needed?
> >>
> >> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> phy“. Others are already ready if everyone has no complain about
> >> current design, except
> >
> > Only adding extcon_dev into usb_phy/phy  and all others are ready?
> > My understanding you will also do:
> > - We need find a central place to send the notification(phy common part).
> 
> That will include these implementation when adding extcon_dev.
> 

OK, thanks.

> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
> API to findup it.
> 
> PMIC can find extcon device by phandle.

extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via devicetree,
how PMIC find it by phandle?
 
> 
> >
> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> information from USB phy driver, for example you will miss super
> >> speed (900mA), which need get the speed information from gadget
> >> driver.)
> >>
> >
> > Can we handle this in USB(so has super speed information) and just
> > send out 900mA directly?
> 
> From Neil's suggestion, we only have one place to send out current
> information from usb phy, so I have this concern and doubt if we still need
> the USB charger framework.

So if put it in phy/usb_phy, this is a problem, that only one place should have
the infor of both speed and usb state, how about put it at usb_gadget, then,
e.g. send the notification in usb_gadget_vbus_connect()?

Li Jun

> 
> --
> Baolin.wang
> Best Regards

  reply	other threads:[~2017-03-10  8:27 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20  8:51 [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2017-02-20  8:51 ` [PATCH v19 1/4] usb: gadget: Introduce the usb charger framework Baolin Wang
2017-02-20  8:51   ` Baolin Wang
2017-02-20  8:51 ` [PATCH v19 2/4] usb: gadget: Support for " Baolin Wang
2017-02-20 10:08   ` kbuild test robot
2017-02-20 10:08     ` kbuild test robot
2017-02-20 10:18     ` Baolin Wang
2017-02-20 10:18       ` Baolin Wang
2017-02-20  8:51 ` [PATCH v19 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2017-02-20  8:51 ` [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang
2017-02-20  8:51   ` Baolin Wang
2017-02-20 10:20   ` kbuild test robot
2017-02-20 10:20     ` kbuild test robot
2017-03-03  2:23 ` [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown
2017-03-03  2:23   ` NeilBrown
2017-03-07  9:38   ` Baolin Wang
2017-03-07  9:38     ` Baolin Wang
2017-03-09  1:50     ` Jun Li
2017-03-09  1:50       ` Jun Li
2017-03-09  6:10       ` Baolin Wang
2017-03-09  6:10         ` Baolin Wang
2017-03-09 10:34         ` Jun Li
2017-03-09 10:34           ` Jun Li
2017-03-09 11:22           ` Baolin Wang
2017-03-09 11:22             ` Baolin Wang
2017-03-10  6:30             ` Jun Li
2017-03-10  6:30               ` Jun Li
2017-03-10  7:15               ` Baolin Wang
2017-03-10  7:15                 ` Baolin Wang
2017-03-10  8:27                 ` Jun Li [this message]
2017-03-10  8:27                   ` Jun Li
2017-03-10 10:52                   ` Baolin Wang
2017-03-10 10:52                     ` Baolin Wang
2017-03-13  1:09                     ` Jun Li
2017-03-13  1:09                       ` Jun Li
2017-03-13  8:43                       ` Baolin Wang
2017-03-13  8:43                         ` Baolin Wang
2017-03-14  1:10                         ` Jun Li
2017-03-14  1:10                           ` Jun Li
2017-03-14  2:03                           ` Baolin Wang
2017-03-14  2:03                             ` Baolin Wang
2017-03-28 23:04     ` NeilBrown
2017-03-28 23:04       ` NeilBrown
2017-03-30  3:16       ` Baolin Wang
2017-03-30  3:16         ` Baolin Wang
2017-03-14  9:57 ` Lee Jones
2017-03-14 10:39   ` Baolin Wang
2017-03-14 10:39     ` Baolin Wang
2017-03-14 12:14     ` Lee Jones
2017-03-14 12:14       ` Lee Jones

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=AM5PR04MB29613EEC7C49426020A538B089200@AM5PR04MB2961.eurprd04.prod.outlook.com \
    --to=jun.li@nxp.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=grygorii.strashko@ti.com \
    --cc=john.stultz@linaro.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=m.szyprowski@samsung.com \
    --cc=neilb@suse.com \
    --cc=patches@opensource.wolfsonmicro.com \
    --cc=peter.chen@freescale.com \
    --cc=robh@kernel.org \
    --cc=ruslan.bilovol@gmail.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 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.