Re: [SHR-Unstable] Forcing fast-charge
2009/5/7 Joerg Reisenweber jo...@openmoko.org A So you think the STANDARD kernel should care about this rather exotic case which isn't specified properly (how long would this charger see the 1A sometimes?) and needs massive care from userland anyway? I mean, there's some reason PCF50633 is built this way, huh? We got enough problems caring about real hw-glitches in this chip. I don't think it's recommendable to tweak it even further far beyond what's normal usecase. All I want from kernel is allowing me to set whatever values I need for both usb_curlim and chg_curlim. (also when charging from an external battery pack it is very usefull too not to pump all its juice just to fill internal battery - chg_curlim set to very low) btw your concept isn't working as you said yourself the USB current is reset to 500mA on powerdown. So how could you charge with 750mA? If system is powered up odds are it will take away 250mA. On powerdown state it seems to me there's no way at all to charge with 750mA. I really don't see the rationale behind all this. /j Personnaly I am not sure but it did not look like usb current was reset on powerdown when I tested (at least it was not reset to 100mA after I had to force it to 500 or 1000 on my dumb charger, and this is what I needed more !) Well, anyway, even if not perfect (chg_curlim following usb_curlim when it is changed), these settings proved really helpfull for me ! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Thu, May 07, 2009 at 12:42:42AM +0200, Joerg Reisenweber wrote: So taking in account your comments above this means the problem case is intentionally shutting down the device during charging from solarpanel. 1) I don't see why anybody should do this To save energy for later. 2) this should be handled during shutdown, rather than all the time by syncing BAT_CURLIM with USB_CURLIM. I'll give it a try. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
2009/5/7 Joerg Reisenweber jo...@openmoko.org Correct - usbdevstat allows 100mA, 500mA, 1A, and suspend (Tbl. 98, MBCC7), anyway... Setting chg_curlim won't help whatsoever, as you can set it only during device powered up and system running, and during this time the system consumption USB-to-SYS will add to the chg_curlim you set. So you exceed intended USB current by setting chg_curlim to the value you intend for USB current, just to shutdown device after that and hope to reach 'correct' USB current then eventually - that's silly. In my case I used setting chg_curlim also for when phone is on. Yes chg_curlim does not help to force usb real current to ie. 750m exactly. But ! This way I could have my phone use approx 750mA when on (by setting chg_curlim to 500mA). Of course it may sometimes consume up to 1A if needed (the peaks I was talking about...). But this is ok in my case for my weak dumb charger. What would not be ok is having chg_curlim not forced and phone pulling 1A for 30 minutes continuously while charging the battery faster than I need... (And usb_curlim to 500mA would on the other hand not charge quickly enough (about 300mA).) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am Do 7. Mai 2009 schrieb Cédric Berger: 2009/5/7 Joerg Reisenweber jo...@openmoko.org Correct - usbdevstat allows 100mA, 500mA, 1A, and suspend (Tbl. 98, MBCC7), anyway... Setting chg_curlim won't help whatsoever, as you can set it only during device powered up and system running, and during this time the system consumption USB-to-SYS will add to the chg_curlim you set. So you exceed intended USB current by setting chg_curlim to the value you intend for USB current, just to shutdown device after that and hope to reach 'correct' USB current then eventually - that's silly. In my case I used setting chg_curlim also for when phone is on. Yes chg_curlim does not help to force usb real current to ie. 750m exactly. But ! This way I could have my phone use approx 750mA when on (by setting chg_curlim to 500mA). Of course it may sometimes consume up to 1A if needed (the peaks I was talking about...). But this is ok in my case for my weak dumb charger. What would not be ok is having chg_curlim not forced and phone pulling 1A for 30 minutes continuously while charging the battery faster than I need... (And usb_curlim to 500mA would on the other hand not charge quickly enough (about 300mA).) So you think the STANDARD kernel should care about this rather exotic case which isn't specified properly (how long would this charger see the 1A sometimes?) and needs massive care from userland anyway? I mean, there's some reason PCF50633 is built this way, huh? We got enough problems caring about real hw-glitches in this chip. I don't think it's recommendable to tweak it even further far beyond what's normal usecase. btw your concept isn't working as you said yourself the USB current is reset to 500mA on powerdown. So how could you charge with 750mA? If system is powered up odds are it will take away 250mA. On powerdown state it seems to me there's no way at all to charge with 750mA. I really don't see the rationale behind all this. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am So 3. Mai 2009 schrieb Rask Ingemann Lambertsen: On Sat, May 02, 2009 at 03:30:10AM +0200, Joerg Reisenweber wrote: Am Mi 29. April 2009 schrieb Cédric Berger: On Tue, Apr 28, 2009 at 15:36, Joerg Reisenweber jo...@openmoko.org wrote: That's nonsense as there is no dumb charger out there not being capable of supplying 500mA. OTOH any management of maximum ingress current to USB by whatever means will inevitably fail when unplugging the charger device connected to FR during powerdown and replace it with a (nonexistent) weaker one. No. For better or for worse, the PCF50633 variant we use will power up the Frerunner and thus run the boot loader when you swap chargers. If the boot loader doesn't set the current limit correctly for the newly inserted charger, then that's where the bug is. TODO: Check U-Boot and Qi. (Long term TODO: Instead of fixing each and every bug three times (kernel, U-Boot and Qi), try to fit a bare-bones kernel and rootfs with boot menu into the 512 kB we currently use for boot loader.) Or a solar panel ? How could setting BAT_CURLIM to USB_CURLIM help? Because USB_CURLIM is reset to 500 mA when the Freerunner is turned off, while BAT_CURLIM remains at what it was last set to. So taking in account your comments above this means the problem case is intentionally shutting down the device during charging from solarpanel. 1) I don't see why anybody should do this 2) this should be handled during shutdown, rather than all the time by syncing BAT_CURLIM with USB_CURLIM. Probably it would be wise to disable shutdown during charge all together. Or you have 2 phone charging from the same usb port ? or I'm using the usb extension in my usb-coffemug-warmer? Or create a shortcircuit? It's not a valid usecase and I don't see how to accomplish that. Don't tell me you haven't seen one of those 4-port unpowered USB hubs which can only supply 100 mA per port. In this case USB-enum shall negotiate correct USB_CURLIM as the host knows about the hub and the (standard btw) restrictions wrt current. Again powering down the device during charge isn't recommended as host might think the device is shutdown because it doesn't respond to USB data anymore. Note than doing this (I used a little GUI with 1 set button for each value), I must set usb current limit, then only I set charge current limit. And in the meanwhile, since charge limit=usb limit=1A, it starts pulling about 1A and I cannot avoid that. Sorry I don't understand this statement. The problem is when you use e.g. a 750 mAh Nokia battery and set chg_curlim to 750 mA like you're supposed to. If you then plug in the charger, usb_curlim will be set to 1000 mA and so will chg_curlim. Automatically setting chg_curlim to 1000 mA is a bug since the user said max 750 mA for the battery. The kernel needs to remember the user specified chg_curlim. TODO: Kernel patch. ToDo: leave crg_curlim alone during normal operation and handle those silly cases of shutdown during charge correctly (e.g by simply disabling them (disallow shutdown), or - as I mentioned before - setting chg_curlim to 100mA unconditionally at shutdown time. Probably both) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am Mo 4. Mai 2009 schrieb Cédric Berger: Sorry, my mail was not really clear. Rask already answered questions. But just about usb_limit : 2009/5/2 Joerg Reisenweber jo...@openmoko.org No you have to push USB_CURLIM to 500mA, if you want 500mA. [... ] This way I have about 700-750mA pulled from my charger (though it can peak to 1A as needed). What's the rationale behind that? If you set USB_CURLIM to 750mA you get exactly the same behaviour without the useless when needed part. As far as I know, 750mA is not an option for usb_curlim. (only 100, 500 and 1000 I think) Anyway, bat_curlim allows more precise control. Correct - usbdevstat allows 100mA, 500mA, 1A, and suspend (Tbl. 98, MBCC7), anyway... Setting chg_curlim won't help whatsoever, as you can set it only during device powered up and system running, and during this time the system consumption USB-to-SYS will add to the chg_curlim you set. So you exceed intended USB current by setting chg_curlim to the value you intend for USB current, just to shutdown device after that and hope to reach 'correct' USB current then eventually - that's silly. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Sorry, my mail was not really clear. Rask already answered questions. But just about usb_limit : 2009/5/2 Joerg Reisenweber jo...@openmoko.org No you have to push USB_CURLIM to 500mA, if you want 500mA. [... ] This way I have about 700-750mA pulled from my charger (though it can peak to 1A as needed). What's the rationale behind that? If you set USB_CURLIM to 750mA you get exactly the same behaviour without the useless when needed part. As far as I know, 750mA is not an option for usb_curlim. (only 100, 500 and 1000 I think) Anyway, bat_curlim allows more precise control. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, May 02, 2009 at 03:30:10AM +0200, Joerg Reisenweber wrote: Am Mi 29. April 2009 schrieb Cédric Berger: On Tue, Apr 28, 2009 at 15:36, Joerg Reisenweber jo...@openmoko.org wrote: That's nonsense as there is no dumb charger out there not being capable of supplying 500mA. OTOH any management of maximum ingress current to USB by whatever means will inevitably fail when unplugging the charger device connected to FR during powerdown and replace it with a (nonexistent) weaker one. No. For better or for worse, the PCF50633 variant we use will power up the Frerunner and thus run the boot loader when you swap chargers. If the boot loader doesn't set the current limit correctly for the newly inserted charger, then that's where the bug is. TODO: Check U-Boot and Qi. (Long term TODO: Instead of fixing each and every bug three times (kernel, U-Boot and Qi), try to fit a bare-bones kernel and rootfs with boot menu into the 512 kB we currently use for boot loader.) Or a solar panel ? How could setting BAT_CURLIM to USB_CURLIM help? Because USB_CURLIM is reset to 500 mA when the Freerunner is turned off, while BAT_CURLIM remains at what it was last set to. Or you have 2 phone charging from the same usb port ? or I'm using the usb extension in my usb-coffemug-warmer? Or create a shortcircuit? It's not a valid usecase and I don't see how to accomplish that. Don't tell me you haven't seen one of those 4-port unpowered USB hubs which can only supply 100 mA per port. Note than doing this (I used a little GUI with 1 set button for each value), I must set usb current limit, then only I set charge current limit. And in the meanwhile, since charge limit=usb limit=1A, it starts pulling about 1A and I cannot avoid that. Sorry I don't understand this statement. The problem is when you use e.g. a 750 mAh Nokia battery and set chg_curlim to 750 mA like you're supposed to. If you then plug in the charger, usb_curlim will be set to 1000 mA and so will chg_curlim. Automatically setting chg_curlim to 1000 mA is a bug since the user said max 750 mA for the battery. The kernel needs to remember the user specified chg_curlim. TODO: Kernel patch. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am Mi 29. April 2009 schrieb Cédric Berger: On Tue, Apr 28, 2009 at 15:36, Joerg Reisenweber jo...@openmoko.org wrote: That's nonsense as there is no dumb charger out there not being capable of supplying 500mA. OTOH any management of maximum ingress current to USB by whatever means will inevitably fail when unplugging the charger device connected to FR during powerdown and replace it with a (nonexistent) weaker one. And what if the charger is a small usb host device... like a Freerunner ? Then uBoot should do standard USB enum. Which is negotiating current host is able to deliver. Or a solar panel ? How could setting BAT_CURLIM to USB_CURLIM help? Or you have 2 phone charging from the same usb port ? or I'm using the usb extension in my usb-coffemug-warmer? Or create a shortcircuit? It's not a valid usecase and I don't see how to accomplish that. I usually charge from a car charger and when I want to charge faster than 500mA from usb (so ~300mA to battery with phone on), I have to push usb limit to 1A. No you have to push USB_CURLIM to 500mA, if you want 500mA. But as it is too much for my poor charger, I also limit battery charge current (ex 500mA). How could setting BAT_CURLIM to USB_CURLIM help? This way I have about 700-750mA pulled from my charger (though it can peak to 1A as needed). What's the rationale behind that? If you set USB_CURLIM to 750mA you get exactly the same behaviour without the useless when needed part. How could setting BAT_CURLIM to USB_CURLIM help? Note than doing this (I used a little GUI with 1 set button for each value), I must set usb current limit, then only I set charge current limit. And in the meanwhile, since charge limit=usb limit=1A, it starts pulling about 1A and I cannot avoid that. Sorry I don't understand this statement. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Tue, Apr 28, 2009 at 15:36, Joerg Reisenweber jo...@openmoko.org wrote: That's nonsense as there is no dumb charger out there not being capable of supplying 500mA. OTOH any management of maximum ingress current to USB by whatever means will inevitably fail when unplugging the charger device connected to FR during powerdown and replace it with a (nonexistent) weaker one. I have several car chargers rated 350mA max. (Though I admit pulling 500mA generally works) And what if the charger is a small usb host device... like a Freerunner ? Or a solar panel ? Or you have 2 phone charging from the same usb port ? I usually charge from a car charger and when I want to charge faster than 500mA from usb (so ~300mA to battery with phone on), I have to push usb limit to 1A. But as it is too much for my poor charger, I also limit battery charge current (ex 500mA). This way I have about 700-750mA pulled from my charger (though it can peak to 1A as needed). Note than doing this (I used a little GUI with 1 set button for each value), I must set usb current limit, then only I set charge current limit. And in the meanwhile, since charge limit=usb limit=1A, it starts pulling about 1A and I cannot avoid that. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am So 26. April 2009 schrieb Rask Ingemann Lambertsen: On Sat, Apr 25, 2009 at 01:16:17PM +0100, Joerg Reisenweber wrote: Am Di 21. April 2009 schrieb Paul Fertser: drivers/power/pcf50633-charger.c: /* * We limit the charging current to be the USB current limit. * The reason is that on pcf50633, when it enters PMU Standby mode, * which it does when the device goes off, the USB current limit * reverts to the variant default. In at least one common case, that * default is 500mA. By setting the charging current to be the same * as the USB limit we set here before PMU standby, we enforce it only * using the correct amount of current even when the USB current limit * gets reset to the wrong thing */ Whoever wrote this amazingly puzzling comment, I think he got something severely wrong with operating principles of PMU PCF50633. Datasheet of PMU clearly states there's no situation whatever that could result in batcharge current overloading the USB_CURLIM, The comment doesn't claim there is. as *allways* there will be priority on serving system by providing up to 100% of usb current to power it. Serving the system takes 0 mA in this particular case, because the device is off. Bat charge will get whatever might remain after that, *up_to* the charging limit programmed into PMU. Exactly. As we may charge our battery with 1C (=1200mA) it's perfectly safe to set bat chg curlim to that value, and rely on PMU managing distribution of actual USB supply current to system and charging according to the momentary needs. The problem is not that of staying under the 1200 mA permitted for the battery. The problem is staying under the maximum USB current, which may be as little as 100 mA. We just can't do anything about the USB current limit being reset to 500 mA, but we _can_ keep the charging current limited to 100 mA, which is good enough when the only consumer is the the battery charger. Good enough for *what*? That's nonsense as there is no dumb charger out there not being capable of supplying 500mA. OTOH any management of maximum ingress current to USB by whatever means will inevitably fail when unplugging the charger device connected to FR during powerdown and replace it with a (nonexistent) weaker one. Then another point to second this is: there are *lots* of silly usb gadgets out there that take up to 500mA without any negotiation at all (USB coffee mug warmers etc). Also please have a look at USB2.0 charger spec supplement. we should use PCF50633 in the way it was designed, IMHO. Not care about constructed imaginary problem cases that are not to appear in real live. There is a reason NXP built this PMU-variant exactly this way though they could have done different. Actually there are different variants of PCF50633 but OM couldn't source because the one we got now is used by other OEMs as well so we could get a small slice of the produced stock. I don't think those bigger customers of NXP specified nonsense when ordering this variant built by NXP to their needs. baseline: switch USB_CURLIM to 100mA if and only if USB enum signalled host isn't capable of anything beyond. There's a reason FR is designed to resume/boot on USB insertion. It might be sensible to switch BATCHG_CURLIM to 100mA on powerdown unconditionally, but it's mere braindead to manage batcharge in dependence of USB_CURLIM. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, Apr 25, 2009 at 01:16:17PM +0100, Joerg Reisenweber wrote: Am Di 21. April 2009 schrieb Paul Fertser: drivers/power/pcf50633-charger.c: /* * We limit the charging current to be the USB current limit. * The reason is that on pcf50633, when it enters PMU Standby mode, * which it does when the device goes off, the USB current limit * reverts to the variant default. In at least one common case, that * default is 500mA. By setting the charging current to be the same * as the USB limit we set here before PMU standby, we enforce it only * using the correct amount of current even when the USB current limit * gets reset to the wrong thing */ Whoever wrote this amazingly puzzling comment, I think he got something severely wrong with operating principles of PMU PCF50633. Datasheet of PMU clearly states there's no situation whatever that could result in batcharge current overloading the USB_CURLIM, The comment doesn't claim there is. as *allways* there will be priority on serving system by providing up to 100% of usb current to power it. Serving the system takes 0 mA in this particular case, because the device is off. Bat charge will get whatever might remain after that, *up_to* the charging limit programmed into PMU. Exactly. As we may charge our battery with 1C (=1200mA) it's perfectly safe to set bat chg curlim to that value, and rely on PMU managing distribution of actual USB supply current to system and charging according to the momentary needs. The problem is not that of staying under the 1200 mA permitted for the battery. The problem is staying under the maximum USB current, which may be as little as 100 mA. We just can't do anything about the USB current limit being reset to 500 mA, but we _can_ keep the charging current limited to 100 mA, which is good enough when the only consumer is the the battery charger. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am Di 21. April 2009 schrieb Paul Fertser: Joerg Reisenweber jo...@openmoko.org writes: Am So 19. April 2009 schrieb Rask Ingemann Lambertsen: On Sat, Apr 18, 2009 at 05:11:36PM -0700, Mike Montour wrote: chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). Note that whenever you set usb_curlim (directly or indirectly by plugging in power), chg_curlim is set to the new value of usb_curlim. where do you find this info? I've checked shortly and e.g. 8.12.6.2 doesn't mention this relation. Maybe I didn't realize the important part? drivers/power/pcf50633-charger.c: /* * We limit the charging current to be the USB current limit. * The reason is that on pcf50633, when it enters PMU Standby mode, * which it does when the device goes off, the USB current limit * reverts to the variant default. In at least one common case, that * default is 500mA. By setting the charging current to be the same * as the USB limit we set here before PMU standby, we enforce it only * using the correct amount of current even when the USB current limit * gets reset to the wrong thing */ Whoever wrote this amazingly puzzling comment, I think he got something severely wrong with operating principles of PMU PCF50633. Datasheet of PMU clearly states there's no situation whatever that could result in batcharge current overloading the USB_CURLIM, as *allways* there will be priority on serving system by providing up to 100% of usb current to power it. Bat charge will get whatever might remain after that, *up_to* the charging limit programmed into PMU. As we may charge our battery with 1C (=1200mA) it's perfectly safe to set bat chg curlim to that value, and rely on PMU managing distribution of actual USB supply current to system and charging according to the momentary needs. There have been issues regarding some glitch resulting in a very short brownout on Vsys when *enabling* batcharge, but I don't think it's covered by the explanation above, and anyway afaik this has been fixed with various uBoot-patches and modifying the Vsys-buffering C (no boot on flat bat issue) See my previous shorter post in this thread cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Joerg Reisenweber jo...@openmoko.org writes: Am So 19. April 2009 schrieb Rask Ingemann Lambertsen: On Sat, Apr 18, 2009 at 05:11:36PM -0700, Mike Montour wrote: chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). Note that whenever you set usb_curlim (directly or indirectly by plugging in power), chg_curlim is set to the new value of usb_curlim. where do you find this info? I've checked shortly and e.g. 8.12.6.2 doesn't mention this relation. Maybe I didn't realize the important part? drivers/power/pcf50633-charger.c: /* * We limit the charging current to be the USB current limit. * The reason is that on pcf50633, when it enters PMU Standby mode, * which it does when the device goes off, the USB current limit * reverts to the variant default. In at least one common case, that * default is 500mA. By setting the charging current to be the same * as the USB limit we set here before PMU standby, we enforce it only * using the correct amount of current even when the USB current limit * gets reset to the wrong thing */ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Tue, Apr 21, 2009 at 02:19:04AM +0100, Joerg Reisenweber wrote: Am So 19. April 2009 schrieb Rask Ingemann Lambertsen: usb_curlim can be 0, 100, 500 or 1000 while chg_curlim is between 0 and 996 (in steps of about 4). checked 8.12.6.9, Tbl 95, Tbl94, and it's mentioning : 255/255 × Ich(ref) for max current. Please explain to me. Probably I'm missing some details The range of the sysfs entry is 0 to 996. I too think the scaling in the pcf50633 driver is slightly off (by about 0.4 %). -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am So 19. April 2009 schrieb Rask Ingemann Lambertsen: On Sat, Apr 18, 2009 at 05:11:36PM -0700, Mike Montour wrote: chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). Note that whenever you set usb_curlim (directly or indirectly by plugging in power), chg_curlim is set to the new value of usb_curlim. where do you find this info? I've checked shortly and e.g. 8.12.6.2 doesn't mention this relation. Maybe I didn't realize the important part? usb_curlim can be 0, 100, 500 or 1000 while chg_curlim is between 0 and 996 (in steps of about 4). checked 8.12.6.9, Tbl 95, Tbl94, and it's mentioning : 255/255 × Ich(ref) for max current. Please explain to me. Probably I'm missing some details /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, Apr 18, 2009 at 05:11:36PM -0700, Mike Montour wrote: chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). Note that whenever you set usb_curlim (directly or indirectly by plugging in power), chg_curlim is set to the new value of usb_curlim. usb_curlim can be 0, 100, 500 or 1000 while chg_curlim is between 0 and 996 (in steps of about 4). -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-Unstable] Forcing fast-charge
I'm trying to get my FR to force fast-charging (500mA) using my generic usb car adaptor. However /sys/ seems to have been shuffled about a bit and the wiki is no longer accurate. Does anyone know what the current means are to force fast charging at 500mA and could they share it with the list? Kind regards, Cameron signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cameron Frazier ha scritto: I'm trying to get my FR to force fast-charging (500mA) using my generic usb car adaptor. However /sys/ seems to have been shuffled about a bit and the wiki is no longer accurate. Does anyone know what the current means are to force fast charging at 500mA and could they share it with the list? Kind regards, Cameron I think this is the *greatest* fault of OM/SHR since the introduction of 2.6.28 kernel. Please, community, try to solve this, to adapt the well known battery.py to the current kernel. I think that after the release of OM 2009.1 and the excellent work of Paroli team, the phone side is about to be completed. But, we still have the problem of battery: I use FR as daily phone (or, better girlfriend phone) since the first times. I don't worry much about battery, I always have a Nokia BL-5C in my bag. But, if we cannot have a quick solution for battery lasting, we should try to make it chargeable all the times: how could we think to use TangoGPS or Navit in the car for long trips with the current situation? I'm not able to adapt battery.py myself, I've little experience with python but don't know much how a kernel works. This is a desperate appeal :D Thanks, - -- Francesco de Virgilio *Ubuntu-it Member and Wiki Editor* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia projects contributor* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://fradeve.netsons.org Love - Peace - Freedom - Free Software GPG 0x6482E056 (FP B996 A12C BD52 2A9B CDD3 812D 462D 93B0 6482 E056) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknp5SEACgkQRi2TsGSC4FaUiQCfQb9MzTDnjswY+UDbI6m5HtpI iFAAniAFGlbL88dsDKEp/h0xPuTMBIxh =m5Jd -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Cameron Frazier wrote: Does anyone know what the current means are to force fast charging at 500mA and could they share it with the list? I don't know if there's a dbus/frameworkd way to do it, but the direct method is: echo 500 /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, Apr 18, 2009 at 16:35, Francesco de Virgilio fradev...@gmail.com wrote: I think this is the *greatest* fault of OM/SHR since the introduction of 2.6.28 kernel. It's only one change in path. Nothing more has changed. I'm going to add functionality of battery.py in SHR Settings. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, 2009-04-18 at 20:14 +0200, Johny Tenfinger wrote: On Sat, Apr 18, 2009 at 16:35, Francesco de Virgilio fradev...@gmail.com wrote: I think this is the *greatest* fault of OM/SHR since the introduction of 2.6.28 kernel. It's only one change in path. Nothing more has changed. I'm going to add functionality of battery.py in SHR Settings. That's pretty much what I was trying to add to my SHR-Settings, at least the charge control portion. signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cameron Frazier ha scritto: On Sat, 2009-04-18 at 20:14 +0200, Johny Tenfinger wrote: On Sat, Apr 18, 2009 at 16:35, Francesco de Virgilio fradev...@gmail.com wrote: I think this is the *greatest* fault of OM/SHR since the introduction of 2.6.28 kernel. It's only one change in path. Nothing more has changed. I'm going to add functionality of battery.py in SHR Settings. That's pretty much what I was trying to add to my SHR-Settings, at least the charge control portion. I hope this changes will be available for all users with next updates... :) - -- Francesco de Virgilio *Ubuntu-it Member and Wiki Editor* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia projects contributor* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://fradeve.netsons.org Love - Peace - Freedom - Free Software GPG 0x6482E056 (FP B996 A12C BD52 2A9B CDD3 812D 462D 93B0 6482 E056) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknqXrcACgkQRi2TsGSC4FYsYwCeLDTG41/qDnK/gCL8d1FSbKLs QUUAoJAavVqsg5Ul3Gk5AzOy0V434SUz =YWJI -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, 2009-04-18 at 10:50 -0700, Mike Montour wrote: Cameron Frazier wrote: Does anyone know what the current means are to force fast charging at 500mA and could they share it with the list? I don't know if there's a dbus/frameworkd way to do it, but the direct method is: echo 500 /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim Ahh, ok. Now things seem to be working correctly. One question though what are the differences between usb_curlim and chg_curlim? I'm not sure I fully understand what chg_curlim represents. signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Cameron Frazier wrote: Ahh, ok. Now things seem to be working correctly. One question though what are the differences between usb_curlim and chg_curlim? I'm not sure I fully understand what chg_curlim represents. chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). The PCF50633 datasheet (linked from somewhere on the wiki) has more information. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
On Sat, 2009-04-18 at 17:11 -0700, Mike Montour wrote: Cameron Frazier wrote: Ahh, ok. Now things seem to be working correctly. One question though what are the differences between usb_curlim and chg_curlim? I'm not sure I fully understand what chg_curlim represents. chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). The PCF50633 datasheet (linked from somewhere on the wiki) has more information. Wonderful. Thanks for the info. signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Am So 19. April 2009 schrieb Cameron Frazier: On Sat, 2009-04-18 at 17:11 -0700, Mike Montour wrote: Cameron Frazier wrote: Ahh, ok. Now things seem to be working correctly. One question though what are the differences between usb_curlim and chg_curlim? I'm not sure I fully understand what chg_curlim represents. chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). The PCF50633 datasheet (linked from somewhere on the wiki) has more information. Wonderful. Thanks for the info. basically you never want to care about chg_curlim as it is a maximum of 1C = 1.2A for GTA01/02 battery cell and you never can draw that much current from USB (The PMU allows for a maximum of 1A here). PMU is automatically handling the distribution of available USB current between charging and system in a way system always has priority and chrg current reduced accordingly - so no need to care about chg_curlim for that topic either. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
