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

Groups > linux.kernel > #1381368 > unrolled thread

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

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 v7 1/4] gadget: Introduce the usb charger framework Felipe Balbi <balbi@kernel.org> - 2016-04-18 10:30 +0200
    Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework Pavel Machek <pavel@ucw.cz> - 2016-04-18 12:40 +0200
      Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework Pavel Machek <pavel@ucw.cz> - 2016-04-18 13:10 +0200
        Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework Felipe Balbi <balbi@kernel.org> - 2016-04-18 14:00 +0200
          Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework Pavel Machek <pavel@ucw.cz> - 2016-04-18 15:20 +0200
            Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework Felipe Balbi <balbi@kernel.org> - 2016-04-18 15:40 +0200
      Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework Felipe Balbi <balbi@kernel.org> - 2016-04-18 13:20 +0200

#1381368 — Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

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

Hi,

Pavel Machek <pavel@ucw.cz> writes:
> Hi!
>
>> > It's your HW :-) You tell me if it's really necessary. But, hey, if you
>> > get enumerated @500mA, this is the host telling you it _CAN_ give you
>> > 500mA. In that case, why wouldn't you ?
>
> Dunno, perhaps not to drain battery in host too quickly?
> Or perhaps you are charging from external battery?
>
>> >>> why RW ? Who's going to use these ? Also, you're not documenting this
>> >>> new sysfs file.
>> >>
>> >> Cause we have show and store operation for SDP type. If users want to
>> >> know or set the SDP current, they can use the sysfs file.
>> >> I'll add the documentation for it.
>> >
>> > but why would the user change it ? Here's the thing: you have a few
>> > posibilities for this:
>> >
>> > a) you are connected to a dedicated charger
>> >
>> >         In this case, you can get up to 2000mA depending on the charger.
>> >
>> >         If $this charger can give you or not 2000mA is not detectable,
>> >         so what do charging ICs do ? They slowly increase the attached
>> >         load accross VBUS/GND and measure VBUS value. When IC notices
>> >         VBUS dropping bit, step back to previous load.
>> >
>> >         This means you will always charger with maximum rating of DCP.
>> >
>> >         Why would user change this ? More is unsafe, less is just
>> >         stupid.
>
> Less is not neccessarily stupid. First, it is useful for debugging, second, you
> don't know how much this charger can give you. You measured you can get 1.8A,
> but the note on the charger says 1.5A. You may want to go with 1.5A.
>
> Also, there are several incompatible standards for detecting
> "dedicated charger". IIRC iPhone has different one from iPad. So it is
> quite important to be able to control this manually.

manually ??? Hell no! Charger IC should be able to do this no
problem. I would be surprised if there's any charger IC out there which
blindly connects a 1.8A load from the start. What these ICs do is that
they slowly increment the load and check voltage level. They'll continue
to do that up to the maximum you listed (1.8A, let's say). As soon as
voltage drops a bit, charger IC knows that it use previous load.

>> > d) you are connected to a standard port and get enumerated with your
>> > 100mA configuration.
>> >
>> >         you *know* 100mA is okay. So you connect a 100mA load and get it
>> >         over with.
>> >
>> >         This means you will always charger with maximum rating for this
>> >         SDP.
>> >
>> >         Why would user change this ? More is unsafe, less is just
>> >         stupid.
>
> I've needed to override 100mA default many times. Maybe it is unsafe,
> but it is useful.

still unsafe. If you really wanna do that, you're welcome to removing
safety margins from your own kernel, but we're definitely not going to
ship this to millions of users.

> (And with USB 5V connected directly to pretty beefy PC power supply...
> it is sometimes safer than it looks).

you're not considering the thermal dissipation on the USB connector
itself. Many of them might not use good metals because they assume the
maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
you could, literally, melt the connector.

-- 
balbi

[toc] | [next] | [standalone]

#1381469

Hi!

