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

Groups > linux.kernel > #1480377 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown <neilb@suse.com> - 2016-09-10 00:00 +0200
    Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-09-12 14:30 +0200
      Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown <neilb@suse.com> - 2016-09-12 15:30 +0200
        Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-09-12 17:30 +0200
          Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown <neilb@suse.com> - 2016-09-13 10:10 +0200
            Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-09-14 13:20 +0200
              Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown <neilb@suse.com> - 2016-09-14 16:20 +0200
                Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-09-14 17:00 +0200
                  Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown <neilb@suse.com> - 2016-09-14 20:00 +0200
                    Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Mark Brown <broonie@kernel.org> - 2016-09-14 20:10 +0200
            Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the  usb gadget power negotation Pavel Machek <pavel@ucw.cz> - 2016-09-15 12:40 +0200

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

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

On Fri, Sep 09 2016, Mark Brown wrote:

> [ Unknown signature status ]
> On Fri, Sep 09, 2016 at 09:13:31AM +1000, NeilBrown wrote:
>
>> Conceptually, the PHY is separate from the power manager and a solution
>> which recognises that will be more universal.
>
> The wm831x driver in the patch series is an example of such hardware -
> it is purely a power manager, it has no USB PHY hardware at all.  It's a
> current limiter intended to sit in line with the USB power lines to
> ensure the system doesn't go over the maximum current draw (and also
> integrates with the power source selection logic the chip has to pick
> the best available power source for the system).

It might be instructive to look at exactly what happens with this
device.
The "probe" routine calls

 +			usb_charger_find_by_name(wm831x_pdata->usb_gadget);

Presumably wm831x_pdata is initialised by a board file?
I strongly suspect it is initialized to  "usb-charger.0" because the
names given to usb chargers are "usb-charger.%d" in discovery order.
I don't see this being at all useful if there is ever more than one
usb-charger.
Do you?

The probe function then registers for charger notifications.  When they
arrive, wm831x_usb_limit_change() will set the highest supported limit
which is less than the notified "limit".  So presumably that "limit"
must be the minimum guaranteed by the charger type.

Let's see when the notification is called...
->uchgr_nh is sent a notification from usb_charger_notify_others()
with (in the "charger is present" case) the value of
   __usb_charger_get_cur_limit(uchger)
which just pulls values out of the cur_limit structure, based on the
type, reported by
		usb_charger_get_type_by_others(uchger);
(The default values in this structure are not the minimums guaranteed
by the charger types, they are generally higher.  So this could easily
result in the charger shutting down).

usb_charger_get_type_by_others()  has two ways to get the charger
type, which it then caches in uchger->type until the charger is removed.

If there is a uchger->psy power supply, then the
  POWER_SUPPLY_PROP_CHARGE_TYPE
property is used...  Oh, that is weird.
The valid values for that property are:

enum {
        POWER_SUPPLY_CHARGE_TYPE_UNKNOWN = 0,
        POWER_SUPPLY_CHARGE_TYPE_NONE,
        POWER_SUPPLY_CHARGE_TYPE_TRICKLE,
        POWER_SUPPLY_CHARGE_TYPE_FAST,
};

but the code in usb_charger_get_type_by_others() compares it against:
 +		case POWER_SUPPLY_TYPE_USB:
 +		case POWER_SUPPLY_TYPE_USB_DCP:
 +		case POWER_SUPPLY_TYPE_USB_CDP:
 +		case POWER_SUPPLY_TYPE_USB_ACA:

Presumably that it just a bug and it was meant to request the
  POWER_SUPPLY_PROP_TYPE ??
I wonder how much testing was done on this code?

Anyway, assuming it is meant to request the TYPE, where is that set?
The new code doesn't set it at all.
Only three existing power supplies set any of
  POWER_SUPPLY_TYPE_USB_*
axp288_charger.c  gpio-charger.c isp1704_charger.c
As I wrote in https://lwn.net/Articles/694062/
axp288_charger.c is broken and cannot possibly work.
gpio-charger.c configures the type at boot-time so it cannot sensibly
detect a newly plugged in charger (how does that make any sense)
and isp1704_charger.c peeks in the usb registers (ULPI) to work out
the charger type.

