Wizzup | ok | 00:05 |
---|---|---|
huckg | I'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 |
Wizzup | freemangordon: re: "how?", well it works for me | 02:25 |
Wizzup | freemangordon: with the other panel patch the device uses like 20mW more in OFF | 02:32 |
Wizzup | freemangordon: tmlind: btw: https://dpaste.com/BH5D5P8E8.txt | 02:40 |
Wizzup | X also not happy: [289971.389] (EE) OMAP(0): ERROR: PVRSRVMapFullDmaBuf failed: PVRSRV_ERROR_BAD_MAPPING fd 264 | 02:40 |
Wizzup | seems like a high fd to me | 02:40 |
Wizzup | freemangordon: latest kernel works for me (panel) | 02:42 |
Wizzup | it's also smoother in 3d for sure | 02:44 |
Wizzup | freemangordon: hm d3 seems to boot for me | 02:46 |
Wizzup | freemangordon: 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 |
freemangordon | Wizzup: seems somehow I managed to uninstall the kernel on my d4 | 07:20 |
freemangordon | I mean - I removed linux-image-droid4 | 07:21 |
freemangordon | but, this was after I installed linux-image-omap | 07:21 |
freemangordon | reinstalling linux-image-omap fixed it | 07:27 |
freemangordon | Wizzup: re that error - seems you are running out of DMM/TILES space somehow | 07:28 |
freemangordon | *TILER | 07:28 |
freemangordon | mighty17[m]: https://pastebin.com/YBxVKZts | 07:30 |
freemangordon | Wizzup: so, ba9c85a6643f9fad15018390a3b59280187b7564. shall be removed and other fix found for high power usage | 07:56 |
mighty17[m] | tysm | 08:37 |
freemangordon | Wizzup: also, why do we carry a20f161298226a368d73af1b1467568ba5d05efa? | 08:46 |
tmlind | freemangordon: your dmabuf fix also fixes my wlroots termite test case even with sgx clock slowed down :) | 10:43 |
tmlind | freemangordon: also, did you update the ddk blobs branch? seems like your blobs changes caused the environment regression somehow if i remember right? | 11:02 |
tmlind | hmm or am i confused again on what caused the environment variable needed regression? | 11:04 |
tmlind | i guess it must have been a mesa change instead.. | 11:04 |
tmlind | spotty connection, bbl | 11:20 |
Wizzup | freemangordon: regarding a20f161298226a368d73af1b1467568ba5d05efa - uvos said to keep it for charge mode iirc | 12:58 |
Wizzup | freemangordon: ok, I'll remove ba9c85a6643f9fad15018390a3b59280187b7564 | 12: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 |
Wizzup | freemangordon: is the tearing gone for you? I think I still have some | 14:34 |
freemangordon | Wizzup: no, as I said, tearing on d4 is another story | 17:14 |
freemangordon | tmlind: great! | 17:14 |
freemangordon | Wizzup: ok, but IIUC this commit causes wakeups 20 times per second | 17:15 |
freemangordon | uvos: ^^^ | 17:33 |
_uvos_ | sicelo: you need to add options "cpcap-battery ignore_temperature_probe=1" | 17:39 |
_uvos_ | with ofc obvious caviates | 17:40 |
_uvos_ | please if you have the time- document this on the wiki | 17:40 |
_uvos_ | (to some modprobe .conf) | 17:41 |
freemangordon | _uvos_: could you comment on kernel commit a20f161298226a368d73af1b1467568ba5d05efa | 17:43 |
freemangordon | "drm/omap: get fbdev working for manually updated display" | 17:43 |
sicelo | thanks. i transplanted the controller though. | 17:46 |
Wizzup | freemangordon: which commit causes wakeups? | 17:56 |
freemangordon | Wizzup: a20f161298226a368d73af1b1467568ba5d05efa ? | 17:57 |
Wizzup | ah | 17:57 |
_uvos_ | what commit is that? | 17:57 |
_uvos_ | im in a train | 17:57 |
freemangordon | ah | 17:57 |
freemangordon | _uvos_: "drm/omap: get fbdev working for manually updated display" | 17:58 |
_uvos_ | ah that | 17:58 |
freemangordon | also, IIUC, this is about fbdev emulation | 17:58 |
_uvos_ | should only cause wakeups if soemthing dirtys the fb | 17:58 |
_uvos_ | yes | 17:58 |
_uvos_ | it makes it work ond mapphones | 17:58 |
freemangordon | do we use/need that at all? | 17:58 |
_uvos_ | otherwise the display is never updated | 17:58 |
freemangordon | fbdev emulation I mean | 17:58 |
_uvos_ | currently for charging-mode | 17:58 |
_uvos_ | but i want to move that to drm | 17:59 |
_uvos_ | havent done it yet | 17:59 |
freemangordon | what is "charging mode"? | 17:59 |
_uvos_ | it was on fbdev because ddk1.9 bugs | 17:59 |
_uvos_ | boot the device by pluging in chargerger | 17:59 |
_uvos_ | a battery icon appears | 17:59 |
_uvos_ | and device charges | 17:59 |
freemangordon | ah, so "actdead" :) | 18:00 |
_uvos_ | yeah | 18:00 |
_uvos_ | sorta | 18:00 |
_uvos_ | implemented differently | 18:00 |
_uvos_ | its a runlevel | 18:00 |
freemangordon | yeah, I see | 18:00 |
_uvos_ | ill move it to drm | 18:00 |
_uvos_ | then we can drop that patch | 18:00 |
freemangordon | ok | 18:00 |
_uvos_ | if it causes trouble | 18:00 |
_uvos_ | otherwise haveing fbdev working is ofc nice in its own right | 18:01 |
freemangordon | well, I am not 100% sure, but IIUC it queues a work 20 times/sec | 18:01 |
freemangordon | IOW - looks like a hack | 18:01 |
_uvos_ | ok | 18:01 |
freemangordon | but yeah, ok, lets keep it for now if there is code that uses it | 18:02 |
freemangordon | _uvos_: though, I think we shall implement that 'charging mode' correctly, like starting matchbox etc | 18:03 |
freemangordon | because the same/similar mode is used for alarms | 18:03 |
_uvos_ | i really really dislkie that | 18:03 |
_uvos_ | and for alarms the charge mode runs a differen runlevel | 18:03 |
freemangordon | dislike what? having an alarm turning on the device? | 18:03 |
_uvos_ | you can have whatever you want there | 18:03 |
_uvos_ | remeber on mapphones we have _very_ little time | 18:03 |
_uvos_ | to settle the devie | 18:04 |
_uvos_ | or it powers off again | 18:04 |
freemangordon | ok, you can start charging immediately and then bring-up whatever UI is needed | 18:04 |
_uvos_ | sure | 18:04 |
freemangordon | I am not saying we shall do a lame implementation | 18:04 |
freemangordon | :) | 18:04 |
_uvos_ | so rn there is a script that chargemode uses to start other runlevels depending on condition | 18:05 |
freemangordon | ok | 18:05 |
_uvos_ | conitions are: unplugged, alarm, full, power button | 18:05 |
_uvos_ | rn all start runlevel default (and hildon) | 18:05 |
freemangordon | how do we know about alarm? | 18:05 |
freemangordon | I mean - is there anything passed by the BL? | 18:05 |
_uvos_ | but we can change that as soon as something else exists | 18:05 |
_uvos_ | it quers the hwclock | 18:06 |
freemangordon | hmmm | 18:06 |
freemangordon | ok | 18:06 |
_uvos_ | so if hwclock was set to boot the device | 18:06 |
freemangordon | yeah, got it | 18:06 |
_uvos_ | it will boot the next runlevel instead | 18:06 |
freemangordon | sounds sane | 18:07 |
freemangordon | I think we shall do something similar for n900 | 18:07 |
freemangordon | if this does not work already | 18:07 |
_uvos_ | it schould work | 18:08 |
freemangordon | not sure what NOLO does with hwclock on power-up | 18:08 |
freemangordon | it may resewt it | 18:08 |
freemangordon | *reset | 18:08 |
freemangordon | because boot mode is passed as ATAG | 18:08 |
_uvos_ | ok | 18:10 |
mighty17[m] | <mighty17[m]> "https://github.com/openpvrsgx-..." <- cc tmlind | 18:26 |
_uvos_ | freemangordon: "ok, you can start charging immediately and then bring-up whatever UI is needed" | 18:39 |
_uvos_ | i thin you missunderstood this | 18:39 |
_uvos_ | the problem isent starting charging | 18:39 |
_uvos_ | its that usb power can not keep d4 alive it uses to mutch | 18:39 |
_uvos_ | it must enter idle asap | 18:40 |
_uvos_ | and the bootloader gives little room here | 18:40 |
_uvos_ | it boots the device just after the battery has bearly enough charge to enter androids charge mode | 18:40 |
_uvos_ | wich is very quick | 18:40 |
bencoh | I'm not sure the bootloader would enter idle anyway (vs busy-waiting) | 18:42 |
bencoh | but I haven't checked, so I dunno | 18:42 |
_uvos_ | the bootloader sets cpcaps idle regs | 18:42 |
_uvos_ | er trickel charge regs | 18:43 |
_uvos_ | and shuts off | 18:43 |
_uvos_ | cpcap then boots again | 18:43 |
bencoh | ah | 18:43 |
_uvos_ | after a set voltage | 18:43 |
bencoh | nice | 18: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 along | 19:02 | |
freemangordon | _uvos_: I think I understand it right. "bring-up" of the UI after battery is charged enough to allow it | 19:13 |
freemangordon | also, I am sure we can power off all but CPU0, and put CPU0 @ lowest frequency | 19:13 |
freemangordon | This should be enough to support minimal UI (like alarm/charging one) with radios off | 19:14 |
uvos | probubly | 19:15 |
uvos | unsuprisingly i like the architecture that i desinged for charge mode :P | 19:15 |
uvos | anyhow ill move it to drm soon | 19:16 |
freemangordon | no, it sounds fine, what I am saying is that we shall extend it (if needed) to support alarm | 19:16 |
uvos | probunly i can do it tomorrow | 19:16 |
uvos | sure | 19:16 |
freemangordon | uvos: also, I am almost sure battery holds enough charge so matchbox to be started | 19:17 |
uvos | no | 19:17 |
freemangordon | hmm, ok | 19:17 |
uvos | so in the deepest discharge state we are allready in the hole | 19:17 |
uvos | when sysinit finishes | 19:17 |
uvos | because of kexecboot | 19:17 |
uvos | that takes extra time | 19:17 |
freemangordon | I see | 19:18 |
uvos | relatvie to android native | 19:18 |
uvos | so we allready have to move charge mode into initramfs | 19:18 |
uvos | at some point | 19:18 |
freemangordon | yeah, so we shall hold a bit in charge-only mode | 19:18 |
uvos | yeah somehting like that | 19:18 |
freemangordon | until we have lets say 2% (made-up) value | 19:18 |
uvos | sure | 19:18 |
freemangordon | and then proceed to charge-only-phase2 | 19:19 |
freemangordon | and here the switch shall be made to alarm, user, unplug, no? | 19:20 |
uvos | yeah | 19:20 |
uvos | thats how it currently works | 19:20 |
freemangordon | ah, nice | 19:20 |
freemangordon | for how long it stays in charge-only mode? | 19:20 |
uvos | untill sone of those switches is tripped | 19:20 |
uvos | (or its full) | 19:21 |
uvos | *s/sone/one | 19:21 |
freemangordon | another note - do you say that with everything but cpu0 and mmc omap4 uses more than 500mA? | 19:21 |
freemangordon | *everything off | 19:21 |
uvos | no idea probubly not | 19:21 |
freemangordon | so, *in theory* we may boot to alarm even if we don;t have minimum charge | 19:22 |
uvos | maybe | 19:22 |
freemangordon | cool | 19:22 |
uvos | the problem is,currently during boot its too mutch | 19:22 |
uvos | before userspace even starts | 19:22 |
uvos | so fix would have to be in kernel somehow | 19:22 |
uvos | or avoid loading so mayne modules | 19:23 |
freemangordon | hmm, maybe we shall load modules manually | 19:23 |
uvos | and have a inintramfs with just cpcap-carhger to dwel in | 19:23 |
uvos | *charger | 19:23 |
freemangordon | I think we shall try to avoid initrd if possible | 19:23 |
freemangordon | not really sure how this can be achieved | 19:24 |
uvos | im pretty neutral on having a initramfs | 19:25 |
freemangordon | well, my point is that this is yet another thing to maintain :) | 19:25 |
freemangordon | if we can avoid... | 19:26 |
freemangordon | but we'll have to find a way to delay module loading until some condition is made | 19:26 |
uvos | yeah | 19:27 |
uvos | anyhow its not that important to fix this rn | 19:27 |
uvos | mce now shutsdown the device well ahead of the problem area | 19:28 |
uvos | so you should only be albe to enter it by leaving the device in cupboard for a long time | 19:28 |
uvos | or leste hanging or something | 19:28 |
freemangordon | my point was about bootup | 19:28 |
uvos | and even then you can just use androids charge mode | 19:28 |
freemangordon | but yeah, a corner case | 19:28 |
uvos | freemangordon: yes i know | 19:29 |
uvos | freemangordon: im saing this problem is farly small | 19:29 |
uvos | atm | 19:29 |
freemangordon | :nod: | 19:29 |
bencoh | freemangordon: don't we already use devuan's initramfs? | 19:34 |
uvos | no | 19:34 |
bencoh | (I agree with maintaining an initramfs being a burden btw) | 19:34 |
bencoh | if we really want to we could probably blacklist modules in /etc/modprobe.d/ and insmod it manually | 19:35 |
bencoh | (it sounds kinda ugly though) | 19:35 |
freemangordon | uvos: 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 |
freemangordon | bencoh: see ^^^ | 19:35 |
bencoh | :) | 19:36 |
uvos | sure but i agree its really ugly | 19:36 |
freemangordon | would that work? | 19:36 |
uvos | we could have a runlevel that avoids running udev instead | 19:36 |
uvos | and modprobes just cpcap modules | 19:36 |
uvos | and then dwels | 19:36 |
bencoh | probably, although bindmounting sounds even worse to me that manually insmoding | 19:36 |
uvos | and then runs normal sysinit | 19:36 |
freemangordon | ah, so it is udev that does modprobe? | 19:36 |
uvos | yeah | 19:36 |
freemangordon | good | 19:36 |
freemangordon | well yeah | 19:36 |
bencoh | we can just add a udev rule then | 19:36 |
freemangordon | bencoh: nor, really, not starting udev is better | 19:37 |
freemangordon | *no | 19:37 |
* bencoh headscratches | 19:37 | |
freemangordon | we build whatever we need in zImage | 19:37 |
freemangordon | for minimal system | 19:37 |
uvos | sure | 19:38 |
freemangordon | that does charging only | 19:38 |
uvos | that probubly helps start charging sooner too | 19:38 |
freemangordon | mhm | 19:38 |
bencoh | (btw at $job bootloader prevents booting (ie waits) until battery is "charged enough") | 19:38 |
freemangordon | and once we have enough charge, we start udev or $whatever_is_needed | 19:38 |
freemangordon | like swithing the runlevel | 19:39 |
freemangordon | *switching | 19:39 |
freemangordon | I think that way we avoid initrd | 19:39 |
bencoh | oh right, using a different runlevel sounds like a decent idea | 19:39 |
freemangordon | uvos: we may want to fix getbootstate to fi that new boot logic | 19:40 |
uvos | whats this? | 19:40 |
freemangordon | a tool that gets boot state, like USER, ACTDEAD, MALF | 19:40 |
uvos | from atags? | 19:41 |
freemangordon | yes | 19:41 |
uvos | ok | 19:41 |
freemangordon | I know you hate it, but we shall keep ACTEAD (in some shape) at least for a while | 19:41 |
freemangordon | there is too much code that relies on env var being set | 19:42 |
uvos | so currently chargemode just checks if the usb cable is plugged in (and assumes that this means we should enter charge mode) and with the hwclock | 19:42 |
uvos | on mapphones we cant asses the boot reason | 19:42 |
uvos | the android kernel has cleard it before we can kexec | 19:42 |
uvos | the good thing about this method is also it works everywhere | 19:42 |
uvos | ie currently on maphones and pp and n900 | 19:42 |
freemangordon | yeah, sounds fine | 19:42 |
uvos | the bad thing ofc is that the user might press the power button | 19:43 |
uvos | then insert the cable | 19:43 |
freemangordon | while on charger? | 19:43 |
freemangordon | ah | 19:43 |
freemangordon | yeah | 19:43 |
uvos | and it will enter charge mode erronously | 19:43 |
uvos | not a big deal of the user will just press the power button again | 19:43 |
uvos | but a bit wonky | 19:43 |
freemangordon | yeah | 19:43 |
uvos | and at least on maphones we cant do better | 19:44 |
freemangordon | not a big issue I would say | 19:44 |
freemangordon | though, I think on OMAPs at least there is some memory location with flags about the boot reason | 19:44 |
freemangordon | ah, but android kernel clears that | 19:45 |
freemangordon | I see | 19:45 |
freemangordon | well, we do the best we can | 19:45 |
freemangordon | then | 19:45 |
freemangordon | uvos: basically, ACTDEAD means we have /tmp/ACT_DEAD :) | 19:46 |
freemangordon | and also ACT_DEAD in /tmp/mode (or something | 19:46 |
freemangordon | alarm 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 device | 19:48 |
freemangordon | also, XSession already supports actdead mode, like different set of applications is started | 19:50 |
freemangordon | Wizzup: what is hildon-kernel-config-n900 ? hildon-meta-n900 depends on it | 20:39 |
freemangordon | Wizzup: OTOH lates kernel seems to boot fine on both d4 and n900 | 20:50 |
Wizzup | 20:39 < freemangordon> Wizzup: what is hildon-kernel-config-n900 ? hildon-meta-n900 depends on it | 21:00 |
Wizzup | freemangordon: this is the uImage postinst | 21:00 |
Wizzup | freemangordon: yes, also boots ok for me | 21:00 |
freemangordon | can't be as it is neither installed nor available :) | 21:01 |
freemangordon | leste-config-n900 is postinst :p | 21:01 |
freemangordon | Wizzup: I think you initially planned to have that additional package | 21:02 |
freemangordon | but later on we decided to move postinst to leste-config-n900 | 21:03 |
freemangordon | so I thing this dependency is not needed | 21:03 |
freemangordon | Wizzup: I think I fixed sgx-ddk-um dependencies | 21:05 |
Wizzup | freemangordon: no, we decided not to go the leste-config route | 21:14 |
Wizzup | leste-config-n900 is not the postinst | 21:14 |
Wizzup | thanks for looking at the deps though | 21:15 |
freemangordon | root@devuan-n900:~# dpkg -S n900-uImage | 21:15 |
freemangordon | maemo-kernel-config-n900: /etc/kernel/postinst.d/n900-uImage | 21:15 |
Wizzup | exactly | 21:15 |
freemangordon | so, again, what is hildon-kernel-config-n900? | 21:15 |
Wizzup | it is the postinst script to make the uImage | 21:15 |
freemangordon | maemo-kernel-config-n900 != is hildon-kernel-config-n900 | 21:16 |
Wizzup | hildon-kernel-config-n900 was a mistake on my side | 21:16 |
Wizzup | I fixed that since | 21:16 |
Wizzup | afaik | 21:16 |
Wizzup | if there is any dep on it, that must go | 21:16 |
freemangordon | not in the repos at least | 21:16 |
Wizzup | https://maedevu.maemo.org/pkgweb/beowulf-devel/main/binary-armhf/maemo-kernel-config-n900.html | 21:16 |
freemangordon | yes, hildon-meta-n900 depends on it | 21:17 |
Wizzup | https://maedevu.maemo.org/pkgweb/search?q=hildon-kernel-config | 21:17 |
Wizzup | freemangordon: ok then the meta needs fixing if it's not fixed already | 21:17 |
Wizzup | let me check | 21:17 |
freemangordon | I think this is the last issue | 21:17 |
Wizzup | ok | 21:17 |
Wizzup | I see it | 21:17 |
Wizzup | yes please fix | 21:17 |
Wizzup | or shall I? | 21:17 |
freemangordon | replace hildon with maemo? | 21:17 |
freemangordon | I will | 21:17 |
Wizzup | yes | 21:18 |
freemangordon | ok, I will do | 21:18 |
Wizzup | ty | 21:30 |
freemangordon | done | 21:37 |
uvos | <freemangordon> uvos: basically, ACTDEAD means we have /tmp/ACT_DEAD :) | 21:58 |
uvos | yean not that crap has to go | 21:58 |
uvos | so actdead can be a runlevel for charging and one for alarms or watever | 21:59 |
uvos | but all the deamons checking some random file and then having houndreds of if(actead) in the code all over the place | 21:59 |
uvos | (mce literally has 100s | 21:59 |
uvos | ) | 21:59 |
uvos | is spagatii crap | 21:59 |
uvos | *spaghetti | 21:59 |
freemangordon | before fixing that we shall have it running | 22:00 |
freemangordon | otherwise we don't know what we fix | 22:00 |
freemangordon | hmm: | 22:01 |
freemangordon | cma: cma_alloc: reserved: alloc failed, req-size: 375 pages, ret: -16 | 22:01 |
freemangordon | OS error code 16: Device or resource busy | 22:02 |
freemangordon | this should not happen | 22:02 |
Wizzup | freemangordon: n900? | 22:02 |
freemangordon | yes | 22:03 |
freemangordon | happened twice, during heavy IO | 22:03 |
* freemangordon checks how is memory allocated | 22:04 | |
Wizzup | uvos: so do you still not get d3 hangs? | 22:05 |
uvos | Wizzup: so i just came home | 22:07 |
uvos | the uptime of my d3 suggests it dident crash | 22:07 |
uvos | but it ussaly hangs while using it | 22:08 |
uvos | i wasent able to test the other day actively more than when i said it dosent seam to crash | 22:08 |
uvos | that was just a couple of hours | 22:08 |
uvos | so maybe | 22:08 |
uvos | if it dident help yours its just noise most likely | 22:08 |
uvos | even it it dosent help with the current hang, i would keep the patch in mind, but maybe not applied | 22:10 |
uvos | since clearly motorola thought it needed at some point, and d3's microcode/fw is so mutch older than d4 | 22:10 |
uvos | where they obviously patched it out | 22:11 |
Wizzup | right | 22:16 |
freemangordon | Wizzup: maybe I shall change DDX to retry allocations until memory is available | 22:26 |
uvos | that can cause an undesirable deadlock no? | 22:27 |
freemangordon | not really | 22:28 |
freemangordon | because we definitely have free CMA memory, it is just that *now* there are too many pages that cannot be migrated | 22:28 |
uvos | sure | 22:28 |
uvos | but do you know that? | 22:29 |
uvos | what happens when something leaks cma | 22:29 |
freemangordon | well, what can we do in such case? restart X? | 22:29 |
freemangordon | I mean - if we have CMA leak, nothing can be done | 22:29 |
uvos | x crashing with obvious messag in this case is mutch better than it hanging | 22:30 |
freemangordon | but, this is not the case here | 22:30 |
freemangordon | well, it can retry some time | 22:30 |
uvos | also cant cma be filled becaue video decoding or whatever is using it | 22:30 |
freemangordon | better that instant crash | 22:30 |
uvos | sure yeah thats fine | 22:30 |
freemangordon | we get -16, not -12 | 22:30 |
freemangordon | -EBUSY | 22:30 |
freemangordon | this seems to be returned after 5 retries to free big enough memory block | 22:31 |
uvos | ok | 22:32 |
freemangordon | I am not sure __GFP_REPEAT is usable if passed to dma_alloc_wc | 22:32 |
Wizzup | freemangordon: I wonder if something is leaking as well (wrt d4) | 22:36 |
Wizzup | freemangordon: but makes sense to try | 22:36 |
freemangordon | Wizzup: d4 does not use CMA | 22:36 |
Wizzup | freemangordon: yeah | 22:36 |
Wizzup | I know | 22:36 |
Wizzup | btw n900 perf is great now imho | 22:36 |
freemangordon | it is most-probably DMM/TILER that gets fragmented | 22:37 |
freemangordon | yeah, but there is a place for improvement | 22:37 |
freemangordon | we still lack HW accell for compositing | 22:37 |
freemangordon | but will do it after abook etc | 22:37 |
freemangordon | I wonder if I can just allocate a pool of 3 BOs in DDX and call it a day | 22:38 |
Wizzup | mhm | 22:39 |
bencoh | probably (why not?) | 22:39 |
Wizzup | freemangordon: agreed @ boabook | 22:39 |
freemangordon | we still can have issues on rotation though | 22:39 |
bencoh | just allocate buffers large enough hold both orientations | 22:39 |
freemangordon | well, too much unused memory | 22:40 |
bencoh | if you use cma for that and are admittedly the only cma user ... | 22:40 |
freemangordon | in theory we can have more CMA users, like DSP etc | 22:40 |
bencoh | sure | 22:40 |
freemangordon | also CMA or not, this is still memory :) | 22:40 |
bencoh | I mean, yeah, but ... | 22:40 |
freemangordon | esp on n900 it is costly | 22:41 |
bencoh | cma memory is not reclaimed for the rest of the system | 22:41 |
uvos | so we are we stil going to be flipping application buffers on d4? | 22:41 |
uvos | or are we blitting everywhere to save n900 cma | 22:41 |
bencoh | so either you will need up to 3 buffers at some point | 22:41 |
bencoh | and there is no downside to allocating it at boot | 22:41 |
bencoh | or you don't, but then I don't see any reason to allocate 3 of those | 22:42 |
freemangordon | uvos: 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 seems | 22:42 |
Wizzup | uvos: clutter does not blit anymore | 22:42 |
bencoh | I'm not sure I understood the fragmented DMM/TILER thing btw | 22:42 |
bencoh | but I gotta go for now :) | 22:42 |
Wizzup | expect blit rather | 22:42 |
freemangordon | Wizzup: yes, but Xorg does | 22:42 |
freemangordon | and basically we do blits to front buffer | 22:43 |
freemangordon | Xorg does flips I mean | 22:43 |
freemangordon | and it basically blits application buffers to the scanout buffer, unless application is in fullscreen | 22:43 |
freemangordon | in which case I am not sure how many scanout buffers we have | 22:44 |
uvos | i mean if the window is not fullscreen i dont see how you have an option except to blit | 22:44 |
freemangordon | right | 22:44 |
uvos | unles you use layers | 22:44 |
freemangordon | not, it blits | 22:44 |
uvos | but fullscren should flip | 22:44 |
freemangordon | yes | 22:45 |
uvos | unless n900 dosent have the ram | 22:45 |
uvos | cma that is | 22:45 |
freemangordon | anyway, I have to stop for today, need some sleep | 22:45 |
uvos | night | 22:45 |
freemangordon | night! | 22:45 |
uvos | freemangordon: bug report btw: | 22:51 |
uvos | freemangordon: xorg allways crashes when you chvt back to it | 22:51 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!