lkml.org 
[lkml]   [2017]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
    On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
    > 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?

    From my understanding, here we should add one pointer (extcon_dev *),
    since usb phy is not one external connect device.

    >
    >>
    >> >
    >> >> 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()?

    That is same what USB charger did, from this point, we need USB
    charger to send out vbus draw information according to speed and usb
    state. But I should listen to other guys suggestion. Peter and Felipe,
    what do you think?

    --
    Baolin.wang
    Best Regards

    \
     
     \ /
      Last update: 2017-03-10 11:53    [W:3.116 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site