None of these set the  POWER_SUPPLY_PROP_TYPE in a useful way, so why
would usb_charger_get_type_by_others() want to use that property?

Maybe it really does want to use POWER_SUPPLY_PROP_CHARGE_TYPE?
Quite a few chargers set that.  It would be a challenge to map names
like "TRICKLE" and "FAST" into mA values for a current limiter though.
My hardware knowledge is running out here.. I see wm8350_power.c reports
that property, but I don't know how that device fits into the picture.
With the patch, that driver would request that property from somewhere
else(?) and also report it.  That is kind-a strange.

The other possible source for the charger type is a call to
   uchger->get_charger_type()

There is no get_charger_type() function anywhere in the patchset.  No code
ever sets that field in the uchger.

So how can this wm831x driver actually find out what sort of charger is
connected and so set the power limit?  I just don't see this working *at*
*all*.

NeilBrown

[toc] | [next] | [standalone]

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

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

On Sat, Sep 10, 2016 at 07:57:26AM +1000, NeilBrown wrote:
> On Fri, Sep 09 2016, Mark Brown wrote:

> > The wm831x driver in the patch series is an example of such hardware -
> > it is purely a power manager, it has no USB PHY hardware at all.  It's a

> The "probe" routine calls

>  +			usb_charger_find_by_name(wm831x_pdata->usb_gadget);

> Presumably wm831x_pdata is initialised by a board file?

Yes.

> I strongly suspect it is initialized to  "usb-charger.0" because the
> names given to usb chargers are "usb-charger.%d" in discovery order.
> I don't see this being at all useful if there is ever more than one
> usb-charger.
> Do you?

It's no worse than any other board file situation - if someone has that
problem they get to fix it.

> So how can this wm831x driver actually find out what sort of charger is
> connected and so set the power limit?  I just don't see this working *at*
> *all*.

The whole point from the point of view of the wm831x driver is that it
just wants something to tell it how much current it's allowed to draw, I
appreciate that doesn't change your analysis of the bit in the middle
but the consumer driver bit seems fine here.

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

#1481274

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

On Mon, Sep 12 2016, Mark Brown wrote:

> [ Unknown signature status ]
> On Sat, Sep 10, 2016 at 07:57:26AM +1000, NeilBrown wrote:
>> On Fri, Sep 09 2016, Mark Brown wrote:
>
>> > The wm831x driver in the patch series is an example of such hardware -
>> > it is purely a power manager, it has no USB PHY hardware at all.  It's a
>
>> The "probe" routine calls
>
>>  +			usb_charger_find_by_name(wm831x_pdata->usb_gadget);
>
>> Presumably wm831x_pdata is initialised by a board file?
>
> Yes.
>
>> I strongly suspect it is initialized to  "usb-charger.0" because the
>> names given to usb chargers are "usb-charger.%d" in discovery order.
>> I don't see this being at all useful if there is ever more than one
>> usb-charger.
>> Do you?
>
> It's no worse than any other board file situation - if someone has that
> problem they get to fix it.

My point is that the present design does not appear to scale beyond a
single USB power supply (as if there were two, they would be named in
discovery order, which is not reliably stable).

Your point is, I think, that when someone actually cares about that lack
of scaling, they can fix it.

I am perfectly happy with that approach.  However if the code doesn't
scale beyond one charger, it shouldn't pretend that it does.
i.e.
  Don't have "usb_charger_find_by_name()", just a global "usb_charger"
  (or similar).
  The first charger to register gets to be the "usb_charger".  The
  second one gets an error.
I could be quite happy with that sort of interface.

>
>> So how can this wm831x driver actually find out what sort of charger is
>> connected and so set the power limit?  I just don't see this working *at*
>> *all*.
>
> The whole point from the point of view of the wm831x driver is that it
> just wants something to tell it how much current it's allowed to draw, I
> appreciate that doesn't change your analysis of the bit in the middle
> but the consumer driver bit seems fine here.