> >> > a) you are connected to a dedicated charger
> >> >
> >> >         In this case, you can get up to 2000mA depending on the charger.
> >> >
> >> >         If $this charger can give you or not 2000mA is not detectable,
> >> >         so what do charging ICs do ? They slowly increase the attached
> >> >         load accross VBUS/GND and measure VBUS value. When IC notices
> >> >         VBUS dropping bit, step back to previous load.
> >> >
> >> >         This means you will always charger with maximum rating of DCP.
> >> >
> >> >         Why would user change this ? More is unsafe, less is just
> >> >         stupid.
> >
> > Less is not neccessarily stupid. First, it is useful for debugging, second, you
> > don't know how much this charger can give you. You measured you can get 1.8A,
> > but the note on the charger says 1.5A. You may want to go with 1.5A.
> >
> > Also, there are several incompatible standards for detecting
> > "dedicated charger". IIRC iPhone has different one from iPad. So it is
> > quite important to be able to control this manually.
> 
> manually ??? Hell no! Charger IC should be able to do this no
> problem. I would be surprised if there's any charger IC out there which
> blindly connects a 1.8A load from the start. What these ICs do is that
> they slowly increment the load and check voltage level. They'll continue
> to do that up to the maximum you listed (1.8A, let's say). As soon as
> voltage drops a bit, charger IC knows that it use previous load.

As I explained, if the note on the wall charger says 1.5A, you want to
do 1.5A, not 1.8A. You can measure voltage on the charger, but you
don't know its temperature.

> >> > d) you are connected to a standard port and get enumerated with your
> >> > 100mA configuration.
> >> >
> >> >         you *know* 100mA is okay. So you connect a 100mA load and get it
> >> >         over with.
> >> >
> >> >         This means you will always charger with maximum rating for this
> >> >         SDP.
> >> >
> >> >         Why would user change this ? More is unsafe, less is just
> >> >         stupid.
> >
> > I've needed to override 100mA default many times. Maybe it is unsafe,
> > but it is useful.
> 
> still unsafe. If you really wanna do that, you're welcome to removing
> safety margins from your own kernel, but we're definitely not going to
> ship this to millions of users.

Not more unsafe than loading wall chargers with "lets see how much we
can get out of it" algorithm. Plus actually required to charge your
machines in useful way. So it is important that common API
exists. Whether it gets enalbed at production is different question.

Unfortunately, there's more than one standard for detecting charger,
so manual control will probably be required.

> > (And with USB 5V connected directly to pretty beefy PC power supply...
> > it is sometimes safer than it looks).
> 
> you're not considering the thermal dissipation on the USB connector
> itself. Many of them might not use good metals because they assume the
> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
> you could, literally, melt the connector.

If you are dissipating 2.5W at the connector, you are doing something
very wrong. You should not be short-circuiting your USB... even when
the ports are usually designed to survive that.

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

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

#1381566

Hi!

