| mighty17[m] | How do you guys handle poweroff for twl6030? | 05:59 |
|---|---|---|
| mighty17[m] | Or I suppose no device has that pmic? (d4 has cpapc, n900 has omap3) soo? | 05:59 |
| mighty17[m] | https://lore.kernel.org/all/1459279341-17389-1-git-send-email-contact@paulk.fr/#b can we merge this to openpvrsgx? | 08:20 |
| sicelo | mighty17[m]: it has nothing to do with powervr though | 10:00 |
| mighty17[m] | sicelo: Yeah but it didn't go in Mainline (idk why) so I asked | 10:04 |
| Wizzup | if you think it still applies you can submit it yourself | 10:07 |
| Wizzup | also see the response | 10:08 |
| Wizzup | s | 10:08 |
| lel | MerlijnWajer assigned an issue: https://github.com/maemo-leste/bugtracker/issues/590 (Try out this Maemo wiki theme) | 13:11 |
| lel | MerlijnWajer closed an issue: https://github.com/maemo-leste/bugtracker/issues/590 (Try out this Maemo wiki theme) | 13:11 |
| freemangordon | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2283 | 13:14 |
| freemangordon | :) | 13:14 |
| Wizzup | great! | 13:18 |
| freemangordon | yeah, now I can move to non-CMA allocated buffers so n900 to be usable with 5.15 | 13:20 |
| Wizzup | great :) | 13:21 |
| Wizzup | I need a bit of a great from all the kernel stuff (day or 2), but then I'll check out more pm stuff and some of the replies on the ML | 13:22 |
| Wizzup | a bit of a break | 13:22 |
| Wizzup | seems the word great is stuck somewhere | 13:22 |
| freemangordon | mhm | 13:23 |
| freemangordon | if we only can find someone to look into xorg ddx :( | 13:23 |
| freemangordon | I wonder if we can find armsoc ddx devs and ask for help | 13:25 |
| freemangordon | tmlind: do you know if there is irc channel for openpvrsgx project? | 16:21 |
| freemangordon | as it seems my patch went into the void or was ignored, in either case I would like to know what happens | 16:24 |
| bencoh | there used to be #powervr on freenode, but iirc that was the old opensource driver channel (which wasn't very activem obviously) | 16:27 |
| bencoh | oh, actually we have #powervr on libera, with the usual suspects joined there, but it's not active either | 16:29 |
| bencoh | freemangordon: ^ | 16:29 |
| freemangordon | great, thanks! | 16:32 |
| Wizzup | freemangordon: the ML might be a better place | 16:43 |
| Wizzup | bu you can try irc | 16:43 |
| freemangordon | I've send even ping on the ML | 16:45 |
| tmlind | freemangordon: not much any activity on the powervr channel, and hns only reads emails | 17:30 |
| tmlind | uvos: interesting, i accidentally did ifup wwan1 with modem configured to gsm and seem to have about 61 - 67 mW idle on d4 with modem online.. | 17:31 |
| tmlind | uvos: i mean modem online but also with network connectivity up over modem | 17:32 |
| bencoh | nice I'd say :) | 17:32 |
| tmlind | yeah.. i recall with 3g and wwan1 up it was easily over 120 mW or something like that the last time i tried | 17:33 |
| bencoh | gsm is admittedly friendlier battery-wise yes | 17:34 |
| bencoh | (something about TDM/FDM vs CMDA) | 17:34 |
| bencoh | CDMA* | 17:34 |
| tmlind | not sure if accidentally doing qmi --nas-set-system-selection-preference=gsm caused this | 17:34 |
| bencoh | ah | 17:35 |
| tmlind | bencoh: but gsm voice online consume at least the same as gsm voice + data right now.. | 17:35 |
| tmlind | maybe the data connection actually now limits the modem from doing endless network scans or something :) | 17:35 |
| bencoh | "gsm voice online" meaning during call? and what is "gsm voice + data" then? | 17:36 |
| tmlind | bencoh: no gsm voice online meaning just voice modem connected to the network with no call active | 17:36 |
| tmlind | data meaning i can ping | 17:37 |
| bencoh | so are you saying it's about the same, or that data on really gives better results? | 17:38 |
| bencoh | (from my experience on n900, it should be pretty much the same, except in case of actual network activity) | 17:38 |
| tmlind | yeah ok, maybe only 3g data consumes more power all the time | 17:39 |
| tmlind | also with v5.15 kernel, looks like the ifup wwan1 with pre-up qmi-network i posted here earlier works but not every time | 17:39 |
| Wizzup | tmlind: hm, I think uvos and I see quite a bit more, but I suppose we might have more subsystems active | 18:03 |
| Wizzup | I should replace the d4 on this lab psu since it has some hw problem that makes it use a lot more power | 18:04 |
| tmlind | Wizzup: hmm i put cpu1 offline when i blank the screen, maybe give that a try? | 18:08 |
| tmlind | echo 0 > /sys/devices/system/cpu/cpu1/online | 18:09 |
| tmlind | that seems to get rid of the constant ipi traffic | 18:09 |
| Wizzup | ok, will try that now | 18:10 |
| tmlind | i also have this looks like: | 18:10 |
| tmlind | echo 600 > /proc/sys/vm/stat_interval | 18:11 |
| Wizzup | my device is in 3g btw, and I think m-l generates quite a bit of debug (and thus mmc) traffic on modem signal strength, although we (should be) disabling that upon screen off | 18:11 |
| tmlind | ok, will check my power consumption with 3g again at some point, don't want to mess with it right now, expecting a package.. | 18:12 |
| Wizzup | heh, makes sense | 18:12 |
| Wizzup | tmlind: I think that saves quite a bit (turning one cpu off) | 19:19 |
| Wizzup | will try to properly measure, but from sleep and droid4-pm it looks like it saves maybe 200mW? | 19:20 |
| Wizzup | 20mW | 19:20 |
| tmlind | yeah so it seems | 19:35 |
| uvos | tmlind: yeah i allways use wwan1 | 20:53 |
| uvos | tmlind: i have no idea why that works best | 20:53 |
| uvos | the ipi interrupts are qutie silly yeah | 20:54 |
| uvos | we can probubly tune the scheduler to try and not have both cpus active when there is little load | 20:55 |
| Wizzup | hmmm ofono uses something else no? | 20:55 |
| uvos | Wizzup: ofono has never worked for me | 20:55 |
| uvos | except by extream massaging | 20:55 |
| uvos | by restarting it often etc | 20:55 |
| uvos | so no idea | 20:55 |
| Wizzup | can try later as well (need to make a list lol) | 20:56 |
| uvos | speaking of powermanagemnt we should maybe import androids interactive scaling govenor | 21:08 |
| uvos | i know its sortof a hack | 21:08 |
| Wizzup | it might just mostly be in mainline | 21:08 |
| uvos | sortof | 21:10 |
| uvos | the mainline version dosent have the pivitol hack :P | 21:10 |
| uvos | the pivitol hack being that it ramps up on ts events | 21:11 |
| uvos | no matter what | 21:11 |
| uvos | this avoids ui latency | 21:11 |
| Wizzup | heh | 21:14 |
| Wizzup | maybe we can turn off a core upon screen blank | 21:14 |
| uvos | sure | 21:14 |
| uvos | i could have mce do that as a hack | 21:14 |
| uvos | but really | 21:14 |
| uvos | the scheduler should be smart enough | 21:14 |
| Wizzup | yeah I am a bit surprised that it wouldn't do that by defaulty | 21:24 |
| uvos | maybe we can use cpuset to prevent kernel threads from running on the second cpu | 21:24 |
| Wizzup | yeah but that's not ideal imho | 21:25 |
| Wizzup | also it would need to be more than just kernel threads probably | 21:25 |
| uvos | i dont think our userspace dose very mutch | 21:26 |
| uvos | when ideling | 21:26 |
| uvos | but yeah its not ideal | 21:26 |
| uvos | but its somewhere between "sched is smart enougth" and "mce disables all cpus except cpu0 when display is off" | 21:27 |
| Wizzup | we'll also need to check that als and other iio stuff doesn't use more pm | 21:27 |
| uvos | in terms of suckyness | 21:27 |
| uvos | no | 21:27 |
| uvos | iio-sensor-proxy sits in select at all times | 21:27 |
| Wizzup | sure, but kernel could keep things alive when fd is open | 21:27 |
| Wizzup | or w/e is used | 21:27 |
| uvos | i closes all fds | 21:27 |
| uvos | too | 21:27 |
| Wizzup | really, how does it know? | 21:28 |
| uvos | its extreamly well behaved - i checked before porting mce over | 21:28 |
| Wizzup | or is that because mce stops talking to it | 21:28 |
| uvos | it knows if it has a dbus client | 21:28 |
| Wizzup | k | 21:28 |
| uvos | on bionic it dosent even poll the accell | 21:28 |
| Wizzup | I'm still going to block the modules just to make sure later on | 21:28 |
| uvos | when the device is on | 21:28 |
| uvos | and accel rotation is active | 21:28 |
| uvos | :) | 21:28 |
| Wizzup | maybe this is the mystery pm difference eh :P | 21:28 |
| uvos | no | 21:28 |
| uvos | but the sensor drivers may be misbehaving yeah | 21:29 |
| uvos | we should add the hw intterupts to the stm accell driver btw | 21:29 |
| uvos | the d4 chip also has the no polling feature | 21:29 |
| uvos | its just missing in the driver | 21:29 |
| Wizzup | all of this would be very valuable to write down somewhere imho | 21:30 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/591 (N900 ssi-protocol / nokia-modem causes sets in OFF mode) | 21:32 |
| lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/591 (N900 ssi-protocol / nokia-modem causes sets in OFF mode) | 21:32 |
| lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/591 (N900 ssi-protocol / nokia-modem causes sets in OFF mode) | 21:32 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/592 (N900: gpio_keys misbehave in OFF mode) | 21:33 |
| lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/592 (N900: gpio_keys misbehave in OFF mode) | 21:33 |
| lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/592 (N900: gpio_keys misbehave in OFF mode) | 21:33 |
| lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/593 (droid4: add hw interrupts to stm accel driver) | 21:46 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/593 (droid4: add hw interrupts to stm accel driver) | 21:46 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/594 (mapphones: look into disable one cpu (or better scheduling) to improve power management) | 21:50 |
| lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/594 (mapphones: look into disable one cpu (or better scheduling) to improve power management) | 21:50 |
| uvos | probubly affects pinephone just the same | 21:51 |
| Wizzup | well, the solution might be generic :-) | 21:52 |
| uvos | sure | 21:52 |
| Wizzup | other stuff we should add/note? | 21:54 |
| uvos | moving all unppinned kernel threads to one cpu via cpuset dosent seam to help | 21:56 |
| uvos | with the ipi activity | 21:57 |
| uvos | uh | 21:57 |
| uvos | i gues you could make a bug to figure out why bionic idles better | 21:57 |
| uvos | but i dont think i need one to remember | 21:57 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!