Yes, the wm831x driver probably does the right thing.
Other drivers might want to know not only the minimum they are allowed
to draw, but also the maximum they should try even if they are carefully
monitoring the voltage.
So wm831x is doing the right thing with the wrong interface.  Maybe you
can describe that as "fine".

NeilBrown

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

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

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

On Mon, Sep 12, 2016 at 03:27:18PM +0200, NeilBrown wrote:
> On Mon, Sep 12 2016, Mark Brown wrote:

> > It's no worse than any other board file situation - if someone has that
> > problem they get to fix it.

> My point is that the present design does not appear to scale beyond a
> single USB power supply (as if there were two, they would be named in
> discovery order, which is not reliably stable).

For the practical purposes of people making systems (as opposed to
upstream where this is likely to get most use) it pretty much is.
Though quite how many systems have multiple chargers is itself also a
question.

> Your point is, I think, that when someone actually cares about that lack
> of scaling, they can fix it.

Yes.

> I am perfectly happy with that approach.  However if the code doesn't
> scale beyond one charger, it shouldn't pretend that it does.
> i.e.
>   Don't have "usb_charger_find_by_name()", just a global "usb_charger"
>   (or similar).
>   The first charger to register gets to be the "usb_charger".  The
>   second one gets an error.
> I could be quite happy with that sort of interface.

Well, a fairly standard way of extending would be to allow the explicit
assignment of names to chargers so this'd avoid such churn.

> > The whole point from the point of view of the wm831x driver is that it
> > just wants something to tell it how much current it's allowed to draw, I
> > appreciate that doesn't change your analysis of the bit in the middle
> > but the consumer driver bit seems fine here.

> Yes, the wm831x driver probably does the right thing.
> Other drivers might want to know not only the minimum they are allowed
> to draw, but also the maximum they should try even if they are carefully
> monitoring the voltage.
> So wm831x is doing the right thing with the wrong interface.  Maybe you
> can describe that as "fine".

That's not actually 100% clear to me - for what the wm831x is doing it
probably *does* want the higher limit.  This is a system inflow limit
(as it should be for this), at least the charger will adapt to voltage
variations though other users in the system are much less likely to do
so.

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

#1482227

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

On Mon, Sep 12 2016, Mark Brown wrote:

> [ Unknown signature status ]
> On Mon, Sep 12, 2016 at 03:27:18PM +0200, NeilBrown wrote:
>> On Mon, Sep 12 2016, Mark Brown wrote:
>
>> > It's no worse than any other board file situation - if someone has that
>> > problem they get to fix it.
>
>> My point is that the present design does not appear to scale beyond a
>> single USB power supply (as if there were two, they would be named in
>> discovery order, which is not reliably stable).
>
> For the practical purposes of people making systems (as opposed to
> upstream where this is likely to get most use) it pretty much is.
> Though quite how many systems have multiple chargers is itself also a
> question.
>
>> Your point is, I think, that when someone actually cares about that lack
>> of scaling, they can fix it.
>
> Yes.
>
>> I am perfectly happy with that approach.  However if the code doesn't
>> scale beyond one charger, it shouldn't pretend that it does.
>> i.e.
>>   Don't have "usb_charger_find_by_name()", just a global "usb_charger"
>>   (or similar).
>>   The first charger to register gets to be the "usb_charger".  The
>>   second one gets an error.
>> I could be quite happy with that sort of interface.
>
> Well, a fairly standard way of extending would be to allow the explicit
> assignment of names to chargers so this'd avoid such churn.

Sure, that might work.  I'm just against a design that obviously cannot
work.


