| Wizzup | sicelo: with improved pm it makes much more sense for us to try to see what's up with the calls | 01:58 |
|---|---|---|
| Wizzup | (audio) on n900 | 01:58 |
| Wizzup | for me the n900 i/o is still slower than I'd expect it to be | 02:47 |
| Wizzup | but maybe my sd card is poor (I think I got this one for free..) | 02:47 |
| freemangordon | Wizzup: yes (one wire change) | 07:21 |
| freemangordon | tmlind: according to MC13783 we can read for pairs of battery U/I samples at once, have you ever tried that? | 08:33 |
| freemangordon | hmm, actually this seems to be already supported byt the iio driver | 08:52 |
| freemangordon | tmlind: please help, I have hard times understanding what in_voltage16_xxx and in_current17_xxx are in terms of cpcap iio driver | 09:43 |
| freemangordon | my gut feeling tells me those shall read 8 samples of battery voltage and 4 pairs of battery voltage/current, but I can't understand how shall I get to those | 09:44 |
| freemangordon | or, maybe this is not implemented? | 09:44 |
| freemangordon | this https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1.y/drivers/iio/adc/cpcap-adc.c#L148 | 09:45 |
| tmlind | freemangordon: 16 and 17 seem to be some battery related values | 12:38 |
| tmlind | probably not ocv values though, but maybe some longer term sampling values? | 12:39 |
| freemangordon | tmlind: IIUC MC13783 UG correctly, those should provide either 8 samples of voltage in a row or 4 pairs of voltage/current in a row | 12:40 |
| tmlind | see the driver for "remuxed" for those two channesl | 12:40 |
| freemangordon | yes, but driver seems to read only one value | 12:40 |
| tmlind | oh so is the mc13783 actually saying something about those two extra channels? | 12:40 |
| freemangordon | yes | 12:40 |
| tmlind | interesting | 12:40 |
| freemangordon | see 9.5.1 | 12:41 |
| tmlind | ok | 12:41 |
| freemangordon | if we have that in cpcap, then we'll be able to estimate charge without coloumb | 12:41 |
| tmlind | yeah i think they provide multiple samples, no idea for how long period though | 12:42 |
| freemangordon | because we'll have correct readings of BATT and BATTISNS | 12:42 |
| freemangordon | tmlind: but, I have hard times finding how to return those smaples to userspace | 12:43 |
| freemangordon | seems read_raw_multi() is limited to 4 values | 12:43 |
| freemangordon | iio core that is | 12:43 |
| tmlind | hmm | 12:44 |
| tmlind | i think the driver currently only works in single channel mode though | 12:44 |
| freemangordon | also, iiuc vendor kernel reads 8 values at once | 12:45 |
| tmlind | ok then maybe the mainline kernel can too, we should have it initialized to the same register values | 12:45 |
| freemangordon | see adc_result() in vendor kernel | 12:46 |
| freemangordon | it does for (i = CPCAP_REG_ADCD0; i <= CPCAP_REG_ADCD7; i++) { ... | 12:46 |
| freemangordon | but then again, how to return 8 values? | 12:47 |
| tmlind | no idea.. | 12:47 |
| freemangordon | :( | 12:47 |
| freemangordon | would upstream accept if I use low/half words of those 4 inegers to store 16bit signed values? | 12:48 |
| freemangordon | low/high | 12:48 |
| freemangordon | sounds terrible though | 12:48 |
| freemangordon | tmlind: hmm, about single-channel: | 12:49 |
| freemangordon | "In single channel mode, with RAND=1, ADSEL=0, ADA1[2:0]=001, the converted result is available in 4 pairs of battery voltage and current reading" | 12:49 |
| freemangordon | I just cannot find the equivalent BATICON bit in cpcap | 12:50 |
| tmlind | what are the four registers to read from? | 13:01 |
| tmlind | or is that 8 registers then? | 13:01 |
| tmlind | my guess is the stock v3.0.8 kernel is using this mode, so comparing register values should make the mode work | 13:02 |
| freemangordon | those are 8 channels | 13:02 |
| freemangordon | still, there is one bit I cannot find | 13:03 |
| freemangordon | BATICON | 13:04 |
| freemangordon | without that set we'll have no input current sense readings | 13:04 |
| tmlind | have you checked v3.0.8 kernel ADC_* defines in include/linux/spi/cpcap-regbits.h? | 13:09 |
| freemangordon | yes | 13:09 |
| tmlind | ok | 13:10 |
| freemangordon | maybe it is CPCAP_BIT_AD4_SELECT | 13:11 |
| freemangordon | this is nowhere used though | 13:11 |
| freemangordon | well, I can start setting bits until I get 4x2 similar readings :) | 13:12 |
| freemangordon | but, lets first verify the theory: | 13:12 |
| freemangordon | if we have correct readings of battery voltage *and* current, samples take at exactly the same moment, that will allow us to correctly calculate Ri and thus OCV, no? | 13:13 |
| tmlind | yup | 13:14 |
| tmlind | well i know nothing about the OCV part | 13:14 |
| freemangordon | also, do I get it right that despite that we read one channel actually all 8 channels ard ADC-ed? | 13:14 |
| freemangordon | *are | 13:14 |
| tmlind | yes might be | 13:15 |
| freemangordon | ok | 13:15 |
| tmlind | but these two extra channels are special somehow, they need to be muxed/routed or something to read the saved values | 13:15 |
| freemangordon | I don;t get that part - what do you mean 'mixed'? | 13:16 |
| freemangordon | value1 |= CPCAP_BIT_RAND1; ? | 13:17 |
| tmlind | well those two extra channels seem to be sampling in the back ground, and to read the values you need to partially reconfigure the adc to read those two extra channels or something | 13:18 |
| freemangordon | this is not clear from the driver code. Or I don;t get it | 13:18 |
| freemangordon | I am still reading through it | 13:19 |
| freemangordon | the only special thing I can found about it is this https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1.y/drivers/iio/adc/cpcap-adc.c#L558 | 13:19 |
| tmlind | yeah i'm totally unsure about this too, might be worth checking the v3.0.8 kernel.. | 13:19 |
| freemangordon | they have this CPCAP_ADC_TYPE_BATT_PI type there | 13:20 |
| freemangordon | which does value1 |= CPCAP_BIT_RAND1; | 13:20 |
| freemangordon | hmm: | 13:21 |
| freemangordon | if (req->type == CPCAP_ADC_TYPE_BATT_PI) | 13:21 |
| freemangordon | tbl_index = (tbl_index % 2) ? CPCAP_ADC_BATTI_ADC : | 13:21 |
| freemangordon | CPCAP_ADC_BATTP; | 13:21 |
| freemangordon | looks like I am on something :) | 13:21 |
| freemangordon | this looks exactly like even channels being U and odd - I | 13:22 |
| tmlind | ok | 13:23 |
| freemangordon | will put some printks | 13:23 |
| tmlind | you are aware of REGMAP_ALLOW_WRITE_DEBUGFS, right? | 13:23 |
| tmlind | define it in the driver | 13:23 |
| freemangordon | I prefer to patch the driver | 13:23 |
| tmlind | ok | 13:23 |
| freemangordon | ok, thanks, will let you know if I have any progress :) | 13:24 |
| tmlind | ok cool | 13:24 |
| freemangordon | Wizzup: is kernel 6.1.y released? | 13:41 |
| freemangordon | I mean maemo-6.1.y branch? | 13:43 |
| freemangordon | tmlind: heh https://pastebin.com/6f7ffLQu | 13:53 |
| freemangordon | :) | 13:53 |
| freemangordon | I don;t understand why there is a difference though | 13:55 |
| Wizzup | freemangordon: I am not sure if I understand your question, do you mean did kernel.org release it? | 13:59 |
| Wizzup | I think if we are at 6.1.y then that usually means it is, as I think uvos rebases on stable | 13:59 |
| freemangordon | no, do we released it, like if we have it in the repo | 14:00 |
| freemangordon | at least chimaera is on 6.1.0.9-1+m7.1 | 14:00 |
| freemangordon | so maybe it is released for beowulf only | 14:00 |
| freemangordon | if at all | 14:00 |
| Wizzup | huh | 14:01 |
| Wizzup | I think it's on the devices? | 14:01 |
| freemangordon | 6.1.0.9-1+m7.1 is -rc8 or something | 14:01 |
| Wizzup | maybe we did not rebase on stable | 14:01 |
| freemangordon | what do you mean 'devices'? my d4 is device, no? :p | 14:01 |
| Wizzup | my device is some 6.1.x | 14:02 |
| Wizzup | I don't know if it is rc or stable | 14:02 |
| Wizzup | probably best to ask uvos, or take my word for it :D | 14:02 |
| Wizzup | he's been managing it | 14:02 |
| freemangordon | what apt-cache policy linux-image-omap says about it? | 14:02 |
| Wizzup | I am restarting my d4 since the screen did not want to turn on, even though it was in leste | 14:02 |
| Wizzup | so give me a minute | 14:03 |
| Wizzup | but I am sure it will show the same as yours | 14:03 |
| freemangordon | maybe you have -experimental enabled, thas whay | 14:03 |
| freemangordon | *why | 14:03 |
| tmlind | freemangordon: cool so looks like you have some data :) i don't understand what difference you're talking about though.. do you mean variation in the sampled data? | 14:03 |
| freemangordon | yes | 14:03 |
| freemangordon | betweeh channel 16 and 17 | 14:03 |
| tmlind | don't you get values both for 16 and 17 the same time? | 14:04 |
| tmlind | if you read 16 separately from 17, then it's a new set of sampled values for 17 already? | 14:04 |
| freemangordon | both seems to produce U/I pairs, but reading 16 seems to produce slightly high I readings | 14:05 |
| freemangordon | no, values for 16 and 17 are in consecutive reads | 14:05 |
| freemangordon | one read reads 8 channels | 14:05 |
| freemangordon | producing 4 pairs of values | 14:06 |
| freemangordon | see the patch | 14:06 |
| freemangordon | so, it seems setting CPCAP_BIT_RAND1 is enough for multi-channel read | 14:07 |
| tmlind | ok | 14:08 |
| Wizzup | freemangordon: it says 6.1.0-rc8 for me | 14:10 |
| Wizzup | bbiab | 14:10 |
| Wizzup | (uname -a) | 14:10 |
| freemangordon | Wizzup: does not sound like .y :) | 14:10 |
| freemangordon | same here though | 14:10 |
| freemangordon | -rc8 | 14:10 |
| freemangordon | so, we have 6.1.y, but not released it seems | 14:10 |
| Wizzup | how about this | 14:11 |
| Wizzup | the branch was called .y as -rc already | 14:11 |
| Wizzup | and we never actually rebased upon release | 14:11 |
| freemangordon | no, because I just built it: | 14:11 |
| freemangordon | Linux devuan-droid4 6.1.9-34584-gf5555be2e326-dirty #2 SMP PREEMPT Sat Mar 18 12:37:36 UTC 2023 armv7l GNU/Linux | 14:11 |
| Wizzup | ok, weird... | 14:11 |
| Wizzup | maybe uvos didn't release | 14:11 |
| Wizzup | bbiab now | 14:12 |
| freemangordon | mhm | 14:12 |
| freemangordon | at least that boots :) | 14:12 |
| arno11 | Hi guys. what is controlling apt-worker on startup? | 14:18 |
| freemangordon | HAM | 14:18 |
| arno11 | it causes slowness during several minutes | 14:18 |
| arno11 | ok | 14:18 |
| freemangordon | well, it does apt-get update | 14:19 |
| freemangordon | more or less | 14:19 |
| arno11 | more | 14:19 |
| arno11 | yes i know | 14:19 |
| arno11 | that s the problem | 14:19 |
| arno11 | there was a similar issue in fremantle iirc | 14:20 |
| freemangordon | right | 14:21 |
| sixwheeledbeast | is it the same thing that checks repos every 24hour? | 14:21 |
| freemangordon | yes | 14:21 |
| arno11 | that's why the 2 first boots with clean chimaerq are complicates | 14:22 |
| sixwheeledbeast | there was some setting for that | 14:22 |
| freemangordon | you wanted fremantle experience, no :p | 14:22 |
| * freemangordon hides | 14:22 | |
| arno11 | no probs for me | 14:22 |
| freemangordon | it is responsible for the blinking yellow icon "update available" in the status menu | 14:23 |
| freemangordon | you can set the check timeout though | 14:23 |
| freemangordon | don;t remember where in gconf is the parameter | 14:23 |
| arno11 | no probs | 14:24 |
| arno11 | i know the parameters | 14:24 |
| arno11 | but on clean install it s complicated | 14:24 |
| arno11 | because of slowness | 14:24 |
| arno11 | that s why i m asking | 14:25 |
| arno11 | i think it should be easier if it was complately disable on fresh install | 14:27 |
| arno11 | i mean from user POV | 14:27 |
| freemangordon | why? like, when will apt-get update happen then? | 14:29 |
| arno11 | on first boot with no swap and rootfs not extanded device is really slow | 14:30 |
| arno11 | when you try | 14:30 |
| arno11 | connecting to wifi | 14:30 |
| arno11 | apt-worker start | 14:30 |
| arno11 | and device is unresponsive | 14:30 |
| freemangordon | but that means that we shall enable swap and extend rootfs, no? | 14:30 |
| arno11 | yes indeed | 14:31 |
| arno11 | but on first boot apt-worker arrive too quickly | 14:32 |
| arno11 | with 100% cpu | 14:32 |
| arno11 | on n900 it means too much processes at same time | 14:34 |
| arno11 | killing it quickly solve issue | 14:34 |
| arno11 | but not really user friendly lol | 14:34 |
| freemangordon | did you check the nice value? | 14:38 |
| arno11 | ? | 14:40 |
| freemangordon | the process priority | 14:40 |
| freemangordon | apt-worker process | 14:40 |
| freemangordon | it should run with low prio (high nice value) | 14:41 |
| freemangordon | if not, something got broken | 14:41 |
| arno11 | ah ok i understand | 14:41 |
| freemangordon | so, if it runs with low prio, 100% cpu usage is not an issue | 14:42 |
| arno11 | i ve to check | 14:42 |
| arno11 | makes sense | 14:42 |
| freemangordon | and most-probably slowness comes from lack of memory | 14:42 |
| freemangordon | mamory/swap | 14:42 |
| freemangordon | *memory | 14:42 |
| freemangordon | have to run, ttyl | 14:43 |
| arno11 | ok | 14:43 |
| arno11 | thx | 14:43 |
| arno11 | ttyl | 14:43 |
| sixwheeledbeast | gconftool -g /apps/hildon/update-notifier/check_interval | 14:54 |
| sixwheeledbeast | it's in hours | 14:54 |
| arno11 | yes no surprise 24 hours | 14:57 |
| arno11 | like fremantle | 14:57 |
| arno11 | but do you think setting a big value will be persistent? | 14:59 |
| arno11 | anyway set 2147483647 | 15:06 |
| arno11 | let's see if it works | 15:06 |
| sixwheeledbeast | well I recall 5 years being common mod, but I don't believe it stops the check on boot? | 15:08 |
| arno11 | agree | 15:10 |
| arno11 | i reboot and we'll have the answer | 15:12 |
| arno11 | surprisingly seems deactivated on boot | 15:22 |
| sixwheeledbeast | check interval and the orange notification have separate keys | 15:23 |
| arno11 | interval has not been reset | 15:24 |
| arno11 | cooll | 15:24 |
| arno11 | orange notif has never worked in leste with my device | 15:27 |
| arno11 | anyway that's fine | 15:29 |
| Wizzup | arno11: I think the i/o load is weird | 15:44 |
| Wizzup | on n900 | 15:44 |
| Wizzup | it really slows down a lot | 15:44 |
| arno11 | really ? | 15:44 |
| Wizzup | maybe my card is slow | 15:45 |
| Wizzup | but that is what I think I see | 15:45 |
| Wizzup | I have emmc swap and memory was nowhere near full | 15:45 |
| Wizzup | but apt indeed slows down device a lot | 15:45 |
| Wizzup | and I think it is i/o related | 15:45 |
| arno11 | so probably the sdcard ? | 15:46 |
| arno11 | or 125mhz opp | 15:46 |
| arno11 | still slow if you use cpufreq performance mode ? | 15:49 |
| Wizzup | arno11: will check in a bit | 16:25 |
| arno11 | ok | 16:28 |
| freemangordon | tmlind: ok, with proper phase and convert I am getting sane values for U/I pairs | 16:28 |
| freemangordon | with charger connected | 16:29 |
| freemangordon | https://pastebin.com/4myM02CV | 16:29 |
| tmlind | freemangordon: cool. if you read the values in a loop, do they only update every 250ms? | 16:32 |
| tmlind | i recall that's what the sample rate configure is | 16:33 |
| freemangordon | could be | 16:33 |
| freemangordon | but, I am not reading in a loop | 16:33 |
| freemangordon | also, I think sample rate can be changed | 16:33 |
| tmlind | yeah probably no need to change it, just wondering | 16:35 |
| freemangordon | anyway, now the question is - how to provide that info to battery driver? | 16:35 |
| tmlind | the battery driver can use the iio api.. how about calculate average for voltage and current and provide only two values? | 16:37 |
| tmlind | or four values of mW? | 16:38 |
| freemangordon | I was thinking abot that | 16:38 |
| freemangordon | *about | 16:38 |
| freemangordon | but that will not allow me to correctly calculate Ri | 16:38 |
| tmlind | hmm knowing the voltage is important too.. | 16:38 |
| freemangordon | anyway, have to run now | 16:38 |
| tmlind | yeah ttyl | 16:38 |
| freemangordon | ttyl | 16:38 |
| freemangordon | tmlind: I think I got it. First of all - channels 16&17 are not really correct - basically both do ADC on channels 0/1, because CPCAP_BIT_ADA0..3=000. CPCAP_BIT_ADAx are used for channel selection when doing single channel ADC | 22:57 |
| freemangordon | in general, single-channel adc gets 8 samples of the same channel, besides when BATICON (the mystery bit) is set, then 4 pairs of U/I are taken | 23:02 |
| freemangordon | CPCAP_BIT_RAND1 selects single channel ADC | 23:03 |
| freemangordon | maybe in cpcap this bit is missing and channel 0 is always read as pairs while the other channels are read normally (8 samples) | 23:04 |
| freemangordon | BTW, there is MC13892 pdf available that has some more info, includein calibration and couloumb counter | 23:06 |
| maemish_ | Started to search info cause wanted to understand your finds. Found this but did not help me. https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/cpcap-adc.c#L1 | 23:15 |
| freemangordon | hmm? | 23:16 |
| freemangordon | you don;t really want to go into that | 23:17 |
| freemangordon | tmlind: sorry, not channel 0 but channel 1 | 23:17 |
| freemangordon | I will play a bit more with it though | 23:18 |
| freemangordon | but, maybe doing average of 4 samples and returning as a pair (which iio read_raw() allows) is the way to go | 23:19 |
| maemish_ | https://www.irccloud.com/pastebin/xDenGoO0 | 23:24 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!