IRC log of #maemo-ssu for Sunday, 2013-03-24

Estel_freemangordon,  hm, I think it could be productive if you would share those arguments in that thread, generally, sensible people there00:03
Estel_I think that those are very valid arguments. OTOH; upgrading to squeeze and hammering bugs, while titanic (excuse pun) work, if suceed, would allow to much easier hammering out future bugs00:03
Estel_i.e. it's like moving forward with all those years maemo packages were behind, just at 5x speed00:04
Estel_if mainstream would be "caught", it would be much easier to keep pace afterwards, at normal speed00:04
Estel_not sure if doable as a whole, but would be great00:05
Estel_otherwise, only one way for future-future would be rebasing HD on Mer... otherwise, with years to come, it would get harder and harder to port anything (tm) with dependencies breaking compatibility with our ancient versions etc00:06
Raimu-XHeh, hildon appman keeps wanting me to "upgrade" my Fennec 17.0 into cssu-thumb's Fennec 17.0alpha. :)00:06
*** Raimu-X is now known as Raimu00:06
kerioRaimu: do eeeet00:07
Estel_Also, from a different and much less meritocratic barrel, I don't see most of hildon@squeeze core contributors in cssu. They don't have time for spending hours on irc00:07
RaimuI guess something in the alpha's version numbering makes apt-get think it's later than the final 17.000:07
Estel_and the later seems like only way to get own contribution merged into cssu nowadays :P00:07
Raimukerio: Try this one out! http://talk.maemo.org/showpost.php?p=1331064&postcount=3700:08
Estel_In my book cssu, while super-great and epic, isn't very friendly welcoming new casual contributions, for reasons i don't understand. It looks that you're either cssu maniac, or gtfo00:09
kerioRaimu: i don't use fennec00:09
RaimuOkies.00:09
Estel_anyway, ade's and idont cases seems to indicate that, and I think cssu still don't get how huge impact for anti-encouraging to contribute it had on dozens of people00:10
Estel_especially bb-p case, as, with respect to cssu, bb-p is more popular (also amongst coding gurus) than cssu itself, despite having no banner on main page ;), and iDont is hero for many coders. If he was treaten like that, what less able coder can expect?00:12
Estel_well, so much food for thought from me, going back to [strike]playing homeworld on N900[/strike] mastering art of coding for maemo in scratchbox vm ;)00:13
*** chainsawbike has quit IRC00:30
*** xmlich02 has quit IRC00:30
*** unclouded has quit IRC00:30
*** SpacedOut has quit IRC00:30
*** chainsawbike has joined #maemo-ssu00:34
*** SpacedOut has joined #maemo-ssu00:35
*** unclouded has joined #maemo-ssu00:36
*** xmlich02 has joined #maemo-ssu00:36
*** futpib has quit IRC00:50
*** kolp has quit IRC01:10
*** luf has quit IRC01:21
*** NIN101 has quit IRC01:26
*** dhbiker has quit IRC01:34
*** Pali has quit IRC01:51
*** Woody14619a has joined #maemo-ssu02:01
*** Woody14619a has quit IRC02:01
*** Woody14619a has joined #maemo-ssu02:01
*** Woody14619b has quit IRC02:05
*** Vlad_on_the_road has quit IRC02:05
*** M4rtinK has quit IRC02:38
*** LauRoman has quit IRC03:20
*** arcean_ has quit IRC04:01
*** amiconn has quit IRC05:10
*** amiconn_ has joined #maemo-ssu05:10
*** amiconn_ is now known as amiconn05:10
*** DocScrutinizer05 has quit IRC06:03
*** DocScrutinizer05 has joined #maemo-ssu06:03
*** M13 has joined #maemo-ssu07:36
*** kolp has joined #maemo-ssu08:54
*** amiconn has quit IRC09:13
*** dhbiker has joined #maemo-ssu09:13
*** amiconn has joined #maemo-ssu09:14
*** LauRoman has joined #maemo-ssu09:24
*** LauRoman has quit IRC09:29
*** Pali has joined #maemo-ssu10:36
*** futpib has joined #maemo-ssu10:42
*** Vlad_on_the_road has joined #maemo-ssu10:44
*** _rd has joined #maemo-ssu10:46
*** NIN101 has joined #maemo-ssu11:13
*** M4rtinK has joined #maemo-ssu11:22
*** _rd has quit IRC11:24
freemangordonmerlin1991: what is the problem with CSSU repos (if any) and who is aware of it?11:32
Palimerlin1991: 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 here11:39
*** _rd has joined #maemo-ssu11:42
Palimerlin1991: 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 sh11:44
*** Mihanizat0r has joined #maemo-ssu11:45
*** M13 has quit IRC11:46
Palifreemangordon, are you going to create packages for 720p video playback?11:47
Paliwith needed libraries & hd codecs?11:47
*** dhbiker has quit IRC11:51
freemangordonPali: 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"11:52
freemangordonall this "my penis is longer" stuff is starting to play on my nevers11:53
freemangordon*nerves11:53
*** arcean has joined #maemo-ssu11:56
*** _rd has quit IRC12:15
*** _rd has joined #maemo-ssu12:15
*** dhbiker has joined #maemo-ssu12:26
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?12:40
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 assumptions12:42
PaliEstel_, hi, can you repeat your problem with bme replacement?12:43
Estel_Pali, sure12:44
Estel_the thing is that this unfixed problem with device not calibrating have more serious consequences than expected, lemme dig what I've exactly written12:45
Estel_http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-03-20.log.html#t2013-03-20T00:39:0012:48
Estel_Pali^12:48
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 ever12:49
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 ever12:49
Estel_sry echo12:50
Estel_Estel_Pali,  not complaining, just trying to show you how serious this bugs are in practice12:50
Estel_Estel_thanks for your work, and hope for fix soon ;)12:50
Estel_thats pretty sums it up ;)12:50
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 above12:51
Paliproblem with battery empty shutdown and maximal/design capacity --> I think we already talked about it --> write wiki page with possible solutions...12:52
Palinext, there is shutdown on modprobe -r bq27x00_battery?12:52
Paliwho shutdown device? hald-addon-bme --> dsme? lifeguard, kernel oops?12:52
Palimodprobe -r rx51_battery also shutdown device?12:53
Palinew hald-addon-bme should work without that two drivers without problem and also support hotplug of that drivers12:53
*** _rd has quit IRC12:54
*** _rd has joined #maemo-ssu12:54
Estel_Pali,  no no, wait12:55
Estel_shutdown is *only* if *both* rx51_battery *and* bq27x00_battery is removed12:55
Estel_I can safely remove one or another12:55
*** unclouded has quit IRC12:56
Estel_but when both are removed, and bme repl. isn't feed voltage data from anywhere, device shutdowns about ~30 sec12:56
Estel_s/about/ in about/12:56
infobotEstel_ meant: but when both are removed, and bme repl. isn't feed voltage data from anywhere, device shutdowns  in about ~30 sec12:56
Estel_no idea who shuts it down, where to looks for guilty? /var/log/syslog haven't contained anything useful12:57
Estel_as for wiki page it is already created, I've sent it to you, wait a second12:57
Estel_it's just a stub, but should do for now12:58
PaliEstel_, try to stop HAL and check if removing both drivers still shutdown device12:58
Palisudo stop hal && sudo /etc/init.d/hal stop12:59
Palips auxf | grep hal12:59
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 hal12:59
Palistarting HAL again not working always, but you can try: sudo start hal12:59
Palibut better is to reboot device12:59
Paliok13:00
PaliEstel_, also syslog could be usefull13:01
*** amiconn has quit IRC13:03
*** amiconn_ has joined #maemo-ssu13:03
*** amiconn_ is now known as amiconn13:03
*** arcean has quit IRC13:05
*** kolp has quit IRC13:05
*** kolp_ has joined #maemo-ssu13:05
*** arcean has joined #maemo-ssu13:05
*** Raimu-Z has quit IRC13:06
*** Sc0rpius has quit IRC13:06
*** Sc0rpius has joined #maemo-ssu13:06
*** Raimu-Z has joined #maemo-ssu13:06
Estel_Pali,  loook here:13:42
Estel_http://wiki.maemo.org/Bme_replacement13:42
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 reports13:43
Estel_Pali,  sorry it took a while, decided to re-fine page a little, so it's easier to read and less stub-like13:43
Paliok13:43
Estel_still, some things are missing, marked by < > - like minimal kernel version - please fill when possible13:44
Estel_Pali, ok, going to problems, so, I'm trying to stop hal now13:44
PaliEstel_, bme replacement using edv1 flag (not voltage) if it is exported by kernel13:44
Paliif not then fallback to edv1 voltage13:45
Estel_just a question - remind me, only those two modules (bq27x00_battery and rx51_battery) feed voltage data to bme replacement?13:45
Estel_Pali, hm13:45
Estel_sounds OK, but how to check if it's exported?13:45
Estel_before it happens?13:45
PaliEstel_, yes13:45
Estel_also, I would fallback to 3150 mV, if not exported13:46
PaliEstel_, maemo kernel-power exporing them via registers file13:46
Estel_OK13:46
Estel_but, I would fallback to lower value, to still give 90% chance for calibration13:46
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% :P13:47
Estel_also, it's just a fallback13:47
Estel_sounds ok, Pali?13:48
Palihm, sounds good13:48
Paliwrite to wiki page, so we will not loose this info13:48
Estel_aaaah, btw, when to shutdown after edv1 flag without a fallback? instantly, or 2 or 3 seconds later, just in case?13:48
Estel_OK13:48
Estel_Pali,  bme replacement require kernel-power as a whole?13:52
Estel_due to bq2415x_charger etc?13:52
Estel_(if not I'll fix it in wiki, also)13:52
PaliEstel_, kernel which provides bq2415x_charger, bq27x00_battery and rx51_battery drivers13:52
Estel_so why we need fallback? If kernel provides that, it also exports edv1 flag13:53
Paliand which has glue between bq2415x_charger and monolitic musb driver13:53
Estel_so in practice, it means "it needs kernel power" as only kp provide that13:53
PaliEstel_, I wrote hal-addon-bme to work also with some other upstream versions of bq27x00_battery driver13:53
Estel_I see, but no such thing available for maemo, anyway, in practice?13:54
Palibut with last kernel power it has access to EDV1 flag13:54
PaliEstel_, yes13:54
Estel_but it is for future, understood13:54
Estel_Pali, when we are at it - doesn't bq2415x_charger feed voltage data, too?13:55
Estel_when testing hal, shouldn't it modprobe -r it too?13:55
Palibq2415x does not provide any voltage data13:55
Estel_OK13:55
Estel_so let me fix wiki first, then I'll proceed to testing it13:56
Estel_Pali,  as im fixing wiki - where exactly can we read about edv1 flag being set, using kernel-power?13:57
Estel_also, which is oldest kp version tha fulfill bme replacement requiments?13:57
Palihald-addon-bme can read bq27 EDV1 flag from some new kernel-power13:57
PaliI think you need kp52 for BME replacement13:58
Estel_user/root can read it too, somehow?13:58
Estel_OK13:58
Palinormal user can read it too13:58
Estel_address?13:58
Estel_I wan't to put that info on wiki too, as it's now a <placeholder>13:58
Palicat /sys/class/power_supply/bq27200*something/registers13:58
Estel_thanks13:58
Palilook at n900 for correct file path13:59
Estel_ok13:59
* Estel_ goes to feed wiki with new data13:59
PaliEDV1 is one bit in some register13:59
Paliin that file13:59
Estel_yes, yes, I know that file13:59
Palibut I do not remember, look into datasheet or bme replacement code13:59
*** xes has joined #maemo-ssu14:01
PaliEstel_, ping kerio about wiki page and ideas about max/design capacity14:02
Estel_yea, planned to do that, too14:02
kerioi 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/ now14:08
Estel_kerio, because bq27x00 reports "nothing" (not even 0), as max capacity, when not calibrated14:10
Estel_kerio, but we had a good solution idea already, remember?14:10
keriothat's sensible actually14:10
*** _rd has quit IRC14:11
kerio(but the data should be accessible from somewhere else - and not the registers, come on, i want something simpler)14:11
Estel_you were too lazy to write it to wiki, so recall it now, as i dont remember14:11
Estel_so what applet should show?14:11
kerioi was about to ask you14:11
kerioi'd say it should show nothing14:11
Estel_when 0 data from capacity?14:11
Estel_0/0 is bad idea14:11
Estel_it also confuses charging idnicator14:11
Estel_it shows green diode 5 sec after plugging charger, despite charging going on full ampere14:12
Estel_it should show smth like "please calibrate"14:12
keriowhat controls the led? hald or the battery applet?14:12
Estel_in place of regular 700/1350, should be Unknown/please calibrate14:13
Estel_ask Pali14:13
Estel_led, po0-up banner14:13
Estel_it also shows "charging full" as banner14:13
kerioi think led is hald and banner is applet14:13
kerioso14:13
Estel_for some reasons, using your modification of applet when battery not calibrated results in such werido14:14
kerio1) the battery applet, and every other maemo battery thing, should be able to work with only hald-provided info14:14
Estel_and using pali's result in other werido, green led when design capacity reached, despite that real capacity is triple as much14:14
kerio2) instead of showing wildly inaccurate data, it's preferrable to show nothing, or a message indicating that data is unavailable14:15
kerio3) 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)14:16
kerio4) 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)14:17
kerio5) 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 on14:18
keriofor example14:18
kerioit's not that my calibration script does precisely that, honest14:19
kerioso... idk, maybe add a way to disable the automatic shutdown14:19
keriobut shutting down once EDV1 *flag* is set is a good idea, imo14:19
kerioshutting down at EDVF is too late14:19
ShadowJKEven at edv1 it's a bit so-so whether my battery would have enough for clean shutdown :)14:22
kerioShadowJK: really? :s14:23
kerioit's supposed to be 6% of the battery14:23
ShadowJKThat is only true for one specific battery that's no longer sold14:23
kerioit's more, nowadays!14:23
* kerio jests14:24
ShadowJKless14:24
ShadowJKalso more worn batts will have it higher than when new14:24
kerioShadowJK: it's kinda hard to figure out something like that via software, when polling :(14:24
ShadowJKsure, I'm just saying the eeprom constants are wrong14:25
DocScrutinizer05*why* does >> bq27x00 reports "nothing" (not even 0), as max capacity, when not calibrated<<?14:25
kerioask Pali14:26
DocScrutinizer05there's ILMD in bq27x00 that kicks in on reset of chip, and without reset the LMD sticks14:26
DocScrutinizer05even when CI=114:26
kerioyou get a read error from the sysfs nodes when CI=114:27
keriothe ones that give you numerical data14:27
DocScrutinizer05so I honestly can't see why bq27200.ko wouldn't report anything for max capacity any time or any situation14:27
kerioit definetely could, but it doesn't14:28
DocScrutinizer05kerio: that's broken in so many ways14:29
DocScrutinizer05it's unlogical, clumsy, useless, and violating the general design rules for device drivers14:29
DocScrutinizer05the chip delivers a (rather meaningful and somewhat correct) value for LMD, so why THE HECK would the device driver fail on reading that value?14:31
kerioprobably for the same reason rx51-battery design capacity is used, instead of any meaningful value14:32
kerioso users won't get confused14:32
DocScrutinizer05user won't get confused??? LOL14:34
Estel_Pali, could you answer it? I also think it's wrong that sysfs node doesn't report anything, when uncalibrated14:36
Estel_I break 3rd party things (bq27200.sh, BNF), it's confusing, and... well, just wrong14:36
DocScrutinizer05a sysfs node is supposed to *always* faithfully report what a hw item delivered14:36
Estel_If no reason to keep it that way, I would propose change on wiki14:36
Estel_agreed14:37
Estel_~pali14:37
infobotsomebody said pali was http://atrey.karlin.mff.cuni.cz/~pali/14:37
DocScrutinizer05if you want a friggin notification about "state uncalibrated" in battery applet, then you need battery applet to look at CI in sysfs14:38
Estel_kerio, could you describe current problem on wiki?14:38
kerioDocScrutinizer05: CI is in sysfs14:39
keriosomewhere in registers :s14:39
DocScrutinizer05*NOT* make readout of LMD fail with a read error! how silly is THAT?14:39
Estel_DocScrutinizer05,  could you update wiki problem 2 with rationale, why bq27x00 shouldn't fail to reports via sysfs node, when uncalibrated?14:39
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)14:40
Estel_DocScrutinizer05,  ^14:40
Estel_(you can write solution, withut waiting for problem description to appear)14:40
Estel_http://wiki.maemo.org/Bme_replacement#Prerequisities14:41
Estel_sry14:41
Estel_sryhttp://wiki.maemo.org/Bme_replacement14:41
Estel_damnit!14:41
Estel_http://wiki.maemo.org/Bme_replacement14:41
Estel_^that is correct link14:41
DocScrutinizer05an 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=114:42
Estel_please, write proposed solutions on wiki, it will get lost on irc14:42
Estel_we discussed it already once, and it was forgotten14:42
Estel_I spend last two hours refinning wiki for a purpose :P14:43
kerioDocScrutinizer05: that would be silly14:43
DocScrutinizer05would add a systemic error to reading of +- 1 least significant digit14:43
keriothis is not an 80's arcade machine14:43
Estel_I think reporting "valu innacurate/please calibrate" in battery applet is enough14:44
keriousing the least significant digit to count continues is a neat trick, but we have a lot more resources on a n90014:44
Estel_s/valu/value/14:44
infobotEstel_ meant: I think reporting "value innacurate/please calibrate" in battery applet is enough14:44
DocScrutinizer05kerio: user could specify whether to use or not this notification sheme, with a kernel module loadtime parameter14:44
Estel_but do realize guys, that nothing will happen, if it won't land on wiki14:44
kerioDocScrutinizer05: or we could just provide a damn node that tells us if CI is set or not14:45
DocScrutinizer05sure, that's mandatory anyway14:45
DocScrutinizer05alas battery applet doesn't usually look for such sysnode14:45
Estel_no need for new node, it is already exported14:46
DocScrutinizer05my 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 value14:46
Estel_via node "registers"14:46
Estel_examples of how to properly use bits from registers from userland are in BNF, for example14:47
DocScrutinizer05a proper comprehensive decently designed device driver should decode all status bits and expose them verbatim14:47
Estel_well, I see nothing wrong in that, either14:47
Estel_-> wiki, please14:47
kerioDocScrutinizer05: fwiw it wouldn't be sacrificing anything, the values in the sysfs nodes have 3 digits more than they should14:49
keriothey're all micro-, and bq27200 provides milli-14:49
DocScrutinizer05kerio: that been my original approach, but I was too lazy to check14:50
DocScrutinizer05actually bq27x00 doesn't provide milli either14:50
DocScrutinizer05it provides a uVh/Rs unit that needs conversion prior to displaing/exporting it14:51
*** Martix_ has quit IRC14:51
DocScrutinizer05and Rs should default to 22mR but should be able to get overridded by kernel module load paramater (again)14:52
keriowhat's that R supposed to be?14:52
*** Martix has joined #maemo-ssu14:53
DocScrutinizer05like modprobe bq27x00.ko notify-CI-in-last-digit=true,rs=2414:53
DocScrutinizer05R is 20 or 22 in all devices we tested so far14:53
DocScrutinizer05but could differ vastly for other hw platforms using bq27x0014:54
kerioyeah but what is it supposed to be?14:54
keriohow do you measure it?14:54
DocScrutinizer05see *my* bq27200.sh script, at http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27200.sh14:55
DocScrutinizer05kerio: you measure it between battery GND and general system GND14:55
Estel_you measure it by hand, or something measure it inside device and give output for reading?14:56
ShadowJKSomeone with a jig reported 21 too14:57
DocScrutinizer05there'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 hw14:58
Estel_DocScrutinizer05,  so what difference in your bq27200.sh and ShadowJK's one, which just provide that value?15:02
Estel_it seems you provide it too, just using another calculation?15:03
ShadowJKI use 2115:03
kerioif some have 20 and some have 22, i guess 21 is close enough for both15:03
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?15:03
Estel_well, I use 21 too15:04
ShadowJKfor some uses 20 seems to fit better for me15:04
Estel_he will gladly and quickly fix those things, but need info on wiki15:04
*** Mihanizat0r has quit IRC15:30
*** M13 has joined #maemo-ssu15:31
DocScrutinizer05# Assuming 30 mOhm sense resistance15:36
DocScrutinizer05RS=${RS:-22}15:37
DocScrutinizer05RS=99 bq27200.sh15:37
DocScrutinizer05echo "LOOPMODE=$LOOPMODE RS=$RS"15:38
*** PaulFertser has joined #maemo-ssu15:48
*** _rd has joined #maemo-ssu15:49
PaulFertserPali: 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?15:51
*** sunny_s has quit IRC15:51
*** M13 has quit IRC15:51
PaliPaulFertser, 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 kernel15:52
DocScrutinizer05Pali: what would be missing?15:53
PaliSkry, what do you think? ^15:53
SkryI can confirm15:53
PaulFertserOh :(15:53
PaulFertserWhat's missing?15:53
Skryvoltage scaling15:53
DocScrutinizer05meh, shouldn't that be done by SR meanwhile ;-P15:53
Skrysmartreflex15:53
PaulFertserI thought TI engineers did the right thing with their omap tree, what happened?15:54
PaliDocScrutinizer05, now in some 3.x there is smartreflex driver15:54
DocScrutinizer05I couldn't think of TI not upstreaming SR15:54
PaliSR is upstreamed15:54
DocScrutinizer05thought as much15:54
SkryI 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 readings15:55
DocScrutinizer05that SR is still tagged "deprecated" on N900 is another thing, that obviously doesn't matter to anybody15:55
PaliI have semi/non-working maemo with upstream kernel15:55
DocScrutinizer05Skry: powertop has zero info about savings15:55
Palifor unknown reason, mce and hal eats 100% cpu always15:55
PaulFertserBut what about DVFS?15:55
DocScrutinizer05it just reports C-states and frequencies15:56
ShadowJKI'd think sr would make no difference in powertop?15:56
DocScrutinizer05ShadowJK: exactly my words ;-)15:56
PaulFertserSkry: do you mean DVFS is still not implemented at all?15:56
DocScrutinizer05~dvfs15:57
DocScrutinizer05~wiki dvfs15:57
infobotAt http://en.wikipedia.org/wiki/DVFS (URL), Wikipedia explains: "'Voltage and frequency scaling' may refer to: * Dynamic voltage scaling, a power management technique in computer architecture, where the voltage used in a component is increased or decreased, depending upon circumstances * Dynamic frequency scaling, a technique in computer architecture whereby the frequency of a microprocessor can be automatically adjusted "on the fly," either to ...15:57
Palidvfs in in upstream since 3.2: https://lwn.net/Articles/460973/15:57
Palibut I do not know if there is omap driver15:57
PaulFertserI think it means that some internal regulator's voltages are automatically adjusted based on the current cpufreq state, right?15:57
SkryDocScrutinizer05, 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.15:58
*** kolp_ has quit IRC15:58
DocScrutinizer05PaulFertser: 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 ;-P15:58
*** kolp has joined #maemo-ssu15:59
DocScrutinizer05Skry: wtf which powertop you got there?15:59
PaulFertserDocScrutinizer05: so the upstream should run using less power, not more :) And Pali says maemo's kernel still wins, how so?15:59
Palistatus of n900 kernel is here: http://elinux.org/N90015:59
PaulFertserYes15:59
PaulFertserPali: thank you for keeping that page up-to-date btw15:59
SkryDocScrutinizer05: 2.2, not on Maemo16:00
DocScrutinizer05Skry: hm?16:00
DocScrutinizer05PaulFertser: no, running SR inparallel to sw-driven scaling will reduce in slight data transfer overhead and nothing else16:01
PaulFertserI see :)16:02
DocScrutinizer05PaulFertser: 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 set16:03
DocScrutinizer05only when enabled, the latter16:04
DocScrutinizer05guys claiming they use SR only enable the latter, while not disabling the former16:04
DocScrutinizer05afaik16:04
DocScrutinizer05there's a sysnode in powerkernel that allows enabling/disabling the dedicated SR voltage adjustment via the dedicated I2C16:05
PaliSkry, is front n900 camera working on your arch?16:06
DocScrutinizer05but 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 marginal16:07
SkryPali: nope, module loading fails. I only tested with 3.5 so can't say for sure how it's with upstream kernel16:07
SkryPali: wait a second, I'll boot to 3.9 and recheck16:08
DocScrutinizer05errr, front and main cam share same interface16:08
DocScrutinizer05only multiplexed by a switch16:08
PaliSkry, ok, try that smiapp driver16:08
ShadowJKvoltage scaling would be relevant for running at not-600, like mp3 playback at 25016:08
DocScrutinizer05:nod:16:08
PaliDocScrutinizer05, problem is that in upstream kernel there is only driver for front webcam16:08
DocScrutinizer05oooh, so *no* driver works16:09
*** dhbiker has quit IRC16:09
*** M13 has joined #maemo-ssu16:09
DocScrutinizer05why not port forward the fcam drivers then?16:09
*** dhbiker has joined #maemo-ssu16:09
PaliDocScrutinizer05, I tried to port forward camera drivers from meego (which was port forwared from maemo kernel)16:10
Palibut not working...16:10
DocScrutinizer05hehe16:10
DocScrutinizer05:-/16:10
Palithen I found that new camera driver (which should work with n900 front webcam) was upstreamed16:11
Paliso I'm trying to write board code for that driver16:11
ShadowJKneed the thing that tells mux to switch to frontcam too, before anything tries to access frontcam16:11
PaliShadowJK, that part of board code16:11
Palibtw, seems that my ansi bootmenu uboot code will be upstreamed16:13
Paliso upstream uboot will have anything needed for user frendly n900 booting...16:13
DocScrutinizer05(SR) btw it seems I recall somebody (fmg) claiming that stock maemo kernel doesn't even do sw-driven core voltage scaling16:15
DocScrutinizer05I'm not sure about a) if I correctly recall that claim, and b) if it's been correct claim to start with16:16
DocScrutinizer05(fmg?)16:17
ShadowJKthe whole point of dropping to a lower frequency is that you can run at less voltage and consume less power :/16:19
DocScrutinizer05hehehehe, indeed, that's why I can't believe Nokia implemented freq scaling without voltage scaling16:20
ShadowJKit'd be like s3c, heh16:21
DocScrutinizer05LOL16:21
DocScrutinizer05gnnhnnhnhnhrrhrrrhrrrr16:21
DocScrutinizer05long live GTA02 \o/16:22
DocScrutinizer05well, we *had* to use that SoC since it been the only one where tech manual been publicly available16:22
DocScrutinizer05when OM started16:23
DocScrutinizer05raster and me pushed for better CPUs/SoCs quite several times, but with little success16:23
DocScrutinizer05instead for gta03 the s3c6400 or whatever been picked16:25
discopighi16:25
*** _rd has quit IRC16:35
*** arcean_ has joined #maemo-ssu16:35
*** arcean has quit IRC16:39
kerioDocScrutinizer05: the gta04 is pretty much a n900, right?16:40
kerioomap316:40
*** arcean_ has quit IRC16:59
DocScrutinizer05yup17:14
DocScrutinizer05kinda17:14
*** _rd has joined #maemo-ssu17:21
freemangordonDocScrutinizer05: 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 parameters17:21
ShadowJKi guess if you started today you'd use an Allwinner chip17:21
kerioa what17:22
freemangordonand those parameters are device specific, that is why you have different power savings for different devices17:22
freemangordonThere is so-called SW SR, but it is not used in Maemo kernel, iirc harmattan kernel uses it (SR 1.5)17:24
DocScrutinizer05freemangordon: I'm starting to think you should read twice my statements before you bitch at me. It's *exactly* what I wrote17:24
ShadowJKkerio: allwinner is a chinese chip maker, allegedly they have docs17:29
ShadowJKmany of the cheap china tablets have them17:29
Estel_~bme-replacement17:35
infoboti guess bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/17:35
Estel_~factinfo bme-replacement17:36
infoboterror: you do not have enough flags for that. (o required)17:36
infobotbme-replacement -- created by Pali <~pali@Maemo/community/contributor/Pali> at Sat Feb 23 14:58:19 2013 (29 days).17:36
Estel_Pali, doesn't you have anything against me adding wiki page to bme-replacement factoid?17:36
Paliadd it17:36
Paliinfobot: 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/17:38
infobot...but bme-replacement is already something else...17:38
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!17:38
infobotEstel_: okay17:38
Estel_olol17:38
Estel_~bme-replacement17:38
infobotsomebody said bme-replacement was http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/17:38
Estel_lol217:38
Paliinfobot: forget bme-replacement17:39
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!17:39
infobotPali: i forgot bme-replacement17:39
infobotEstel_: okay17:39
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!17:39
infoboti already had it that way, Estel_17:39
Estel_~bme-replacement17:39
infobotextra, extra, read all about it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/17:39
Estel_~fu17:39
infobotFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU-17:39
Paliinfobot: forget bme-replacement17:39
infobotPali: i forgot bme-replacement17:39
DocScrutinizer05~bme-replacement17:40
infobotbme-replacement is probably http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/17:40
DocScrutinizer05~literal bme-replacement17:40
infobot"#maemo bme-replacement" is "http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/"17:40
Paliinfobot, 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!17:42
Estel_freemangordon,  haven't had time to answer my question, missed it, or ignored on purpose?17:42
infobotokay, Pali17:42
Pali~bme-replacement17:42
infobotrumour has it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/17:42
Estel_~like17:42
infoboti guess like is it a gateway or and HP or something?17:42
Paliinfobot: forget bme-replacement17:43
infobotPali: i forgot bme-replacement17:43
Pali~bme-replacement17:43
infobotextra, extra, read all about it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/17:43
PaliWTF?17:43
Estel_read-only17:43
DocScrutinizer05WTF do you ever read what others do and write in chan?17:43
DocScrutinizer05~literal bme-replacement17:43
infobot"#maemo bme-replacement" is "http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/"17:43
DocScrutinizer05~factinfo bme-replacement17:43
infobotDocScrutinizer05: there's no such factoid as bme-replacement17:43
DocScrutinizer05~factinfo #maemo bme-replacement17:44
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.17:44
Estel_infobot, forget #maemo bme-replacement17:44
infobotEstel_: i forgot #maemo bme-replacement17:44
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!17:44
infobotokay, Estel_17:44
Estel_~bme-replacement17:44
infobotit 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!17:44
*** xes has quit IRC17:45
DocScrutinizer05also note that this factid been created by kerio, but we don't want to be more religious than the pope here17:46
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 :P17:46
Estel_hehe, right17:46
kerioi feel murderous rage because of my lost factoid17:47
Estel_I feel murderous rage, because you haven't added bat applet problem to wiki17:47
Estel_so it won't be fixed17:47
DocScrutinizer05kerio: It been augmented, not lost.17:47
DocScrutinizer05that's pretty allowable17:47
keriomy artistic integrity has been tainted by that addition17:47
kerioEstel_: which problem?17:48
Estel_ffs17:48
Estel_the one with using design capacity17:48
Estel_+ problem with bq27x00 not exporting sysfs nodes when not calibrated17:49
Estel_(some of them)17:49
Estel_pretty good argumentation on this channel was present, but it's irrelevant, as will get lost in irc time and space17:49
kerioinfobot: 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!17:50
infobotkerio: okay17:50
Estel_Pali, are you still here?17:50
Estel_~factinfo bme-replacement17:50
infoboterror: you do not have enough flags for that. (o required)17:50
infobotthere's no such factoid as bme-replacement, Estel_17:50
Estel_~factinfo #maemo bme-replacement17:50
infoboterror: you do not have enough flags for that. (o required)17:50
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.17:50
Estel_:P17:50
Estel_Pali,  why bq27x00 fails to export some sysnodes when not calibrated?17:51
Estel_it gives read error, and is wrong, sysfnodes shouldn't act like that17:51
Estel_chip, have some default value somewhere (2056) that replaces calibration info, when calibration lost, for example, due to sitting without battery inserted17:52
Palisysfs entires are exported to upower (and also old hal) daemon and 2056 is really bad value17:52
kerioPali: 2056 is more correct for estel than the value reported by rx51-battery17:52
kerioso we have at least one case where it's better17:53
Palikerio, you can unload rx51 battery driver --> not use it17:53
Estel_Pali,  also, "read error" is always worse than 205617:53
PaliI think in function is returning -ENODATA17:53
Palithat kernel doing with -ENODATA is other question17:54
Estel_well, 2rd party things depending on those nodes break with "aritmetic syntax error" then17:54
keriothere *is* data17:54
Paliany open() syscall can fail17:55
Paliand also any read() syscall can fail17:55
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?17:55
Estel_aka "calibrated" or not?17:55
Estel_but isn't sysfs node supposed to report religiously what hardware reports, instead of censoring it?17:55
Estel_as kerio said, there *is* data17:55
Estel_a default one17:56
Estel_it makes life harder, without any gains17:56
Estel_the way it is now17:56
Estel_all your stuff could get same results just watching for "calibrated" flag CI17:56
kerionot only that, ILMD is still a much, much better value than the value for design battery from rx51-battery17:56
DocScrutinizer05Pali: no, sysfs entries are not supposed to return -ENODATA when in fact there IS data17:57
DocScrutinizer05and usually even pretty good data17:57
DocScrutinizer05sysfs API is supposed to show ehat hw reports, not what devel censored out of it17:59
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 -ENODATA17:59
PaliDocScrutinizer05, I'm not using sysfs api, but power supply17:59
Paliand what power supply is doing is other question...18:00
DocScrutinizer05I 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 idea18:00
PaliDocScrutinizer05, I do not care too :-) that api is used for notifing upower daemon which should receivce correct data18:01
DocScrutinizer05my bq27200 wvalues are still highly accurate, despite last learning cycle is 68 and thus CI=118:01
PaliDocScrutinizer05, when battery is not calibrated data can be useless18:02
kerioas opposed to the currently-used data, which *is* useless all the time18:02
DocScrutinizer05so -ENODATA is correct data??? I don't see that, not a bit18:02
DocScrutinizer05Pali: you made that nonsense up18:02
PaulFertserI'd ask the power_supply maintainer about the correct behaviour.18:04
DocScrutinizer05Pali: 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"18:04
DocScrutinizer05PaulFertser: we don't talk about powersupply but about bq27200 driver18:05
Palibq is powersupply driver18:05
DocScrutinizer05if using power-supply API for that chip means that available data gets censored, then it's simply the wrong API18:05
Estel_Pali, I agree that -ENODATA is always worse than innacurate data18:07
PaulFertserDocScrutinizer05: 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.18:07
DocScrutinizer05it's always the actual hw and not the developer of a randomly picked API that defines what a driver needs to provide/support18:07
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)18:07
PaulFertserOne reason Linux is great because it provides uniform API to different hardware.18:08
DocScrutinizer05PaulFertser: no, au conttaire, we used bq27000 API18:08
DocScrutinizer05which even had a proper dump sysnode18:08
PaulFertserDocScrutinizer05: nope18:08
Estel_PaulFertser,  we're talking about different things18:08
DocScrutinizer05PaulFertser: please watch http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail218:09
Estel_btw, tell lennart about uniform things...18:09
PaulFertserDocScrutinizer05: http://paste.debian.net/244225/18:09
PaulFertserDocScrutinizer05: i wrote the platform battery driver btw. And it's certainly using the power_supply API.18:09
DocScrutinizer05I don't give a f* about which api it uses, I want it to expose all available info/data18:10
PaulFertserDocScrutinizer05: i remember that script, it's awesome. Was using direct dump of the registers. No other userspace app was using it.18:10
ShadowJKyou guys are mxinig up 5 subjects and threads of conversation18:10
PaulFertserEstel_: do not you agree that we should take this conversation to the power_supply maintainer?18:11
PaulFertserEstel_: to get his opinion to understand how the framework is supposed to be used?18:11
ShadowJKBut regardless, the data provided by bme replacement in a power_supply style is also not useful :)18:11
DocScrutinizer05why?18:11
Estel_PaulFertser,  no, as Pali is maintainer for those things in maemo, and he can fix it by 2 lines of code18:11
DocScrutinizer05hehe18:11
Estel_PaulFertser,  then, we may submit fix upstream18:11
PaulFertserI personally would prefer getting inaccurate data and a flag and then deciding myself if i can tolerate that inaccuracy.18:12
Estel_PaulFertser,  exactly18:12
PaulFertserSo yes, i prefer what Estel_ suggests18:12
DocScrutinizer05exactly18:12
DocScrutinizer05censoring perfectly sane and accurate data just because >32 cycles since last learning cycle. That's insane18:13
DocScrutinizer05and it doesn't work either18:13
PaulFertserEstel_: 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.18:13
ShadowJKAs for N900, the biggest issue is that all our datasources are bad :)18:14
PaulFertserDocScrutinizer05: agree, censoring data makes no sense at all imho18:14
DocScrutinizer05since 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 sense18:14
PaulFertserShadowJK: the bq chip should be pretty accurate though, don't you think so?18:14
Estel_Pali,  right, I've forget, that "uncalibrated" flag is also set when more than 32 cycles since last calibration18:15
ShadowJKsure, but it's programmed for 2000mAh battery, which we don't have18:15
Estel_Pali,  it makes it even more wrong, to do "ENODATA"18:15
Estel_ShadowJK,  speaks for yourself, I'm currently using 3460 mAh one :P18:15
Estel_s/speaks/speak/18:17
infobotEstel_ meant: ShadowJK,  speak for yourself, I'm currently using 3460 mAh one :P18:17
Estel_ok, adding it to wiki18:18
Estel_~bme-replacement18:18
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!18:18
ShadowJKSo 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?18:18
Estel_isn't charge_full_design took from resistor in battery, not bq chip predefined values?18:19
Estel_kerio, you lazy bastard18:21
Estel_f- word in wiki?18:21
kerioit's a wiki, fix it :P18:21
Estel_irc raw paste than no one who haven't been in that discussion understand, instead of formatting it?18:21
*** keesj has joined #maemo-ssu18:22
DocScrutinizer05ShadowJK: charge_full_design is deduced from BSI18:22
Estel_don't be afraid of properly contributing to wiki, it won't eat you :P18:22
Palihuh, big irc log... if you want to change power supply api send patch to power supply maintainer18:23
DocScrutinizer05>:-(18:23
PaliI du not want to have some patched forked version of power supply in kernel power18:23
keriojust /provide the data/ then18:23
ShadowJKI'd take a holistic approach, other drivers and other systems provide data even when not calibrated ;)18:24
kerioespecially because otherwise, the only way to access that data is to parse and do calculations on the `registers` file18:24
DocScrutinizer05I 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 month18:25
ShadowJKI guess power_supply class has no available api for expressing estimated accuracy18:26
DocScrutinizer05if you think you could use that driver with that semantics fro bme-replacement then you're pretty badly mistaken18:27
Palicorrect way for this is to use regmap api18:27
ShadowJKof 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 inaccurate18:27
DocScrutinizer05it will *never* work - it can't18:27
ShadowJKShould CHARGE* go away when VDQ goes low, or CI high?18:27
ShadowJKOr maybe user space apps interested in knowing expected accuracy should look in registers18:28
kerioShadowJK: then why fucking bother with a kernel module?18:28
ShadowJK:P18:29
DocScrutinizer05indeed18:29
kerioyes, the "registers" file holds what you'd get from i2cget18:29
keriobut if it's the only way to access the data, you might as well use i2cget18:29
ShadowJKI'd much prefer if charge*/energy* was always reported regardless of expected accuracy levels18:29
DocScrutinizer05again: if power-supply API mandates data censoring, then it's not the right API to use here18:29
ShadowJKDocScrutinizer05; dunno, the doc I read didn't18:30
DocScrutinizer05ooh 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 level18:31
DocScrutinizer05there is no such thing like register pairs on I2C18:33
Paliok, now going offline. if you want to change bq drivers send patches to power supply maintainer and/or ask what is correct solution18:33
Paliif patches will be accepted, I will backport them to kernel-power18:33
DocScrutinizer05>:-(18:33
keriowoohoo, pali being stubborn as usual18:34
DocScrutinizer05again: if power-supply API mandates data censoring, then it's not the right API to use here18:34
ShadowJKPali; so you'll ask maintianer whether driver should censor output or not?18:34
DocScrutinizer05I'm not going to ask power-supply maintainer if we are using the right API18:35
Paligoing to study measure theory..., bye18:35
ShadowJKand by censor we mean changing the output depending on CI (lmd may be inaccurate) or VDQ (NAC, CACD, CACT may be inaccurate)18:35
*** Pali has quit IRC18:35
DocScrutinizer05ShadowJK: that driver with that semantics fro bme-replacement will *never* work - it can't.18:36
kerioDocScrutinizer05: assuming pali's using it correctly18:36
DocScrutinizer05since after 32 charge cycles battery applet will display BS18:37
keriothe battery applet in normal mode shouldn't even display the charge, probably18:37
kerioin "advanced mode" it should, and it should display a tiny "(CI)" next to the charge when CI is set18:37
kerioShadowJK: how does bq27200 guesstimate the percentage when CI?18:38
ShadowJKDocScrutinizer05; there's note in the docs that drivers shouldn't infer things18:38
ShadowJKkerio; same way as usual18:38
kerioyeah but assuming which battery?18:38
DocScrutinizer05ShadowJK: yep, fine! exactly where I came from18:38
ShadowJKsame as usual, last measured discharge18:38
kerioi see18:39
ShadowJKThere's also note the drivers shouldn't make their own capacity percentage if hw doesn't provide it18:39
ShadowJKcuriously enough18:39
keriowouldn't that be inferring?18:39
ShadowJKthat's why it says should not18:40
ShadowJKinstead of should18:40
kerioit's not curious, it's sensible :)18:40
keriowhat does it say about flags?18:40
kerioor other non-numerical data18:41
*** _rd has quit IRC18:41
ShadowJKok, 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_DESIGN18:41
DocScrutinizer05well, usually such data gets masked out and displayed/provided plaintext or as 0|118:42
*** _rd has joined #maemo-ssu18:42
kerioso why didn't that happen for CI, VDQ, EDV1?18:42
ShadowJKCHARGE_FULL, CHARGE_EMPTY, full is LMD in bq, empty is always 6 percent of LMD in b, but should probably be left out18:42
ShadowJKCHARGE_COUNTER is NAC in bq18:43
ShadowJKCAPACITY is RSO18:43
Estel_grrrr18:44
Estel_what a "send a patch to mainstream" bullshit18:44
ShadowJK.. i'd map those values straight from bq27, and onlyh process it to convert to the units mandated by power-supply spec18:44
Estel_busybox-power fixed many things in busyboc and THEN send patches to mainstream18:44
Estel_that do accepted, btw18:44
DocScrutinizer05CHARGE_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. BSI18:44
Estel_which doesn't mean we need to wait for having usable thing for mainstream!18:44
ShadowJKQ: Where is POWER_SUPPLY_PROP_XYZ attribute?18:44
Estel_I've added shit to wiki18:45
ShadowJKA: If you cannot find attribute suitable for your driver needs, feel free18:45
keriobq27x00-battery isn't even in mainstream, is it18:45
ShadowJK   to add it and send patch along with your driver.18:45
Estel_If Pali won't fix it, I hope someone will fork it for maemo's sake18:45
ShadowJK   Good candidates to add in future: model/part#, cycle_time, manufacturer18:45
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 bugs18:46
ShadowJKalso: http://pastebin.com/5SNYPpm318:47
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 problem18:47
Estel_need to go out for now18:47
Estel_bye18:47
keriowait!18:48
kerioclose your string first!18:48
*** rd_ has joined #maemo-ssu18:49
DocScrutinizer05http://pastebin.com/5SNYPpm3  INDEED!18:49
DocScrutinizer05also don't infer -ENODATA from CI18:49
*** rd_ is now known as Guest5038218:49
*** _rd has quit IRC18:51
ShadowJKDocScrutinizer05; I assume the -22 in your version is to flip the sign on the mA column? :P18:56
DocScrutinizer05which -22?18:56
ShadowJKOh I thought I saw a RS -2218:57
DocScrutinizer05no, you seen $RS-2218:57
ShadowJKwhat does that do18:57
DocScrutinizer05RS=${RS:-22}18:58
ShadowJKis that like ? operator in C?18:58
DocScrutinizer05use $RS, unless empty, then use 2218:58
DocScrutinizer05so RS=22 for "bq27200.sh" but 67 for "RS=67 bq27200.sh"18:59
ShadowJKI 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 :)19:00
DocScrutinizer05you only can do that with driving a known current along that line and see what bq27200 reports as current19:00
DocScrutinizer05you'd need to decouple the battery GND line from battery for that, and connect battery/cell GND to e.g. USB shielding19:02
DocScrutinizer05then drive 1.000A from USB shield to battery minus blade of battery plug in N900 and see what that results in bq2720019:03
ShadowJK...run N900 from usb sans battery19:04
DocScrutinizer05of 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 connector19:04
DocScrutinizer05:nod:19:04
DocScrutinizer05it also doesn't need to be 1000mA, any relatively high defined constant current will do, as long as you probe it with an accurate DMM19:05
DocScrutinizer05there are more nifty methods, (like using alternating squarewave current with a freq of 0.05Hz and then analizing the average deviation) but they're cumbersome19:07
DocScrutinizer05another 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 gauge19:09
DocScrutinizer05since this won't result in any halfway constant current,  probing for point-in-time current would be meaningless for that setup19:11
*** Vlad_on_the_road has quit IRC19:17
*** Vlad_on_the_road has joined #maemo-ssu19:18
*** tg has quit IRC19:22
*** Vlad_on_the_road has quit IRC19:23
*** Vlad_on_the_road has joined #maemo-ssu19:23
*** tg has joined #maemo-ssu19:26
*** dhbiker has quit IRC19:40
*** dhbiker has joined #maemo-ssu19:43
*** sunny_s has joined #maemo-ssu20:21
*** M13 has quit IRC20:26
*** Guest50382 has quit IRC20:27
*** Guest50382 has joined #maemo-ssu20:27
*** arcean has joined #maemo-ssu21:12
*** Guest50382 has quit IRC21:36
*** sunny_s has quit IRC21:40
*** sunny_s has joined #maemo-ssu21:43
*** Guest50382 has joined #maemo-ssu21:53
*** Guest50382 has quit IRC22:10
*** luf has joined #maemo-ssu22:12
*** futpib has quit IRC22:24
*** Guest50382 has joined #maemo-ssu22:34
*** Vlad_on_the_road has quit IRC22:45
*** LauRoman has joined #maemo-ssu22:52
*** sunny_s has quit IRC22:53
*** sunny_s has joined #maemo-ssu22:56
*** nox- has joined #maemo-ssu23:01
*** Guest50382 has quit IRC23:20
*** Guest50382 has joined #maemo-ssu23:20
*** NIN101 has quit IRC23:36
*** xes has joined #maemo-ssu23:39
*** Guest50382 has quit IRC23:57

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!