i think one way is format to my n900 ! Thx KP51

One word - bullsh|t.

kp doesn't have anything to do with Your EXTERNAL charger temperature. Theoretically, it could get warmer, if You would use bq2145x_charger module with manually set higher charging current, but even this is unlikely to happen.

Proper "bug report" would contain any useful data - like monitor of charging current, when your charger becomes hot (that would prove or deny something fishy going out), etc. I don't care if You're using -devel for 3 or 300 years, both content of what You've written, and way in which You have written it, mark You as person that should stay away from -devel, in my humble opinion (and You have right to not agree )

/Estel

Pali, as per:
http://mg.pov.lt/maemo-irclog/%23mae...08-02T01:19:39

...Joerg doesn't have slightest idea why bq2415x_charger is acting like I've described in last page. Considering, that You followed his formula, it isn't expected result.

Could You compare things I've reported with what You wanted to achieve, and check for bugs in code?

/Estel

// Edit

Also see from here:
http://mg.pov.lt/maemo-irclog/%23mae...08-02T01:35:23

...to the end of discussion. wrong RS value is candidate to being responsible for insane values, but, still it doesn't explain fubar'ish behavior of termination_current (described in my earlier posts). Something is definitely wrong here.

As I use bq2415x_charger exclusively for every charging, I've noticed another 2 glitches in bq2415x_charger:

1. Using default settings, charging doesn't terminate properly - it terminates *too early*, i.e. before battery reach full capacity, and before vdq is turned to 1. This prevent calibration of battery sensor, and usage of our last 5% of battery capacity

2. To overcome point 1, I've investigated buggy behavior of termination_current sysfs entry, mentioned earlier. I discovered why it accept 6500 and 6800 only, as value - just like charge_current it's strange translation of real current, but unlike charge_current, it accepts *only* real values.

For example, with charge_current, to have 950 mA current, You must specify 1750 as sysfs value. to have 1250 mA, You must put 2050 there, and so goes on. Values are accepted, and remain this way.

For termination_current, hoever, to have 50 mA termination current, You must specify exactly this - 50. It gets "translated" to 6450 then, and sysfs entry turns itself to 6450 (which means 50 mA). If You want 100 mA, You need to specify 100, and it translates itself to 6500 - etc, up to 400 of termination current (which translates to 6800).
---

It's definitely a bug (or chain of bugs), but at least it works (when You RE it's twisted logic) and allow full control over charging current and termination current.

Ok
i try to upgrade kernel (kp51) two days ago and crashed my system. But today, i try again to install kernel (kp51) but this time, it install perfectly. Now working very well ! Cleven is ok, and o have not any charging problem ! i think new kernel is good job.

PALI thank you very much ! Sorry my other posts.

Hi Estel,

there is sysfs entry registers which output raw value of each bq24150a register. Look at datasheet http://www.ti.com/lit/ds/symlink/bq24150a.pdf (page 29) to check if all values are correct. Also you can ask Doc about raw register values.

registers sysfs entry is read-write. You can set to register 0x01 value 0xFF by: echo "0x01 0xFF" > registers

EN_STAT is for enabling/disabling (emergency) charge led.

Then rmmod bq2415x_charger driver and use charge21.sh script for charging... Use i2cget to raw register values and check if values are correct.

Next week I will be without internet, so I cannot look at it.

Pali, I've looked at it briefly, and raw values via i2cget (charge21.sh) looks OK. It seems that they're wrong only when bq2415x_charger is used.

I'll look at it later, as I'm also starting 2-weeks vacations

my charger is AC-10E i haven't any problem

Well, point taken. I guess you are right, this inconsistency should be solved somehow (either moving some stuff to e.g. /opt/additional-kernel-modules and symlinking them as e.g. /lib/modules/2.6.28.10-power51/extra/* or placing them all in /lib/modules together... probably the first option is a bit better, as if someone needs some special modules in rootfs to be loaded at boot, she/he will have sufficient knowledge to copy them by their own to rootfs manually).

lol, i found a workaround for the non unlockable display. I don't lock it and start bedside instead (doesn't really work but turns my screen black). To "unlock" I press strg shift x so bedside is minimized and I can close it again.