>
>> > The whole point from the point of view of the wm831x driver is that it
>> > just wants something to tell it how much current it's allowed to draw, I
>> > appreciate that doesn't change your analysis of the bit in the middle
>> > but the consumer driver bit seems fine here.
>
>> Yes, the wm831x driver probably does the right thing.
>> Other drivers might want to know not only the minimum they are allowed
>> to draw, but also the maximum they should try even if they are carefully
>> monitoring the voltage.
>> So wm831x is doing the right thing with the wrong interface.  Maybe you
>> can describe that as "fine".
>
> That's not actually 100% clear to me - for what the wm831x is doing it
> probably *does* want the higher limit.  This is a system inflow limit
> (as it should be for this), at least the charger will adapt to voltage
> variations though other users in the system are much less likely to do
> so.

Interesting ... I hadn't considered that possibility.

As long as the current remains below the maximum, the charger will
reduce the voltage towards 2V as load increases.  Somewhere before it
gets there, the system will not be able to make use of the power as the
voltage will be too low to be usable. So that will naturally limit the
current being drawn.

Not having very much electrical engineering background, I cannot say for
sure what will happen, but it seems likely that once the voltage drops
much below 4.75V, the charger won't be operating at peak efficiency,
which would be a waste.
I can easily imagine that the hardware would switch off at some voltage
level, rather than just making do with what is there.
So I'm skeptical of this approach, but I'm open to being corrected by
someone more knowledgeable than I.

Looking at it from a different perspective, according to the patch set,
the limits that wm831x is able to impose are:

 +	0,
 +	2,
 +	100,
 +	500,
 +	900,
 +	1500,
 +	1800,
 +	550,

These are, from the battery charger spec, minimums rather than maximums.
e.g. a CDP provides at least 1500, and as much as 5000.  So it seems
that the wm831x was designed to be told the minimum guaranteed available.
But that is circumstantial evidence and might be misleading.

NeilBrown

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

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

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

On Tue, Sep 13, 2016 at 10:00:28AM +0200, NeilBrown wrote:
> On Mon, Sep 12 2016, Mark Brown wrote:

> > That's not actually 100% clear to me - for what the wm831x is doing it
> > probably *does* want the higher limit.  This is a system inflow limit
> > (as it should be for this), at least the charger will adapt to voltage
> > variations though other users in the system are much less likely to do
> > so.

> Not having very much electrical engineering background, I cannot say for
> sure what will happen, but it seems likely that once the voltage drops
> much below 4.75V, the charger won't be operating at peak efficiency,
> which would be a waste.
> I can easily imagine that the hardware would switch off at some voltage
> level, rather than just making do with what is there.
> So I'm skeptical of this approach, but I'm open to being corrected by
> someone more knowledgeable than I.

Yes, the idea is that the charger will back off charging and stop
entirely if the rest of the system is consuming too much power to allow
it to continue effectively.  The same thing happens with wall power, if
a wall supply isn't able to power the charger (eg, because the rest of
the system is running flat out) it'll have to cope with that.

> Looking at it from a different perspective, according to the patch set,
> the limits that wm831x is able to impose are:

>  +	0,
>  +	2,
>  +	100,
>  +	500,
>  +	900,
>  +	1500,
>  +	1800,
>  +	550,

> These are, from the battery charger spec, minimums rather than maximums.
> e.g. a CDP provides at least 1500, and as much as 5000.  So it seems
> that the wm831x was designed to be told the minimum guaranteed available.
> But that is circumstantial evidence and might be misleading.

AIUI this is conservatisim in the system design - another way of reading
a spec with a range like this is that the consumer should aim for the
lower limit, the provider should aim for the upper limit and that way if
either of them has issues with tolerances things will still work out.
It predates wide availability of CDP so I wouldn't be surprised if that
bit were just an oversight.  Like I say this bit of hardware is totally
separate to the battery charger.

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

#1483350

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

On Wed, Sep 14 2016, Mark Brown wrote:

