libera/#maemo-leste/ Thursday, 2022-01-06

Wizzupok00:05
huckgI'm still having trouble with droid bionic; I am on step 8 of https://github.com/IMbackK/bionic-clown-boot and getting Sending 'mbm' (256 KB) FAILED (remote: 'unsupported command') despite having upgraded to latest Android platform-tools as uvos suggested.00:11
Wizzupfreemangordon: re: "how?", well it works for me02:25
Wizzupfreemangordon: with the other panel patch the device uses like 20mW more in OFF02:32
Wizzupfreemangordon: tmlind: btw: https://dpaste.com/BH5D5P8E8.txt02:40
WizzupX also not happy: [289971.389] (EE) OMAP(0): ERROR: PVRSRVMapFullDmaBuf failed: PVRSRV_ERROR_BAD_MAPPING fd 26402:40
Wizzupseems like a high fd to me02:40
Wizzupfreemangordon: latest kernel works for me (panel)02:42
Wizzupit's also smoother in 3d for sure02:44
Wizzupfreemangordon: hm d3 seems to boot for me02:46
Wizzupfreemangordon: d4 boots ok for me as well?02:51
mighty17[m]freemangordon: can you send 99-modesetting.conf again? the pastebin expired? :(05:32
mint[m]hey, not sure if this question goes in this channel but i'm having some issues with surf2. after clicking the URL box i can't use a text box in the web view, how can i stop highlighting the URL box?07:19
freemangordonWizzup: seems somehow I managed to uninstall the kernel on my d407:20
freemangordonI mean - I removed linux-image-droid407:21
freemangordonbut, this was after I installed linux-image-omap07:21
freemangordonreinstalling linux-image-omap fixed it07:27
freemangordonWizzup: re that error - seems you are running out of DMM/TILES space somehow07:28
freemangordon*TILER07:28
freemangordonmighty17[m]: https://pastebin.com/YBxVKZts07:30
freemangordonWizzup: so, ba9c85a6643f9fad15018390a3b59280187b7564. shall be removed and other fix found for high power usage07:56
mighty17[m]tysm08:37
freemangordonWizzup: also, why do we carry a20f161298226a368d73af1b1467568ba5d05efa?08:46
tmlindfreemangordon: your dmabuf fix also fixes my wlroots termite test case even with sgx clock slowed down :)10:43
tmlindfreemangordon: also, did you update the ddk blobs branch? seems like your blobs changes caused the environment regression somehow if i remember right?11:02
tmlindhmm or am i confused again on what caused the environment variable needed regression?11:04
tmlindi guess it must have been a mesa change instead..11:04
tmlindspotty connection, bbl11:20
Wizzupfreemangordon: regarding a20f161298226a368d73af1b1467568ba5d05efa - uvos said to keep it for charge mode iirc12:58
Wizzupfreemangordon: ok, I'll remove ba9c85a6643f9fad15018390a3b59280187b756412:58
mighty17[m]https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux-pvrsrvkm-5.16-rc2/arch/arm/boot/dts/omap4-l4.dtsi#L2150 is this not gonna be changed to sdhci?14:28
Wizzupfreemangordon: is the tearing gone for you? I think I still have some14:34
freemangordonWizzup: no, as I said, tearing on d4 is another story17:14
freemangordontmlind: great!17:14
freemangordonWizzup: ok, but IIUC this commit causes wakeups 20 times per second17:15
freemangordonuvos: ^^^17:33
_uvos_sicelo: you need to add options "cpcap-battery ignore_temperature_probe=1"17:39
_uvos_with ofc obvious caviates17:40
_uvos_please if you have the time- document this on the wiki17:40
_uvos_(to some modprobe .conf)17:41
freemangordon_uvos_: could you comment on kernel commit a20f161298226a368d73af1b1467568ba5d05efa17:43
freemangordon"drm/omap: get fbdev working for manually updated display"17:43
sicelothanks. i transplanted the controller though.17:46
Wizzupfreemangordon: which commit causes wakeups?17:56
freemangordonWizzup: a20f161298226a368d73af1b1467568ba5d05efa ?17:57
Wizzupah17:57
_uvos_what commit is that?17:57
_uvos_im in a train17:57
freemangordonah17:57
freemangordon_uvos_: "drm/omap: get fbdev working for manually updated display"17:58
_uvos_ah that17:58
freemangordonalso, IIUC, this is about fbdev emulation17:58
_uvos_should only cause wakeups if soemthing dirtys the fb17:58
_uvos_yes17:58
_uvos_it makes it work ond mapphones17:58
freemangordondo we use/need that at all?17:58
_uvos_otherwise the display is never updated17:58
freemangordonfbdev emulation I mean17:58
_uvos_currently for charging-mode17:58
_uvos_but i want to move that to drm17:59
_uvos_havent done it yet17:59
freemangordonwhat is "charging mode"?17:59
_uvos_it was on fbdev because ddk1.9 bugs17:59
_uvos_boot the device by pluging in chargerger17:59
_uvos_a battery icon appears17:59
_uvos_and device charges17:59
freemangordonah, so "actdead" :)18:00
_uvos_yeah18:00
_uvos_sorta18:00
_uvos_implemented differently18:00
_uvos_its a runlevel18:00
freemangordonyeah, I see18:00
_uvos_ill move it to drm18:00
_uvos_then we can drop that patch18:00
freemangordonok18:00
_uvos_if it causes trouble18:00
_uvos_otherwise haveing fbdev working is ofc nice in its own right18:01
freemangordonwell, I am not 100% sure, but IIUC it queues a work 20 times/sec18:01
freemangordonIOW - looks like a hack18:01
_uvos_ok18:01
freemangordonbut yeah, ok, lets keep it for now if there is code that uses it18:02
freemangordon_uvos_: though, I think we shall implement that 'charging mode' correctly, like starting matchbox etc18:03
freemangordonbecause the same/similar mode is used for alarms18:03
_uvos_i really really dislkie that18:03
_uvos_and for alarms the charge mode runs a differen runlevel18:03
freemangordondislike what? having an alarm turning on the device?18:03
_uvos_you can have whatever you want there18:03
_uvos_remeber on mapphones we have _very_ little time18:03
_uvos_to settle the devie18:04
_uvos_or it powers off again18:04
freemangordonok, you can start charging immediately and then bring-up whatever UI is needed18:04
_uvos_sure18:04
freemangordonI am not saying we shall do a lame implementation18:04
freemangordon:)18:04
_uvos_so rn there is a script that chargemode uses to start other runlevels depending on condition18:05
freemangordonok18:05
_uvos_conitions are: unplugged, alarm, full, power button18:05
_uvos_rn all start runlevel default (and hildon)18:05
freemangordonhow do we know about alarm?18:05
freemangordonI mean - is there anything passed by the BL?18:05
_uvos_but we can change that as soon as something else exists18:05
_uvos_it quers the hwclock18:06
freemangordonhmmm18:06
freemangordonok18:06
_uvos_so if hwclock was set to boot the device18:06
freemangordonyeah, got it18:06
_uvos_it will boot the next runlevel instead18:06
freemangordonsounds sane18:07
freemangordonI think we shall do something similar for n90018:07
freemangordonif this does not work already18:07
_uvos_it schould work18:08
freemangordonnot sure what NOLO does with hwclock on power-up18:08
freemangordonit may resewt it18:08
freemangordon*reset18:08
freemangordonbecause boot mode is passed as ATAG18:08
_uvos_ok18:10
mighty17[m]<mighty17[m]> "https://github.com/openpvrsgx-..." <- cc tmlind18:26
_uvos_freemangordon: "ok, you can start charging immediately and then bring-up whatever UI is needed"18:39
_uvos_i thin you missunderstood this18:39
_uvos_the problem isent starting charging18:39
_uvos_its that usb power can not keep d4 alive it uses to mutch18:39
_uvos_it must enter idle asap18:40
_uvos_and the bootloader gives little room here18:40
_uvos_it boots the device just after the battery has bearly enough charge to enter androids charge mode18:40
_uvos_wich is very quick18:40
bencohI'm not sure the bootloader would enter idle anyway (vs busy-waiting)18:42
bencohbut I haven't checked, so I dunno18:42
_uvos_the bootloader sets cpcaps idle regs18:42
_uvos_er trickel charge regs18:43
_uvos_and shuts off18:43
_uvos_cpcap then boots again18:43
bencohah18:43
_uvos_after a set voltage18:43
bencohnice18:43
* sicelo will probably now start using Leste/Droid 4 more, now that he has a somewhat better battery. at around 20 hours now, and still has 3.6v. calibration not finished yet, but definitely feels better than the 700mAh I had all along19:02
freemangordon_uvos_: I think I understand it right. "bring-up" of the UI after battery is charged enough to allow it19:13
freemangordonalso, I am sure we can power off all but CPU0, and put CPU0 @ lowest frequency19:13
freemangordonThis should be enough to support minimal UI (like alarm/charging one) with radios off19:14
uvosprobubly19:15
uvosunsuprisingly i like the architecture that i desinged for charge mode :P19:15
uvosanyhow ill move it to drm soon19:16
freemangordonno, it sounds fine, what I am saying is that we shall extend it (if needed) to support alarm19:16
uvosprobunly i can do it tomorrow19:16
uvossure19:16
freemangordonuvos: also, I am almost sure battery holds enough charge so matchbox to be started19:17
uvosno19:17
freemangordonhmm, ok19:17
uvosso in the deepest discharge state we are allready in the hole19:17
uvoswhen sysinit finishes19:17
uvosbecause of kexecboot19:17
uvosthat takes extra time19:17
freemangordonI see19:18
uvosrelatvie to android native19:18
uvosso we allready have to move charge mode into initramfs19:18
uvosat some point19:18
freemangordonyeah, so we shall hold a bit in charge-only mode19:18
uvosyeah somehting like that19:18
freemangordonuntil we have lets say 2% (made-up) value19:18
uvossure19:18
freemangordonand then proceed to charge-only-phase219:19
freemangordonand here the switch shall be made to alarm, user, unplug, no?19:20
uvosyeah19:20
uvosthats how it currently works19:20
freemangordonah, nice19:20
freemangordonfor how long it stays in charge-only mode?19:20
uvosuntill sone of those switches is tripped19:20
uvos(or its full)19:21
uvos*s/sone/one19:21
freemangordonanother note - do you say that with everything but cpu0 and mmc omap4 uses more than 500mA?19:21
freemangordon*everything off19:21
uvosno idea probubly not19:21
freemangordonso, *in theory* we may boot to alarm even if we don;t have minimum charge19:22
uvosmaybe19:22
freemangordoncool19:22
uvosthe problem is,currently during boot its too mutch19:22
uvosbefore userspace even starts19:22
uvosso fix would have to be in kernel somehow19:22
uvosor avoid loading so mayne modules19:23
freemangordonhmm, maybe we shall load modules manually19:23
uvosand have a inintramfs with just cpcap-carhger to dwel in19:23
uvos*charger19:23
freemangordonI think we shall try to avoid initrd if possible19:23
freemangordonnot really sure how this can be achieved19:24
uvosim  pretty neutral on having a initramfs19:25
freemangordonwell, my point is that this is yet another thing to maintain :)19:25
freemangordonif we can avoid...19:26
freemangordonbut we'll have to find a way to delay module loading until some condition is made19:26
uvosyeah19:27
uvosanyhow its not that important to fix this rn19:27
uvosmce now shutsdown the device well ahead of the problem area19:28
uvosso you should only be albe to enter it by leaving the device in cupboard for a long time19:28
uvosor leste hanging or something19:28
freemangordonmy point was about bootup19:28
uvosand even then you can just use androids charge mode19:28
freemangordonbut yeah, a corner case19:28
uvosfreemangordon: yes i know19:29
uvosfreemangordon: im saing this problem is farly small19:29
uvosatm19:29
freemangordon:nod:19:29
bencohfreemangordon: don't we already use devuan's initramfs?19:34
uvosno19:34
bencoh(I agree with maintaining an initramfs being a burden btw)19:34
bencohif we really want to we could probably blacklist modules in /etc/modprobe.d/ and insmod it manually19:35
bencoh(it sounds kinda ugly though)19:35
freemangordonuvos: what about having modprobe.d file that blacklists all the modules and later on, when we don't need it anymore, we can bindmount to an empty file?19:35
freemangordonbencoh: see ^^^19:35
bencoh:)19:36
uvossure but i agree its really ugly19:36
freemangordonwould that work?19:36
uvoswe could have a runlevel that avoids running udev instead19:36
uvosand modprobes just cpcap modules19:36
uvosand then dwels19:36
bencohprobably, although bindmounting sounds even worse to me that manually insmoding19:36
uvosand then runs normal sysinit19:36
freemangordonah, so it is udev that does modprobe?19:36
uvosyeah19:36
freemangordongood19:36
freemangordonwell yeah19:36
bencohwe can just add a udev rule then19:36
freemangordonbencoh: nor, really, not starting udev is better19:37
freemangordon*no19:37
* bencoh headscratches19:37
freemangordonwe build whatever we need in zImage19:37
freemangordonfor minimal system19:37
uvossure19:38
freemangordonthat does charging only19:38
uvosthat probubly helps start charging sooner too19:38
freemangordonmhm19:38
bencoh(btw at $job bootloader prevents booting (ie waits) until battery is "charged enough")19:38
freemangordonand once we have enough charge, we start udev or $whatever_is_needed19:38
freemangordonlike swithing the runlevel19:39
freemangordon*switching19:39
freemangordonI think that way we avoid initrd19:39
bencohoh right, using a different runlevel sounds like a decent idea19:39
freemangordonuvos: we may want to fix getbootstate to fi that new boot logic19:40
uvoswhats this?19:40
freemangordona tool that gets boot state, like USER, ACTDEAD, MALF19:40
uvosfrom atags?19:41
freemangordonyes19:41
uvosok19:41
freemangordonI know you hate it, but we shall keep ACTEAD (in some shape) at least for a while19:41
freemangordonthere is too much code that relies on env var being set19:42
uvosso currently chargemode just checks if the usb cable is plugged in (and assumes that this means we should enter charge mode) and with the hwclock19:42
uvoson mapphones we cant asses the boot reason19:42
uvosthe android kernel has cleard it before we can kexec19:42
uvosthe good thing about this method is also it works everywhere19:42
uvosie currently on maphones and pp and n90019:42
freemangordonyeah, sounds fine19:42
uvosthe bad thing ofc is that the user might press the power button19:43
uvosthen insert the cable19:43
freemangordonwhile on charger?19:43
freemangordonah19:43
freemangordonyeah19:43
uvosand it will enter charge mode erronously19:43
uvosnot a big deal of the user will just press the power button again19:43
uvosbut a bit wonky19:43
freemangordonyeah19:43
uvosand at least on maphones we cant do better19:44
freemangordonnot a big issue I would say19:44
freemangordonthough, I think on OMAPs at least there is some memory location with flags about the boot reason19:44
freemangordonah, but android kernel clears that19:45
freemangordonI see19:45
freemangordonwell, we do the best we can19:45
freemangordonthen19:45
freemangordonuvos: basically, ACTDEAD means we have /tmp/ACT_DEAD :)19:46
freemangordonand also ACT_DEAD in /tmp/mode (or something19:46
freemangordonalarm plugin already supports that, and if device was woken-up by an alarm, after you snooze/stop it, you are asked if you want to power-on the device19:48
freemangordonalso, XSession already supports actdead mode, like different set of applications is started19:50
freemangordonWizzup: what is hildon-kernel-config-n900 ? hildon-meta-n900 depends on it20:39
freemangordonWizzup: OTOH lates kernel seems to boot fine on both d4 and n90020:50
Wizzup20:39 < freemangordon> Wizzup: what is hildon-kernel-config-n900 ? hildon-meta-n900 depends on it21:00
Wizzupfreemangordon: this is the uImage postinst21:00
Wizzupfreemangordon: yes, also boots ok for me21:00
freemangordoncan't be as it is neither installed nor available :)21:01
freemangordonleste-config-n900 is postinst :p21:01
freemangordonWizzup: I think you initially planned to have that additional package21:02
freemangordonbut later on we decided to move postinst to leste-config-n90021:03
freemangordonso I thing this dependency is not needed21:03
freemangordonWizzup: I think I fixed sgx-ddk-um dependencies21:05
Wizzupfreemangordon: no, we decided not to go the leste-config route21:14
Wizzupleste-config-n900 is not the postinst21:14
Wizzupthanks for looking at the deps though21:15
freemangordonroot@devuan-n900:~# dpkg -S n900-uImage21:15
freemangordonmaemo-kernel-config-n900: /etc/kernel/postinst.d/n900-uImage21:15
Wizzupexactly21:15
freemangordonso, again, what is hildon-kernel-config-n900?21:15
Wizzupit is the postinst script to make the uImage21:15
freemangordonmaemo-kernel-config-n900 != is hildon-kernel-config-n90021:16
Wizzuphildon-kernel-config-n900 was a mistake on my side21:16
WizzupI fixed that since21:16
Wizzupafaik21:16
Wizzupif there is any dep on it, that must go21:16
freemangordonnot in the repos at least21:16
Wizzuphttps://maedevu.maemo.org/pkgweb/beowulf-devel/main/binary-armhf/maemo-kernel-config-n900.html21:16
freemangordonyes, hildon-meta-n900 depends on it21:17
Wizzuphttps://maedevu.maemo.org/pkgweb/search?q=hildon-kernel-config21:17
Wizzupfreemangordon: ok then the meta needs fixing if it's not fixed already21:17
Wizzuplet me check21:17
freemangordonI think this is the last issue21:17
Wizzupok21:17
WizzupI see it21:17
Wizzupyes please fix21:17
Wizzupor shall I?21:17
freemangordonreplace hildon with maemo?21:17
freemangordonI will21:17
Wizzupyes21:18
freemangordonok, I will do21:18
Wizzupty21:30
freemangordondone21:37
uvos<freemangordon> uvos: basically, ACTDEAD means we have /tmp/ACT_DEAD :)21:58
uvosyean not that crap has to go21:58
uvosso actdead can be a runlevel for charging and one for alarms or watever21:59
uvosbut all the deamons checking some random file and then having houndreds of if(actead) in the code all over the place21:59
uvos(mce literally has 100s21:59
uvos)21:59
uvosis spagatii crap21:59
uvos*spaghetti21:59
freemangordonbefore fixing that we shall have it running22:00
freemangordonotherwise we don't know what we fix22:00
freemangordonhmm:22:01
freemangordoncma: cma_alloc: reserved: alloc failed, req-size: 375 pages, ret: -1622:01
freemangordonOS error code  16:  Device or resource busy22:02
freemangordonthis should not happen22:02
Wizzupfreemangordon: n900?22:02
freemangordonyes22:03
freemangordonhappened twice, during heavy IO22:03
* freemangordon checks how is memory allocated22:04
Wizzupuvos: so do you still not get d3 hangs?22:05
uvosWizzup: so i just came home22:07
uvosthe uptime of my d3 suggests it dident crash22:07
uvosbut it ussaly hangs while using it22:08
uvosi wasent able to test the other day actively more than when i said it dosent seam to crash22:08
uvosthat was just a couple of hours22:08
uvosso maybe22:08
uvosif it dident help yours its just noise most likely22:08
uvoseven it it dosent help with the current hang, i would keep the patch in mind, but maybe not applied22:10
uvossince clearly motorola thought it needed at some point, and d3's microcode/fw is so mutch older than d422:10
uvoswhere they obviously patched it out22:11
Wizzupright22:16
freemangordonWizzup: maybe I shall change DDX to retry allocations until memory is available22:26
uvosthat can cause an undesirable deadlock no?22:27
freemangordonnot really22:28
freemangordonbecause we definitely have free CMA memory, it is just that *now* there are too many pages that cannot be migrated22:28
uvossure22:28
uvosbut do you know that?22:29
uvoswhat happens when something leaks cma22:29
freemangordonwell, what can we do in such case? restart X?22:29
freemangordonI mean - if we have CMA leak, nothing can be done22:29
uvosx crashing with obvious messag in this case is mutch better than it hanging22:30
freemangordonbut, this is not the case here22:30
freemangordonwell, it can retry some time22:30
uvosalso cant cma be filled becaue video decoding or whatever is using it22:30
freemangordonbetter that instant crash22:30
uvossure yeah thats fine22:30
freemangordonwe get -16, not -1222:30
freemangordon-EBUSY22:30
freemangordonthis seems to be returned after 5 retries to free big enough memory block22:31
uvosok22:32
freemangordonI am not sure __GFP_REPEAT is usable if passed to dma_alloc_wc22:32
Wizzupfreemangordon: I wonder if something is leaking as well (wrt d4)22:36
Wizzupfreemangordon: but makes sense to try22:36
freemangordonWizzup: d4 does not use CMA22:36
Wizzupfreemangordon: yeah22:36
WizzupI know22:36
Wizzupbtw n900 perf is great now imho22:36
freemangordonit is most-probably DMM/TILER that gets fragmented22:37
freemangordonyeah, but there is a place for improvement22:37
freemangordonwe still lack HW accell for compositing22:37
freemangordonbut will do it after abook etc22:37
freemangordonI wonder if I can just allocate a pool of 3 BOs in DDX and call it a day22:38
Wizzupmhm22:39
bencohprobably (why not?)22:39
Wizzupfreemangordon: agreed @ boabook22:39
freemangordonwe still can have issues on rotation though22:39
bencohjust allocate buffers large enough hold both orientations22:39
freemangordonwell, too much unused memory22:40
bencohif you use cma for that and are admittedly the only cma user ...22:40
freemangordonin theory we can have more CMA users, like DSP etc22:40
bencohsure22:40
freemangordonalso CMA or not, this is still memory :)22:40
bencohI mean, yeah, but ...22:40
freemangordonesp on n900 it is costly22:41
bencohcma memory is not reclaimed for the rest of the system22:41
uvosso we are we stil going to be flipping application buffers on d4?22:41
uvosor are we blitting everywhere to save n900 cma22:41
bencohso either you will need up to 3 buffers at some point22:41
bencohand there is no downside to allocating it at boot22:41
bencohor you don't, but then I don't see any reason to allocate 3 of those22:42
freemangordonuvos: honestly, I am not sure how it works, but judging by the allocations, we flip 3 buffers only. application windows are composited to those 3 it seems22:42
Wizzupuvos: clutter does not blit anymore22:42
bencohI'm not sure I understood the fragmented DMM/TILER thing btw22:42
bencohbut I gotta go for now :)22:42
Wizzupexpect blit rather22:42
freemangordonWizzup: yes, but Xorg does22:42
freemangordonand basically we do blits to front buffer22:43
freemangordonXorg does flips I mean22:43
freemangordonand it basically blits application buffers to the scanout buffer, unless application is in fullscreen22:43
freemangordonin which case I am not sure how many scanout buffers we have22:44
uvosi mean if the window is not fullscreen i dont see how you have an option except to blit22:44
freemangordonright22:44
uvosunles you use layers22:44
freemangordonnot, it blits22:44
uvosbut fullscren should flip22:44
freemangordonyes22:45
uvosunless n900 dosent have the ram22:45
uvoscma that is22:45
freemangordonanyway, I have to stop for today, need some sleep22:45
uvosnight22:45
freemangordonnight!22:45
uvosfreemangordon: bug report btw:22:51
uvosfreemangordon: xorg allways crashes when you chvt back to it22:51

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!