From: Baolin Wang <baolin.wang@linaro.org>
To: NeilBrown <neilb@suse.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>,
robh@kernel.org, Jun Li <jun.li@nxp.com>,
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 v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Date: Mon, 14 Nov 2016 20:36:51 +0800 [thread overview]
Message-ID: <CAMz4ku+1ohwSaGs6BEZkM9WJS7q1qz7vA01uBsPN_YaUT07NkA@mail.gmail.com> (raw)
In-Reply-To: <87eg2ek7ye.fsf@notabene.neil.brown.name>
On 14 November 2016 at 12:21, NeilBrown <neilb@suse.com> wrote:
> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> Hi
>>
>> On 8 November 2016 at 04:36, NeilBrown <neilb@suse.com> wrote:
>>> On Mon, Nov 07 2016, Baolin Wang wrote:
>>>
>>>> On 3 November 2016 at 09:25, NeilBrown <neilb@suse.com> wrote:
>>>>> On Tue, Nov 01 2016, Baolin Wang wrote:
>>>>
>>>> I agree with your most opinions, but these are optimization.
>>>
>>> I see them as bug fixes, not optimizations.
>>>
>>>> Firstly I
>>>> think we should upstream the USB charger driver.
>>>
>>> I think you missed the point. The point is that we don't *need* your
>>> "USB charger driver" because all the infrastructure we need is *already*
>>> present in the kernel. It is buggy and not used uniformly, and could
>>> usefully be polished and improved. But the structure is already
>>> present.
>>>
>>> If everyone just added new infrastructure when they didn't like, or
>>> didn't understand, what was already present, the kernel would become
>>> like the Mad Hatter's tea party, full of dirty dishes.
>>>
>>>> What I want to ask is
>>>> how can we notify power driver if we don't set the
>>>> usb_register_notifier(), then I think you give the answer is: power
>>>> driver can register by 'struct usb_phy->notifier'. But why usb phy
>>>> should notify the power driver how much current should be drawn, and I
>>>> still think we should notify the current in usb charger driver which
>>>> is better, and do not need to notify current for power driver in usb
>>>> phy driver.
>>>
>>> I accept that it isn't clear that the phy *should* be involved in
>>> communicating the negotiated power availability, but nor is it clear
>>> that it shouldn't. The power does travel through the physical
>>> interface, so physically it plays a role.
>>>
>>> But more importantly, it already *does* get told (in some cases).
>>> There is an interface "usb_phy_set_power()" which exists explicitly to
>>> tell the phy what power has been negotiated. Given that infrastructure
>>> exists and works, it make sense to use it.
>>>
>>> If you think it is a broken design and should be removed, then fine:
>>> make a case for that. Examine the history. Make sure you know why it
>>> is there (or make sure that information cannot be found), and then
>>> present a case as to why it should be removed and replaced with
>>> something else. But don't just leave it there and pretend it doesn't
>>> exist and create something similar-but-different and hope people will
>>> know why yours is better. That way lies madness.
>>
>> Like Peter said, it is not only PHY can detect the USB charger type,
>> which means there are other places can detect the charger type.
>
> If I understand Peter's example correctly, it shows a configuration
> where the USB PHysical interface is partly implemented in the SOC and
> partly in the PMIC. I appreciate that would make it more challenging to
> implement a PHY driver, but there is no reason it should impact anything
> outside of the PHY.
Like Peter's example, it need to use controller register to pull up dp
to begin the secondary detection, which is not belonged to phy driver
and I don't think it is suitable we implemented these in phy driver.
>
>> Second, some controller need to detect the charger type manually which
>> USB phy did not support.
>
> "manually" is an odd term to use in this context.
Sorry for the confusing.
> I think you mean that to detect the charger type you need to issue some
> command to the hardware and wait for it to respond, then assess the
> response.
Yes.
> That isn't at all surprising. The charger type is detected by measuring
> resistance between ID and GND, which may require setting up a potential
> and activating ADCs to measure the voltage. This can all be done
> internally to the phy driver.
> Sometimes it is easy (I did https://lkml.org/lkml/2015/2/23/746 for
> twl4030, though it never got upstream).
> The code for the imx7d does look more complex, but not intrinsically
> different.
But you should implement these in every phy driver, why not one
standard framework?
>
>> Third, it did not handle what current should
>> be drawn in USB phy.
>
> The standards define that. The extcon just reports the cable type.
> Certainly it would be sensible to provide a library function to
> translate from cable type to current range. You don't need a new
> subsystem to do that, just a library function.
I don't think the extcon should handle current things. For example,
the extcon can not know the gadget speed, which is used to change the
default current values for super speed gadget.
>
>> Fourth, we need integrate all charger plugin/out
>> event in one framework, not from extcon, maybe type-c in future.
>
> Why not extcon? Given that a charger is connected by an external
> connector, extcon seems like exactly the right thing to use.
My mistake, what I mean is not only from extcon, maybe from other
places in future.
>
> Obviously extcon doesn't report the current that was negotiated, but
> that is best kept separate. The battery charger can be advised of the
> available current either via extcon or separately via the usb
> subsystem. Don't conflate the two.
>
>
>> In a
>> word, we need one standard integration of this feature we need, though
>> like you said we should do some clean up or fix to make it better.
>
> But really, I'm not the person you need to convince. I'm just a vaguely
> interested bystander who is rapidly losing interest. You need to
> convince a maintainer, but they have so far shown remarkably little
> interest. I don't know why, but I'd guess that reviewing a complex new
> subsystem isn't much fun. Reviewing and applying clear bugfixes and
> incremental improvements is much easier and more enjoyable. But that is
> just a guess.
Maybe you missed previous comments, and we had a lot of discussion
about this patchset. Also Felipe had reviewed this patchset with some
suggestion.
--
Baolin.wang
Best Regards
next prev parent reply other threads:[~2016-11-14 12:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 2:37 [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2016-10-19 2:37 ` [PATCH v18 1/4] usb: gadget: Introduce the usb charger framework Baolin Wang
2016-10-19 2:37 ` [PATCH v18 2/4] usb: gadget: Support for " Baolin Wang
2016-10-19 2:37 ` [PATCH v18 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2016-10-19 2:37 ` [PATCH v18 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang
2016-10-27 7:33 ` [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2016-10-27 22:00 ` NeilBrown
2016-10-28 12:51 ` Baolin Wang
2016-10-28 17:03 ` Mark Brown
2016-10-31 11:25 ` Baolin Wang
2016-10-31 0:00 ` NeilBrown
2016-11-01 12:54 ` Baolin Wang
2016-11-03 1:25 ` NeilBrown
2016-11-07 8:14 ` Baolin Wang
2016-11-07 20:36 ` NeilBrown
2016-11-10 9:42 ` Baolin Wang
2016-11-14 4:21 ` NeilBrown
2016-11-14 12:04 ` Mark Brown
2016-11-14 21:35 ` NeilBrown
2016-11-15 5:03 ` Peter Chen
2016-11-16 16:16 ` Mark Brown
2016-11-17 6:46 ` NeilBrown
2016-11-21 17:17 ` Mark Brown
2016-11-21 22:40 ` NeilBrown
2016-11-25 13:00 ` Mark Brown
2016-11-26 0:44 ` NeilBrown
2016-11-28 7:15 ` Baolin Wang
2016-11-14 12:36 ` Baolin Wang [this message]
2016-11-08 8:41 ` Peter Chen
2016-11-08 20:38 ` NeilBrown
2016-11-09 1:33 ` Peter Chen
2016-12-20 7:05 ` Baolin Wang
2016-12-20 22:07 ` NeilBrown
2016-12-21 2:54 ` Baolin Wang
2016-12-21 3:48 ` NeilBrown
2016-12-21 9:07 ` Baolin Wang
2016-12-21 23:47 ` NeilBrown
2016-12-22 7:06 ` 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=CAMz4ku+1ohwSaGs6BEZkM9WJS7q1qz7vA01uBsPN_YaUT07NkA@mail.gmail.com \
--to=baolin.wang@linaro.org \
--cc=balbi@kernel.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=jun.li@nxp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).