> [ Unknown signature status ]
> On Tue, Sep 13, 2016 at 10:00:28AM +0200, NeilBrown wrote:
>> On Mon, Sep 12 2016, Mark Brown wrote:
>
>> > That's not actually 100% clear to me - for what the wm831x is doing it
>> > probably *does* want the higher limit.  This is a system inflow limit
>> > (as it should be for this), at least the charger will adapt to voltage
>> > variations though other users in the system are much less likely to do
>> > so.
>
>> Not having very much electrical engineering background, I cannot say for
>> sure what will happen, but it seems likely that once the voltage drops
>> much below 4.75V, the charger won't be operating at peak efficiency,
>> which would be a waste.
>> I can easily imagine that the hardware would switch off at some voltage
>> level, rather than just making do with what is there.
>> So I'm skeptical of this approach, but I'm open to being corrected by
>> someone more knowledgeable than I.
>
> Yes, the idea is that the charger will back off charging and stop
> entirely if the rest of the system is consuming too much power to allow
> it to continue effectively.  The same thing happens with wall power, if
> a wall supply isn't able to power the charger (eg, because the rest of
> the system is running flat out) it'll have to cope with that.

Maybe you are correct.  I don't find your argument convincing, but maybe
that is because I don't want to...
Some facts though:
 1/ I had a report once from someone whose device stopped charging
   because it was pulling more current than the charger could supply.
   The voltage dropped below the 3.5V (I think) that the battery
   charging hardware needed, so it switched off.  It wouldn't switch
   back on again until explicitly told too.  It would then overload the
   charger again and switch off.
   Changing the code to put a lower limit on the current allowed the
   battery to be charged.  So empirical evidence suggests that the
   lower number should be used.

 2/ I hoped that
      Battery Charging Specification
      Revision 1.2
      December 7, 2010

    would say something definite, but I cannot find it.
    However,  "note 1" to "Table 5-2 Currents" says:
     
        1) The maximum current is for safety reasons, as per USB 2.0 section 7.2.1.2.1.
     
    Which seems to say the maximum is just for safety, implying that the
    minimum is the important value.

 3/  Felipe Balbi <balbi@kernel.org>  appears to agree with my
   perspective.
      http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1224904.html
   does argument-by-authority work?


>
>> Looking at it from a different perspective, according to the patch set,
>> the limits that wm831x is able to impose are:
>
>>  +	0,
>>  +	2,
>>  +	100,
>>  +	500,
>>  +	900,
>>  +	1500,
>>  +	1800,
>>  +	550,
>
>> These are, from the battery charger spec, minimums rather than maximums.
>> e.g. a CDP provides at least 1500, and as much as 5000.  So it seems
>> that the wm831x was designed to be told the minimum guaranteed available.
>> But that is circumstantial evidence and might be misleading.
>
> AIUI this is conservatisim in the system design - another way of reading
> a spec with a range like this is that the consumer should aim for the
> lower limit, the provider should aim for the upper limit and that way if
> either of them has issues with tolerances things will still work out.
> It predates wide availability of CDP so I wouldn't be surprised if that
> bit were just an oversight.  Like I say this bit of hardware is totally
> separate to the battery charger.

Your last sentence is interesting .... I would reply "of course".
All the code we are talking about is only tangentially related to battery
charging.  It is about how much current can safely be pulled from a USB
port.  What that current is used for is a completely separate question.

NeilBrown

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

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

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

On Wed, Sep 14, 2016 at 04:11:58PM +0200, NeilBrown wrote:
> On Wed, Sep 14 2016, Mark Brown wrote:

> > Yes, the idea is that the charger will back off charging and stop
> > entirely if the rest of the system is consuming too much power to allow
> > it to continue effectively.  The same thing happens with wall power, if
> > a wall supply isn't able to power the charger (eg, because the rest of
> > the system is running flat out) it'll have to cope with that.

> Maybe you are correct.  I don't find your argument convincing, but maybe
> that is because I don't want to...

There's a *huge* variation in how chargers are designed, some are
designed to be dumb and won't function without software while the wm831x
is more at the opposite end of the spectrum and will quite happily run
all the charging and power source selection logic with no software
intervention at all - the parameters it uses can be changed at runtime
but that's about it.  Software implementations are obviously more
flexible but hardware implementations can be more responsive to changes
in system state like drooping supplies and aren't vulnerable to things
like software lockups.

