| freemangordon | sicelo: ok, we shall read the tocs more carefully then, taking 8s for bq to report status does not seem like HW issue, but rather how it is programmed | 08:31 |
|---|---|---|
| freemangordon | *docs | 08:31 |
| freemangordon | sicelo: it seens this 2s timeout is to re-start charging on temporal low input voltage, see "Input Source Detection" | 08:44 |
| freemangordon | *seems | 08:44 |
| freemangordon | so, I would think that we shall have (almost) immediate status change | 08:50 |
| sicelo | freemangordon, have you done the LED test? | 09:15 |
| sicelo | we can report instantaneous charging state if we want, by simply setting ONLINE true when reported_mode changes in notifier_call. but that's cheating, because in reality, the chip has not yet decided that we're charging or not. it's possible (although not very likely) that it'll end up in fault state instead | 09:18 |
| sicelo | that's why I prefer we rely on the STAT_1 & STAT_2 flags, which the STAT pin also uses | 09:30 |
| sicelo | i have looked at the docs multiple times, and i have never seen a way to influence how fast the detection/reporting takes place | 09:39 |
| sicelo | anyway, i guess in the meantime we can drop the whole thing, blacklist bq24 in the status applet, so it will automatically switch to tracking isp1704. | 09:47 |
| sicelo | but please do the STAT pin LED test, or someone else can do it and report their result, so we're sure i don't have a broken N900. Wizzup, arno11 ... | 09:57 |
| sicelo | echo 1 > /sys/class/power_supply/bq24150a-0/stat_pin_enable from a fresh boot. plug in charger, note how fast steady amber LED comes on. disconnect charger. reconnect it, not when steady amber LED comes on. repeat as much as you can afford to | 10:27 |
| sicelo | s/not/note/ | 11:17 |
| freemangordon | sicelo: will do once I am home, next week | 11:23 |
| freemangordon | in the meanwhile it will be good if arno11 does it | 11:24 |
| freemangordon | however, it is not reasonable charging detection to take 8 seconds | 11:25 |
| arno11 | sicelo: on my device, the amber led never comes | 11:26 |
| arno11 | (leds work fine on Fremantle) | 11:27 |
| arno11 | the green led is ok | 11:27 |
| sicelo | arno11: that's not possible. did you do the stat_pin_enable? | 11:29 |
| arno11 | let me try again (sorry, not too much spare time atm) | 11:30 |
| sicelo | arno11: ah, what you're talking about is what i want to fix. you mean it never comes when running 'normally' :-) | 11:30 |
| arno11 | yes indeed | 11:30 |
| sicelo | but yes, please do the test mentioned above. no rush. note how fast, or how slow that amber led comes up, each time you plugin charger | 11:30 |
| arno11 | ok no probs | 11:31 |
| arno11 | results in sec: 9, 7, 8, 0, 0, 0 | 11:35 |
| arno11 | if i wait a couple of seconds and test again, same results | 11:36 |
| arno11 | that's a bit random | 11:37 |
| arno11 | now: 6, 0, 0 | 11:38 |
| arno11 | 5, 0, 0 | 11:38 |
| arno11 | 7, 0, 0, 0 | 11:39 |
| sicelo | thank you so much! you're testing with a real charger or port on pc? | 11:41 |
| arno11 | and now after waiting 30 sec to plug it again: 0, 2, 2, 3, 7 | 11:41 |
| arno11 | i use a real charger | 11:41 |
| sicelo | perfect. thank you ;-) | 11:44 |
| arno11 | no probs | 11:44 |
| sicelo | don't forget to zero the stat_pin_enable sysfs node | 11:45 |
| sicelo | if you want, i can share the fixed charger driver corresponding to my PR. amber LED works with it | 11:46 |
| arno11 | yup already set to zero, no rush for amber led :) , thx anyway | 11:47 |
| uvos | so the problem is that sometimes the chip takes a long time to detect? | 12:01 |
| sicelo | let me say, long to report | 12:05 |
| * sicelo is 99% sure his fix is correct | 12:07 | |
| uvos | sicelo: ok so i gues you sleep for the maximum time so that you allways catch the register state after it has "settled"? | 12:15 |
| sicelo | yup | 12:16 |
| uvos | if the time is very variable (like arno's msg seams to suggest) | 12:16 |
| uvos | i gues it would be better to use a periodic timer to poll the state for 10s, so most of the time it finishes sooner | 12:16 |
| sicelo | in reality, we run call power_supply_changed() three times for every charger insertion or removal, since for some magical reason, the PHY sends events twice | 12:20 |
| sicelo | so if your device is in 'fast mode' so to speak, then it doesn't wait for the 10s at all | 12:21 |
| uvos | i see | 12:21 |
| uvos | ok | 12:21 |
| sicelo | also important to note that this whole dance doesn't affect charging itself ... chip is charging just fine. this is only about reporting to userspace. i don't think we have a very big need to report very quickly, especially here the delay is in the hw itself. so that's why i'm not really in favor of polling | 12:30 |
| uvos | well 10s is a long time | 12:30 |
| uvos | the user might get confused and think something is wrong with his cable etc | 12:30 |
| uvos | so i can see the apeal of keeping this responsive | 12:31 |
| sicelo | my samsung phones, for some reason i don't know, also take a little while | 12:32 |
| sicelo | anyway, if we really want this to be snappy, then sure, i'll restore the blacklist in the status applet. that causes it to use the PHY for reporting, and that microsecond fast. then we can leave bq to take its 10s and userspace won't even know about that | 12:34 |
| sicelo | still curious what causes the bq to be very fast first time, then start delaying. maybe there was (or should have been) some errata for it :) | 12:37 |
| uvos | mz617 sensor suite is quite extensive | 14:28 |
| uvos | we have a max9635 als (no driver in mainline), a lis3dh accel, an akm8975 compass, a l3g4200d gyro, a bmp180 pressure sensor, and an attiny48 driveing a custom pannel wide capacative proximity sensor (for the pen i presume) | 14:31 |
| sicelo | docs for the als available? | 14:35 |
| uvos | yeah | 14:36 |
| uvos | maybe we should try to buy these https://www.ebay.com/itm/285851310777 | 16:29 |
| uvos | the presence of the attiny makes me wonder how they work | 16:29 |
| buZz | my surface pro tablet has similar, it supports 'finger touch' -and- 'pen input' , programs can handle them differently | 16:31 |
| uvos | buZz: i mean more hw wise | 16:32 |
| uvos | the touch sensor chip has no support for a active stylus | 16:32 |
| buZz | fancy | 16:32 |
| buZz | so that chip does just the fingers | 16:32 |
| uvos | but there is a mysterious attiny doing "cpapacitive proximity" in the stock kernel | 16:33 |
| uvos | and android has a callibration procedure for the stylus | 16:33 |
| uvos | so motorola seams to be doing something fairly fancy here to get the hovering pen effect | 16:34 |
| buZz | wacom uses 'EMR Electromagnetic Resonance' | 16:34 |
| buZz | here on this tablet, the pen functions before touching the screen | 16:34 |
| buZz | it starts a couple mm before the screen | 16:35 |
| uvos | i wonder if i can find the attiny on the board and dump its rom | 16:38 |
| uvos | avr assembly is pretty easy to read | 16:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!