| 00:00.55 | *** join/#maemo-ssu arcean_ (~Tomek@apn-46-169-246-127.dynamic.gprs.plus.pl) |
| 00:10.20 | *** join/#maemo-ssu _LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 00:16.56 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@120.85.133.181) |
| 02:22.50 | *** join/#maemo-ssu discopig (~discopig@2001:5c0:1000:a::5cb) |
| 02:22.50 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 03:39.56 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 04:03.55 | *** join/#maemo-ssu DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 04:21.15 | *** join/#maemo-ssu chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 04:47.05 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 07:10.40 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 08:11.25 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 08:19.00 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 08:26.17 | Estel_ | DocScrutinizer05, extremely usefull info here |
| 08:26.38 | Estel_ | pity that you won't put it on wiki, as it will gest lost, and in 3 weeks no one will remember it, too |
| 08:26.53 | Estel_ | (the things about bmi, shutdown graceful and not graceful levels, etc) |
| 08:27.24 | Estel_ | kerio, and what are your experiences with no compression? :P |
| 08:28.15 | Estel_ | kerio, what do you think would it be much code change to stop behavior of missing sysfs nodes when not calibrated? |
| 08:28.18 | Estel_ | in module? |
| 08:28.49 | Estel_ | maybe forking it and 99% of sensible users using fork would convince Pali to stop selling bulls about "send patch to mainstream" |
| 08:29.18 | Estel_ | if it's small change, maintaining it over next versions of bq27x00_battery would be easy |
| 08:34.22 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 08:54.54 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 09:16.03 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 09:22.18 | *** join/#maemo-ssu kolp (~quassel@212.255.224.77) |
| 09:52.28 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 10:26.18 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-lkaecqphtlpkjnbd) |
| 10:38.34 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 11:09.23 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 11:43.07 | *** join/#maemo-ssu futpib (~futpib@89.106.197.13) |
| 13:19.48 | Pali | ping Estel_ |
| 13:19.50 | Pali | ping kerio |
| 13:21.31 | Pali | I updated bme replacement wiki |
| 13:22.12 | Pali | there is one question (at wiki): what should battery applet show when battery is not calibrated and is configured to not use rx51_battery driver |
| 13:22.31 | kerio | "<charge>/<full charge> (CI)" |
| 13:22.52 | kerio | it's already written in my proposal afaik |
| 13:37.17 | *** join/#maemo-ssu xmlich02_ (~imlich@2001:67c:1220:80c:26:8299:1985:175d) |
| 15:46.27 | discopig | hi |
| 16:31.08 | Pali | kerio, small update which allow to do not use design capacity in status menu applet |
| 16:31.12 | Pali | package is in cssu-devel |
| 16:32.26 | kerio | yay |
| 16:32.37 | kerio | what does it do if bq27k isn't calibrated? |
| 16:32.39 | kerio | 0/0? |
| 16:32.56 | Pali | Estel_, I fixed hald-addon-bme, now it does not power off device when drivers are unloaded |
| 16:33.11 | Pali | kerio, it will show message that data are no available or battery is not calibrated |
| 16:33.24 | kerio | and does the usual guesstimate for bars and percentage? alright |
| 16:33.40 | Pali | yes |
| 16:34.15 | Pali | kerio, changes are on gitorious |
| 16:34.37 | kerio | gitorious where? |
| 16:35.04 | kerio | doesn't grok gitorious' interface |
| 16:59.03 | Pali | merlin1991: I pushed new version of rtcom-messaging-ui-portrait to cssu-devel. I only changed version string to 1.0-1 and it fixed that infinity upgrade loop |
| 16:59.32 | Pali | merlin1991: add this version of package to cssu-testing list |
| 17:21.11 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28F99.dip0.t-ipconnect.de) |
| 17:24.39 | merlin1991 | Pali: I'll do |
| 17:37.36 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 17:42.07 | *** join/#maemo-ssu luf (~luf@ip-94-112-59-161.net.upcbroadband.cz) |
| 18:00.23 | Estel_ | Pali, thanks |
| 18:00.59 | Estel_ | Pali, is battery status applet also on your page, for non cssu-devel users? of course, I can install it from cssu-d, too, if not |
| 18:01.31 | Estel_ | Pali, so there remains one problem - about missing sysnode. You're not right, that it should be adressed by mainstream |
| 18:01.50 | Estel_ | look how busybox-power does it - it fixes things for maemo, *then* send patches to upstream |
| 18:01.58 | Estel_ | then, they're accepted in upstream |
| 18:02.38 | Estel_ | DocScrutinizer05, thought you may be interested in it (guy have problems with maemo repos) |
| 18:02.40 | Estel_ | http://talk.maemo.org/showpost.php?p=1331800&postcount=63 |
| 18:03.02 | Pali | Estel_, please read that email thread about bq27x al lkml |
| 18:03.22 | Estel_ | ok, any highlights to look for? |
| 18:03.49 | Pali | https://lkml.org/lkml/2013/1/19/162 |
| 18:03.53 | Pali | link is on wiki |
| 18:03.58 | Estel_ | btw, I'm mainly interested about our maemo case, not what mainstream does. It's good practice to fix for maemo, and send upstream - if they accept it it's fine, if not, fine too |
| 18:03.58 | Estel_ | ah |
| 18:04.01 | Estel_ | thanks |
| 18:04.23 | Pali | https://wiki.maemo.org/Bme_replacement |
| 18:04.24 | Estel_ | most of the times, they're much likely to accept it mainstream, if practically used "live" on some devices |
| 18:05.53 | Estel_ | Pali, seen mail on lkml, can't see hpw it is related |
| 18:06.18 | Pali | correct solution is to use debugfs |
| 18:06.22 | Estel_ | he talk about i2cget for userland, we fat about bq27x00_battery stopping censoring info for no reason |
| 18:06.33 | Estel_ | s/fat/talk/ |
| 18:06.47 | Pali | afk |
| 18:07.06 | Estel_ | correct solution is to comment out those damn 3 lines of code, that make it censor data for no practical or theoretical reason |
| 18:07.16 | Estel_ | so it always export to sysfs node what hardware tells it, period |
| 18:07.35 | Estel_ | someone who thought it's good idea to censor that data when not calibrated, was fucked in head |
| 18:07.46 | Estel_ | I must go off-line now, sorry |
| 18:08.15 | DocScrutinizer05 | yes |
| 18:40.18 | Estel_ | Pali, as a suplement - you've talked with every user of your early stage bme replacement. Everyone think censoring that sysfs node is freakin bad idea |
| 18:40.47 | Estel_ | that must mean something. BTW, if me and DocScrutinizer05 speaks the same voice, it means even more :P |
| 18:41.09 | kerio | even a broken clock etc. etc. |
| 18:51.40 | kerio | Pali: hmm, is the default to not use design now? |
| 18:51.58 | Pali | kerio, when battery is not calibrated, see wiki |
| 18:52.08 | kerio | to *not* use design i said |
| 18:52.44 | kerio | oh i see |
| 19:29.02 | *** join/#maemo-ssu arcean (~arcean@apn-95-41-251-142.dynamic.gprs.plus.pl) |
| 20:04.54 | *** join/#maemo-ssu futpib (~futpib@89.106.197.1) |
| 20:34.58 | Estel_ | Pali, new hald-addon-bme is in your page? |
| 20:35.15 | Pali | Estel_, yes, also dsme plugin |
| 20:35.18 | Estel_ | any more packages updated? |
| 20:35.20 | Estel_ | thanks |
| 20:35.25 | Estel_ | installing now |
| 20:35.29 | Estel_ | ~pali |
| 20:35.30 | infobot | from memory, pali is http://atrey.karlin.mff.cuni.cz/~pali/ |
| 20:35.35 | Pali | dsme plugin now fallback to bq27x temperature if rx51 is not available |
| 20:35.41 | Estel_ | new batt applet from cssu-dev only? |
| 20:35.47 | Estel_ | nice |
| 20:36.05 | Estel_ | ~bme-replacement |
| 20:36.06 | infobot | bme-replacement is probably 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! |
| 20:36.10 | Pali | yes, battery plugin is in cssu-devel |
| 20:37.00 | Estel_ | Pali, and what about shutdown, was it fixed? |
| 20:37.04 | Estel_ | edv1 and co? |
| 20:37.16 | Pali | not implemented yet |
| 20:37.17 | Estel_ | I want to update wiki if smth is solved |
| 20:37.19 | Estel_ | OK |
| 20:37.20 | Pali | it shutdown at edv1 |
| 20:37.29 | Estel_ | but one can unload modules |
| 20:37.42 | Pali | yes |
| 20:37.43 | Pali | https://gitorious.org/community-ssu/status-area-applet-battery/commit/3d3599743a598a833c1ecfa886ebf53fb6d11a12 |
| 20:38.02 | Estel_ | all right, I want to maintain wiki up to date, as no one else seems to be interested in it (and you're, rightly so, busy with coding) |
| 20:40.19 | Estel_ | please, Pali, include that gconf value to set up own shutdown limit, too :P |
| 20:40.34 | Pali | ok, later |
| 20:40.49 | Estel_ | best would be to make it inclusive or exclusive with edv1 |
| 20:40.53 | Estel_ | so, 2 gconf values |
| 20:41.00 | Estel_ | one for treeshold voltage |
| 20:41.22 | Estel_ | and one that triggers behavior of watching for shutdown voltage only after edv1 flag |
| 20:42.09 | Estel_ | so, for example, 3000 mV shutdown from first gconf value, but triggered only, id edv1 flag was set (if 2nd gconf value, for example, "wait_for_edv1" is 1) |
| 20:42.21 | Estel_ | or doesn't care about edv1 flag, if set otherwise |
| 20:42.45 | Estel_ | it allow to rise voltage for devices with gsm problem, or lower it for dual-cells, ignoring spikes (due to waiting for edv1) |
| 20:42.49 | Estel_ | Pali ^ |
| 20:43.30 | Pali | Estel_, next simple patch will be to replace #define VOLTAGE with value from gconf |
| 20:43.35 | Estel_ | OK |
| 20:43.39 | Estel_ | looks great |
| 20:43.55 | Estel_ | but you said voltage will be significant only, if edv1 flag isn't exported by kernel |
| 20:44.15 | Estel_ | it would be nice to have this gconf value working even, when kernel properly exports edv1 flag |
| 20:44.25 | Pali | I will add gconf value to disable edv1 |
| 20:44.33 | Estel_ | ok |
| 20:44.37 | Pali | (I wrote that on wiki) |
| 20:44.50 | Estel_ | so I'm talking about - it's good idea to make it inclusive, no exclusive |
| 20:45.15 | Estel_ | so one could have both $voltage from gconf AND edv1 gconf |
| 20:45.29 | Estel_ | = shutdown at $voltage, but only if edv1 flag is set |
| 20:45.45 | Pali | inclusive is simple, exclusive will be hard to write |
| 20:45.51 | Estel_ | or, when edv1 gconf is 0, shutdown at $voltage (ignoring edv1 totally) |
| 20:46.17 | Estel_ | I think most people that are willing to change shutdown voltage would like to have it inclusive with edv1 |
| 20:46.35 | Estel_ | to ensure that low voltage spike won't make device shutdown before edv1 flag |
| 20:46.53 | Estel_ | voltage can drop even to 3000 mV, without edv1 flag still in place, as it needs 15 seconds |
| 20:47.36 | Estel_ | Pali, I'm glad inclusive will be easy to write, but it will work for people that want RISING voltage, too? |
| 20:47.47 | Estel_ | for example, shutting down at 3300 mV? |
| 20:47.54 | Estel_ | (for people with gsm modem problems) |
| 20:48.17 | Estel_ | edv1 will be never set, then, so 3300 mV won't work without exclusive |
| 20:48.41 | Estel_ | flexibility is key here, to less rewrites later |
| 20:49.07 | Estel_ | when everyone will be able to set whatever fancy scenario, no one will pester you about features/bugs, later :P |
| 20:51.05 | Estel_ | Pali, I've seen your info about i2c_slave |
| 20:51.12 | Estel_ | problem is, no one know how to use it :P |
| 20:51.17 | Estel_ | properly |
| 20:51.24 | Pali | Estel_, what? |
| 20:51.39 | Estel_ | from wiki, you said that problems can be solved by using i2c_slave |
| 20:51.58 | Estel_ | I2C_SLAVE_FORCE |
| 20:52.17 | Pali | you can use i2cget without problem with force flag |
| 20:52.23 | Estel_ | no idea how to do it, properly, as no one want to access i2c wrong way and fuck something up |
| 20:52.31 | Estel_ | I see |
| 20:52.40 | Pali | use *only* for bq27200 |
| 20:52.45 | Estel_ | so it's just a matter of proper i2cget command syntax? |
| 20:52.46 | Estel_ | yes |
| 20:52.50 | Pali | i2cget -f |
| 20:53.02 | Pali | (check if -f is really force, but I think yes) |
| 20:53.07 | Estel_ | and it stop complaining about resource in use? |
| 20:53.10 | Estel_ | ok |
| 20:53.24 | Estel_ | well, lemme check it, if I dissappear, it mean something went wrong :P |
| 20:53.27 | Pali | and double check if you are sending command to bq27200 address |
| 20:54.48 | Estel_ | you're right, it works |
| 20:54.56 | Estel_ | how to determine that addres is bq27200? |
| 20:55.02 | Estel_ | address* |
| 20:55.46 | Estel_ | 0x55 |
| 20:55.50 | Estel_ | is bq27200? |
| 20:56.50 | Estel_ | it solves many problems, then |
| 20:57.23 | Estel_ | I still think sysfsnode shouldn't censor data, but I can at least workaround it by using 82cget directly |
| 20:57.28 | Estel_ | not ideal, but at least works |
| 20:58.03 | Estel_ | I appreciate you work on this, Pali, and I'm glad I could contribute by at least wiki |
| 20:58.29 | Pali | ok |
| 20:58.49 | Estel_ | just don't, *ever*, write "send patch to upstream", when we report something valid :P It makes people go berseker |
| 21:09.40 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 21:14.01 | DocScrutinizer05 | >>dsme plugin now fallback to bq27x temperature if rx51 is not available<< WTF? bq27x temperature is as meaningless as my little toe's temperature |
| 21:15.08 | DocScrutinizer05 | actually tempreature from bq27200 is the most useless and void-of-any-meaning value you can read out from that chip |
| 21:16.45 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 21:17.28 | Estel_ | DocScrutinizer05, except for the fact, that, in reality, it's always same as rx51 temperature :P |
| 21:17.45 | Estel_ | i.e. difference never exceeds 1C |
| 21:17.59 | Estel_ | and rarely ever exceeds 0.5C |
| 21:18.31 | Estel_ | also, nothing ever use that temperature for any real-life purpose, so we can safely ignore it? or I'm wrong? |
| 21:19.05 | ShadowJK | would expect bq27 temp to be close to that of the pcb it sits on |
| 21:19.14 | DocScrutinizer05 | yeah, and temperature difference between my living room and outside rarely ever is >2°C (in spring and autumn, when my windows are opened wide) - MEH, the one is battery tempreature and the other one some bogus bullshit |
| 21:19.29 | Estel_ | I think that Pali followed our suggestion, that presenting not-accurate data is better than no data at all :P |
| 21:19.36 | Estel_ | why bogus? |
| 21:20.02 | DocScrutinizer05 | because that chip is not even near to battery cell |
| 21:20.31 | DocScrutinizer05 | and no, that value isn't useless or unused, bme uses it for batterty safety monitoring I'd say |
| 21:20.47 | Pali | dsme needs some value and what is better? some hardcoded? some reported by bq27200? |
| 21:20.48 | ShadowJK | I don't think either are very close to the batteri |
| 21:20.59 | DocScrutinizer05 | dang, my ignore filter failed |
| 21:21.12 | Estel_ | Pali, definitelly reported by bq27200 is better than hardcoded |
| 21:21.36 | ShadowJK | But the thermistor attached to madc is first source, right? |
| 21:21.50 | Estel_ | DocScrutinizer05, not very mature to use some bullshit ignore filter as argument in civilized discussion, really *shrug* feel free to leave conversation, though |
| 21:21.50 | DocScrutinizer05 | for cell temperature? there's only ONE "better", the theristor labeled "battery temp" in schematics |
| 21:21.56 | Estel_ | ShadowJK, yes |
| 21:22.10 | ShadowJK | Estel_; right |
| 21:22.11 | Estel_ | fallbacks to bq27200 only if rx51 one isn't available |
| 21:22.25 | ShadowJK | So I'd agree that bq27 is better than nothing |
| 21:22.36 | ShadowJK | For sure better than the one in omap :) |
| 21:22.39 | Estel_ | DocScrutinizer05 fails to understand, that dsme need *some* temperature to function |
| 21:22.50 | DocScrutinizer05 | this is a safety relevant design detail, you shouldn't mess with it |
| 21:22.56 | Estel_ | so if not bq27200, we would use dummy hardcoded palceholder |
| 21:23.05 | Estel_ | placeholder, even |
| 21:23.46 | ShadowJK | As long as madc continues to function, and battery temp thermistor stays attached, dsme will use exactly the same data as before, right? |
| 21:23.55 | Estel_ | ShadowJK, yes |
| 21:24.01 | ShadowJK | right.. |
| 21:24.17 | DocScrutinizer05 | ShadowJK: if those guys can't get the ADC-4(?) readout, then for sure they should SHUT DOWN that crap, and not try to handle LiIon cell based on some guestimate about cell temperature |
| 21:24.46 | Estel_ | can't agree, no temperature can be due to unloaded module or whatever |
| 21:25.21 | Estel_ | I want to be able to unload some module for debugging or whatsnit, without device shutting down in flames, because someone thought it's good idea to hardcode it. |
| 21:26.22 | *** join/#maemo-ssu XDS2010 (uid1218@gateway/web/irccloud.com/x-rjvqqxnpeguhkvmc) |
| 21:26.40 | ShadowJK | The battery temp sensor is kinda useless anyway, with that big air gap (or was it air gap + shield?) between it and battery :/ |
| 21:26.50 | Estel_ | agreed. |
| 21:27.05 | Estel_ | air+ shield, in fact |
| 21:27.19 | DocScrutinizer05 | not at all, the battery temp sensor is in contact with shield which in turn is in *tight* contact with battery |
| 21:27.42 | Estel_ | sure, with insulating layer between. and definitelly not "tight" |
| 21:28.04 | Estel_ | only springs are tight, without them battery can fell of on it's own |
| 21:28.24 | Estel_ | s/can/will always/ |
| 21:28.48 | Estel_ | springs, otoh, touch even thicker plastic insul. layer |
| 21:28.57 | ShadowJK | Oh I remembered it as the batt thermistor not touching anything at all except for the point it's soldered to the pcb |
| 21:29.21 | Estel_ | Because it's that fckin way |
| 21:29.29 | ShadowJK | ah lol |
| 21:29.29 | DocScrutinizer05 | feels like watching those experts who go like "that fuse is useless anyway, so let's use a nail to short it" |
| 21:29.31 | Estel_ | IDK why DocScrutinizer05 thinks it's attached to shield |
| 21:30.06 | Estel_ | in contact = may accidentaly touch it, from time to time, or not at all |
| 21:30.31 | Estel_ | before it would detect any temp. change, it would be dissicipated in whole ground plane already |
| 21:30.40 | ShadowJK | hm, if I used my 1000mR battery, I'd get some mean heat dissipation, wonder if that would provoke bigger temperature gradients |
| 21:30.47 | Estel_ | and bq27200 temp sensor would know it already, too |
| 21:31.37 | Estel_ | belive me, when I got some overheating batteries, that rx51 sensor was last thing that knew about it |
| 21:31.47 | Estel_ | I first felt it through backcover, lol |
| 21:32.03 | Estel_ | 30 seconds later sensor started to notice slowly rising temp |
| 21:32.28 | ShadowJK | Never had a situation like that myself |
| 21:32.31 | Estel_ | when backcover was 60C already |
| 21:32.42 | ShadowJK | Except on N810 |
| 21:32.56 | Estel_ | I had some funny batteries around |
| 21:33.47 | Estel_ | Pali, you said unloading both bq27x00_battery and rx51_battery won't cause reboot now. So dsme will work despite no temp. readings? |
| 21:34.44 | Pali | Estel_, I tested it and no reboot, but I do not know what will dsme do if it will not receivce temperature for 1hour/1day... |
| 21:34.49 | Estel_ | btw, keeping fuse analogy... we're talking about "if that fuse fails, let's redirect it through another fuse", instead of using hardcoded value, with would be exactly using a nail. |
| 21:35.06 | DocScrutinizer05 | oh fine. some self-certified experts declare battery sensor useless and thus suggest to replace its readout by a hardoced value or even some unrelated bogus shit. FINE, will you next redefine cmt to be a LTS modem? |
| 21:35.14 | Estel_ | Pali, OK. |
| 21:35.23 | Estel_ | DocScrutinizer05, you're talkung bullshit, no one replaces anything. |
| 21:35.39 | Estel_ | we use 2nd value, when 1st value is unavailable. |
| 21:36.01 | ShadowJK | New behaviour identical to previous in all normal conditions |
| 21:36.08 | Estel_ | 1st - marginal chances of that ever happening 2nd - if that ever happens, it's better than use hardcoded thing not related to anything |
| 21:36.15 | Estel_ | ShadowJK, exactly. |
| 21:36.18 | Pali | DocScrutinizer05, write solution what to do when rx51_battery driver is not loaded |
| 21:36.26 | DocScrutinizer05 | except that sensor is exactly NOT about _normal_ situations |
| 21:36.31 | Pali | and reboot/shutdown device is not solution |
| 21:36.32 | Estel_ | DocScrutinizer05 preffer shutdown, then. |
| 21:36.34 | Estel_ | I don't agree |
| 21:38.48 | Estel_ | I would like that energy spent on improving bme replacement wiki, or convincing that cripplig sysfs nodes is bad idea :P |
| 21:39.49 | Estel_ | instead of arguing about bullshit temp. readout, which, in practical life, is completely irrelevant (meaning anything only in theoretical situations, and even there, discussably) |
| 21:40.36 | DocScrutinizer05 | btw wtf is adc-x via anything bme related? |
| 21:41.40 | Estel_ | Pali, version number of packages haven't changed on your page, but content changed? |
| 21:42.04 | Pali | yes |
| 21:42.07 | Pali | look at date |
| 21:42.11 | Estel_ | hald-addon-bme and dsme-thermaobject, yes? |
| 21:42.12 | Estel_ | ok |
| 21:42.29 | Estel_ | if you would, in future, bump versions, it would be less asking you about it |
| 21:42.34 | Estel_ | just a suggestion |
| 21:43.09 | DocScrutinizer05 | and wtf would it ever be "not available"?? |
| 21:43.57 | Estel_ | DocScrutinizer05, due to rx51_battery module being not loaded. |
| 21:44.39 | DocScrutinizer05 | pukes a little while heading out |
| 21:45.10 | Estel_ | take your time and have all pleasure ;) |
| 21:48.11 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 21:50.10 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 21:50.14 | *** join/#maemo-ssu freemangordon_ (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 21:50.52 | *** part/#maemo-ssu freemangordon_ (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 21:52.08 | DocScrutinizer05 | on a sidenote: if nokia had thought bq27200 temp was *any* useful for battery overtemp/undertemp(!) protection, don't you think they *happily* had saved that thermistor from the BOM? |
| 22:03.38 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:17.08 | DocScrutinizer05 | btw while N1110 (bat temp thermistor) is indeed close to battery and has even direct airflow contact (I admit the direct material contact to shield I seen been a debris), the N1130 (bq27200) is not *under* the battery but >10mm aside from it, separated by shiled, plastic, and a second tight shielding can that's virtually entirely NOT under battery, rather it's close to heat sources like e.g. camera flash LEDs and even uSD |
| 22:18.10 | DocScrutinizer05 | s/N1110/R1110/ |
| 22:20.53 | DocScrutinizer05 | and a rationale about keeping "bme" operational while unloading the module that probes the thermistor needed for "bme" is about as sensible as asking for flash LEDs staying operational while unloading the cam driver |
| 22:23.17 | DocScrutinizer05 | actually bq24150-bme.ko should *directly* read out the thermistor to unconditionally shut down charging when over/undertemp |
| 22:24.17 | DocScrutinizer05 | and it should be kernel directly signalling dsme about thermal shutdown needed, to protect device from damage |
| 22:25.40 | DocScrutinizer05 | and when dsme doesn't react, kernel MUST shut down autonomously, when temperature is rising another 2°C |
| 23:20.53 | *** join/#maemo-ssu DocScrutinizer51 (~lagrange@lagrange.cloud-7.de) |
| 23:22.44 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 23:41.24 | *** join/#maemo-ssu discopig (~discopig@2001:5c0:1000:a::7f3) |
| 23:41.24 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |