| sicelo | Wizzup: looks like the dma patch is no longer enough in 6.1 :'( | 10:53 |
|---|---|---|
| Wizzup | sicelo: usually I had to manually call 'git revert' on the original commit | 11:00 |
| Wizzup | did you try doing that? you might have to manually fix some things | 11:00 |
| Wizzup | e right | 11:01 |
| Wizzup | (oops, xrandr) | 11:02 |
| uvos__ | sicelo: it would be great if you could provide me with a list of patches you currently use on top of 6,1 for n900 purposes, since i dont really know what is sill required | 12:16 |
| uvos__ | you can find what i currently have at https://github.com/IMbackK/droid4-linux | 12:16 |
| uvos__ | branch n900-61 | 12:16 |
| Wizzup | uvos__: imho I'd keep all patches we had unless we're certain we don't need them anymore | 12:25 |
| uvos__ | that leads to an absolute mess | 12:26 |
| Wizzup | if we still have the patch, we can easily test if we need it, if we don't have the patch, we might not know which one we need, no? :p | 12:26 |
| buZz | ahh, i reset charge_full to 1750000 and did a full discharge while gprs on, ssh open, got 1250000 as calibration now | 13:22 |
| buZz | having too low a charge_full leads too almost impossible to calibrate 'up' as when battery get under '10 percent' mce starts to nag and below 5% it gets reaaally annoyed | 13:23 |
| buZz | even if that 5% if at 3.9V , lol | 13:23 |
| buZz | is at* | 13:23 |
| buZz | (also i now default set constant_voltage to 4.max volt and input_current to 888888 | 13:24 |
| buZz | just need some repeatable figures and tests for the battery replacement :) | 13:25 |
| uvos__ | i dont see how the modem dropping away beacuse of low battery can be normal btw | 13:55 |
| Wizzup | agreed | 13:56 |
| uvos__ | we shutdown earlier than android (but i have to check androids critical voltage again), and this would mean that celluar would stop working on android when the battery is low | 13:56 |
| uvos__ | i can attest this is not the case | 13:56 |
| uvos__ | i never had any problems using cellular on android at anny state of charge, includeing calls that lasted right up to the point where the device shut off | 13:57 |
| Wizzup | I think it could also be perhaps thermal reasons, I am not sure | 13:58 |
| Wizzup | I don't regular switch to different d4's, so I don't know how much it happens on other d4's | 13:58 |
| Wizzup | uvos__: hm on ~3.4v on psu the system is much slower than on ~3.6v it seems | 14:27 |
| Wizzup | maybe 3.4 was too low, but yeah | 14:28 |
| Wizzup | I wonder if something reclocks without us knowing, seems unlikely | 14:28 |
| buZz | maybe the modem has some lowvoltage mode that we arent enabling? | 14:29 |
| tmlind | the modem has it's own pmic wired to the battery directly, no idea what it's shutdown voltage might be | 14:30 |
| uvos__ | Wizzup: you getting a cpcap irq storm? | 14:32 |
| uvos__ | that makes it lower | 14:32 |
| uvos__ | tmlind: the point is we shutdown at a higher voltage than android, which dosent encounter the modem not working when it thinks he battery is low | 14:33 |
| tmlind | uvos__: yeah.. this could be easily tested by connecting a bench power to d4 instead of a battery and lowering voltage until modem issue occurs | 14:34 |
| uvos__ | so clearly the shutdown voltage in the modem must be below androids threshold | 14:34 |
| uvos__ | or android must have some way to telling the modem not to shutdown | 14:35 |
| buZz | tmlind: maybe that pmic needs some controls? | 14:35 |
| tmlind | buZz: the modem uses it's own signed firmware, nothing we can do about it | 14:35 |
| buZz | aw right | 14:35 |
| buZz | beside beg to qualcomm i guess | 14:35 |
| uvos__ | motorola | 14:35 |
| uvos__ | who dont exist anymore anyhow | 14:36 |
| Wizzup | uvos__: I didn't see a lot in dmesg, so not sure | 14:36 |
| uvos__ | Wizzup: ok | 14:37 |
| uvos__ | maybe we should check if android dose something when battery is below 10% wrt dowclocking | 14:37 |
| uvos__ | or if it tells the modem something via usb | 14:38 |
| tmlind | uvos__: well with a weak battery the modem pmic might actually know the remaining capacity better and shut down earlier? | 14:39 |
| Wizzup | I think maybe sgx is clocked lower too | 14:43 |
| Wizzup | anyway bbiab | 14:43 |
| uvos__ | tmlind: idk, at the very least i have never seen the modem pmic decide to shutdown before the rest of the device on android | 14:44 |
| tmlind | ok | 14:44 |
| tmlind | having the soc usb phy integrated into the modem is not a nice design solution :( | 14:44 |
| uvos__ | this would have been extreamly obvious while i was using it as my main device for 4 or so years ;) | 14:44 |
| tmlind | the other option is the modem just hangs because of some reason | 14:45 |
| uvos__ | the device behaves wierd when the battery is low on the mainline kernel in general | 14:46 |
| uvos__ | maybe there is just some errata that motorola masked by reducing clocks while the battery is low | 14:46 |
| uvos__ | ill check that first | 14:46 |
| tmlind | ok | 14:47 |
| Wizzup | is it possible things get re-clocked out of our control? | 14:47 |
| uvos__ | i dont see who would be doing that | 14:48 |
| uvos__ | we fully controll the plls in the omap4 | 14:48 |
| uvos__ | if it gets slower when the battery is low atm | 14:49 |
| uvos__ | id lean towards irq pressure because some periferal device is misbehaveing | 14:49 |
| uvos__ | like hickuping or somehting | 14:49 |
| uvos__ | theres probubly a global irq counter somewhere we can look at to see if there are lots more handlers fireing? | 14:50 |
| uvos__ | tmlind? | 14:50 |
| Wizzup | back in ~1 hour | 14:50 |
| uvos__ | we def had irq pressure from the cpcap low irq before | 14:51 |
| uvos__ | where it would start fireing lots of times per second | 14:51 |
| uvos__ | while the battery was low | 14:51 |
| uvos__ | but this should be fixed now | 14:51 |
| sicelo | uvos__: i have asked a number of times what config is used for the leste kernel ... no response from you ... | 14:54 |
| sicelo | i don't know what patches matter for leste and n900 because i don't really use leste with n900 much. please keep the patches and configs that were already there from spinal/Wizzup | 14:55 |
| freemangordon | I think I see ants more clearly when battery is low | 14:55 |
| freemangordon | so there must be something going on | 14:55 |
| tmlind | Wizzup: you can cat /proc/interrupts every 10 secs and diff to see if there's a crazy amount of some interrupts | 14:56 |
| uvos__ | sicelo: its just omap2plus_defconfig | 14:57 |
| tmlind | freemangordon: pvr should not know anything about the battery voltage hopefully :) | 14:57 |
| uvos__ | some patches in the old n900 pach collection are def obsolete | 14:57 |
| uvos__ | they are in the mainline kernel allready | 14:58 |
| tmlind | uvos__: ok | 14:59 |
| uvos__ | tmlind: i have noticed that that d4's voltage rails are noticably more noisy than xt875's | 14:59 |
| uvos__ | maybe this is related to issues | 15:00 |
| sicelo | vanilla omap2plus is not best option for N900/droid4, as it includes a lot of other omap stuff that doesn't apply to any of them. in the past, there was an n900_defconfig somewhere, for example | 15:03 |
| sicelo | s/droid4/mapphones/ | 15:03 |
| tmlind | uvos__: so are the ants there on xt875? | 15:04 |
| buZz | oh yeah, the modem is usb, can we 'unplug it' and plug back in? might just be the usb phy complaining | 15:08 |
| buZz | i've seen the modem going offline at >4v too | 15:08 |
| uvos__ | sicelo: sure but those are mostly just modules and the omap2 stuff (wich we disabled via patch iirc) and extra modules we dont need (wich have minimal detriment to build for no reason) our omap2plus_defconfig isent entirely stock either, see the mameo repo and diff the file vs mainline | 15:09 |
| uvos__ | its true that eventually we might want to have a maemo_defconfig or so | 15:10 |
| uvos__ | tmlind: yes however i have at least not encounterd them to the same degree as on d4 | 15:10 |
| tmlind | i believe multi_v7_defconfig does not work with kexec on d4, kernel is too big for something | 15:10 |
| uvos__ | on d4 sometimes the statusbar is compealty hidden behind ants | 15:10 |
| uvos__ | but that might just be because my usage hours with xt875 is lower | 15:11 |
| tmlind | ok | 15:11 |
| uvos__ | tmlind: the kernel will be to big for n900 way before that happens presumably :P | 15:12 |
| tmlind | heh yeah | 15:15 |
| buZz | can we get rid of the 4330000 charge limit at next kernel? :) and just do 4349000 as battery states | 15:25 |
| buZz | such minor step, it seems :P | 15:25 |
| uvos__ | have to check where it comes from first | 15:25 |
| uvos__ | its possible that exatcly 4,349 is not a possible register state at all | 15:25 |
| buZz | i bet cpcan_charger | 15:26 |
| buZz | ah | 15:26 |
| buZz | wonder what android does :) | 15:26 |
| uvos__ | nothing special if so | 15:27 |
| uvos__ | the eb41 cell (not the battery case) was used on lots of moto phones from the era | 15:27 |
| uvos__ | with different pmics | 15:27 |
| uvos__ | the 4,349 dosent need to line up with anything in cpcap | 15:27 |
| buZz | hmhm alright | 15:30 |
| buZz | using this ; http://space.nurdspace.nl/~buzz/maemo/bermbom.sh from rc.local now | 15:31 |
| buZz | it seems to work to get more mah, likely at lower lifespan, but havent even seen battery going >40C | 15:32 |
| buZz | (during charge) | 15:32 |
| sicelo | Wizzup: please remind me ... when a kernel is referred to as 5.9.y for example, the 'y' means anything? i mean - there's no git tag with that | 15:37 |
| uvos__ | .y is from the linux-stable branches | 15:41 |
| uvos__ | 5.9.y is the branch were patches that backport fixes are merged into and 5.9.1 etc are tagged from | 15:42 |
| Wizzup | what uvos said | 15:44 |
| Wizzup | (regarding the stable versioning) | 15:45 |
| freemangordon | tmlind: it is rather a memory issue that sgx | 16:00 |
| freemangordon | or some bus issue | 16:01 |
| freemangordon | *than sgx | 16:01 |
| freemangordon | as it seems somehow the texture is corrupted *before* uploading to GPU | 16:02 |
| freemangordon | also, I had some logs in pstore where those logs were kind of corrupted - half the characters were replaced with random ones | 16:03 |
| tmlind | freemangordon: so how was it.. do we also see the ants on a hdmi panel? | 16:05 |
| freemangordon | I tested hdmi just a couple of times | 16:05 |
| tmlind | or does the constant refresh hide it on hdmi? | 16:05 |
| freemangordon | so can't tell | 16:06 |
| tmlind | ok | 16:06 |
| freemangordon | but IIRC uvos__ said he had seen ants on hdmi | 16:06 |
| tmlind | ok | 16:06 |
| freemangordon | uvos__: ^^^ ? | 16:06 |
| tmlind | slowed down video of a hdmi panel might show up the ants in some frames? | 16:06 |
| freemangordon | could it be that we are missing correct emif config | 16:07 |
| freemangordon | the reason for ants | 16:07 |
| freemangordon | ? | 16:07 |
| freemangordon | tmlind: I cannot test now, will be get back from business trip on thursday | 16:08 |
| tmlind | well the emif config we're using is for the fastest soc frequency, it should work fine with slower frequencies | 16:08 |
| freemangordon | are we sure this is ok actually? | 16:08 |
| uvos__ | im pretty sure i have seen ants on hdmi | 16:09 |
| uvos__ | at one point the where omnipresent | 16:09 |
| uvos__ | and you could see them easly | 16:09 |
| tmlind | no but compiling code like mesa would faile randomly :) | 16:09 |
| freemangordon | ok | 16:09 |
| freemangordon | :) | 16:09 |
| tmlind | if the emif timings did not work | 16:09 |
| uvos__ | we ccould downclock android to see if its fine i gues | 16:09 |
| uvos__ | whithout downclocking emif on android | 16:09 |
| freemangordon | tmlind: well, but compiling mesa makes cpus run on 1.3 | 16:10 |
| uvos__ | the ants are one word in length right? | 16:10 |
| freemangordon | uvos__: not really | 16:10 |
| freemangordon | there are times I see them here all over the top window stripe | 16:11 |
| uvos__ | right, longer | 16:11 |
| uvos__ | like one ant is 4 pix or so | 16:11 |
| freemangordon | sometime there are behind tasknav button on top-left | 16:11 |
| uvos__ | so 16 ish words | 16:11 |
| uvos__ | ok nvm | 16:11 |
| freemangordon | and there are almost that wide and high | 16:12 |
| freemangordon | sometimes they appear on random places | 16:12 |
| uvos__ | er bytes, i not words | 16:12 |
| uvos__ | i need coffe | 16:12 |
| freemangordon | tmlind: my idea being - when SGX runs in full speed, that does not necessarily mean that CPU is @ full speed | 16:13 |
| freemangordon | and we may hit the issue because of that | 16:13 |
| freemangordon | but, I have no idea how is SGX connected to memory bus | 16:13 |
| freemangordon | how easy is to *downclock* the mempry bus? | 16:14 |
| freemangordon | to see if it will affect ants? | 16:14 |
| uvos__ | emif interface has lots of registers with offsets based on its main clock | 16:15 |
| uvos__ | i gues if the times are longer it should be ok | 16:15 |
| uvos__ | but no dram expert here | 16:15 |
| uvos__ | we could just force android into a low oop | 16:15 |
| uvos__ | read the emif registers | 16:15 |
| uvos__ | and then just write them back | 16:15 |
| uvos__ | on mainline | 16:15 |
| freemangordon | could you do that? It will really take me too much time as I have not idea where to start at :) | 16:16 |
| uvos__ | sec there is an easy way | 16:16 |
| uvos__ | https://github.com/tmlind/buildroot/blob/7d09d9eea638ee6c74bc5be124fd79935ca1fdcf/board/motorola/droid4/rootfs_overlay/sbin/preinit.sh#L45 | 16:18 |
| uvos__ | change that to something else | 16:18 |
| uvos__ | rebuild kexecboot | 16:18 |
| uvos__ | should end up with mainline booted with different emif reg state | 16:18 |
| uvos__ | altho it might not work at all, see comment | 16:18 |
| uvos__ | the flaky comes from that the state was more or less random before this was added | 16:19 |
| uvos__ | i gues removing the opps above whatever you set here in the mainline kernel dts, should work | 16:19 |
| uvos__ | since the main problem is likely that linux throttles up the cpu but not emif too | 16:20 |
| uvos__ | figureing out how to reclock emif would be good in general anyhow, we are wasteing some power here (but idk how mutch) | 16:21 |
| tmlind | sure, only matters for runtime power consumption though, not idle power consumption | 16:23 |
| uvos__ | sure | 16:23 |
| uvos__ | to it also feals like runtime power consumption where we seam to lagg most behind android | 16:24 |
| uvos__ | at least by feal from rembering how long the device lasted with use back when it used it with android | 16:24 |
| uvos__ | runtime pm hard to benchmark ofc | 16:24 |
| freemangordon | we don;t have off mode | 16:24 |
| uvos__ | freemangordon: we are talking about pm while the device is in use | 16:25 |
| uvos__ | android dosent hit off mutch or at all in this case | 16:25 |
| tmlind | yeah won't it off at all if lcd is active | 16:25 |
| freemangordon | IIRC leste run-time usage is lower | 16:26 |
| freemangordon | check xml files | 16:26 |
| freemangordon | sorry | 16:26 |
| freemangordon | excel files | 16:26 |
| uvos__ | not sure how you come to this conclusion, i have no data but it def feals otherwise | 16:26 |
| uvos__ | could just be that android has hw decodeing and accelerated browser etc | 16:27 |
| uvos__ | all that saves power | 16:27 |
| freemangordon | http://46.249.74.23/leste/d4/power_usage/ | 16:27 |
| freemangordon | this | 16:27 |
| freemangordon | well, didn;t play much within OS | 16:27 |
| freemangordon | but I can | 16:27 |
| uvos__ | well i mean "usage" | 16:28 |
| uvos__ | like watching videos, browsing etc | 16:28 |
| uvos__ | anyhow its not important | 16:28 |
| freemangordon | well, without having GPU accelerated browser... | 16:28 |
| freemangordon | :nod: | 16:28 |
| uvos__ | right | 16:28 |
| uvos__ | also gtk2 is not hw accelered | 16:28 |
| uvos__ | while androids widget set is | 16:28 |
| uvos__ | that prob also helps android | 16:29 |
| freemangordon | mhm | 16:29 |
| uvos__ | anyhow not important rn | 16:29 |
| tmlind | yeah | 16:29 |
| * freemangordon is afk | 16:29 | |
| norayr | i always read everything in this and some chats. and hdmi and performance issues brought me back to this thought that though we love and enjoy old retro devices (and i wish droid3 would be better supported) people cannot buy them, those aren't availble in amounts old film cameras are available. | 19:02 |
| norayr | so we need new devices. | 19:02 |
| norayr | and what we have is librem and pinephone, most supported devicen of pmos are pine64 devices. | 19:03 |
| norayr | i wish we had something better or could support devices that have better availability. | 19:03 |
| norayr | but even now if i want to buy segond d4 or if i want to regommend someone to get a d4, you cannot buy it today on ebay. | 19:04 |
| norayr | for months already. | 19:04 |
| norayr | sorry for typos - screen kbd. | 19:04 |
| Wizzup | https://www.phoronix.com/news/Wayland-Tearing-Control-Proto | 19:53 |
| Wizzup | haha | 19:53 |
| bencoh | wait, what? :D | 19:57 |
| Wizzup | just in case you wanted the performance back | 19:58 |
| Wizzup | (I'm mostly kidding) | 19:58 |
| bencoh | yeah, but ... :] | 19:58 |
| ravelo | I should try to get droid 4 | 20:31 |
| ravelo | it looks like linux is working pretty great | 20:31 |
| BlagovestPetrov[ | fyi, that's what I got when installing the latest version of clockd from the repository: | 20:35 |
| BlagovestPetrov[ | Setting up clockd (0.0.46+m7) ...... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b566debff387ae1bd6a2f58be5f5d9a707baaf73>) | 20:35 |
| BlagovestPetrov[ | not sure if it's an issue with openrc | 20:35 |
| uvos | hildon w/o pvrkm works better than i remember | 22:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!