> >> manually ??? Hell no! Charger IC should be able to do this no
> >> problem. I would be surprised if there's any charger IC out there which
> >> blindly connects a 1.8A load from the start. What these ICs do is that
> >> they slowly increment the load and check voltage level. They'll continue
> >> to do that up to the maximum you listed (1.8A, let's say). As soon as
> >> voltage drops a bit, charger IC knows that it use previous load.
> >
> > As I explained, if the note on the wall charger says 1.5A, you want to
> > do 1.5A, not 1.8A. You can measure voltage on the charger, but you
> > don't know its temperature.
> 
> phone can't read what it says in the wall charger, nor can it know that
> it's connected charger ABC and not charger XYZ. Think of the user
> experience. You can't expect users to tell you "okay phone, the charger
> reads that maximum is 1.5A, so please don't go over that."

Of course, we may do something sensible by default. But manual
controls should still be present. You called them "stupid" but they
are not.

Note that just because you detected wall charger does not even mean
you are connected to wall charger. See the link below.

> >> still unsafe. If you really wanna do that, you're welcome to removing
> >> safety margins from your own kernel, but we're definitely not going to
> >> ship this to millions of users.
> >
> > Not more unsafe than loading wall chargers with "lets see how much we
> > can get out of it" algorithm. Plus actually required to charge your
> 
> it actually _is_ more unsafe. You could burn mother boards with that. If
> host tells you it only has 100mA power budget left, why are you trying
> to get more ?

No, you can't burn motherboard like that... You can force emergency
shutdowns, which is also bad, but... There are many devices that break
this aspect of USB protocol.

https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the

> > Unfortunately, there's more than one standard for detecting charger,
> > so manual control will probably be required.
> 
> n900 never had manual control of anything. It was just using information
> given by the battery IC, charger IC and twl4030 madc.

Manual control of n900 charging is done by:

echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit

> >> > (And with USB 5V connected directly to pretty beefy PC power supply...
> >> > it is sometimes safer than it looks).
> >> 
> >> you're not considering the thermal dissipation on the USB connector
> >> itself. Many of them might not use good metals because they assume the
> >> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
> >> you could, literally, melt the connector.
> >
> > If you are dissipating 2.5W at the connector, you are doing something
> > very wrong. You should not be short-circuiting your USB... even when
> > the ports are usually designed to survive that.
> 
> yes. You shouldn't. You also shouldn't go over that limit. If you have a
> 500mA total power budget, we should not let anybody try to draw more
> because we have no control over what's on the side of the wire.

They already can go over the limit, for example using cable linked
above. I have several such cables here. I also have various wall
supplies that are not detected as a wall supply by N900. So I either
have to remember and connect them with the "special" cable, or
(easier) use the override above to get useful charging.

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

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

#1381636

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

Hi,

Pavel Machek <pavel@ucw.cz> writes:
>> >> manually ??? Hell no! Charger IC should be able to do this no
>> >> problem. I would be surprised if there's any charger IC out there which
>> >> blindly connects a 1.8A load from the start. What these ICs do is that
>> >> they slowly increment the load and check voltage level. They'll continue
>> >> to do that up to the maximum you listed (1.8A, let's say). As soon as
>> >> voltage drops a bit, charger IC knows that it use previous load.
>> >
>> > As I explained, if the note on the wall charger says 1.5A, you want to
>> > do 1.5A, not 1.8A. You can measure voltage on the charger, but you
>> > don't know its temperature.
>> 
>> phone can't read what it says in the wall charger, nor can it know that
>> it's connected charger ABC and not charger XYZ. Think of the user
>> experience. You can't expect users to tell you "okay phone, the charger
>> reads that maximum is 1.5A, so please don't go over that."
>
> Of course, we may do something sensible by default. But manual
> controls should still be present. You called them "stupid" but they
> are not.
>
> Note that just because you detected wall charger does not even mean
> you are connected to wall charger. See the link below.

that's a horrible product. So what ? If you want to use that, be my
guest. Just, again, don't ask for support when things start falling
apart ;-)

>> >> still unsafe. If you really wanna do that, you're welcome to removing
>> >> safety margins from your own kernel, but we're definitely not going to
>> >> ship this to millions of users.
>> >
>> > Not more unsafe than loading wall chargers with "lets see how much we
>> > can get out of it" algorithm. Plus actually required to charge your
>> 
>> it actually _is_ more unsafe. You could burn mother boards with that. If
>> host tells you it only has 100mA power budget left, why are you trying
>> to get more ?
>
> No, you can't burn motherboard like that... You can force emergency
> shutdowns, which is also bad, but... There are many devices that break
> this aspect of USB protocol.
>
> https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the

we can't prevent people from coming up with bad devices/cables/whatever,
right ? But we can make sure that overcoming a 500mA power budget on a
USB 2.0 port will not be allowed.

>> > Unfortunately, there's more than one standard for detecting charger,
>> > so manual control will probably be required.
>> 
>> n900 never had manual control of anything. It was just using information
>> given by the battery IC, charger IC and twl4030 madc.
>
> Manual control of n900 charging is done by:
>
> echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit

yes, that's fine. And if you're connected to a dedicated charger (DCP)
which follows USB Battery Charger specification, we *know* that it
should, per the spec, source up to 2A, so this is fine.

However, if you're connected to SDP (regular PC port), which has a power
budget of 500mA per-port (meaning, that if you're behind a bus powered
hub, you can't even get 500mA), then this write() of yours should be
invalid. It should *not* be a successful write() as that creates an
unsafe and potentially dangerous scenario for the user.

>> >> > (And with USB 5V connected directly to pretty beefy PC power supply...
>> >> > it is sometimes safer than it looks).
>> >> 
>> >> you're not considering the thermal dissipation on the USB connector
>> >> itself. Many of them might not use good metals because they assume the
>> >> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
>> >> you could, literally, melt the connector.
>> >
>> > If you are dissipating 2.5W at the connector, you are doing something
>> > very wrong. You should not be short-circuiting your USB... even when
>> > the ports are usually designed to survive that.
>> 
>> yes. You shouldn't. You also shouldn't go over that limit. If you have a
>> 500mA total power budget, we should not let anybody try to draw more
>> because we have no control over what's on the side of the wire.
>
> They already can go over the limit, for example using cable linked
> above. I have several such cables here. I also have various wall

people can use unsupported cable assemblies if they want, but you can't
expect kernel to support you.

> supplies that are not detected as a wall supply by N900. So I either
> have to remember and connect them with the "special" cable, or
> (easier) use the override above to get useful charging.

those supplies are not supported by N900. N900 was designed with USB
Battery Chaging specification in mind and Nokia is not around anymore to
give you SW updates. Sorry, but that's not the kernel's fault.

The point is the following: there are a handful of people who would
*know* how to fiddle with these limits, many would not. The vast
majority would not. And, considering this is something completely out of
spec, and, again, potentially dangerous to the user, we are not going to
support it.

You may use your hacked up cables, not a problem. I did that myself
during N900 development (though I was using a lab power supply with a 2A
current limit sourcing 5V) to test port type detection and charging
algorithm. But that's really not something any company (or this
community) will support.

-- 
balbi

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

#1381694

Hi!

> > Of course, we may do something sensible by default. But manual
> > controls should still be present. You called them "stupid" but they
> > are not.
> >
> > Note that just because you detected wall charger does not even mean
> > you are connected to wall charger. See the link below.
> 
> that's a horrible product. So what ? If you want to use that, be my
> guest. Just, again, don't ask for support when things start falling
> apart ;-)

