| 00:01.48 | *** join/#maemo-ssu Woody14619a (~Woody@2620:4:4000:11:e835:757c:1fd1:ddff) |
| 00:01.48 | *** join/#maemo-ssu Woody14619a (~Woody@Maemo/community/contributor/Woody14619) |
| 03:10.20 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 04:03.40 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 05:36.15 | *** join/#maemo-ssu M13 (~M13@170.133-224-87.telenet.ru) |
| 06:54.14 | *** join/#maemo-ssu kolp (~quassel@212.255.229.148) |
| 07:13.53 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 07:14.07 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 07:24.40 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 08:36.53 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 08:42.58 | *** join/#maemo-ssu futpib (~futpib@89.106.197.47) |
| 08:44.23 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 08:46.48 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 09:13.15 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2900B.dip0.t-ipconnect.de) |
| 09:22.07 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 09:32.24 | freemangordon | merlin1991: what is the problem with CSSU repos (if any) and who is aware of it? |
| 09:39.40 | Pali | merlin1991: on my hdd is for a long time new git repository for fmtx-middleware which contains patched fmtxd. If you create git repo on gitorious I can push it here |
| 09:42.33 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 09:44.38 | Pali | merlin1991: I have git repo for sudo with two debian patches for our maemo sudo version (1.6.8p12) and patch which use su for gainroot instead sh |
| 09:45.40 | *** join/#maemo-ssu Mihanizat0r (~M13@170.133-224-87.telenet.ru) |
| 09:47.45 | Pali | freemangordon, are you going to create packages for 720p video playback? |
| 09:47.55 | Pali | with needed libraries & hd codecs? |
| 09:52.35 | freemangordon | Pali: honestly, I won;t write one more line of code until all this mess is fixed. And when it is fixed I'll decide what to do, based on the "fix" |
| 09:53.02 | freemangordon | all this "my penis is longer" stuff is starting to play on my nevers |
| 09:53.06 | freemangordon | *nerves |
| 09:56.03 | *** join/#maemo-ssu arcean (~arcean@aacv198.neoplus.adsl.tpnet.pl) |
| 10:15.56 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 10:26.44 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 10:40.46 | Estel_ | freemangordon, feel free to bash me if I'm asking about obvious things, but by "mess" you mean cssu main repos not working, or some deeper problem with cssu? |
| 10:42.02 | Estel_ | asking, because I can't relate the former to "longer penis", thus feeling about more general problems. But wouldn't like to get wrong impression or unjustified assumptions |
| 10:43.49 | Pali | Estel_, hi, can you repeat your problem with bme replacement? |
| 10:44.14 | Estel_ | Pali, sure |
| 10:45.46 | Estel_ | the thing is that this unfixed problem with device not calibrating have more serious consequences than expected, lemme dig what I've exactly written |
| 10:48.41 | Estel_ | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-03-20.log.html#t2013-03-20T00:39:00 |
| 10:48.45 | Estel_ | Pali^ |
| 10:49.38 | Estel_ | Estel_mixing it all up, due to unfixed edv1 shutdown bug and shutting down on modprobe -r of bq27x00_battery and rx51_battery, it means installing bme replacement = no calibration ever, no battery indication ever, no charging indication ever |
| 10:49.56 | Estel_ | Estel_mixing it all up, due to unfixed edv1 shutdown bug and shutting down on modprobe -r of bq27x00_battery and rx51_battery, it means installing bme replacement = no calibration ever, no battery indication ever, no charging indication ever |
| 10:50.00 | Estel_ | sry echo |
| 10:50.10 | Estel_ | Estel_Pali, not complaining, just trying to show you how serious this bugs are in practice |
| 10:50.23 | Estel_ | Estel_thanks for your work, and hope for fix soon ;) |
| 10:50.29 | Estel_ | thats pretty sums it up ;) |
| 10:51.40 | Estel_ | Pali, when you finish reading, I'm here to explain if anything is not clear, also, tell me when you finish, as I got another thing related to bme replacement, unrelated to problem mentioned above |
| 10:52.01 | Pali | problem with battery empty shutdown and maximal/design capacity --> I think we already talked about it --> write wiki page with possible solutions... |
| 10:52.23 | Pali | next, there is shutdown on modprobe -r bq27x00_battery? |
| 10:52.55 | Pali | who shutdown device? hald-addon-bme --> dsme? lifeguard, kernel oops? |
| 10:53.11 | Pali | modprobe -r rx51_battery also shutdown device? |
| 10:53.45 | Pali | new hald-addon-bme should work without that two drivers without problem and also support hotplug of that drivers |
| 10:54.26 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 10:55.26 | Estel_ | Pali, no no, wait |
| 10:55.49 | Estel_ | shutdown is *only* if *both* rx51_battery *and* bq27x00_battery is removed |
| 10:55.57 | Estel_ | I can safely remove one or another |
| 10:56.35 | Estel_ | but when both are removed, and bme repl. isn't feed voltage data from anywhere, device shutdowns about ~30 sec |
| 10:56.45 | Estel_ | s/about/ in about/ |
| 10:57.20 | Estel_ | no idea who shuts it down, where to looks for guilty? /var/log/syslog haven't contained anything useful |
| 10:57.51 | Estel_ | as for wiki page it is already created, I've sent it to you, wait a second |
| 10:58.00 | Estel_ | it's just a stub, but should do for now |
| 10:58.50 | Pali | Estel_, try to stop HAL and check if removing both drivers still shutdown device |
| 10:59.01 | Pali | sudo stop hal && sudo /etc/init.d/hal stop |
| 10:59.07 | Pali | ps auxf | grep hal |
| 10:59.38 | Estel_ | OK, will do it in a minute, need to dig up that wiki link and send it to you, OK? after that I'll try stopping hal |
| 10:59.44 | Pali | starting HAL again not working always, but you can try: sudo start hal |
| 10:59.51 | Pali | but better is to reboot device |
| 11:00.06 | Pali | ok |
| 11:01.31 | Pali | Estel_, also syslog could be usefull |
| 11:03.42 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 11:05.31 | *** join/#maemo-ssu kolp_ (~quassel@212.255.229.148) |
| 11:05.45 | *** join/#maemo-ssu arcean (~arcean@aacv198.neoplus.adsl.tpnet.pl) |
| 11:06.56 | *** join/#maemo-ssu Sc0rpius (~naikel@190.79.197.57) |
| 11:06.57 | *** join/#maemo-ssu Raimu-Z (~raimu@kameli.net) |
| 11:42.14 | Estel_ | Pali, loook here: |
| 11:42.16 | Estel_ | http://wiki.maemo.org/Bme_replacement |
| 11:43.14 | Estel_ | [General notice] all bme-replacement users, or ones that are interested in trying it - please use above page for mentioning problems, and proposing solutions, it's method preffered by Pali over IRC reports |
| 11:43.47 | Estel_ | Pali, sorry it took a while, decided to re-fine page a little, so it's easier to read and less stub-like |
| 11:43.59 | Pali | ok |
| 11:44.24 | Estel_ | still, some things are missing, marked by < > - like minimal kernel version - please fill when possible |
| 11:44.40 | Estel_ | Pali, ok, going to problems, so, I'm trying to stop hal now |
| 11:44.57 | Pali | Estel_, bme replacement using edv1 flag (not voltage) if it is exported by kernel |
| 11:45.08 | Pali | if not then fallback to edv1 voltage |
| 11:45.18 | Estel_ | just a question - remind me, only those two modules (bq27x00_battery and rx51_battery) feed voltage data to bme replacement? |
| 11:45.26 | Estel_ | Pali, hm |
| 11:45.38 | Estel_ | sounds OK, but how to check if it's exported? |
| 11:45.46 | Estel_ | before it happens? |
| 11:45.53 | Pali | Estel_, yes |
| 11:46.10 | Estel_ | also, I would fallback to 3150 mV, if not exported |
| 11:46.12 | Pali | Estel_, maemo kernel-power exporing them via registers file |
| 11:46.17 | Estel_ | OK |
| 11:46.32 | Estel_ | but, I would fallback to lower value, to still give 90% chance for calibration |
| 11:47.42 | Estel_ | 3150 mV shouldn't cause problems with GSM on devices, where 3248 mV haven't caused it already. It doesn't guarantee calibration, as it might be low voltage spike, but chances are higher, than at edv1 voltage, when chances are 0% :P |
| 11:47.56 | Estel_ | also, it's just a fallback |
| 11:48.02 | Estel_ | sounds ok, Pali? |
| 11:48.14 | Pali | hm, sounds good |
| 11:48.27 | Pali | write to wiki page, so we will not loose this info |
| 11:48.46 | Estel_ | aaaah, btw, when to shutdown after edv1 flag without a fallback? instantly, or 2 or 3 seconds later, just in case? |
| 11:48.49 | Estel_ | OK |
| 11:52.00 | Estel_ | Pali, bme replacement require kernel-power as a whole? |
| 11:52.16 | Estel_ | due to bq2415x_charger etc? |
| 11:52.32 | Estel_ | (if not I'll fix it in wiki, also) |
| 11:52.41 | Pali | Estel_, kernel which provides bq2415x_charger, bq27x00_battery and rx51_battery drivers |
| 11:53.03 | Estel_ | so why we need fallback? If kernel provides that, it also exports edv1 flag |
| 11:53.25 | Pali | and which has glue between bq2415x_charger and monolitic musb driver |
| 11:53.50 | Estel_ | so in practice, it means "it needs kernel power" as only kp provide that |
| 11:53.56 | Pali | Estel_, I wrote hal-addon-bme to work also with some other upstream versions of bq27x00_battery driver |
| 11:54.35 | Estel_ | I see, but no such thing available for maemo, anyway, in practice? |
| 11:54.43 | Pali | but with last kernel power it has access to EDV1 flag |
| 11:54.47 | Pali | Estel_, yes |
| 11:54.50 | Estel_ | but it is for future, understood |
| 11:55.08 | Estel_ | Pali, when we are at it - doesn't bq2415x_charger feed voltage data, too? |
| 11:55.20 | Estel_ | when testing hal, shouldn't it modprobe -r it too? |
| 11:55.50 | Pali | bq2415x does not provide any voltage data |
| 11:55.53 | Estel_ | OK |
| 11:56.05 | Estel_ | so let me fix wiki first, then I'll proceed to testing it |
| 11:57.07 | Estel_ | Pali, as im fixing wiki - where exactly can we read about edv1 flag being set, using kernel-power? |
| 11:57.48 | Estel_ | also, which is oldest kp version tha fulfill bme replacement requiments? |
| 11:57.56 | Pali | hald-addon-bme can read bq27 EDV1 flag from some new kernel-power |
| 11:58.15 | Pali | I think you need kp52 for BME replacement |
| 11:58.18 | Estel_ | user/root can read it too, somehow? |
| 11:58.21 | Estel_ | OK |
| 11:58.27 | Pali | normal user can read it too |
| 11:58.33 | Estel_ | address? |
| 11:58.50 | Estel_ | I wan't to put that info on wiki too, as it's now a <placeholder> |
| 11:58.51 | Pali | cat /sys/class/power_supply/bq27200*something/registers |
| 11:58.55 | Estel_ | thanks |
| 11:59.01 | Pali | look at n900 for correct file path |
| 11:59.09 | Estel_ | ok |
| 11:59.19 | Estel_ | goes to feed wiki with new data |
| 11:59.21 | Pali | EDV1 is one bit in some register |
| 11:59.26 | Pali | in that file |
| 11:59.30 | Estel_ | yes, yes, I know that file |
| 11:59.41 | Pali | but I do not remember, look into datasheet or bme replacement code |
| 12:01.44 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 12:02.11 | Pali | Estel_, ping kerio about wiki page and ideas about max/design capacity |
| 12:02.30 | Estel_ | yea, planned to do that, too |
| 12:08.39 | kerio | i just can't fathom *why* should *anything* care for any reason about the capacity the battery is designed for as opposed to the capacity the battery /has/ now |
| 12:10.37 | Estel_ | kerio, because bq27x00 reports "nothing" (not even 0), as max capacity, when not calibrated |
| 12:10.51 | Estel_ | kerio, but we had a good solution idea already, remember? |
| 12:10.58 | kerio | that's sensible actually |
| 12:11.16 | kerio | (but the data should be accessible from somewhere else - and not the registers, come on, i want something simpler) |
| 12:11.23 | Estel_ | you were too lazy to write it to wiki, so recall it now, as i dont remember |
| 12:11.29 | Estel_ | so what applet should show? |
| 12:11.30 | kerio | i was about to ask you |
| 12:11.39 | kerio | i'd say it should show nothing |
| 12:11.43 | Estel_ | when 0 data from capacity? |
| 12:11.49 | Estel_ | 0/0 is bad idea |
| 12:11.57 | Estel_ | it also confuses charging idnicator |
| 12:12.18 | Estel_ | it shows green diode 5 sec after plugging charger, despite charging going on full ampere |
| 12:12.43 | Estel_ | it should show smth like "please calibrate" |
| 12:12.55 | kerio | what controls the led? hald or the battery applet? |
| 12:13.11 | Estel_ | in place of regular 700/1350, should be Unknown/please calibrate |
| 12:13.13 | Estel_ | ask Pali |
| 12:13.19 | Estel_ | led, po0-up banner |
| 12:13.30 | Estel_ | it also shows "charging full" as banner |
| 12:13.36 | kerio | i think led is hald and banner is applet |
| 12:13.56 | kerio | so |
| 12:14.06 | Estel_ | for some reasons, using your modification of applet when battery not calibrated results in such werido |
| 12:14.20 | kerio | 1) the battery applet, and every other maemo battery thing, should be able to work with only hald-provided info |
| 12:14.36 | Estel_ | and using pali's result in other werido, green led when design capacity reached, despite that real capacity is triple as much |
| 12:15.43 | kerio | 2) instead of showing wildly inaccurate data, it's preferrable to show nothing, or a message indicating that data is unavailable |
| 12:16.17 | kerio | 3) fuck rx51-battery, given 2) there's no reason whatsoever to use it (except the temperature thing, but that's for dsme and pulseaudio, not for the battery/charging) |
| 12:17.29 | kerio | 4) bq27200 is our lord, bq27200 is our ruler, bq27200 is our saviour - when calibrated, /everything/ should be grabbed from bq27200 and that's it - percentages, capacity (when full and at the moment) |
| 12:18.57 | kerio | 5) shutting down at EDV1 flag set could be good, but there might be a script that's doing the calibration, so it could decide to wait for that flag and turn the charging back on |
| 12:18.59 | kerio | for example |
| 12:19.13 | kerio | it's not that my calibration script does precisely that, honest |
| 12:19.30 | kerio | so... idk, maybe add a way to disable the automatic shutdown |
| 12:19.43 | kerio | but shutting down once EDV1 *flag* is set is a good idea, imo |
| 12:19.49 | kerio | shutting down at EDVF is too late |
| 12:22.09 | ShadowJK | Even at edv1 it's a bit so-so whether my battery would have enough for clean shutdown :) |
| 12:23.09 | kerio | ShadowJK: really? :s |
| 12:23.16 | kerio | it's supposed to be 6% of the battery |
| 12:23.45 | ShadowJK | That is only true for one specific battery that's no longer sold |
| 12:23.57 | kerio | it's more, nowadays! |
| 12:24.03 | kerio | jests |
| 12:24.05 | ShadowJK | less |
| 12:24.23 | ShadowJK | also more worn batts will have it higher than when new |
| 12:24.44 | kerio | ShadowJK: it's kinda hard to figure out something like that via software, when polling :( |
| 12:25.32 | ShadowJK | sure, I'm just saying the eeprom constants are wrong |
| 12:25.56 | DocScrutinizer05 | *why* does >> bq27x00 reports "nothing" (not even 0), as max capacity, when not calibrated<<? |
| 12:26.36 | kerio | ask Pali |
| 12:26.41 | DocScrutinizer05 | there's ILMD in bq27x00 that kicks in on reset of chip, and without reset the LMD sticks |
| 12:26.50 | DocScrutinizer05 | even when CI=1 |
| 12:27.21 | kerio | you get a read error from the sysfs nodes when CI=1 |
| 12:27.35 | kerio | the ones that give you numerical data |
| 12:27.39 | DocScrutinizer05 | so I honestly can't see why bq27200.ko wouldn't report anything for max capacity any time or any situation |
| 12:28.12 | kerio | it definetely could, but it doesn't |
| 12:29.46 | DocScrutinizer05 | kerio: that's broken in so many ways |
| 12:29.48 | DocScrutinizer05 | it's unlogical, clumsy, useless, and violating the general design rules for device drivers |
| 12:31.20 | DocScrutinizer05 | the chip delivers a (rather meaningful and somewhat correct) value for LMD, so why THE HECK would the device driver fail on reading that value? |
| 12:32.33 | kerio | probably for the same reason rx51-battery design capacity is used, instead of any meaningful value |
| 12:32.36 | kerio | so users won't get confused |
| 12:34.56 | DocScrutinizer05 | user won't get confused??? LOL |
| 12:36.07 | Estel_ | Pali, could you answer it? I also think it's wrong that sysfs node doesn't report anything, when uncalibrated |
| 12:36.41 | Estel_ | I break 3rd party things (bq27200.sh, BNF), it's confusing, and... well, just wrong |
| 12:36.47 | DocScrutinizer05 | a sysfs node is supposed to *always* faithfully report what a hw item delivered |
| 12:36.57 | Estel_ | If no reason to keep it that way, I would propose change on wiki |
| 12:37.03 | Estel_ | agreed |
| 12:37.27 | Estel_ | ~pali |
| 12:37.27 | infobot | somebody said pali was http://atrey.karlin.mff.cuni.cz/~pali/ |
| 12:38.47 | DocScrutinizer05 | if you want a friggin notification about "state uncalibrated" in battery applet, then you need battery applet to look at CI in sysfs |
| 12:38.58 | Estel_ | kerio, could you describe current problem on wiki? |
| 12:39.13 | kerio | DocScrutinizer05: CI is in sysfs |
| 12:39.18 | kerio | somewhere in registers :s |
| 12:39.19 | DocScrutinizer05 | *NOT* make readout of LMD fail with a read error! how silly is THAT? |
| 12:39.34 | Estel_ | DocScrutinizer05, could you update wiki problem 2 with rationale, why bq27x00 shouldn't fail to reports via sysfs node, when uncalibrated? |
| 12:40.22 | Estel_ | kerio will provide problem description, and in proposed solutions, please elaborate why bq27x00_battery should be fixed, to not fail with read error (as it's exactly what it's happening) |
| 12:40.29 | Estel_ | DocScrutinizer05, ^ |
| 12:40.49 | Estel_ | (you can write solution, withut waiting for problem description to appear) |
| 12:41.00 | Estel_ | http://wiki.maemo.org/Bme_replacement#Prerequisities |
| 12:41.03 | Estel_ | sry |
| 12:41.06 | Estel_ | sryhttp://wiki.maemo.org/Bme_replacement |
| 12:41.11 | Estel_ | damnit! |
| 12:41.22 | Estel_ | http://wiki.maemo.org/Bme_replacement |
| 12:41.27 | Estel_ | ^that is correct link |
| 12:42.18 | DocScrutinizer05 | an alternative I recently came up with, to notify user about CI=1 was to report only impair values for LMD etc, like 1001, 45, when CI-=0, but only nnn0 values (last digit always "0") when CI=1 |
| 12:42.45 | Estel_ | please, write proposed solutions on wiki, it will get lost on irc |
| 12:42.55 | Estel_ | we discussed it already once, and it was forgotten |
| 12:43.10 | Estel_ | I spend last two hours refinning wiki for a purpose :P |
| 12:43.10 | kerio | DocScrutinizer05: that would be silly |
| 12:43.21 | DocScrutinizer05 | would add a systemic error to reading of +- 1 least significant digit |
| 12:43.31 | kerio | this is not an 80's arcade machine |
| 12:44.04 | Estel_ | I think reporting "valu innacurate/please calibrate" in battery applet is enough |
| 12:44.06 | kerio | using the least significant digit to count continues is a neat trick, but we have a lot more resources on a n900 |
| 12:44.23 | Estel_ | s/valu/value/ |
| 12:44.35 | DocScrutinizer05 | kerio: user could specify whether to use or not this notification sheme, with a kernel module loadtime parameter |
| 12:44.42 | Estel_ | but do realize guys, that nothing will happen, if it won't land on wiki |
| 12:45.04 | kerio | DocScrutinizer05: or we could just provide a damn node that tells us if CI is set or not |
| 12:45.21 | DocScrutinizer05 | sure, that's mandatory anyway |
| 12:45.40 | DocScrutinizer05 | alas battery applet doesn't usually look for such sysnode |
| 12:46.44 | Estel_ | no need for new node, it is already exported |
| 12:46.46 | DocScrutinizer05 | my botch was a way to transport some aditional info inband (I.E. with existing unaltered apps), at the expense of sacrificing a LSB/D of accuracy in the original value |
| 12:46.49 | Estel_ | via node "registers" |
| 12:47.26 | Estel_ | examples of how to properly use bits from registers from userland are in BNF, for example |
| 12:47.36 | DocScrutinizer05 | a proper comprehensive decently designed device driver should decode all status bits and expose them verbatim |
| 12:47.51 | Estel_ | well, I see nothing wrong in that, either |
| 12:47.59 | Estel_ | -> wiki, please |
| 12:49.32 | kerio | DocScrutinizer05: fwiw it wouldn't be sacrificing anything, the values in the sysfs nodes have 3 digits more than they should |
| 12:49.50 | kerio | they're all micro-, and bq27200 provides milli- |
| 12:50.13 | DocScrutinizer05 | kerio: that been my original approach, but I was too lazy to check |
| 12:50.40 | DocScrutinizer05 | actually bq27x00 doesn't provide milli either |
| 12:51.19 | DocScrutinizer05 | it provides a uVh/Rs unit that needs conversion prior to displaing/exporting it |
| 12:52.28 | DocScrutinizer05 | and Rs should default to 22mR but should be able to get overridded by kernel module load paramater (again) |
| 12:52.50 | kerio | what's that R supposed to be? |
| 12:53.04 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 12:53.14 | DocScrutinizer05 | like modprobe bq27x00.ko notify-CI-in-last-digit=true,rs=24 |
| 12:53.57 | DocScrutinizer05 | R is 20 or 22 in all devices we tested so far |
| 12:54.17 | DocScrutinizer05 | but could differ vastly for other hw platforms using bq27x00 |
| 12:54.55 | kerio | yeah but what is it supposed to be? |
| 12:54.58 | kerio | how do you measure it? |
| 12:55.08 | DocScrutinizer05 | see *my* bq27200.sh script, at http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27200.sh |
| 12:55.33 | DocScrutinizer05 | kerio: you measure it between battery GND and general system GND |
| 12:56.24 | Estel_ | you measure it by hand, or something measure it inside device and give output for reading? |
| 12:57.37 | ShadowJK | Someone with a jig reported 21 too |
| 12:58.28 | DocScrutinizer05 | there's no way to measure that on-board, since it's one of the parts that other measurements are based on. So it's kinda of an axiom in hw |
| 13:02.46 | Estel_ | DocScrutinizer05, so what difference in your bq27200.sh and ShadowJK's one, which just provide that value? |
| 13:03.01 | Estel_ | it seems you provide it too, just using another calculation? |
| 13:03.45 | ShadowJK | I use 21 |
| 13:03.53 | kerio | if some have 20 and some have 22, i guess 21 is close enough for both |
| 13:03.59 | Estel_ | btw I hope you all realize that without updating wiki, you're just claping jaw (fingers) to no use, as Pali won't go through those 7656787678 lines of irc? |
| 13:04.12 | Estel_ | well, I use 21 too |
| 13:04.34 | ShadowJK | for some uses 20 seems to fit better for me |
| 13:04.47 | Estel_ | he will gladly and quickly fix those things, but need info on wiki |
| 13:31.16 | *** join/#maemo-ssu M13 (~M13@87.224.133.170) |
| 13:36.58 | DocScrutinizer05 | # Assuming 30 mOhm sense resistance |
| 13:37.00 | DocScrutinizer05 | RS=${RS:-22} |
| 13:37.21 | DocScrutinizer05 | RS=99 bq27200.sh |
| 13:38.57 | DocScrutinizer05 | echo "LOOPMODE=$LOOPMODE RS=$RS" |
| 13:48.41 | *** join/#maemo-ssu PaulFertser (paul@2001:470:26:54b:250:70ff:fee7:41ec) |
| 13:49.25 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 13:51.16 | PaulFertser | Pali: hi :) I know you're doing upstreaming work for rx-51, sounds great. I remember back in 2.6.35 days there were some serious issues with power-saving, are they resolved by now, is upstream kernel as good as maemo's fork was? |
| 13:52.51 | Pali | PaulFertser, hi, I do not know if power-saving is fixed now, but I'm sure it is not good as in maemo 2.6.28 kernel |
| 13:53.14 | DocScrutinizer05 | Pali: what would be missing? |
| 13:53.15 | Pali | Skry, what do you think? ^ |
| 13:53.21 | Skry | I can confirm |
| 13:53.27 | PaulFertser | Oh :( |
| 13:53.30 | PaulFertser | What's missing? |
| 13:53.37 | Skry | voltage scaling |
| 13:53.55 | DocScrutinizer05 | meh, shouldn't that be done by SR meanwhile ;-P |
| 13:53.58 | Skry | smartreflex |
| 13:54.17 | PaulFertser | I thought TI engineers did the right thing with their omap tree, what happened? |
| 13:54.19 | Pali | DocScrutinizer05, now in some 3.x there is smartreflex driver |
| 13:54.27 | DocScrutinizer05 | I couldn't think of TI not upstreaming SR |
| 13:54.40 | Pali | SR is upstreamed |
| 13:54.49 | DocScrutinizer05 | thought as much |
| 13:55.16 | Skry | I actually don't know how much sr is supposed to save power, enabling it with 3.5 does show some saving in powertop but I'm not sure how to interpret its readings |
| 13:55.22 | DocScrutinizer05 | that SR is still tagged "deprecated" on N900 is another thing, that obviously doesn't matter to anybody |
| 13:55.36 | Pali | I have semi/non-working maemo with upstream kernel |
| 13:55.53 | DocScrutinizer05 | Skry: powertop has zero info about savings |
| 13:55.53 | Pali | for unknown reason, mce and hal eats 100% cpu always |
| 13:55.57 | PaulFertser | But what about DVFS? |
| 13:56.09 | DocScrutinizer05 | it just reports C-states and frequencies |
| 13:56.19 | ShadowJK | I'd think sr would make no difference in powertop? |
| 13:56.42 | DocScrutinizer05 | ShadowJK: exactly my words ;-) |
| 13:56.49 | PaulFertser | Skry: do you mean DVFS is still not implemented at all? |
| 13:57.01 | DocScrutinizer05 | ~dvfs |
| 13:57.11 | DocScrutinizer05 | ~wiki dvfs |
| 13:57.40 | Pali | dvfs in in upstream since 3.2: https://lwn.net/Articles/460973/ |
| 13:57.53 | Pali | but I do not know if there is omap driver |
| 13:57.57 | PaulFertser | I think it means that some internal regulator's voltages are automatically adjusted based on the current cpufreq state, right? |
| 13:58.34 | Skry | DocScrutinizer05, ShadowJK, well, looking at powertop currently running, it reads "The Battery reports a discharge rate of 560mW", if it's bogus or not, I do not know. |
| 13:58.48 | DocScrutinizer05 | PaulFertser: in maemo stock kernel all that scaling is done in software since SR been considered instable. Now it seems everybody and his dog uses SR *in parallel* to the sw-driven scaling, and reports giant power savings ;-P |
| 13:59.01 | *** join/#maemo-ssu kolp (~quassel@212.255.229.148) |
| 13:59.13 | DocScrutinizer05 | Skry: wtf which powertop you got there? |
| 13:59.31 | PaulFertser | DocScrutinizer05: so the upstream should run using less power, not more :) And Pali says maemo's kernel still wins, how so? |
| 13:59.32 | Pali | status of n900 kernel is here: http://elinux.org/N900 |
| 13:59.39 | PaulFertser | Yes |
| 13:59.48 | PaulFertser | Pali: thank you for keeping that page up-to-date btw |
| 14:00.07 | Skry | DocScrutinizer05: 2.2, not on Maemo |
| 14:00.40 | DocScrutinizer05 | Skry: hm? |
| 14:01.17 | DocScrutinizer05 | PaulFertser: no, running SR inparallel to sw-driven scaling will reduce in slight data transfer overhead and nothing else |
| 14:02.37 | PaulFertser | I see :) |
| 14:03.40 | DocScrutinizer05 | PaulFertser: the TPS65950 companion chip with all the power regulators has a "general purpose" I2C bus which sw-driven scaling uses to adjust core voltages, and it has a dedicated SmartReflex-I2C where CPU does automatic adjusting of core voltages according to some tables in SoC and CPU-clock set |
| 14:04.17 | DocScrutinizer05 | only when enabled, the latter |
| 14:04.39 | DocScrutinizer05 | guys claiming they use SR only enable the latter, while not disabling the former |
| 14:04.45 | DocScrutinizer05 | afaik |
| 14:05.34 | DocScrutinizer05 | there's a sysnode in powerkernel that allows enabling/disabling the dedicated SR voltage adjustment via the dedicated I2C |
| 14:06.49 | Pali | Skry, is front n900 camera working on your arch? |
| 14:07.13 | DocScrutinizer05 | but honestly CPU is supposed to spend most time in zeroclock and not eating much power at all, no matter which "scaling", and when it runs it's normally in C0 and there's no scaling happening either. So the whole SR thing is rather marginal |
| 14:07.43 | Skry | Pali: nope, module loading fails. I only tested with 3.5 so can't say for sure how it's with upstream kernel |
| 14:08.08 | Skry | Pali: wait a second, I'll boot to 3.9 and recheck |
| 14:08.14 | DocScrutinizer05 | errr, front and main cam share same interface |
| 14:08.25 | DocScrutinizer05 | only multiplexed by a switch |
| 14:08.31 | Pali | Skry, ok, try that smiapp driver |
| 14:08.31 | ShadowJK | voltage scaling would be relevant for running at not-600, like mp3 playback at 250 |
| 14:08.43 | DocScrutinizer05 | :nod: |
| 14:08.50 | Pali | DocScrutinizer05, problem is that in upstream kernel there is only driver for front webcam |
| 14:09.12 | DocScrutinizer05 | oooh, so *no* driver works |
| 14:09.19 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 14:09.30 | DocScrutinizer05 | why not port forward the fcam drivers then? |
| 14:09.43 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 14:10.07 | Pali | DocScrutinizer05, I tried to port forward camera drivers from meego (which was port forwared from maemo kernel) |
| 14:10.17 | Pali | but not working... |
| 14:10.18 | DocScrutinizer05 | hehe |
| 14:10.22 | DocScrutinizer05 | :-/ |
| 14:11.00 | Pali | then I found that new camera driver (which should work with n900 front webcam) was upstreamed |
| 14:11.18 | Pali | so I'm trying to write board code for that driver |
| 14:11.32 | ShadowJK | need the thing that tells mux to switch to frontcam too, before anything tries to access frontcam |
| 14:11.54 | Pali | ShadowJK, that part of board code |
| 14:13.04 | Pali | btw, seems that my ansi bootmenu uboot code will be upstreamed |
| 14:13.38 | Pali | so upstream uboot will have anything needed for user frendly n900 booting... |
| 14:15.54 | DocScrutinizer05 | (SR) btw it seems I recall somebody (fmg) claiming that stock maemo kernel doesn't even do sw-driven core voltage scaling |
| 14:16.42 | DocScrutinizer05 | I'm not sure about a) if I correctly recall that claim, and b) if it's been correct claim to start with |
| 14:17.11 | DocScrutinizer05 | (fmg?) |
| 14:19.28 | ShadowJK | the whole point of dropping to a lower frequency is that you can run at less voltage and consume less power :/ |
| 14:20.43 | DocScrutinizer05 | hehehehe, indeed, that's why I can't believe Nokia implemented freq scaling without voltage scaling |
| 14:21.14 | ShadowJK | it'd be like s3c, heh |
| 14:21.27 | DocScrutinizer05 | LOL |
| 14:21.40 | DocScrutinizer05 | gnnhnnhnhnhrrhrrrhrrrr |
| 14:22.10 | DocScrutinizer05 | long live GTA02 \o/ |
| 14:22.47 | DocScrutinizer05 | well, we *had* to use that SoC since it been the only one where tech manual been publicly available |
| 14:23.01 | DocScrutinizer05 | when OM started |
| 14:23.52 | DocScrutinizer05 | raster and me pushed for better CPUs/SoCs quite several times, but with little success |
| 14:25.19 | DocScrutinizer05 | instead for gta03 the s3c6400 or whatever been picked |
| 14:25.39 | discopig | hi |
| 14:35.38 | *** join/#maemo-ssu arcean_ (~arcean@aaem235.neoplus.adsl.tpnet.pl) |
| 14:40.31 | kerio | DocScrutinizer05: the gta04 is pretty much a n900, right? |
| 14:40.57 | kerio | omap3 |
| 15:14.11 | DocScrutinizer05 | yup |
| 15:14.19 | DocScrutinizer05 | kinda |
| 15:21.19 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 15:21.36 | freemangordon | DocScrutinizer05: I am starting to think you have NFC what is SR and how it works. The only thing you need to do from kernel side in Maemo kernel, is to load some values and let the HW do it's job. CPU DOES NOT touch voltage regulators once voltage for the particular OPP is set up. It is HW that communicates with power regulator and tweaks the voltage based on some parameters |
| 15:21.40 | ShadowJK | i guess if you started today you'd use an Allwinner chip |
| 15:22.17 | kerio | a what |
| 15:22.36 | freemangordon | and those parameters are device specific, that is why you have different power savings for different devices |
| 15:24.05 | freemangordon | There is so-called SW SR, but it is not used in Maemo kernel, iirc harmattan kernel uses it (SR 1.5) |
| 15:24.44 | DocScrutinizer05 | freemangordon: I'm starting to think you should read twice my statements before you bitch at me. It's *exactly* what I wrote |
| 15:29.28 | ShadowJK | kerio: allwinner is a chinese chip maker, allegedly they have docs |
| 15:29.45 | ShadowJK | many of the cheap china tablets have them |
| 15:35.05 | Estel_ | ~bme-replacement |
| 15:35.05 | infobot | i guess bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:36.01 | Estel_ | ~factinfo bme-replacement |
| 15:36.01 | infobot | error: you do not have enough flags for that. (o required) |
| 15:36.01 | infobot | bme-replacement -- created by Pali <~pali@Maemo/community/contributor/Pali> at Sat Feb 23 14:58:19 2013 (29 days). |
| 15:36.26 | Estel_ | Pali, doesn't you have anything against me adding wiki page to bme-replacement factoid? |
| 15:36.33 | Pali | add it |
| 15:38.04 | Pali | infobot: bme-replacement is https://wiki.maemo.org/Bme_replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:38.04 | infobot | ...but bme-replacement is already something else... |
| 15:38.07 | Estel_ | infobot, no, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement. See also: http://wiki.maemo.org/Bme_replacement. Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:38.07 | infobot | Estel_: okay |
| 15:38.17 | Estel_ | olol |
| 15:38.35 | Estel_ | ~bme-replacement |
| 15:38.35 | infobot | somebody said bme-replacement was http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:38.43 | Estel_ | lol2 |
| 15:39.01 | Pali | infobot: forget bme-replacement |
| 15:39.01 | infobot | Pali: i forgot bme-replacement |
| 15:39.01 | Estel_ | infobot, no, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement. See also: http://wiki.maemo.org/Bme_replacement. Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:39.01 | infobot | Estel_: okay |
| 15:39.17 | Estel_ | infobot, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement. See also: http://wiki.maemo.org/Bme_replacement. Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:39.17 | infobot | i already had it that way, Estel_ |
| 15:39.25 | Estel_ | ~bme-replacement |
| 15:39.25 | infobot | extra, extra, read all about it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:39.31 | Estel_ | ~fu |
| 15:39.31 | infobot | FFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU- |
| 15:39.53 | Pali | infobot: forget bme-replacement |
| 15:39.53 | infobot | Pali: i forgot bme-replacement |
| 15:40.16 | DocScrutinizer05 | ~bme-replacement |
| 15:40.16 | infobot | bme-replacement is probably http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:40.27 | DocScrutinizer05 | ~literal bme-replacement |
| 15:40.27 | infobot | "#maemo bme-replacement" is "http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/" |
| 15:42.14 | Pali | infobot, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement. Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:42.14 | infobot | okay, Pali |
| 15:42.14 | Estel_ | freemangordon, haven't had time to answer my question, missed it, or ignored on purpose? |
| 15:42.24 | Pali | ~bme-replacement |
| 15:42.24 | infobot | rumour has it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:42.33 | Estel_ | ~like |
| 15:42.33 | infobot | i guess like is it a gateway or and HP or something? |
| 15:43.10 | Pali | infobot: forget bme-replacement |
| 15:43.10 | infobot | Pali: i forgot bme-replacement |
| 15:43.14 | Pali | ~bme-replacement |
| 15:43.15 | infobot | extra, extra, read all about it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/ |
| 15:43.22 | Pali | WTF? |
| 15:43.26 | Estel_ | read-only |
| 15:43.37 | DocScrutinizer05 | WTF do you ever read what others do and write in chan? |
| 15:43.44 | DocScrutinizer05 | ~literal bme-replacement |
| 15:43.44 | infobot | "#maemo bme-replacement" is "http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/" |
| 15:43.54 | DocScrutinizer05 | ~factinfo bme-replacement |
| 15:43.54 | infobot | DocScrutinizer05: there's no such factoid as bme-replacement |
| 15:44.05 | DocScrutinizer05 | ~factinfo #maemo bme-replacement |
| 15:44.05 | infobot | #maemo bme-replacement -- created by kerio <~kerio@Maemo/community/contributor/kerio> at Sat Feb 23 14:13:35 2013 (29 days); it has been requested 9 times, last by Pali, 50s ago. |
| 15:44.12 | Estel_ | infobot, forget #maemo bme-replacement |
| 15:44.12 | infobot | Estel_: i forgot #maemo bme-replacement |
| 15:44.43 | Estel_ | infobot, #maemo bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement. Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:44.43 | infobot | okay, Estel_ |
| 15:44.50 | Estel_ | ~bme-replacement |
| 15:44.50 | infobot | it has been said that bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement. Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:46.20 | DocScrutinizer05 | also note that this factid been created by kerio, but we don't want to be more religious than the pope here |
| 15:46.39 | Estel_ | DocScrutinizer05, dont't get upset, not everyone is in so intimate relations with infobot, to know cliche details about her #channel and general workings :P |
| 15:46.41 | Estel_ | hehe, right |
| 15:47.03 | kerio | i feel murderous rage because of my lost factoid |
| 15:47.25 | Estel_ | I feel murderous rage, because you haven't added bat applet problem to wiki |
| 15:47.29 | Estel_ | so it won't be fixed |
| 15:47.29 | DocScrutinizer05 | kerio: It been augmented, not lost. |
| 15:47.36 | DocScrutinizer05 | that's pretty allowable |
| 15:47.54 | kerio | my artistic integrity has been tainted by that addition |
| 15:48.19 | kerio | Estel_: which problem? |
| 15:48.32 | Estel_ | ffs |
| 15:48.47 | Estel_ | the one with using design capacity |
| 15:49.06 | Estel_ | + problem with bq27x00 not exporting sysfs nodes when not calibrated |
| 15:49.09 | Estel_ | (some of them) |
| 15:49.30 | Estel_ | pretty good argumentation on this channel was present, but it's irrelevant, as will get lost in irc time and space |
| 15:50.15 | kerio | infobot: no, #maemo bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement . Please, use wiki page to report bugs/problems and/or solutions to them! |
| 15:50.15 | infobot | kerio: okay |
| 15:50.22 | Estel_ | Pali, are you still here? |
| 15:50.31 | Estel_ | ~factinfo bme-replacement |
| 15:50.32 | infobot | error: you do not have enough flags for that. (o required) |
| 15:50.32 | infobot | there's no such factoid as bme-replacement, Estel_ |
| 15:50.44 | Estel_ | ~factinfo #maemo bme-replacement |
| 15:50.44 | infobot | error: you do not have enough flags for that. (o required) |
| 15:50.44 | infobot | #maemo bme-replacement -- created by Estel_ <~Estel@Maemo/community/contributor/Estel-> 6m 1s ago; last modified 29s ago by kerio!~kerio@Maemo/community/contributor/kerio; it has been requested once, last by Estel_, 5m 54s ago. |
| 15:50.49 | Estel_ | :P |
| 15:51.02 | Estel_ | Pali, why bq27x00 fails to export some sysnodes when not calibrated? |
| 15:51.17 | Estel_ | it gives read error, and is wrong, sysfnodes shouldn't act like that |
| 15:52.02 | Estel_ | chip, have some default value somewhere (2056) that replaces calibration info, when calibration lost, for example, due to sitting without battery inserted |
| 15:52.38 | Pali | sysfs entires are exported to upower (and also old hal) daemon and 2056 is really bad value |
| 15:52.58 | kerio | Pali: 2056 is more correct for estel than the value reported by rx51-battery |
| 15:53.12 | kerio | so we have at least one case where it's better |
| 15:53.27 | Pali | kerio, you can unload rx51 battery driver --> not use it |
| 15:53.30 | Estel_ | Pali, also, "read error" is always worse than 2056 |
| 15:53.55 | Pali | I think in function is returning -ENODATA |
| 15:54.12 | Pali | that kernel doing with -ENODATA is other question |
| 15:54.22 | Estel_ | well, 2rd party things depending on those nodes break with "aritmetic syntax error" then |
| 15:54.45 | kerio | there *is* data |
| 15:55.00 | Pali | any open() syscall can fail |
| 15:55.09 | Pali | and also any read() syscall can fail |
| 15:55.17 | Estel_ | Pali, couldn't it just report what is there, no matter if correct or not, and things from your bme replacement copnsoider it valid or not depending on CI flag? |
| 15:55.23 | Estel_ | aka "calibrated" or not? |
| 15:55.54 | Estel_ | but isn't sysfs node supposed to report religiously what hardware reports, instead of censoring it? |
| 15:56.00 | Estel_ | as kerio said, there *is* data |
| 15:56.04 | Estel_ | a default one |
| 15:56.15 | Estel_ | it makes life harder, without any gains |
| 15:56.21 | Estel_ | the way it is now |
| 15:56.38 | Estel_ | all your stuff could get same results just watching for "calibrated" flag CI |
| 15:56.53 | kerio | not only that, ILMD is still a much, much better value than the value for design battery from rx51-battery |
| 15:57.11 | DocScrutinizer05 | Pali: no, sysfs entries are not supposed to return -ENODATA when in fact there IS data |
| 15:57.20 | DocScrutinizer05 | and usually even pretty good data |
| 15:59.31 | DocScrutinizer05 | sysfs API is supposed to show ehat hw reports, not what devel censored out of it |
| 15:59.47 | Estel_ | Pali, I would add this problem to wiki, but would like to see if there is any good rationale for keeping it the way it is. It seems that there is none? No gains in keeping it -ENODATA |
| 15:59.58 | Pali | DocScrutinizer05, I'm not using sysfs api, but power supply |
| 16:00.11 | Pali | and what power supply is doing is other question... |
| 16:00.50 | DocScrutinizer05 | I don't care. It's a sysfs node and thus it's supposed to report what the chip answered, not what you think might be a nifty new idea |
| 16:01.48 | Pali | DocScrutinizer05, I do not care too :-) that api is used for notifing upower daemon which should receivce correct data |
| 16:01.53 | DocScrutinizer05 | my bq27200 wvalues are still highly accurate, despite last learning cycle is 68 and thus CI=1 |
| 16:02.12 | Pali | DocScrutinizer05, when battery is not calibrated data can be useless |
| 16:02.25 | kerio | as opposed to the currently-used data, which *is* useless all the time |
| 16:02.26 | DocScrutinizer05 | so -ENODATA is correct data??? I don't see that, not a bit |
| 16:02.50 | DocScrutinizer05 | Pali: you made that nonsense up |
| 16:04.21 | PaulFertser | I'd ask the power_supply maintainer about the correct behaviour. |
| 16:04.59 | DocScrutinizer05 | Pali: golden rule: never reduce data that's available. While you could argue -ENODATA was another way of saying "2056 and CI=1", you censored out "1044 and CI=1" |
| 16:05.27 | DocScrutinizer05 | PaulFertser: we don't talk about powersupply but about bq27200 driver |
| 16:05.57 | Pali | bq is powersupply driver |
| 16:05.59 | DocScrutinizer05 | if using power-supply API for that chip means that available data gets censored, then it's simply the wrong API |
| 16:07.14 | Estel_ | Pali, I agree that -ENODATA is always worse than innacurate data |
| 16:07.27 | PaulFertser | DocScrutinizer05: well, power_supply is established and uniform kernel framework, we were using it too on gta02. And everybody uses it now. I guess this matter you're discussing needs the opinion of the framework maintainer. |
| 16:07.28 | DocScrutinizer05 | it's always the actual hw and not the developer of a randomly picked API that defines what a driver needs to provide/support |
| 16:07.45 | Estel_ | please, fix that, as there is no reason to do otherwise. Stuff that depends on correct data may get info about corectness from CI flag (calibrated flag) |
| 16:08.02 | PaulFertser | One reason Linux is great because it provides uniform API to different hardware. |
| 16:08.13 | DocScrutinizer05 | PaulFertser: no, au conttaire, we used bq27000 API |
| 16:08.21 | DocScrutinizer05 | which even had a proper dump sysnode |
| 16:08.23 | PaulFertser | DocScrutinizer05: nope |
| 16:08.27 | Estel_ | PaulFertser, we're talking about different things |
| 16:09.03 | DocScrutinizer05 | PaulFertser: please watch http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail2 |
| 16:09.04 | Estel_ | btw, tell lennart about uniform things... |
| 16:09.14 | PaulFertser | DocScrutinizer05: http://paste.debian.net/244225/ |
| 16:09.38 | PaulFertser | DocScrutinizer05: i wrote the platform battery driver btw. And it's certainly using the power_supply API. |
| 16:10.08 | DocScrutinizer05 | I don't give a f* about which api it uses, I want it to expose all available info/data |
| 16:10.22 | PaulFertser | DocScrutinizer05: i remember that script, it's awesome. Was using direct dump of the registers. No other userspace app was using it. |
| 16:10.37 | ShadowJK | you guys are mxinig up 5 subjects and threads of conversation |
| 16:11.02 | PaulFertser | Estel_: do not you agree that we should take this conversation to the power_supply maintainer? |
| 16:11.20 | PaulFertser | Estel_: to get his opinion to understand how the framework is supposed to be used? |
| 16:11.29 | ShadowJK | But regardless, the data provided by bme replacement in a power_supply style is also not useful :) |
| 16:11.30 | DocScrutinizer05 | why? |
| 16:11.45 | Estel_ | PaulFertser, no, as Pali is maintainer for those things in maemo, and he can fix it by 2 lines of code |
| 16:11.46 | DocScrutinizer05 | hehe |
| 16:11.55 | Estel_ | PaulFertser, then, we may submit fix upstream |
| 16:12.00 | PaulFertser | I personally would prefer getting inaccurate data and a flag and then deciding myself if i can tolerate that inaccuracy. |
| 16:12.08 | Estel_ | PaulFertser, exactly |
| 16:12.14 | PaulFertser | So yes, i prefer what Estel_ suggests |
| 16:12.17 | DocScrutinizer05 | exactly |
| 16:13.15 | DocScrutinizer05 | censoring perfectly sane and accurate data just because >32 cycles since last learning cycle. That's insane |
| 16:13.38 | DocScrutinizer05 | and it doesn't work either |
| 16:13.51 | PaulFertser | Estel_: are you sure that's the way the Linux development usually happens? Afaict when there's some doubt about how to use interfaces people try to talk to the interested parties (including subsystem maintainers) to get the opinions and to come to the common solution that would be the official upstream way to do things. |
| 16:14.05 | ShadowJK | As for N900, the biggest issue is that all our datasources are bad :) |
| 16:14.22 | PaulFertser | DocScrutinizer05: agree, censoring data makes no sense at all imho |
| 16:14.39 | DocScrutinizer05 | since in larger picture of bme-replacement, that sysfs interface been meant to replace what bme been reporting to hal about batery actual capacity, and in that context a -ENODATA makes absolutely no sense |
| 16:14.45 | PaulFertser | ShadowJK: the bq chip should be pretty accurate though, don't you think so? |
| 16:15.00 | Estel_ | Pali, right, I've forget, that "uncalibrated" flag is also set when more than 32 cycles since last calibration |
| 16:15.09 | ShadowJK | sure, but it's programmed for 2000mAh battery, which we don't have |
| 16:15.14 | Estel_ | Pali, it makes it even more wrong, to do "ENODATA" |
| 16:15.37 | Estel_ | ShadowJK, speaks for yourself, I'm currently using 3460 mAh one :P |
| 16:17.17 | Estel_ | s/speaks/speak/ |
| 16:18.16 | Estel_ | ok, adding it to wiki |
| 16:18.21 | Estel_ | ~bme-replacement |
| 16:18.21 | infobot | [bme-replacement] http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement . Please, use wiki page to report bugs/problems and/or solutions to them! |
| 16:18.44 | ShadowJK | So in a power_supply context, our CHARGE_FULL_DESIGN is 2000-ish, and CHARGE_FULL will end up as 1200-ish with a regular battery after calibration.. though I understand the kernel module is doing something else now? |
| 16:19.42 | Estel_ | isn't charge_full_design took from resistor in battery, not bq chip predefined values? |
| 16:21.12 | Estel_ | kerio, you lazy bastard |
| 16:21.17 | Estel_ | f- word in wiki? |
| 16:21.31 | kerio | it's a wiki, fix it :P |
| 16:21.44 | Estel_ | irc raw paste than no one who haven't been in that discussion understand, instead of formatting it? |
| 16:22.09 | *** join/#maemo-ssu keesj (~keesj@dellpc132.few.vu.nl) |
| 16:22.11 | DocScrutinizer05 | ShadowJK: charge_full_design is deduced from BSI |
| 16:22.13 | Estel_ | don't be afraid of properly contributing to wiki, it won't eat you :P |
| 16:23.05 | Pali | huh, big irc log... if you want to change power supply api send patch to power supply maintainer |
| 16:23.18 | DocScrutinizer05 | >:-( |
| 16:23.37 | Pali | I du not want to have some patched forked version of power supply in kernel power |
| 16:23.48 | kerio | just /provide the data/ then |
| 16:24.01 | ShadowJK | I'd take a holistic approach, other drivers and other systems provide data even when not calibrated ;) |
| 16:24.49 | kerio | especially because otherwise, the only way to access that data is to parse and do calculations on the `registers` file |
| 16:25.07 | DocScrutinizer05 | I do not want to have a fsckdup driver for bq27200 in kernel that occupies exclusively that chip and doesn't allow me to read out my bq27200-probed perfectly correct capacity-now, just because there been no learning cycle sine a month |
| 16:26.42 | ShadowJK | I guess power_supply class has no available api for expressing estimated accuracy |
| 16:27.08 | DocScrutinizer05 | if you think you could use that driver with that semantics fro bme-replacement then you're pretty badly mistaken |
| 16:27.26 | Pali | correct way for this is to use regmap api |
| 16:27.34 | ShadowJK | of which we have two levels in bq27200, if CI is high, then last measured discharge may be inaccurate. If VDQ is low, then the charge counter itself may be inaccurate |
| 16:27.35 | DocScrutinizer05 | it will *never* work - it can't |
| 16:27.57 | ShadowJK | Should CHARGE* go away when VDQ goes low, or CI high? |
| 16:28.30 | ShadowJK | Or maybe user space apps interested in knowing expected accuracy should look in registers |
| 16:28.51 | kerio | ShadowJK: then why fucking bother with a kernel module? |
| 16:29.05 | ShadowJK | :P |
| 16:29.06 | DocScrutinizer05 | indeed |
| 16:29.21 | kerio | yes, the "registers" file holds what you'd get from i2cget |
| 16:29.34 | kerio | but if it's the only way to access the data, you might as well use i2cget |
| 16:29.57 | ShadowJK | I'd much prefer if charge*/energy* was always reported regardless of expected accuracy levels |
| 16:29.59 | DocScrutinizer05 | again: if power-supply API mandates data censoring, then it's not the right API to use here |
| 16:30.12 | ShadowJK | DocScrutinizer05; dunno, the doc I read didn't |
| 16:31.46 | DocScrutinizer05 | ooh yeah, that registers file's content is also fux0red since it doesn't display a uniform map of registers but introduces register pairs that are not even *detectable* on hw level |
| 16:33.13 | DocScrutinizer05 | there is no such thing like register pairs on I2C |
| 16:33.43 | Pali | ok, now going offline. if you want to change bq drivers send patches to power supply maintainer and/or ask what is correct solution |
| 16:33.57 | Pali | if patches will be accepted, I will backport them to kernel-power |
| 16:33.58 | DocScrutinizer05 | >:-( |
| 16:34.00 | kerio | woohoo, pali being stubborn as usual |
| 16:34.20 | DocScrutinizer05 | again: if power-supply API mandates data censoring, then it's not the right API to use here |
| 16:34.24 | ShadowJK | Pali; so you'll ask maintianer whether driver should censor output or not? |
| 16:35.14 | DocScrutinizer05 | I'm not going to ask power-supply maintainer if we are using the right API |
| 16:35.17 | Pali | going to study measure theory..., bye |
| 16:35.22 | ShadowJK | and by censor we mean changing the output depending on CI (lmd may be inaccurate) or VDQ (NAC, CACD, CACT may be inaccurate) |
| 16:36.34 | DocScrutinizer05 | ShadowJK: that driver with that semantics fro bme-replacement will *never* work - it can't. |
| 16:36.44 | kerio | DocScrutinizer05: assuming pali's using it correctly |
| 16:37.01 | DocScrutinizer05 | since after 32 charge cycles battery applet will display BS |
| 16:37.23 | kerio | the battery applet in normal mode shouldn't even display the charge, probably |
| 16:37.40 | kerio | in "advanced mode" it should, and it should display a tiny "(CI)" next to the charge when CI is set |
| 16:38.08 | kerio | ShadowJK: how does bq27200 guesstimate the percentage when CI? |
| 16:38.12 | ShadowJK | DocScrutinizer05; there's note in the docs that drivers shouldn't infer things |
| 16:38.18 | ShadowJK | kerio; same way as usual |
| 16:38.27 | kerio | yeah but assuming which battery? |
| 16:38.52 | DocScrutinizer05 | ShadowJK: yep, fine! exactly where I came from |
| 16:38.54 | ShadowJK | same as usual, last measured discharge |
| 16:39.01 | kerio | i see |
| 16:39.38 | ShadowJK | There's also note the drivers shouldn't make their own capacity percentage if hw doesn't provide it |
| 16:39.44 | ShadowJK | curiously enough |
| 16:39.55 | kerio | wouldn't that be inferring? |
| 16:40.08 | ShadowJK | that's why it says should not |
| 16:40.11 | ShadowJK | instead of should |
| 16:40.21 | kerio | it's not curious, it's sensible :) |
| 16:40.44 | kerio | what does it say about flags? |
| 16:41.15 | kerio | or other non-numerical data |
| 16:41.59 | ShadowJK | ok, CHARGE_FULL_DESIGN and ENERGY_FULL_DESIGN, the former has value in bq27k eeprom (ILMD).. i forget if there's one for energy too, but following the power_supply docs, if there isn't one. leave it out... same for _EMPTY_DESIGN |
| 16:42.23 | DocScrutinizer05 | well, usually such data gets masked out and displayed/provided plaintext or as 0|1 |
| 16:42.31 | *** join/#maemo-ssu _rd (~rd@p57B489EB.dip0.t-ipconnect.de) |
| 16:42.44 | kerio | so why didn't that happen for CI, VDQ, EDV1? |
| 16:42.52 | ShadowJK | CHARGE_FULL, CHARGE_EMPTY, full is LMD in bq, empty is always 6 percent of LMD in b, but should probably be left out |
| 16:43.11 | ShadowJK | CHARGE_COUNTER is NAC in bq |
| 16:43.36 | ShadowJK | CAPACITY is RSO |
| 16:44.07 | Estel_ | grrrr |
| 16:44.15 | Estel_ | what a "send a patch to mainstream" bullshit |
| 16:44.22 | ShadowJK | .. i'd map those values straight from bq27, and onlyh process it to convert to the units mandated by power-supply spec |
| 16:44.30 | Estel_ | busybox-power fixed many things in busyboc and THEN send patches to mainstream |
| 16:44.34 | Estel_ | that do accepted, btw |
| 16:44.48 | DocScrutinizer05 | CHARGE_FULL_DESIGN = bq ILMD makes sense only for explicit bq27x00.ko but not for generic power-supply API which might choose to use better sources for that, like e.g. BSI |
| 16:44.50 | Estel_ | which doesn't mean we need to wait for having usable thing for mainstream! |
| 16:44.56 | ShadowJK | Q: Where is POWER_SUPPLY_PROP_XYZ attribute? |
| 16:45.01 | Estel_ | I've added shit to wiki |
| 16:45.09 | ShadowJK | A: If you cannot find attribute suitable for your driver needs, feel free |
| 16:45.19 | kerio | bq27x00-battery isn't even in mainstream, is it |
| 16:45.20 | ShadowJK | <PROTECTED> |
| 16:45.20 | Estel_ | If Pali won't fix it, I hope someone will fork it for maemo's sake |
| 16:45.43 | ShadowJK | <PROTECTED> |
| 16:46.43 | Estel_ | I'm starting to thing that using nokia's closed bme shit, even if it doesn't work in hostmode, is less pita than convincing pali to fix some critical bugs |
| 16:47.04 | ShadowJK | also: http://pastebin.com/5SNYPpm3 |
| 16:47.33 | Estel_ | now I'm really feed up with this, Pali's recent behavior is telling to GTFO by "send it to mainstream even, if mainstream isn't fuckin related to actual problem |
| 16:47.39 | Estel_ | need to go out for now |
| 16:47.46 | Estel_ | bye |
| 16:48.05 | kerio | wait! |
| 16:48.08 | kerio | close your string first! |
| 16:49.14 | *** join/#maemo-ssu rd_ (~rd@p57B48044.dip0.t-ipconnect.de) |
| 16:49.19 | DocScrutinizer05 | http://pastebin.com/5SNYPpm3 INDEED! |
| 16:49.33 | DocScrutinizer05 | also don't infer -ENODATA from CI |
| 16:56.32 | ShadowJK | DocScrutinizer05; I assume the -22 in your version is to flip the sign on the mA column? :P |
| 16:56.48 | DocScrutinizer05 | which -22? |
| 16:57.10 | ShadowJK | Oh I thought I saw a RS -22 |
| 16:57.30 | DocScrutinizer05 | no, you seen $RS-22 |
| 16:57.54 | ShadowJK | what does that do |
| 16:58.05 | DocScrutinizer05 | RS=${RS:-22} |
| 16:58.22 | ShadowJK | is that like ? operator in C? |
| 16:58.26 | DocScrutinizer05 | use $RS, unless empty, then use 22 |
| 16:59.41 | DocScrutinizer05 | so RS=22 for "bq27200.sh" but 67 for "RS=67 bq27200.sh" |
| 17:00.04 | ShadowJK | I was going to try measure between batt gnd and random pcb gnds like you said, but then I realized I don't have anything that can give meaningful results at milliohm levels :) |
| 17:00.52 | DocScrutinizer05 | you only can do that with driving a known current along that line and see what bq27200 reports as current |
| 17:02.09 | DocScrutinizer05 | you'd need to decouple the battery GND line from battery for that, and connect battery/cell GND to e.g. USB shielding |
| 17:03.16 | DocScrutinizer05 | then drive 1.000A from USB shield to battery minus blade of battery plug in N900 and see what that results in bq27200 |
| 17:04.09 | ShadowJK | ...run N900 from usb sans battery |
| 17:04.24 | DocScrutinizer05 | of course you could try to operate N900 without any battery, but you need it operating to read out bq27200 while driving 1A through that minus contact of bat connector |
| 17:04.33 | DocScrutinizer05 | :nod: |
| 17:05.43 | DocScrutinizer05 | it also doesn't need to be 1000mA, any relatively high defined constant current will do, as long as you probe it with an accurate DMM |
| 17:07.35 | DocScrutinizer05 | there are more nifty methods, (like using alternating squarewave current with a freq of 0.05Hz and then analizing the average deviation) but they're cumbersome |
| 17:09.58 | DocScrutinizer05 | another method would be to power the device via battery connectors and precisely probe and integrate the current drawn, then compare to bq's charge gas gauge |
| 17:11.15 | DocScrutinizer05 | since this won't result in any halfway constant current, probing for point-in-time current would be meaningless for that setup |
| 17:18.18 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 17:23.41 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 17:26.42 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 17:43.51 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 18:21.56 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 18:27.37 | *** join/#maemo-ssu Guest50382 (~rd@p57B48044.dip0.t-ipconnect.de) |
| 19:12.54 | *** join/#maemo-ssu arcean (~Tomek@apn-46-76-221-129.dynamic.gprs.plus.pl) |
| 19:43.20 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 19:53.52 | *** join/#maemo-ssu Guest50382 (~rd@p57B48044.dip0.t-ipconnect.de) |
| 20:12.39 | *** join/#maemo-ssu luf (~luf@ip-94-112-59-161.net.upcbroadband.cz) |
| 20:34.20 | *** join/#maemo-ssu Guest50382 (~rd@p57B48044.dip0.t-ipconnect.de) |
| 20:52.19 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 20:56.32 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 21:01.25 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 21:20.29 | *** join/#maemo-ssu Guest50382 (~rd@p57B48044.dip0.t-ipconnect.de) |
| 21:39.37 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 22:38.00 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 22:38.51 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:c076:8c29:88fc:68a3) |
| 22:42.53 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 22:59.09 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |