| freemangordon | uvos: do you want to make a new kernel update with cpcap fixes | 11:22 |
|---|---|---|
| freemangordon | branch is maemo-5.18.y-cpcap, no tag | 11:23 |
| uvos | freemangordon: makes sense to build it for devel no? | 11:24 |
| uvos | not sure what your saying | 11:24 |
| uvos | do you want me to tag it? | 11:25 |
| freemangordon | yes, tag and build for -devel | 11:25 |
| uvos | ok | 11:25 |
| freemangordon | maybe merge back to maemo-5.18.y and delete maemo-5.18.y-cpcap branch | 11:26 |
| freemangordon | I made it mostly for you and tmlind to review | 11:26 |
| uvos | i get that | 11:26 |
| uvos | i have to review it first | 11:27 |
| freemangordon | I already fixed leste-config to enable hdq, I amd sure it does not increase idle current draw | 11:27 |
| freemangordon | well, 99.99% sure :) | 11:27 |
| uvos | leste-config-mapphone/etc/modprobe.d/wire.conf.leste lacks ending newline | 11:28 |
| freemangordon | not really | 11:28 |
| freemangordon | pull again | 11:29 |
| uvos | gh sais so | 11:29 |
| uvos | i havent pulled yet | 11:29 |
| freemangordon | hmm, I am sure I pushed, lemme check | 11:29 |
| uvos | https://github.com/maemo-leste/leste-config/commit/8548645e63b81b9911c25674d761bcd500790af1 | 11:29 |
| uvos | might be bug idk but its not happy | 11:29 |
| freemangordon | https://github.com/maemo-leste/leste-config/commit/e01c0762084ae6d01b3a7ff6d3bc77900f4cd99b | 11:29 |
| uvos | oh you fixed it | 11:29 |
| uvos | sorry | 11:29 |
| freemangordon | maybe I didn;t push to master, lemme check | 11:30 |
| freemangordon | it is there as well | 11:30 |
| uvos | its there | 11:30 |
| freemangordon | hmm, with the new battry thing are looking way batter | 11:40 |
| freemangordon | *things | 11:40 |
| freemangordon | I disconnected from the charger yesterday evening | 11:40 |
| freemangordon | it still reports 50% full, but I think it has more juice actually | 11:41 |
| uvos | just in: man is suprised new 2200mah battery works better than 10 year old 1750mah cell :P | 11:43 |
| freemangordon | :D | 12:32 |
| freemangordon | tmlind: BTW, I have a patch for a panel (simple-panel), I know the model but not the manufacturer, what compatible I shall make for it? All panels are like $manufacturer,$model. | 13:02 |
| freemangordon | in case anybody is curious about how that allwinner tablet I am using behaves with leste: http://46.249.74.23/leste/sunxi/20221102_001.mp4 | 13:03 |
| sicelo | Wizzup: any chance that you're not too far from your n900 serial jig? would be great if you could assist Pali with u-boot test that he needs | 15:23 |
| tmlind | freemangordon: noname,panelxyz or something similar? | 15:55 |
| freemangordon | will upstream accept it? | 15:56 |
| freemangordon | uvos: "Nov 2 16:25:10 localhost kernel: [73611.267822] cpcap_battery cpcap_battery.0: Battery low at 3393mV!" | 15:58 |
| freemangordon | and immediate shutdown | 15:58 |
| freemangordon | something is broken, I guess mce logic | 15:58 |
| freemangordon | battery capacity is measured to be 1619 mAh, not even close to 2250 | 15:59 |
| tmlind | freemangordon: if some mobile device, there are usually multiple providers of components, maybe generic,panelxyz | 16:00 |
| freemangordon | hmm, yeah, generic should do the job | 16:00 |
| freemangordon | it is tablet, but still | 16:00 |
| freemangordon | uvos: this https://github.com/maemo-leste/leste-config/blob/master/leste-config-droid4/etc/mce/mce.ini.d/70-droid4.ini.leste#L40 | 16:05 |
| freemangordon | I think it is better to calculate that based on POWER_SUPPLY_VOLTAGE_MIN_DESIGN | 16:06 |
| freemangordon | like POWER_SUPPLY_VOLTAGE_MIN_DESIGN+50 or something | 16:07 |
| freemangordon | also, I guess you have some hard values in charge-mode | 16:20 |
| sicelo | that "Battery low at 3393mV" came from kernel. isn't it kernel that initiated the shutdown in this case? | 16:22 |
| freemangordon | no | 16:22 |
| freemangordon | also, it seems there are 2 types of 'low' one @ 3.3 and other @ 3.1, no idea what are those used for | 16:23 |
| freemangordon | tmlind: ^^^ do you remember? | 16:23 |
| freemangordon | ah, it seems 'high' low is for low reporting, 'low' low is for shutdown | 16:24 |
| freemangordon | cpcap_battery_low() has some hardcoded values too | 16:26 |
| freemangordon | but that is not so critical as mce deciding to do power off too early and charge-mode assuming normal li-ion battery no matter what kernel says | 16:29 |
| sicelo | iirc it was set to 3350 in mce because d4 can't boot easily once battery is completely depleted | 16:31 |
| freemangordon | *what* battery? | 16:31 |
| sicelo | d4 battery :-) | 16:32 |
| freemangordon | 10yo one? | 16:32 |
| freemangordon | because here I have new polarcell 2250 mAh | 16:32 |
| sicelo | 10yo battery and cheap replacements | 16:32 |
| freemangordon | and yes, it can boot the device even @ 3150 | 16:32 |
| freemangordon | the point is that genuine moto batteries are 3.1-4.35 | 16:34 |
| freemangordon | not 3.2-4.2 | 16:34 |
| freemangordon | and that is the difference between 1600 and 2200 | 16:34 |
| freemangordon | 30% | 16:34 |
| freemangordon | or something | 16:34 |
| freemangordon | but anyway, lets wait for uvos, to see if we will be able to come-up with some idea that will make both (old battery/new battery) parties happy | 16:35 |
| freemangordon | in any case, mce shutdown voltage must be less that 3.3, otherwise you don't have any chance to get a charger | 16:40 |
| freemangordon | hmm, what about: | 17:06 |
| freemangordon | 1. mce stores current voltage @ first 'low' signal received | 17:06 |
| freemangordon | 2. on every following 'low' received, it subtracts the current voltage from the stored one and if it is more than a threshold or if the current voltage is less that DESIGN_LOW + 100 (for example), then it shuts down | 17:06 |
| freemangordon | 3. stored 'first low' is reset on charger connected | 17:06 |
| freemangordon | that way bad batteries will be guaranteed to have enough charge to boot and good batteries will be used properly and users will have a chance to find a charger | 17:08 |
| freemangordon | hmm? | 17:08 |
| freemangordon | my old (bad) battery was giving low @ 3636mV, so I think threshold should be calculated based on lowVoltage - 3300, somehow | 17:15 |
| freemangordon | hmm, actually threshold = $device_specific_value + (4200-DESIGN_LOW) should be better | 17:18 |
| freemangordon | oh, I mean 3200-DESIGN_LOW | 17:21 |
| freemangordon | hmm, increasing POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE doesn't actually work | 17:49 |
| Wizzup | sicelo: I wil be near it on sunday and onwards | 17:55 |
| uvos | mce deicdes to turn off the device early because of the mapphone bootloader booting problem when totaly empty | 18:00 |
| uvos | we discussed this plenty of times before | 18:00 |
| uvos | yes its early (slightly the amount of engery in a lipo at 3.35 volts is fairly tiny over 3.0V the curve gets really steep down there) | 18:00 |
| uvos | it _needs_ to be early | 18:00 |
| uvos | take a look at https://learn.adafruit.com/li-ion-and-lipoly-batteries/voltages for a referance discharge curve | 18:08 |
| uvos | note that teh differencein capcaity between a discarge to 3.1 and 3.2 is less than to even worry about | 18:08 |
| uvos | 3.35 is slightly early, but note that we do that because the device will die before it reaches a bootstate where it can charge if you do that | 18:10 |
| uvos | becasue of kexecboot etc | 18:10 |
| uvos | but even that is in the rage of a couple pecent | 18:10 |
| uvos | 2% maybe 5% if the device is heavly loaded at shutdown | 18:11 |
| uvos | so i did the expieraments wrt when to shutdown with my best stock eb41 btw | 18:13 |
| uvos | that hat about 1250mAh as callibrated by cpcap | 18:14 |
| uvos | also taking into account that we use quite a large amount of power even when off, if the mainline kernel is the one to turn the device off | 18:14 |
| uvos | so we also needed some extra | 18:14 |
| freemangordon | uvos: I understand and agree that we should have some extra power on shutdown | 18:20 |
| freemangordon | that's not the issue, the issue is that I was not give any chance to connect a charger | 18:21 |
| freemangordon | *given | 18:21 |
| freemangordon | no warning, nothing, as soon as 'low' was signaled, bang, a shutdown | 18:21 |
| freemangordon | that's why I think a more complicated logic, like the one ^^^ shall be implemented | 18:22 |
| freemangordon | also, it is not about d4 only | 18:22 |
| uvos | well we have a conflict here | 18:22 |
| freemangordon | I know | 18:22 |
| uvos | we dont want to change the values in kernel | 18:22 |
| uvos | because they should be correct | 18:22 |
| freemangordon | we should not | 18:22 |
| uvos | so we want a workaround in userspace only | 18:22 |
| freemangordon | see the algo I came up with ^^^ | 18:22 |
| freemangordon | this is all in mce | 18:23 |
| uvos | i dont see why its not about d4 only | 18:23 |
| uvos | any other device should not have this issue | 18:23 |
| uvos | the kernel should just signal at the appropriate times | 18:24 |
| freemangordon | we may have similar issues on other devices, in theory | 18:24 |
| freemangordon | but lets not discuss that now | 18:24 |
| freemangordon | please comment on the alog | 18:24 |
| freemangordon | *algo | 18:24 |
| uvos | i dont grok it | 18:26 |
| uvos | what is your first low? | 18:26 |
| freemangordon | 'current_voltage' at the tim e'low' is generated for the first time | 18:26 |
| uvos | thats essentaly a random number generator | 18:26 |
| uvos | since it depends on load | 18:26 |
| sicelo | those 'lows' don't exist in bq27200 iirc | 18:27 |
| freemangordon | not really, because the worse battery is, the higher the voltage | 18:27 |
| uvos | but you cant realy on that | 18:27 |
| uvos | since it wont be so when the device is not loaded | 18:27 |
| uvos | i also dont see what is nessecary | 18:27 |
| uvos | besides rasing the low threshold (for the banner) in userspace | 18:28 |
| freemangordon | to have at least few minutes of "battery low" ranings before a shutdoen | 18:28 |
| uvos | sure | 18:28 |
| freemangordon | *warnings | 18:28 |
| uvos | so just raise the tresh in upower | 18:28 |
| freemangordon | this somes from the kernel | 18:28 |
| uvos | to 3.5 or so | 18:28 |
| freemangordon | *comes | 18:28 |
| uvos | and ignore the kernel | 18:28 |
| uvos | just need to make this selective like in mce | 18:28 |
| freemangordon | see, *defaults* should work | 18:28 |
| uvos | the defaults are what is in kernel | 18:29 |
| freemangordon | no, mce ignores the kernel and makes its own shut-down decision | 18:29 |
| uvos | yes | 18:29 |
| uvos | the fact that the kernel is "lieing" is a quirk on mapphones only | 18:29 |
| freemangordon | this is wrong the way it is implemented for d4 | 18:29 |
| freemangordon | that quirk makes it so that those with good batteries have absolutely no chance to plug a charger when the battery is low | 18:30 |
| freemangordon | and this has to be fixed | 18:30 |
| uvos | sure and i told you how i would do that | 18:31 |
| uvos | just ignore the low signal from the kernel in upower | 18:31 |
| freemangordon | why upower? | 18:31 |
| uvos | and add something based on configureable voltage instead | 18:31 |
| uvos | where else would you do it? | 18:31 |
| uvos | upower is the common thing here | 18:31 |
| freemangordon | that agin depends on the load, no? | 18:31 |
| uvos | sure, but its the best we have | 18:32 |
| freemangordon | did you grok what I am proposing? | 18:32 |
| uvos | yes and it cant be reliable | 18:32 |
| freemangordon | I don;t see why? | 18:32 |
| uvos | since it depends on instanainous load | 18:32 |
| uvos | while upower dose smoothing | 18:32 |
| freemangordon | no, there are 2 shutdoen conditions | 18:32 |
| freemangordon | either threshold or low voltage | 18:33 |
| freemangordon | whichever comes first | 18:33 |
| uvos | sure. but should be critical not low | 18:33 |
| uvos | for the latter | 18:33 |
| uvos | low is the banner | 18:33 |
| freemangordon | sure | 18:33 |
| freemangordon | I have no issue with too mane 'low' banners | 18:33 |
| freemangordon | given that I had none before shutdown :) | 18:34 |
| uvos | right so the problem is not the shutdown threshold in mce | 18:34 |
| freemangordon | back then I had my n900 beeping 'low' all day long | 18:34 |
| freemangordon | it is | 18:34 |
| uvos | or the cirtical signal | 18:34 |
| uvos | it is that the low signal dosent follow the thresh in mce | 18:34 |
| freemangordon | no, it is the shutdown threshold in mce | 18:34 |
| uvos | ie it isent above the tresh in mce | 18:34 |
| freemangordon | lemme explain: | 18:34 |
| freemangordon | I got kernel low @3393mV | 18:35 |
| freemangordon | mce threshold is 3350 | 18:35 |
| sicelo | freemangordon: was the N900 battery calibrated? (that beeped low all day) | 18:35 |
| uvos | yes so it shutdown | 18:35 |
| uvos | and you never saw the low banner | 18:35 |
| freemangordon | exactly | 18:35 |
| uvos | the issue here isent the mce threshold | 18:35 |
| uvos | its that the banner is to late | 18:36 |
| freemangordon | it is | 18:36 |
| freemangordon | because it shuts down | 18:36 |
| uvos | mce _has_ to shutdown | 18:36 |
| freemangordon | no, banner is not late | 18:36 |
| uvos | it has no choice | 18:36 |
| freemangordon | yes, but that should depend on the quality of the battery | 18:36 |
| freemangordon | sicelo: this is d4 | 18:36 |
| uvos | it cant | 18:36 |
| freemangordon | sicelo: oh | 18:36 |
| freemangordon | no, that was bme | 18:37 |
| uvos | there is no reliable way for mce to know how mutch capacity is below 3.35V | 18:37 |
| uvos | what you propose is not a relaible way to mesure it | 18:37 |
| freemangordon | but is better than current behaviour | 18:37 |
| uvos | no | 18:37 |
| uvos | and as i also explained | 18:37 |
| uvos | if mce thresh is 3.35 | 18:37 |
| freemangordon | no, current behaviour is unacceprable | 18:37 |
| uvos | and your special thresh is 3.15V | 18:37 |
| uvos | the lost extra capacity is <5% in exream cases | 18:38 |
| uvos | probubly less than 2 | 18:38 |
| freemangordon | because it leeves me without a phone, withoug giving me a warning | 18:38 |
| freemangordon | *leaves | 18:38 |
| uvos | but thats not a problem with the treshold at all | 18:38 |
| uvos | the indication of low just needs to come earlier | 18:38 |
| freemangordon | it cannot | 18:38 |
| freemangordon | because the battery is good | 18:38 |
| uvos | ofc it can | 18:39 |
| uvos | we need 2-3% extra capcaity to boot again | 18:39 |
| freemangordon | exactly | 18:39 |
| uvos | so we need to move the low signal up 2-3% | 18:39 |
| uvos | aswell | 18:39 |
| freemangordon | no, we should not shutdown @ 3350 | 18:40 |
| uvos | yes we must | 18:40 |
| uvos | there is no alternative | 18:40 |
| freemangordon | or at least that should account for the DESIGN_LOW | 18:40 |
| uvos | no | 18:40 |
| freemangordon | aaaaa | 18:40 |
| freemangordon | I give up | 18:40 |
| uvos | DESIGN_LOW should be the real value | 18:40 |
| uvos | not the value we moved up 2-3% | 18:40 |
| uvos | becasue of the bootloader issue | 18:41 |
| uvos | so we should absolutly not include it | 18:41 |
| uvos | and we dont have to either | 18:41 |
| uvos | becuase the differences in design low are immaterial | 18:41 |
| uvos | 3.1 vs 3.2 vs 3.0 v are <<1% capcaity | 18:41 |
| uvos | we cant mesure that accuratly anyhow | 18:41 |
| uvos | so there is no point | 18:41 |
| freemangordon | ok, lemme try again: | 18:45 |
| freemangordon | uvos: what is the lowest battery capacity we shall support? | 18:45 |
| uvos | android works fine even with really degraded batteies | 18:45 |
| freemangordon | ok, so 1000mAh? | 18:45 |
| uvos | sure | 18:45 |
| freemangordon | now, to boot, we need about 50mAh remaning, no? | 18:46 |
| uvos | not sure about the exact value | 18:46 |
| uvos | but yes some amount | 18:46 |
| freemangordon | and high enough voltage, like maybe 3.3 if we assume internal resistance to be 1 ohm | 18:46 |
| freemangordon | this is for bad batteries | 18:47 |
| uvos | high enougth voltage at what stage | 18:47 |
| freemangordon | boot | 18:47 |
| uvos | we need to stay above mbms shutdown threshold | 18:47 |
| uvos | the android kernels threshold | 18:47 |
| uvos | during boot | 18:47 |
| freemangordon | so 3.1 | 18:47 |
| uvos | yes, mbm is a bit higher | 18:47 |
| freemangordon | threshold I mean | 18:47 |
| uvos | but it comes first so no matter | 18:47 |
| freemangordon | ok | 18:48 |
| uvos | we also need to say above the mainline kernels emergency shutdown thresh | 18:48 |
| uvos | at least for the second it takes to enable charging | 18:48 |
| freemangordon | yes | 18:48 |
| freemangordon | so, lets assume 3.3 is ok | 18:48 |
| uvos | sure at boot time | 18:48 |
| uvos | so we need to issue shutdown slightly before that ofc | 18:49 |
| freemangordon | but, this is 3.3 with no load | 18:49 |
| uvos | sure | 18:49 |
| uvos | but you need to accound for usage during shutdown | 18:49 |
| freemangordon | sure, but this is about 30 seconds | 18:50 |
| uvos | and the bug that cuases the device to use 1-2mA during off | 18:50 |
| uvos | we need the device to survive a day or so while off after low battery shutdown | 18:50 |
| uvos | 30 quite processing intense seconds | 18:50 |
| freemangordon | also, we can use the measured capacity to make an estimation of the quality of the battery | 18:50 |
| uvos | do remember the discarge curve, 3.3v and 3.1 are very close | 18:50 |
| uvos | well the problem here is | 18:51 |
| uvos | that we dont know where the charge counter is ususal | 18:51 |
| sicelo | uvos: shouldn't that be figured out? "the bug that cuases the device to use 1-2mA during off" | 18:51 |
| uvos | sicelo: yes | 18:51 |
| uvos | sicelo: but thats very hard | 18:51 |
| uvos | sicelo: how do you get hw state when the device is off | 18:51 |
| uvos | sicelo: clearly we are not doing something, but what? | 18:51 |
| freemangordon | anyway, we shall either raise the 'low' threshold above 3.3 or lower the mce shutdown threshold | 18:52 |
| freemangordon | we can;t do former, so we shall make mce smarter | 18:52 |
| uvos | well we cant lower the mce shutdown threshold as that will softbrick peoples devices | 18:52 |
| uvos | and we must make the low threshold be above whatever mce decides at all times | 18:52 |
| freemangordon | byt either lowering the threshold or do not do shutdown before warning at least couple of times | 18:53 |
| uvos | so it needs to account for the mce tresh being 3.35v | 18:53 |
| uvos | we cant just not shutdown before warning a couple of times | 18:53 |
| freemangordon | so, what about ignoring firts couple of "low" signals then? | 18:53 |
| uvos | a bad idea | 18:54 |
| uvos | since if the device is very quiet they wont come | 18:54 |
| freemangordon | why? | 18:54 |
| uvos | it will only come once | 18:54 |
| uvos | there is only one solution: | 18:54 |
| uvos | remove the code from mce, and add it to upower | 18:54 |
| uvos | the real issue here is | 18:54 |
| uvos | that the ui and mce take the values from upower | 18:54 |
| uvos | and chaingn something in mce (like how low is determined) dosent affect the ui | 18:55 |
| freemangordon | again, it is not about the low but about shutdown | 18:55 |
| freemangordon | and this is decided in mce | 18:55 |
| uvos | yes but thats not the root issue | 18:55 |
| uvos | so really mce should just shutdown when upower sais battery is ciritcal | 18:56 |
| uvos | and the ui should notify when upower sais low | 18:56 |
| freemangordon | agree | 18:56 |
| uvos | so we messed with mce to change when critical is | 18:56 |
| uvos | but thats bad | 18:56 |
| freemangordon | that's what I am trying to say all the time | 18:56 |
| uvos | because it dosent move low and it dosent move critical for other upower clients | 18:56 |
| uvos | the solution is not to make mce "smarter" | 18:57 |
| uvos | but to add config options to upower | 18:57 |
| uvos | to define low and critical other than what the kernel sais | 18:57 |
| freemangordon | which we have to support, no? | 18:57 |
| freemangordon | upower patches I mean | 18:57 |
| uvos | not sure what you mean by support | 18:57 |
| uvos | we have to write upower patches | 18:57 |
| uvos | yes | 18:57 |
| uvos | we have plenty of those allready..... | 18:57 |
| freemangordon | well, whatever the solution is, the current behaviour is not ok | 18:59 |
| freemangordon | I'll think about that a bit more | 19:00 |
| uvos | well the only way to solve it is to change A: kernel, but we dont want to do that or B: upower | 19:00 |
| uvos | and changing upower would involve adding a udev var that it checks for a low voltage threshold for critical | 19:00 |
| uvos | and antoher for low | 19:00 |
| freemangordon | or simply lowering the current mce threshold a bit | 19:01 |
| uvos | no | 19:01 |
| freemangordon | I think current value is too conservative | 19:01 |
| uvos | that dosent solve the issue at all | 19:01 |
| uvos | even if the value is too converative ( i strongly dissagree ) | 19:01 |
| freemangordon | ok | 19:01 |
| uvos | the issue is that the distance between low and cirictcal is not constant | 19:02 |
| freemangordon | who is going to implement the code in upower? | 19:02 |
| uvos | ugh, im not to bothered by current behavior xD | 19:02 |
| freemangordon | but your users are | 19:02 |
| uvos | heh | 19:04 |
| uvos | well idk - not right now make an issue is what i say to that | 19:05 |
| norayr | floks, i agree with uvos. even now d4 is problematic. i recently found myself preparing special wires and connecting my phone to my friends' phone in other town because there was no way to charge it. i revived it, luckily, gave it enough charge from my battery so that it would start and charge itself. | 22:45 |
| norayr | it sdould preserve even more charge when shutting down. | 22:45 |
| norayr | not less. | 22:45 |
| norayr | many people won't be able to care about the phone rike it is tamagocci. | 22:45 |
| norayr | the phone should care about itself y shutting itself down earlier and preserving enough charge to boot a le of times. | 22:46 |
| norayr | a couple of times. | 22:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!