So you have USB spec? So what? There are many such products out there,
and I have at least two such cables here.

They did not cause end of the world, yet, and they are actually very useful.

> >> >> still unsafe. If you really wanna do that, you're welcome to removing
> >> >> safety margins from your own kernel, but we're definitely not going to
> >> >> ship this to millions of users.
> >> >
> >> > Not more unsafe than loading wall chargers with "lets see how much we
> >> > can get out of it" algorithm. Plus actually required to charge your
> >> 
> >> it actually _is_ more unsafe. You could burn mother boards with that. If
> >> host tells you it only has 100mA power budget left, why are you trying
> >> to get more ?
> >
> > No, you can't burn motherboard like that... You can force emergency
> > shutdowns, which is also bad, but... There are many devices that break
> > this aspect of USB protocol.
> >
> > https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the
> 
> we can't prevent people from coming up with bad devices/cables/whatever,
> right ? But we can make sure that overcoming a 500mA power budget on a
> USB 2.0 port will not be allowed.

No, you can't, because you don't know if you are connected to USB 2.0
port. (Because non-compliant cables exist).

> >> > Unfortunately, there's more than one standard for detecting charger,
> >> > so manual control will probably be required.
> >> 
> >> n900 never had manual control of anything. It was just using information
> >> given by the battery IC, charger IC and twl4030 madc.
> >
> > Manual control of n900 charging is done by:
> >
> > echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit
> 
> yes, that's fine. And if you're connected to a dedicated charger (DCP)
> which follows USB Battery Charger specification, we *know* that it
> should, per the spec, source up to 2A, so this is fine.

BTW have you ever seen such USB-compliant dedicated charger? I have
more than 5 chargers here, and not one of them is 2A. (Most are .5A,
some are 1A, one is 1.2A).

> However, if you're connected to SDP (regular PC port), which has a power
> budget of 500mA per-port (meaning, that if you're behind a bus powered
> hub, you can't even get 500mA), then this write() of yours should be
> invalid. It should *not* be a successful write() as that creates an
> unsafe and potentially dangerous scenario for the user.

Yes, USB is "potentially dangerous", because noone follows the
specs. Fortunately, everyone knows (except you?) that noone follows
the specs, so the hardware can deal with that, and they include
(poly?) fuses where neccessary.

> > They already can go over the limit, for example using cable linked
> > above. I have several such cables here. I also have various wall
> 
> people can use unsupported cable assemblies if they want, but you can't
> expect kernel to support you.

Then we won't have useful charging support in kernel.

> > supplies that are not detected as a wall supply by N900. So I either
> > have to remember and connect them with the "special" cable, or
> > (easier) use the override above to get useful charging.
> 
> those supplies are not supported by N900. N900 was designed with USB
> Battery Chaging specification in mind and Nokia is not around anymore to
> give you SW updates. Sorry, but that's not the kernel's fault.
> 
> The point is the following: there are a handful of people who would
> *know* how to fiddle with these limits, many would not. The vast
> majority would not. And, considering this is something completely out of
> spec, and, again, potentially dangerous to the user, we are not going to
> support it.

You speak about dangerous where little danger exist; number of
non-compliant cables and USB devices is very high (take your power
bank. Does it really limit to .5A when charging from computer?) and we
should support them, not cry "dangerous" and force everyone to come
with their own "solutions".

> You may use your hacked up cables, not a problem. I did that myself
> during N900 development (though I was using a lab power supply with a 2A
> current limit sourcing 5V) to test port type detection and charging
> algorithm. But that's really not something any company (or this
> community) will support.