>  1/ I had a report once from someone whose device stopped charging
>  because it was pulling more current than the charger could supply.
>  The voltage dropped below the 3.5V (I think) that the battery
>  charging hardware needed, so it switched off.  It wouldn't switch
>  back on again until explicitly told too.  It would then overload the
>  charger again and switch off.

That's just one charger's algorithm though, other options are available.

>     Which seems to say the maximum is just for safety, implying that the
>     minimum is the important value.

This is what I was saying about a sensible reading being for the supply
and consumer side to directly target the maximum and minimum limits
respectively (though for the battery charger spec it's a bit different
as the range is so wide).

>  3/  Felipe Balbi <balbi@kernel.org>  appears to agree with my
>    perspective.
>       http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1224904.html
>    does argument-by-authority work?

TI do a lot of the more software managed chargers (which I suspect are
the main thing Felipe will have looked at) if that's what you're
referring to here?  The device is implementing pretty much the algorithm
you're describing in that e-mail so I'm a bit confused as to what you're
saying here.

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

#1483513

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

On Wed, Sep 14 2016, Mark Brown wrote:

> TI do a lot of the more software managed chargers (which I suspect are
> the main thing Felipe will have looked at) if that's what you're
> referring to here?  The device is implementing pretty much the algorithm
> you're describing in that e-mail so I'm a bit confused as to what you're
> saying here.

Ah.... my mistake, sorry.
When earlier you said:
>                                                                 It's a
> current limiter intended to sit in line with the USB power lines to
> ensure the system doesn't go over the maximum current draw (and also
> integrates with the power source selection logic the chip has to pick
> the best available power source for the system).

I assumed that all it did was limit the current to number given.
If it also limits the current to ensure that voltage doesn't drop
unduly, then I agree with your assertion that it just needs to be told
the upper limit.
I hope you'll agree that other drivers might need to know the lower
limit, so reporting both to all drivers is sensible.

Thanks,
NeilBrown

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

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

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

On Wed, Sep 14, 2016 at 07:50:00PM +0200, NeilBrown wrote:
> On Wed, Sep 14 2016, Mark Brown wrote:

> Ah.... my mistake, sorry.
> When earlier you said:

> >                                                                 It's a
> > current limiter intended to sit in line with the USB power lines to

> I assumed that all it did was limit the current to number given.
> If it also limits the current to ensure that voltage doesn't drop
> unduly, then I agree with your assertion that it just needs to be told
> the upper limit.

Oh, I see the gap here - the USB specific bit is only a current limiter
but it works in concert with other bits of the system that try to stop
the voltage from whatever supply is in use from dropping and can't be
used independently of them.  That's why I wasn't clear in what I said!

> I hope you'll agree that other drivers might need to know the lower
> limit, so reporting both to all drivers is sensible.

Yes, absolutely.

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

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

Hi!

> > That's not actually 100% clear to me - for what the wm831x is doing it
> > probably *does* want the higher limit.  This is a system inflow limit
> > (as it should be for this), at least the charger will adapt to voltage
> > variations though other users in the system are much less likely to do
> > so.
> 
> Interesting ... I hadn't considered that possibility.
> 
> As long as the current remains below the maximum, the charger will
> reduce the voltage towards 2V as load increases.  Somewhere before it
> gets there, the system will not be able to make use of the power as the
> voltage will be too low to be usable. So that will naturally limit the
> current being drawn.
> 
> Not having very much electrical engineering background, I cannot say for
> sure what will happen, but it seems likely that once the voltage drops
> much below 4.75V, the charger won't be operating at peak efficiency,
> which would be a waste.
> I can easily imagine that the hardware would switch off at some voltage
> level, rather than just making do with what is there.
> So I'm skeptical of this approach, but I'm open to being corrected by
> someone more knowledgeable than I.

Devices I seen charge down to ~4.2V. This is useful thing to play
with:

dx.com: 406496
1" USB Current & Voltage Detector Tester Meter w/ Red LED Display -
Blue

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web