Fortunately, that's not your decision and community already decided
the other way.
									Pavel

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

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

#1381703

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

Hi,

Pavel Machek <pavel@ucw.cz> writes:
>> > Of course, we may do something sensible by default. But manual
>> > controls should still be present. You called them "stupid" but they
>> > are not.
>> >
>> > Note that just because you detected wall charger does not even mean
>> > you are connected to wall charger. See the link below.
>> 
>> that's a horrible product. So what ? If you want to use that, be my
>> guest. Just, again, don't ask for support when things start falling
>> apart ;-)
>
> So you have USB spec? So what? There are many such products out there,
> and I have at least two such cables here.
>
> They did not cause end of the world, yet, and they are actually very
> useful.

they are also breaking safety requirements and, as I already said, are
potentially dangerous to the user.

>> >> >> still unsafe. If you really wanna do that, you're welcome to removing
>> >> >> safety margins from your own kernel, but we're definitely not going to
>> >> >> ship this to millions of users.
>> >> >
>> >> > Not more unsafe than loading wall chargers with "lets see how much we
>> >> > can get out of it" algorithm. Plus actually required to charge your
>> >> 
>> >> it actually _is_ more unsafe. You could burn mother boards with that. If
>> >> host tells you it only has 100mA power budget left, why are you trying
>> >> to get more ?
>> >
>> > No, you can't burn motherboard like that... You can force emergency
>> > shutdowns, which is also bad, but... There are many devices that break
>> > this aspect of USB protocol.
>> >
>> > https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the
>> 
>> we can't prevent people from coming up with bad devices/cables/whatever,
>> right ? But we can make sure that overcoming a 500mA power budget on a
>> USB 2.0 port will not be allowed.
>
> No, you can't, because you don't know if you are connected to USB 2.0
> port. (Because non-compliant cables exist).

yeah, we can't also protect car passenger from bad drivers, but we can
give them all a seat belt ;-)

>> >> > Unfortunately, there's more than one standard for detecting charger,
>> >> > so manual control will probably be required.
>> >> 
>> >> n900 never had manual control of anything. It was just using information
>> >> given by the battery IC, charger IC and twl4030 madc.
>> >
>> > Manual control of n900 charging is done by:
>> >
>> > echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit
>> 
>> yes, that's fine. And if you're connected to a dedicated charger (DCP)
>> which follows USB Battery Charger specification, we *know* that it
>> should, per the spec, source up to 2A, so this is fine.
>
> BTW have you ever seen such USB-compliant dedicated charger? I have
> more than 5 chargers here, and not one of them is 2A. (Most are .5A,
> some are 1A, one is 1.2A).

yeah, if it has the USB BC logo, it _must_ be compliant and full all
requirements of the USB BC spec.

>> However, if you're connected to SDP (regular PC port), which has a power
>> budget of 500mA per-port (meaning, that if you're behind a bus powered
>> hub, you can't even get 500mA), then this write() of yours should be
>> invalid. It should *not* be a successful write() as that creates an
>> unsafe and potentially dangerous scenario for the user.
>
> Yes, USB is "potentially dangerous", because noone follows the
> specs. Fortunately, everyone knows (except you?) that noone follows
> the specs, so the hardware can deal with that, and they include
> (poly?) fuses where neccessary.

heh :-)

>> > They already can go over the limit, for example using cable linked
>> > above. I have several such cables here. I also have various wall
>> 
>> people can use unsupported cable assemblies if they want, but you can't
>> expect kernel to support you.
>
> Then we won't have useful charging support in kernel.

oh no, we will. We just won't let users step outside of safety requirements.

>> > supplies that are not detected as a wall supply by N900. So I either
>> > have to remember and connect them with the "special" cable, or
>> > (easier) use the override above to get useful charging.
>> 
>> those supplies are not supported by N900. N900 was designed with USB
>> Battery Chaging specification in mind and Nokia is not around anymore to
>> give you SW updates. Sorry, but that's not the kernel's fault.
>> 
>> The point is the following: there are a handful of people who would
>> *know* how to fiddle with these limits, many would not. The vast
>> majority would not. And, considering this is something completely out of
>> spec, and, again, potentially dangerous to the user, we are not going to
>> support it.
>
> You speak about dangerous where little danger exist; number of
> non-compliant cables and USB devices is very high (take your power
> bank. Does it really limit to .5A when charging from computer?) and we
> should support them, not cry "dangerous" and force everyone to come
> with their own "solutions".

hehe, you're pretty funny at times

>> You may use your hacked up cables, not a problem. I did that myself
>> during N900 development (though I was using a lab power supply with a 2A
>> current limit sourcing 5V) to test port type detection and charging
>> algorithm. But that's really not something any company (or this
>> community) will support.
>
> Fortunately, that's not your decision and community already decided
> the other way.

actually, it has not ;-) As long as it's not in Linus' tree, it has not
been decided yet.

now, chill out dude. You're always pushy and arrogant instead of
discussing things technically. Calm down, yeah !?

-- 
balbi

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

#1381592

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

Hi,

Pavel Machek <pavel@ucw.cz> writes:
>> >> > a) you are connected to a dedicated charger
>> >> >
>> >> >         In this case, you can get up to 2000mA depending on the charger.
>> >> >
>> >> >         If $this charger can give you or not 2000mA is not detectable,
>> >> >         so what do charging ICs do ? They slowly increase the attached
>> >> >         load accross VBUS/GND and measure VBUS value. When IC notices
>> >> >         VBUS dropping bit, step back to previous load.
>> >> >
>> >> >         This means you will always charger with maximum rating of DCP.
>> >> >
>> >> >         Why would user change this ? More is unsafe, less is just
>> >> >         stupid.
>> >
>> > Less is not neccessarily stupid. First, it is useful for debugging, second, you
>> > don't know how much this charger can give you. You measured you can get 1.8A,
>> > but the note on the charger says 1.5A. You may want to go with 1.5A.
>> >
>> > Also, there are several incompatible standards for detecting
>> > "dedicated charger". IIRC iPhone has different one from iPad. So it is
>> > quite important to be able to control this manually.
>> 
>> manually ??? Hell no! Charger IC should be able to do this no
>> problem. I would be surprised if there's any charger IC out there which
>> blindly connects a 1.8A load from the start. What these ICs do is that
>> they slowly increment the load and check voltage level. They'll continue
>> to do that up to the maximum you listed (1.8A, let's say). As soon as
>> voltage drops a bit, charger IC knows that it use previous load.
>
> As I explained, if the note on the wall charger says 1.5A, you want to
> do 1.5A, not 1.8A. You can measure voltage on the charger, but you
> don't know its temperature.

phone can't read what it says in the wall charger, nor can it know that
it's connected charger ABC and not charger XYZ. Think of the user
experience. You can't expect users to tell you "okay phone, the charger
reads that maximum is 1.5A, so please don't go over that."

>> >> > d) you are connected to a standard port and get enumerated with your
>> >> > 100mA configuration.
>> >> >
>> >> >         you *know* 100mA is okay. So you connect a 100mA load and get it
>> >> >         over with.
>> >> >
>> >> >         This means you will always charger with maximum rating for this
>> >> >         SDP.
>> >> >
>> >> >         Why would user change this ? More is unsafe, less is just
>> >> >         stupid.
>> >
>> > I've needed to override 100mA default many times. Maybe it is unsafe,
>> > but it is useful.
>> 
>> still unsafe. If you really wanna do that, you're welcome to removing
>> safety margins from your own kernel, but we're definitely not going to
>> ship this to millions of users.
>
> Not more unsafe than loading wall chargers with "lets see how much we
> can get out of it" algorithm. Plus actually required to charge your

it actually _is_ more unsafe. You could burn mother boards with that. If
host tells you it only has 100mA power budget left, why are you trying
to get more ?

> machines in useful way. So it is important that common API
> exists. Whether it gets enalbed at production is different question.

as I said, if you wanna do some unsafe manual method, be my guest; but
I'm not convinced that every user of the linux kernel wants that in
their pockets.

> Unfortunately, there's more than one standard for detecting charger,
> so manual control will probably be required.

n900 never had manual control of anything. It was just using information
given by the battery IC, charger IC and twl4030 madc.

>> > (And with USB 5V connected directly to pretty beefy PC power supply...
>> > it is sometimes safer than it looks).
>> 
>> you're not considering the thermal dissipation on the USB connector
>> itself. Many of them might not use good metals because they assume the
>> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
>> you could, literally, melt the connector.
>
> If you are dissipating 2.5W at the connector, you are doing something
> very wrong. You should not be short-circuiting your USB... even when
> the ports are usually designed to survive that.

yes. You shouldn't. You also shouldn't go over that limit. If you have a
500mA total power budget, we should not let anybody try to draw more
because we have no control over what's on the side of the wire.

-- 
balbi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web