| Wizzup | uvos__: neat, I'll try that as well | 00:03 |
|---|---|---|
| Wizzup | uvos__: does emergency shell start droid4-powermanagement and detach kernel console? | 00:04 |
| uvos__ | Wizzup: no | 00:04 |
| Wizzup | uvos__: glad you're testing the throughput btw | 00:04 |
| Wizzup | uvos__: well that's the explanation then | 00:04 |
| Wizzup | uvos__: I'm 99% sure the problem is console detach | 00:04 |
| uvos__ | ok | 00:04 |
| Wizzup | (or caused by at least) | 00:04 |
| uvos__ | that explains why i just failed at captureing the problem on uart | 00:05 |
| Wizzup | it prints it to console when it tries to power down | 00:08 |
| Wizzup | it should be in your messages | 00:09 |
| Wizzup | uvos__: re: more corruption could also be that you have a custom theme and/or backgrounds on your other devices | 01:18 |
| freemangordon | Wizzup: one more thing while we are at it - I think it makes sense to not set zswap on n900 but use dedicated swap partition on eMMC | 08:12 |
| freemangordon | also, using 16bpp will greatly reduce memory usage | 08:12 |
| Wizzup | freemangordon: yeah I am still not convinced about zswap being a bad idea and swapping to slow and irreplaceable disk instead | 10:43 |
| parazyd | Yeah swapping on such storage is bound to degrade lifetime | 11:01 |
| Wizzup | parazyd: hm it looks like /etc/kernel/postinst.d runs before the postinst of our kernel image package | 12:40 |
| Wizzup | that can't be right? | 12:41 |
| uvos__ | parazyd: irc.txt is broken | 12:41 |
| Wizzup | parazyd: hmmmm I guess our modifications to builddeb actually make it run our stuff before run-parts | 12:41 |
| Wizzup | that's wrong | 12:41 |
| Wizzup | I fixed builddeb | 12:43 |
| uvos__ | freemangordon: is it really smart to swap on emmc on a device thats 10+ years old? its probubly getting up there on writes allready | 12:43 |
| Wizzup | well it depends right | 12:44 |
| Wizzup | if we want 0.75GB of swap we will need to do that | 12:44 |
| Wizzup | (which is what fremantle has) | 12:44 |
| Wizzup | we could swap to sd card as well but it is kinda slow | 12:44 |
| Wizzup | otoh I think a bit of zswap really isn't a bad idea | 12:44 |
| Wizzup | of course not too much, and maybe our ratio is off | 12:45 |
| uvos__ | if the 100mhz clock hack works on omap3/n900 then modern sdcards way outprerform mmc | 12:45 |
| Wizzup | you tried this mostly on d4 though right? | 12:47 |
| Wizzup | also iirc n900 bus width is small | 12:47 |
| uvos__ | exclusively yeah | 12:47 |
| uvos__ | its 4bit like d4 | 12:47 |
| uvos__ | emmc bus with is 8 | 12:47 |
| uvos__ | on both | 12:47 |
| uvos__ | doubleing the bus clock levels the field | 12:47 |
| Wizzup | ok | 12:50 |
| bencoh | the "hack" is basically allowing SDR104 even though it shouldn't be supported? | 13:04 |
| uvos__ | not really | 13:04 |
| uvos__ | so we can do in spec sdr50 with 5v bus | 13:06 |
| uvos__ | omap4 can also do sdr100 @5v and ddr50 @5v and thats supported by some mmc chips | 13:06 |
| bencoh | 5V or 3.3V? | 13:07 |
| uvos__ | but sdcard spec for uhs1 is 50mhz @5v sdr or 50mhz @1.8 ddr or 100mhz @1.8v sdr | 13:07 |
| uvos__ | we cant do 1.8v at all | 13:07 |
| uvos__ | s/5v/3.3v | 13:10 |
| uvos__ | see sdcard uhs1 spec page 3 | 13:11 |
| freemangordon | Wizzup: re zswap, as I told you, I played enough with compcache (which is the same) back then, and I can tell you that it only makes things worse | 13:23 |
| freemangordon | slow CPU on 256 MiB RAM zswap is a recipe for disaster | 13:23 |
| freemangordon | even if you tell it to be 64MiB only | 13:23 |
| freemangordon | so, we either have a dedicated swap partition on uSD (which will be slow as hell) or we use swap partition which is already there | 13:24 |
| freemangordon | not much we can do about eMMC wearing | 13:25 |
| Wizzup | I think we will give users the option | 13:25 |
| Wizzup | We do zswap every where at the moment and it hasn't caused many problems really | 13:25 |
| bencoh | including n900? | 13:26 |
| Wizzup | yes | 13:26 |
| Wizzup | btw, once latest droid4-linux is done I think n900 on experimental should apt-get upgrade to newer 5.15 kernel | 13:26 |
| Wizzup | including postinst hook | 13:26 |
| Wizzup | I still got a X crash on it after opening ~5 terminals though | 13:26 |
| Wizzup | bencoh: but we might want to tweak the ratio for some low power devices perhaps | 13:27 |
| freemangordon | Wizzup: please disable that on n900 | 13:27 |
| Wizzup | freemangordon: will it help with the x crash? | 13:28 |
| freemangordon | do you want me to give you the link to TMO thread? | 13:28 |
| Wizzup | no I remember the thread on compcache | 13:28 |
| freemangordon | does it still crash? | 13:28 |
| Wizzup | yes | 13:28 |
| freemangordon | maybe, I dont; know | 13:28 |
| freemangordon | is it still CMA related crash? | 13:28 |
| Wizzup | [ 308.908050] cma: cma_alloc: reserved: alloc failed, req-size: 277 pages, ret: -12 | 13:29 |
| freemangordon | with compaction enabled? | 13:29 |
| Wizzup | yes | 13:29 |
| freemangordon | CMA is 32 MiB? | 13:29 |
| Wizzup | yes | 13:29 |
| freemangordon | maybe we have a memleak | 13:29 |
| Wizzup | and proactive timeout of 120s | 13:29 |
| freemangordon | and yes, maybe too much memory is non-evictable | 13:29 |
| Wizzup | the kernel is building on jenkins atm | 13:30 |
| bencoh | /proc/slabinfo might have some info | 13:30 |
| bencoh | although .... nevermind | 13:30 |
| freemangordon | Wizzup: please disable zswap and enable eMMC swap and see if it will continue with the crashes | 13:30 |
| bencoh | cma might not show there | 13:30 |
| freemangordon | bencoh: /proc/meminfo | 13:30 |
| bencoh | freemangordon: I wanted something more detailed, but yeah | 13:31 |
| Wizzup | freemangordon: seems insane to me but ok I'll rename the zram init script | 13:31 |
| freemangordon | but I don;t really understand what exactly CmaFree is supposed to mean | 13:31 |
| bencoh | is there any other CMA user on n900? | 13:31 |
| Wizzup | freemangordon: ah wait looks like zram is already disabled | 13:31 |
| freemangordon | no, it is not | 13:31 |
| freemangordon | at least no in the image | 13:31 |
| freemangordon | *not | 13:31 |
| freemangordon | bencoh: none I am aware of | 13:31 |
| freemangordon | buw we can simply have a memleak | 13:32 |
| freemangordon | *but | 13:32 |
| Wizzup | freemangordon: on my device | 13:32 |
| freemangordon | ah | 13:32 |
| freemangordon | and do you have swap? | 13:32 |
| Wizzup | there was some | 13:32 |
| Wizzup | I'm rebooting and will disable | 13:32 |
| freemangordon | can't parse | 13:32 |
| Wizzup | I am rebooting and will run swapoff | 13:33 |
| Wizzup | and then try to crash it again | 13:33 |
| freemangordon | of zswap? | 13:33 |
| Wizzup | swapoff -a | 13:33 |
| freemangordon | well, swapon /dev/mmcblk1p3 | 13:33 |
| Wizzup | why? we have only 80MB out of 250MB in use | 13:33 |
| Wizzup | clearly swap is not needed for such a simple test | 13:33 |
| freemangordon | (iirc this is swap partition on eMMC) | 13:33 |
| freemangordon | Wizzup: I think swap is needed for page migration | 13:34 |
| Wizzup | what is that? | 13:34 |
| freemangordon | moving pages between zones | 13:34 |
| freemangordon | in order to have CMA, you need to migrate pages | 13:34 |
| freemangordon | compactin is the process which does it | 13:35 |
| freemangordon | *compaction | 13:35 |
| freemangordon | in order to have a big block of contiguous memory, you need to move the pages that are in the middle of the block | 13:36 |
| freemangordon | used ones that is | 13:36 |
| freemangordon | bencoh: do you have any idea how to choose CMA size? | 13:36 |
| Wizzup | freemangordon: same problem | 13:39 |
| Wizzup | with zram off and mmcblk1p3 as swap | 13:39 |
| freemangordon | how many applications? | 13:39 |
| Wizzup | I just open about ~5 osso-xterms quickly | 13:39 |
| Wizzup | through the menu button and then the new button | 13:39 |
| Wizzup | you caxn just press the same place on the ts to open many quickly | 13:39 |
| freemangordon | hmm, cannot repro here | 13:39 |
| freemangordon | lemme check though | 13:39 |
| Wizzup | well let's wait for -experimental kernel | 13:40 |
| freemangordon | *try | 13:40 |
| Wizzup | it'll be ~2hrs | 13:40 |
| Wizzup | solidrun still didn't ship the server, 6 weeks later :( | 13:40 |
| freemangordon | ok, but using my config might bring different results | 13:40 |
| Wizzup | freemangordon: sure | 13:40 |
| freemangordon | also, I am with 24MiB CMA | 13:41 |
| Wizzup | root@devuan-n900:~# zgrep COMPACT /proc/config.gz | 13:41 |
| Wizzup | CONFIG_COMPACTION=y | 13:41 |
| Wizzup | root@devuan-n900:~# zgrep CMA /proc/config.gz | grep MBYTES | 13:41 |
| Wizzup | CONFIG_CMA_SIZE_MBYTES=32 | 13:41 |
| Wizzup | CONFIG_CMA_SIZE_SEL_MBYTES=y | 13:41 |
| freemangordon | booting the device | 13:42 |
| bencoh | freemangordon: cma= at boot | 13:43 |
| freemangordon | 16 xterms open | 13:43 |
| freemangordon | no crash | 13:43 |
| bencoh | (bootargs I mean) | 13:43 |
| freemangordon | 24 | 13:44 |
| freemangordon | root@devuan-n900:~# zgrep COMPACT /proc/config.gz | 13:46 |
| freemangordon | CONFIG_COMPACTION=y | 13:46 |
| freemangordon | root@devuan-n900:~# zgrep CMA /proc/config.gz | grep MBYTES | 13:46 |
| freemangordon | CONFIG_CMA_SIZE_MBYTES=24 | 13:46 |
| freemangordon | CONFIG_CMA_SIZE_SEL_MBYTES=y | 13:46 |
| freemangordon | bencoh: no, my question was not how to set it, but how to choose the size itself | 13:46 |
| bencoh | ah | 13:47 |
| freemangordon | like, do we prefer 16MiB or 64MiB | 13:47 |
| freemangordon | Wizzup: I don;t understand why it behaves liek that on your device | 13:47 |
| bencoh | well, simply count how many frames we need, round frame size to silly-aligned-size (I don't know what it is aligned to on n900), and it should give us the required size | 13:48 |
| bencoh | that's how I do it $here | 13:48 |
| Wizzup | freemangordon: maybe try with repo kernel | 13:48 |
| Wizzup | freemangordon: it's still building fwiw but the only diff is the postinst script swap | 13:49 |
| Wizzup | (swapping of what runs when) | 13:49 |
| freemangordon | Wizzup: ok | 13:49 |
| Wizzup | freemangordon: probably easier to just fetch the branch and build yourself | 13:49 |
| freemangordon | bencoh: what is "frames"? | 13:49 |
| bencoh | freemangordon: display/gpu/whatever frame | 13:50 |
| bencoh | as in framebuffer | 13:50 |
| freemangordon | ah | 13:50 |
| freemangordon | well, not that simple I think | 13:50 |
| bencoh | it's that simple with v4l2 devices at least | 13:50 |
| freemangordon | because every application uses additional front framebuffer which must be CMA | 13:50 |
| bencoh | each app has its own buffer in CMA? | 13:51 |
| freemangordon | mhm | 13:51 |
| bencoh | how large is a frame? 840x480x2? | 13:51 |
| bencoh | (assuming RGB565) | 13:52 |
| freemangordon | 24 xterms+HAM+calculator+cpl+pdf reader | 13:52 |
| freemangordon | 24bpp | 13:52 |
| bencoh | ah | 13:52 |
| bencoh | so 840x480x3 | 13:52 |
| freemangordon | mhm | 13:52 |
| bencoh | ~1.2M, still need to know what it should be aligned to, 2M might be the right answer | 13:53 |
| freemangordon | 2MiB per application? | 13:53 |
| bencoh | that sounds silly and super high | 13:53 |
| bencoh | but yeah | 13:53 |
| freemangordon | lemme check something | 13:53 |
| bencoh | I don't think I ever hit that limit on fremantle, let's see | 13:53 |
| freemangordon | on fremantle it is different | 13:54 |
| bencoh | why? | 13:54 |
| freemangordon | they don;t flip (that's why the tearing) | 13:54 |
| bencoh | ah | 13:54 |
| freemangordon | on fremantle they use blit | 13:54 |
| freemangordon | IIUC | 13:54 |
| bencoh | well ... | 13:54 |
| bencoh | considering that n900 is quite low on memory, I wonder if flipping is really the way to go then | 13:55 |
| freemangordon | yeah | 13:55 |
| freemangordon | well, we still need memory for the buffers | 13:56 |
| freemangordon | the question is whether it will be CMA or not | 13:56 |
| freemangordon | so not much of a difference | 13:56 |
| freemangordon | Total 247 objects, 91979776 bytes | 13:57 |
| freemangordon | cat /sys/kernel/debug/dma_buf/bufinfo that is | 13:57 |
| freemangordon | ;) | 13:57 |
| bencoh | 247 objects? | 13:57 |
| freemangordon | this is for 24 xterms+HAM+calculator+cpl+pdf reader | 13:58 |
| freemangordon | sure | 13:58 |
| bencoh | uh | 13:58 |
| Wizzup | 87MB? | 13:58 |
| freemangordon | mhm | 13:58 |
| freemangordon | only part of this is CMA | 13:58 |
| bencoh | on desktop (intel/i915) I see 8 objects, 26148864 bytes | 13:58 |
| bencoh | ah | 13:58 |
| freemangordon | well, I guess your desktop is not 800x480 :) | 13:59 |
| bencoh | sure, but the interesting part was : only 8 objects :) | 13:59 |
| freemangordon | compositing WM? | 14:00 |
| bencoh | oh, that's the difference | 14:00 |
| bencoh | obviously not :) | 14:00 |
| bencoh | (wmii) | 14:00 |
| freemangordon | also, maybe it does not use DMA_BUF | 14:00 |
| freemangordon | but normal memory | 14:00 |
| bencoh | i915 uses dmabuf | 14:00 |
| freemangordon | for everything? | 14:00 |
| bencoh | no idea :) | 14:01 |
| freemangordon | I mean - on omap DDX every pixmap is backed by BO | 14:01 |
| bencoh | do you know which of those buffers are allocated in CMA? | 14:01 |
| freemangordon | yes | 14:01 |
| bencoh | is there really one per app then? | 14:01 |
| freemangordon | lemme check | 14:02 |
| freemangordon | hmm, something is wrong here | 14:09 |
| bencoh | what is? | 14:09 |
| freemangordon | 1z1mLC45 | 14:10 |
| freemangordon | https://pastebin.com/1z1mLC45 | 14:10 |
| freemangordon | flags should tell us whether this is scanout buffer or not | 14:10 |
| freemangordon | https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/omap_drm.h#L42 | 14:11 |
| freemangordon | but I only see OMAP_BO_WC | 14:11 |
| bencoh | that's a lot of small (4k) buffers | 14:11 |
| freemangordon | yeah | 14:12 |
| bencoh | what are those used for? | 14:12 |
| freemangordon | icons? | 14:12 |
| freemangordon | I don;t know | 14:12 |
| bencoh | ah, right | 14:12 |
| freemangordon | root@devuan-n900:/sys/kernel/debug/dma_buf# cat bufinfo | grep 01536000 | wc -l | 14:13 |
| freemangordon | 30 | 14:13 |
| bencoh | for 24 windows? | 14:13 |
| freemangordon | mhm | 14:13 |
| freemangordon | +2 for X itself | 14:13 |
| freemangordon | not 24 | 14:13 |
| freemangordon | 28 | 14:13 |
| freemangordon | 24 xterms+HAM+calculator+cpl+pdf reader | 14:14 |
| bencoh | ah | 14:14 |
| bencoh | so window buffers are rounded to 1536000 | 14:14 |
| bencoh | what did you expect apart from BO_WC? | 14:15 |
| freemangordon | OMAP_BO_SCANOUT | 14:15 |
| bencoh | is it dmabuf-exported? | 14:15 |
| freemangordon | hmm? | 14:15 |
| freemangordon | what do you mean? | 14:16 |
| bencoh | I'm basically wondering if the dss scanout buffer is actually supposed to show up in that list | 14:17 |
| freemangordon | sure | 14:17 |
| freemangordon | it is dma_buf BO | 14:18 |
| bencoh | well ... | 14:18 |
| freemangordon | yes, it is, omap DDX uses omap_bo_new(tiled)() | 14:19 |
| freemangordon | for every CreatePixmap | 14:19 |
| freemangordon | hmm | 14:24 |
| freemangordon | /sys/kernel/debug/dri/1 seems to provide more info | 14:25 |
| freemangordon | bencoh: https://pastebin.com/ybzQvDYH | 14:30 |
| freemangordon | https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1038 | 14:31 |
| freemangordon | we have 5 scanout buffers only | 14:33 |
| freemangordon | scanout == CMA allocated | 14:33 |
| freemangordon | Wizzup: could you check on your device? | 14:33 |
| bencoh | freemangordon: so 5*1536000 | 14:34 |
| freemangordon | mhm | 14:34 |
| bencoh | unless we hit some mem alloc issue preventing the kernel from allocating a buffer from CMA | 14:35 |
| bencoh | (which would sound like a bug) | 14:35 |
| freemangordon | Total 56 objects, 6766592 bytes | 14:35 |
| freemangordon | after I closed all applications | 14:36 |
| bencoh | and still 5 CMA? | 14:36 |
| freemangordon | mhm | 14:36 |
| bencoh | well ... :) | 14:36 |
| freemangordon | 4x1536000 and 1x16384 | 14:36 |
| freemangordon | I think the small one is cursor | 14:36 |
| bencoh | we still need to know how buffers are allocated (alignement) | 14:37 |
| bencoh | but in any case cma=16M should probably be enough | 14:37 |
| freemangordon | what do you mean alignment? this is ordinary DMA memory (excluding CMA ones) | 14:38 |
| freemangordon | and we use sg lists | 14:38 |
| freemangordon | this is the patch I wrote yesterday, basically | 14:38 |
| freemangordon | so, alignment is on page | 14:39 |
| bencoh | like, page-aligned allocations (ie buffers allocated on page boundaries), but with a higher ... ah | 14:39 |
| bencoh | well then ... | 14:39 |
| freemangordon | no, this is valid for CMA allocations only (higher...) | 14:39 |
| bencoh | but we _are_ talking about cma right ? :) | 14:40 |
| bencoh | I mean, the question was to know how to define cma size | 14:40 |
| freemangordon | no all the time :) | 14:40 |
| freemangordon | ah yeah | 14:40 |
| bencoh | :) | 14:40 |
| freemangordon | Wizzup: which branch is the latest one? | 14:41 |
| freemangordon | ah, found it | 14:41 |
| freemangordon | or not? | 14:41 |
| freemangordon | where are those patches? | 14:42 |
| freemangordon | bencoh: see this https://github.com/maemo-leste/droid4-linux/commit/d1668c20ff26556874392947337a03cbf43b13e6 | 14:43 |
| freemangordon | https://github.com/maemo-leste/droid4-linux/commit/d1668c20ff26556874392947337a03cbf43b13e6#diff-9b3c6ba4dcbd05c07bafe254dd7bc5fd1ac42fede2f7d43aa8250a20c31eecb3R1041 | 14:43 |
| freemangordon | this is what happens with non-cma buffers | 14:43 |
| freemangordon | bencoh: so, it seems we need 3+1 fulscreen buffers | 14:44 |
| freemangordon | 3 are for DRI2 TripleBuffer | 14:44 |
| freemangordon | 1 is for kernel console | 14:44 |
| freemangordon | I think this is the math | 14:44 |
| Wizzup | freemangordon: this branch https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15-cleaned-up | 14:46 |
| freemangordon | Wizzup: yep, found it | 14:46 |
| freemangordon | Wizzup: could you share what you have in /sys/kernel/debug/dri/1/gem after you open few applications? | 14:46 |
| Wizzup | ok | 14:47 |
| Wizzup | let me boot | 14:47 |
| freemangordon | Wizzup: oh, my wifi iface is wlan24 :) | 14:50 |
| freemangordon | no wonder it does not work | 14:50 |
| Wizzup | n900? | 14:50 |
| freemangordon | mhm | 14:50 |
| freemangordon | udev did that I guess | 14:50 |
| freemangordon | not sure where to look though | 14:50 |
| Wizzup | freemangordon: # ls /sys/kernel/debug/dri/*/gem | 14:50 |
| Wizzup | /sys/kernel/debug/dri/0/gem /sys/kernel/debug/dri/128/gem | 14:50 |
| Wizzup | do you want 0 ? 1 does not have gem here | 14:50 |
| freemangordon | sec | 14:51 |
| freemangordon | 'cat name' should show omapdrm | 14:52 |
| freemangordon | check in 0 | 14:52 |
| Wizzup | # cat /sys/kernel/debug/dri/0/name | 14:53 |
| Wizzup | omapdrm dev=omapdrm.0 master=omapdrm.0 unique=omapdrm.0 | 14:53 |
| freemangordon | mhm | 14:53 |
| freemangordon | this one | 14:53 |
| Wizzup | I have one osso-xterm open | 14:53 |
| Wizzup | do you want the full output of gem? | 14:53 |
| freemangordon | yeah | 14:53 |
| freemangordon | please open 3-4 | 14:53 |
| freemangordon | terminals that is | 14:54 |
| Wizzup | https://dpaste.com/34D2762RF | 14:54 |
| Wizzup | oh | 14:54 |
| Wizzup | ok | 14:54 |
| Wizzup | will open 3-4 and hope it doesn't already crash | 14:54 |
| freemangordon | stop | 14:54 |
| freemangordon | wait | 14:54 |
| freemangordon | Wizzup: you're using wrong ddx | 14:54 |
| Wizzup | how | 14:54 |
| freemangordon | no idea | 14:54 |
| Wizzup | didn't you build it? | 14:54 |
| freemangordon | I did | 14:54 |
| freemangordon | lemme check | 14:54 |
| Wizzup | ii xserver-xorg-video-omap 0.5.1+2m7 armhf X.Org X server -- OMAP display driver | 14:55 |
| freemangordon | ugh | 14:55 |
| Wizzup | should be 0.5.4 it seems? | 14:56 |
| freemangordon | https://github.com/maemo-leste/xf86-video-omap/blob/master/debian/changelog#L1 | 14:56 |
| freemangordon | mhm | 14:56 |
| freemangordon | you bad boy :p | 14:56 |
| Wizzup | ? | 14:57 |
| Wizzup | I am fully up to date | 14:57 |
| freemangordon | using wrong ddx makes you bad boy. kidding... | 14:57 |
| freemangordon | how's that? | 14:57 |
| Wizzup | yeah but it's not my fault | 14:57 |
| Wizzup | I don't get it as update | 14:57 |
| freemangordon | maybe I screwed it somehow | 14:57 |
| Wizzup | Section: droid4 | 14:57 |
| freemangordon | lemme check | 14:57 |
| Wizzup | this is not ideal | 14:57 |
| Wizzup | still I think I have droid4 as component | 14:57 |
| Wizzup | freemangordon: nah it looks ok | 14:57 |
| freemangordon | Wizzup: plese help me to fix my wifi | 14:58 |
| Wizzup | freemangordon: just nuke the persistent net rules file I think | 14:58 |
| freemangordon | where this wlan24 comes from? | 14:58 |
| freemangordon | where from? | 14:58 |
| Wizzup | but I think this happens when you get a random mac every time | 14:58 |
| freemangordon | yes, I know | 14:58 |
| Wizzup | sorry my n900 is updating atm, sec | 14:58 |
| freemangordon | ok | 14:58 |
| freemangordon | /etc/udev/rules.d/ should be it | 14:59 |
| Wizzup | root@devuan-n900:~# ls -lsh /etc/udev/rules.d/70-persistent-net.rules | 14:59 |
| Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 2000 /etc/udev/rules.d/70-persistent-net.rules -> /dev/null | 14:59 |
| freemangordon | I have no such rule | 14:59 |
| freemangordon | actually there is nothing there | 14:59 |
| Wizzup | yeah my n900 really does not see 0.5.4 | 15:00 |
| Wizzup | this will be fun to debug | 15:00 |
| Wizzup | freemangordon: maybe try 'find /lib | grep persistent' | 15:00 |
| Wizzup | freemangordon: ok I see | 15:01 |
| Wizzup | freemangordon: I only had 'droid4' as component for experimental, not for -devel | 15:01 |
| Wizzup | really the droid4 component in the control file should go | 15:01 |
| freemangordon | coul dyou fix that? | 15:02 |
| Wizzup | k | 15:02 |
| freemangordon | thanks! | 15:02 |
| freemangordon | umm, what the? it is wlan0 | 15:03 |
| Wizzup | what did you do? | 15:03 |
| freemangordon | nothing | 15:03 |
| freemangordon | I was thinking it is wlan24 | 15:03 |
| freemangordon | but it is wlan0 | 15:03 |
| Wizzup | freemangordon: wonder if it will also get faster now with new ddx | 15:03 |
| freemangordon | maybe | 15:04 |
| Wizzup | freemangordon: if you have your own kernel branch, I assume you picked my wifi patch | 15:04 |
| freemangordon | no :) | 15:04 |
| freemangordon | I guess this is the issue | 15:04 |
| Wizzup | then yes it won't work | 15:04 |
| freemangordon | mhm | 15:04 |
| Wizzup | maybe apt install linux-image-omap | 15:04 |
| freemangordon | ok, lemme try | 15:04 |
| Wizzup | (also you need maemo-kernel-config-n900) | 15:05 |
| freemangordon | oh, no | 15:05 |
| freemangordon | no wifi :) | 15:05 |
| freemangordon | wpa_supplicant I guess | 15:05 |
| Wizzup | freemangordon: you can just cp the debs to the rootfs | 15:06 |
| Wizzup | or use usbnet | 15:06 |
| Wizzup | https://leste.maemo.org/Status/USB_Peripheral#Share_PC_network_with_Leste_device | 15:06 |
| Wizzup | in any case when this works ok/stable I will push all experimental stuff to -devel for n900 and then we can empty experimental | 15:07 |
| freemangordon | :nod: | 15:07 |
| Wizzup | one thing I kind of want but won't for now is to have drm built in | 15:10 |
| Wizzup | last time I tried that gave trouble, but it would be real nice to have fast tty output | 15:10 |
| mighty17[m] | tried running xfce with openpvrsgx and freemangordon's mesa, and it fails even on sw rendering https://paste.debian.net/1225677/ (i didnt set MESA_LOADER_DRIVER_OVERRIDE=pvr coz idk how its done in x) | 15:11 |
| freemangordon | mighty17[m]: you should provide correct kmsdev to modesetting | 15:13 |
| mighty17[m] | as in? i havent touched x at all | 15:13 |
| uvos__ | xorg.conf | 15:13 |
| Wizzup | freemangordon: seems ok now, also with zswap or, and with normal swap on | 15:13 |
| Wizzup | so we can rule out any form of swap being a problem | 15:14 |
| uvos__ | also MESA_LOADER_DRIVER_OVERRIDE dosent have anything to do with the window manager | 15:14 |
| freemangordon | Wizzup: yeah, but I still kind of think zswap should be disabled | 15:14 |
| uvos__ | s/window manager/windowing system | 15:14 |
| mighty17[m] | uvos__: well but in wayland i had tinydm which'd set env vars for me | 15:14 |
| freemangordon | Wizzup: also, I think 24 MiB or even 16MiB of CMA should suffice | 15:15 |
| mighty17[m] | uvos__: cant find it :( | 15:15 |
| Wizzup | up to you , I am fine with whatever doesn't cause crashes | 15:15 |
| uvos__ | mighty17[m]: the xdg-session manager also has nothing to do with wayland vs x | 15:15 |
| uvos__ | they just start a xdg-session that starts some windowing system | 15:15 |
| freemangordon | Wizzup: maybe try with 16 MiB | 15:16 |
| freemangordon | or... | 15:16 |
| Wizzup | freemangordon: I suggest we potentially postpone finding the exact number | 15:16 |
| mighty17[m] | uvos__: right soo im confused aboout modsetting part | 15:17 |
| Wizzup | I'm really hoping that I can start doing some non-kernel stuff again soon | 15:17 |
| freemangordon | ok, make it 24 then | 15:17 |
| freemangordon | not 32 | 15:17 |
| Wizzup | there are open issues but those are now mostly regarding idle/ret/off mode | 15:17 |
| Wizzup | and I also have to do some work-work today :p | 15:17 |
| freemangordon | ok :) | 15:17 |
| uvos__ | mighty17[m]: man modesetting | 15:17 |
| Wizzup | freemangordon: this is great though | 15:17 |
| Wizzup | freemangordon: I am not sure if it is at same perf as 5.1 with other ddk and other clutter | 15:17 |
| Wizzup | but this is good | 15:17 |
| freemangordon | it is not | 15:18 |
| freemangordon | it is slightly slower | 15:18 |
| Wizzup | yeah it feels a bit more stuttery | 15:18 |
| Wizzup | but fine for now | 15:18 |
| freemangordon | but, this is because of we wait in DDX for gpu rendering to complete before requesting flip | 15:19 |
| uvos__ | freemangordon: interesting side note | 15:19 |
| freemangordon | instead of omapdrm waiting for write fence to be signalled | 15:19 |
| mighty17[m] | uvos__: `man: No entry for modesetting in the manual.` :( | 15:19 |
| freemangordon | mighty17[m]: sec to boot my d4 | 15:20 |
| freemangordon | uvos__: hmm? | 15:20 |
| uvos__ | mighty17[m]: freemangordon: since you worked around the corruption (looks like missing tiles) in omap ddx, when the d3/d4 | 15:20 |
| uvos__ | upps | 15:20 |
| uvos__ | freemangordon: since you worked around the corruption (looks like missing tiles) in omap ddx, it dosent show up anymore but when the d3/d4 hangs (d3 dose it way more often) it displays a frame that has the corruption again as its last frame | 15:21 |
| uvos__ | untill it watchdog reboots | 15:21 |
| uvos__ | mighty17[m]: https://linux.die.net/man/4/modesetting | 15:21 |
| freemangordon | GPU hangs the system while rendering? | 15:21 |
| freemangordon | hmm, no | 15:21 |
| uvos__ | mighty17[m]: hmm no thats not the right man page | 15:22 |
| uvos__ | anyhow on arch i have it, and the option you need to set is Option "kmsdev" "string" | 15:22 |
| freemangordon | uvos__: I'll provide him xorg.conf for modesetting | 15:22 |
| uvos__ | you need to set it to /dev/dri/card1 | 15:22 |
| uvos__ | freemangordon: ok | 15:22 |
| uvos__ | [15:21] <freemangordon> GPU hangs the system while rendering? <-- maybe, why do you say it cant be? | 15:23 |
| mighty17[m] | uvos__: mandoc is what i have on alpine :D | 15:23 |
| freemangordon | because that rendered frame is flipped | 15:23 |
| freemangordon | mighty17[m]: create /usr/share/X11/xorg.conf.d/99-modesetting.conf | 15:24 |
| uvos__ | it might be leaving it in a bad state | 15:24 |
| uvos__ | so the next filp fails | 15:24 |
| freemangordon | yeah, could be | 15:24 |
| mighty17[m] | freemangordon: `samsung-espresso3g:/etc/X11$ ls` -> `Xwrapper.config xinit` | 15:24 |
| freemangordon | mighty17[m]: and put https://pastebin.com/Ae7MzgKK in 99-modesetting.conf | 15:25 |
| mighty17[m] | alrighty will do, thanks a lot | 15:26 |
| freemangordon | mighty17[m]: look ath the options, you may want/need to tweak some | 15:26 |
| freemangordon | if you comment Option "AccelMethod" "none" it will try to use glamor | 15:27 |
| freemangordon | but it will fail | 15:27 |
| mighty17[m] | aand it worked tadda! | 15:27 |
| freemangordon | as glamor is broken on pvr | 15:27 |
| mighty17[m] | freemangordon: but pvr doesnt like glamor | 15:27 |
| freemangordon | mhm | 15:27 |
| freemangordon | so, if you want to use accelerated X11 | 15:27 |
| mighty17[m] | can we do nothing about that missing egl extension? | 15:27 |
| uvos__ | the extension isent the real problem | 15:27 |
| freemangordon | then you have to use https://github.com/maemo-leste/xf86-video-omap/blob/master/debian/changelog#L1 | 15:27 |
| freemangordon | right | 15:28 |
| mighty17[m] | im a bit lost here | 15:28 |
| freemangordon | mighty17[m]: glamor does not work fine on pvr. period :) | 15:29 |
| freemangordon | if you want fast 3D you need to use omap DDX (driver that is) instead of modesetting | 15:29 |
| mighty17[m] | okay, so fast 3d + x, i need omap ddx | 15:32 |
| uvos__ | spcificly that omap ddx | 15:32 |
| uvos__ | not the upstream xorg one | 15:32 |
| freemangordon | yeah | 15:32 |
| freemangordon | though, it is not thoroughly tested with non-compositing WMs, so you may have issues | 15:34 |
| mighty17[m] | uvos__: ohk, is it already in openpvrsgx | 15:34 |
| uvos__ | ? | 15:34 |
| uvos__ | its not a gpu driver | 15:34 |
| uvos__ | its a ddx | 15:34 |
| uvos__ | device dependand x | 15:34 |
| freemangordon | or X driver | 15:34 |
| freemangordon | :) | 15:34 |
| uvos__ | a glue driver between x and the real driver | 15:35 |
| mighty17[m] | ooooh | 15:35 |
| freemangordon | also, you want leste kernel as well | 15:35 |
| mighty17[m] | leste kernel? | 15:35 |
| uvos__ | droid4-linux | 15:35 |
| uvos__ | rebase on that | 15:35 |
| freemangordon | or, as known since yesterday, leste-omap :p | 15:35 |
| freemangordon | or was it omap-leste? | 15:36 |
| * freemangordon checks | 15:36 | |
| uvos__ | https://github.com/maemo-leste/droid4-linux/tree/wip/n900%2Fmaemo-5.15-cleaned-up | 15:36 |
| uvos__ | oh ok | 15:36 |
| mighty17[m] | well uhh its still openpvrsgx? | 15:36 |
| uvos__ | did we move the git repo too | 15:36 |
| freemangordon | don;t know | 15:36 |
| freemangordon | it seems no | 15:36 |
| uvos__ | yeah | 15:37 |
| uvos__ | i dont like that... | 15:37 |
| uvos__ | uh Wizzup | 15:37 |
| Wizzup | uvos__: what? | 15:37 |
| uvos__ | we were keeping sgx and the rest of the kernel seperate for a reason... | 15:37 |
| freemangordon | hmm? | 15:37 |
| Wizzup | uvos__: this is my wip branch, it is not meant to be the main branch for all our stuff, but if you're worried about a rebase I am happy to cherry pick 15 commits | 15:38 |
| uvos__ | ok | 15:38 |
| Wizzup | and no I didn't rename the repo yet | 15:38 |
| Wizzup | we can do that if we want | 15:38 |
| freemangordon | Wizzup: if you're going to do that (cherry-pick), please LMK, or simply make sure you don;t cherry-pick old versions of my omapdrm/pvr patches which a re reverted later-on | 15:39 |
| uvos__ | so if you need to bisect some problem you dont want sgx in the tree, really. also keeping the sgx seperate makes sense for people who want a untainted kernel | 15:39 |
| mighty17[m] | so its mainline? (i dont think patches for d4/n900 specific help me on espresso) | 15:39 |
| uvos__ | i liked that the sgx stuf was seperate | 15:39 |
| uvos__ | and was merged at compile time | 15:39 |
| uvos__ | mighty17[m]: the d4 paches do help you on espresso | 15:40 |
| Wizzup | uvos__: it was never merged at compile time? | 15:40 |
| mighty17[m] | i dont seem to understand the diff in kernels (openpvrsgx and leste-omap) | 15:40 |
| bencoh | uvos__: basically you're saying you prefer it as a set of patches? | 15:41 |
| uvos__ | bencoh: essentally | 15:41 |
| bencoh | I'd rather have a branch | 15:41 |
| uvos__ | or a branch but based on mainline | 15:41 |
| uvos__ | and then leste patches in a different branch on mainline | 15:41 |
| uvos__ | and then merge before compile | 15:41 |
| uvos__ | essentaly patches yeah | 15:41 |
| uvos__ | Wizzup: https://github.com/maemo-leste/droid4-linux/commits/droid4-pending-v5.15 dosent contain sgx | 15:42 |
| bencoh | "merge before compile" sounds just like something I'd want to avoid | 15:42 |
| uvos__ | bencoh: right but now if i want a untainted kernel with leste patches i have to cherry pick random commits to avoid merging in sgx | 15:43 |
| Wizzup | uvos__: whatever we tagged did | 15:43 |
| bencoh | is that part tainted? | 15:43 |
| bencoh | I don't think it should be | 15:43 |
| uvos__ | bencoh: not tainted in the kernel sense | 15:43 |
| bencoh | right | 15:43 |
| uvos__ | bencoh: ie the flag | 15:43 |
| uvos__ | but its tainted in that its somehting that can never be upstreamed | 15:44 |
| Wizzup | uvos__: I am fine with separating some things out logically, point is this is just mostly my personal branch | 15:44 |
| Wizzup | happy for some feedback also, but otoh it'd be nice to have something that's not -rc2 based | 15:44 |
| uvos__ | i mostly just want to be able to merge in leste patches onto a mainline kernel without mutch effort or merging in sgx | 15:45 |
| freemangordon | uvos__: which patches in particular? | 15:46 |
| uvos__ | that varies with time :P | 15:46 |
| freemangordon | how having a tree with PVR driver prevents you from sending patches upstream? | 15:46 |
| uvos__ | testing | 15:46 |
| Wizzup | testing is harder without the pvr driver for mwe | 15:47 |
| Wizzup | that's why I had it in | 15:47 |
| uvos__ | i want to allways test it on mainline as far a possible beofore sending it upstream to be applied to a kernel without pvr | 15:47 |
| freemangordon | ok, seems your workflow is totally different compared to mine | 15:47 |
| bencoh | :) | 15:47 |
| uvos__ | it used to be that d4 had real issues without leste patches (hanging etc) in the past | 15:47 |
| uvos__ | so i had to have those | 15:47 |
| uvos__ | those used to just be a couple of patches in the debian dir | 15:47 |
| freemangordon | well, but you can always pull latest -rc, no? | 15:48 |
| uvos__ | so i could merge them without sgx without looking for random commits in the tree to cerry pick | 15:48 |
| freemangordon | why shall we keep a mirror of upstream linux? | 15:48 |
| Wizzup | the patches in the debian dir was a nightmare for maintenance | 15:48 |
| uvos__ | Wizzup: sure im not advocating for the return of it | 15:48 |
| Wizzup | just let me know how you want it structured and I'll try | 15:48 |
| Wizzup | really it's just a matter of a few cherry picks | 15:48 |
| uvos__ | so id like it like this | 15:49 |
| bencoh | Since we're talking about patch management and git/cherrypicks and checking log: git log --cherry-mark --left-only origin/master... | 15:49 |
| uvos__ | we have a omap-linux-pending with patches we want to upstream at some point | 15:49 |
| freemangordon | Wizzup: hmm, my mail to nigupta was rejected | 15:49 |
| uvos__ | all new patches go there | 15:49 |
| freemangordon | it it possible s/he got none of the emails? | 15:49 |
| freemangordon | *is it | 15:49 |
| uvos__ | we have omap-linux-pending-sgx with mainline+omap-linux-pending+sgx merged | 15:50 |
| freemangordon | "550 5.4.1 Recipient address rejected: Access denied" | 15:50 |
| Wizzup | freemangordon: could be, when did you sent it | 15:50 |
| uvos__ | sgx branch is just mainline + OpenPVRSGX + whatever we do that changes the pvr | 15:50 |
| Wizzup | send* | 15:50 |
| uvos__ | driver | 15:50 |
| freemangordon | a minute ago | 15:51 |
| Wizzup | ah just now | 15:51 |
| Wizzup | freemangordon: my most recent email also included the linux-mm ml | 15:51 |
| Wizzup | which is hosted somewhere else (confusingly) | 15:51 |
| Wizzup | but I also didn't see a response there | 15:51 |
| freemangordon | ok, lets see if I will get a response | 15:51 |
| freemangordon | do you see my mail? | 15:52 |
| Wizzup | https://marc.info/?l=linux-mm&m=163966788011309&w=2 | 15:54 |
| Wizzup | freemangordon: yes | 15:54 |
| Wizzup | freemangordon: btw so maybe we do not need compaction after all | 15:54 |
| Wizzup | since I had old ddx | 15:54 |
| freemangordon | Wizzup: yes, we have it :) | 15:55 |
| freemangordon | *need | 15:55 |
| Wizzup | ok | 15:55 |
| uvos__ | do we need hugepages at all? | 15:55 |
| uvos__ | if your worryed about fragmentation | 15:55 |
| uvos__ | w/o compation | 15:55 |
| uvos__ | *compaction | 15:55 |
| freemangordon | how will CMA work without that? | 15:55 |
| uvos__ | idk how cma works so no idea | 15:55 |
| uvos__ | thats why i ask | 15:55 |
| freemangordon | I think CMA will not work without it | 15:55 |
| freemangordon | someone shall do page migration when contiguous buffer is needed | 15:56 |
| uvos__ | not having hugepages dosent prevent in kernel users allocating contiguous buffers | 15:56 |
| uvos__ | afaik | 15:56 |
| freemangordon | we are not talking about huge pages, but compaction | 15:56 |
| uvos__ | compaction was added for hugepages | 15:57 |
| freemangordon | once memory gets fragmented... | 15:57 |
| freemangordon | I think the same thing is used for CMA | 15:57 |
| freemangordon | but might be wrong | 15:57 |
| freemangordon | Wizzup: maybe it worths a try | 15:58 |
| uvos__ | well the compatction stuff was added for hugepages since ofc having those causes lots of fragmetnation having only 4kb pages dosent | 15:58 |
| freemangordon | uvos__: ok, seems we lack knowledge, so Wizzup can try to disable compaction now he uses the correct DDX and see | 15:59 |
| Wizzup | I mean I am fine keeping it on with the timeout nerfed | 16:00 |
| Wizzup | just wanted to mention it | 16:00 |
| uvos__ | yeah sure | 16:00 |
| uvos__ | real fix is not having the timeout | 16:00 |
| freemangordon | Wizzup: sure, but if it is not needed, then it will mean less code and one patch less to carry | 16:00 |
| freemangordon | Wizzup: I can test too | 16:00 |
| freemangordon | but not sure how valid my test will be | 16:01 |
| freemangordon | Wizzup: btw, do I still need droid4 component on n900? | 16:02 |
| bencoh | basically compaction shouldn't run in idle | 16:04 |
| bencoh | and it shouldn't prevent the scheduler from entering idle either | 16:04 |
| Wizzup | freemangordon: I need to triple check all components, so keep it for now | 16:05 |
| freemangordon | ok | 16:05 |
| freemangordon | ugh: E: Unable to locate package maemo-kernel-config-n900 | 16:06 |
| freemangordon | is that in experimental? | 16:06 |
| uvos__ | yeah the 500ms timer is clearly silly, i mean whats the point of checking fragmentation potentaly hours since the device was last awake for anything. if nothing runs nothing can cause fragmentation | 16:06 |
| Wizzup | uvos__: regarding setup, which do we merge on top of which | 16:06 |
| Wizzup | uvos__: I guess what you suggest can work if tmlind carries all our non pvr patches | 16:07 |
| Wizzup | but not all of them are ready yet | 16:07 |
| uvos__ | not sure why we need tmlind | 16:07 |
| Wizzup | well we were just based on top of his pending branches before | 16:07 |
| uvos__ | well we can have an intermeidate branch | 16:07 |
| uvos__ | thats his pending + our non pvr patches | 16:07 |
| uvos__ | or tmlind can accept maintinaice of essentally linux-omap for leste | 16:09 |
| uvos__ | he kinda dose allready | 16:09 |
| uvos__ | tmlind: ^^^ | 16:09 |
| Wizzup | uvos__: I think we/I need to do a bit of work and suggest which ones to carry | 16:11 |
| Wizzup | some of mine are just reverts for things that broke that we still need proper fixes for | 16:11 |
| uvos__ | i gues a midway house here | 16:12 |
| uvos__ | is we have linux-omap for leste with everything sgx+our patches+hacks+whatever | 16:12 |
| uvos__ | and we try and "upstream" our patches to at least tmlinds brach soon | 16:13 |
| uvos__ | and then we rebase the linux-omap leste branch on timlind with eatch release as before | 16:13 |
| uvos__ | idk really what is best here | 16:13 |
| Wizzup | well I did try to upstream whatever fixes I had, I just ran out of time and energy for others | 16:14 |
| Wizzup | we'll have to revisit them in the future anyway | 16:14 |
| Wizzup | bbiab | 16:14 |
| bencoh | freemangordon: iiuic CMA should only use pre-allocated buffers | 16:34 |
| bencoh | so compaction (or lack thereof) shouldn't affect it | 16:34 |
| bencoh | basically you can even specify the CMA segment at boot (cma=42M@0x12120000) | 16:35 |
| tmlind | Wizzup, uvos: it's best to try to mainline what we can, then set up topic branches that can be merged together for m-l kernel. i'd rather not start piling up patches, best to have uvos deal with his own patches, freemangordon deal with his patches etc | 17:42 |
| tmlind | then just merge those topic branches together :) | 17:42 |
| Wizzup | agreed | 17:46 |
| uvos__ | Wizzup: tmlind: looks like the touchscreen buttons are connected to KLC led cpcap channel | 17:52 |
| uvos__ | and is probubly the same on xt86x | 17:52 |
| uvos__ | *Wizzup: tmlind: looks like the touchscreen buttons are connected to KLC led cpcap channel on xt875 | 17:54 |
| tmlind | uvos: hmm is klc keyboard light controller or something like that? | 17:57 |
| uvos__ | yeah | 17:57 |
| uvos__ | but its unused on d4 | 17:57 |
| tmlind | ah | 17:57 |
| uvos__ | with the keyboard being on the other led chip instead | 17:57 |
| tmlind | so does the xt875 firmware control the klc led then? | 17:57 |
| uvos__ | its set on on reset | 17:58 |
| uvos__ | other than that no i think | 17:58 |
| tmlind | ah ok, so linux could control it | 17:58 |
| uvos__ | yeah | 17:58 |
| tmlind | nice | 17:58 |
| uvos__ | for some reason | 18:01 |
| uvos__ | in the current leste tree | 18:01 |
| uvos__ | the sgx driver gets rebuilt on every build of modules | 18:01 |
| tmlind | yeah that sucks.. it's because we can't yet build all the socs into a single module :( | 18:02 |
| tmlind | uvos: so that's the CPCAP_REG_KLC then? | 18:02 |
| uvos__ | yeah | 18:02 |
| tmlind | ok | 18:02 |
| uvos__ | i have a patch incomeing | 18:02 |
| tmlind | :) | 18:02 |
| uvos__ | also needs support added to the cpcap led driver for that channel | 18:02 |
| tmlind | ok | 18:02 |
| Wizzup | uvos__: let's coordinate on your various patches so we can get them in omap-linux | 18:04 |
| uvos__ | ok | 18:04 |
| tmlind | when v5.15 is out, i suggest we all set up minimal personal topic branches, then attempt to merge them to m-l kernel | 18:05 |
| tmlind | i mean v5.16 | 18:06 |
| tmlind | one or more topic branches per developer | 18:07 |
| tmlind | i think these branches already exist, we just need to merge them into the m-l kernel git tree | 18:08 |
| Wizzup | well yeah, but for m-l purposes we also want a stable branch, maybe 5.15 based now | 18:08 |
| tmlind | yeah, not sure if we want to redo the 5.15 branch though | 18:09 |
| Wizzup | well I am going to clean up my 5.15 based one, but it's based on your rc2 | 18:09 |
| tmlind | most of these topic branches could be based on v5.15 at this point for sure | 18:11 |
| Wizzup | yeah mostly meant that having a pvr one based on 5.15.y would be nice, but I imagine it might even just rebase without conflicts | 18:11 |
| tmlind | yeah it should | 18:11 |
| tmlind | we need some kind of txt list of topic branches to merge in :) | 18:12 |
| freemangordon | Wizzup: there is already 5.16-rc pvr repo | 18:51 |
| freemangordon | my patches should be already there | 18:51 |
| freemangordon | also, omapdrm patch is in rc as well | 18:52 |
| freemangordon | so I think it makes sense to go for that | 18:52 |
| freemangordon | as next step ofc | 18:52 |
| freemangordon | hmm, it is in drm-next, maybe it will be in 5.17-rc | 18:54 |
| freemangordon | it is in linux-next, no idea what that means in terms of version | 18:56 |
| Wizzup | freemangordon: I'd like something stable for our users too | 18:58 |
| Wizzup | so maybe 5.15.y | 18:58 |
| freemangordon | is it lts? | 18:58 |
| freemangordon | or we don;t care | 18:58 |
| Wizzup | don't care re lts | 18:59 |
| huckg | I am following directions from this page: https://maedevu.maemo.org/images/bionic/README.txt I am wondering where is a safe place to obtain the file Root_Bionic_JB_20130501-4.ova | 19:58 |
| uvos | huckg: https://maedevu.maemo.org/images/bionic/ | 19:59 |
| huckg | D'oh, thanks! | 20:00 |
| uvos | tmlind: any idea why if i remove https://github.com/maemo-leste/droid4-linux/blob/32fd293562d705670dfb3522e19e533e98729a9e/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi#L137 | 21:36 |
| uvos | and https://github.com/maemo-leste/droid4-linux/blob/32fd293562d705670dfb3522e19e533e98729a9e/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi#L143 | 21:36 |
| uvos | cpcap_led_probe https://github.com/maemo-leste/droid4-linux/blob/32fd293562d705670dfb3522e19e533e98729a9e/drivers/leds/leds-cpcap.c#L159 still runs a total of 5 times | 21:38 |
| uvos | and causes 2 nullpointer derefs beacuse device_get_match_data fails (because ofc it dose) | 21:38 |
| uvos | i dont get why the kernel would still try to probe cpcap-led for motorola,cpcap-led-adl when the dts node dosent exist | 21:39 |
| uvos | tmlind: yeah i dont get it heres the dts runing on the system decompiled from the generated dtb http://uvos.xyz/maserati/tmp.dts | 21:56 |
| uvos | ah, this: https://github.com/maemo-leste/droid4-linux/blob/32fd293562d705670dfb3522e19e533e98729a9e/drivers/mfd/motorola-cpcap.c#L270 | 22:01 |
| uvos | ok | 22:01 |
| uvos | i see i see | 22:01 |
| uvos | tmlind: hmm static mfd_cell dosent seam a good fit for cpcap | 22:10 |
| uvos | tmlind: since cpcap contains lots of devices that are often unused | 22:10 |
| uvos | Wizzup: so the ts-buttons on d3 are also connected to cpcap klc | 23:37 |
| uvos | Wizzup: also the alt key light is on bledc | 23:38 |
| uvos | Wizzup: and shift key light is on cledc | 23:38 |
| uvos | neat that d2 has extra keyboard staus lights | 23:39 |
| uvos | Wizzup: unfortinatly the backlight isent on cpcaps pannel backlight channel, nor any of the other cpcap channels | 23:49 |
| uvos | (d3) | 23:49 |
| Wizzup | uvos: thanks for investigating :) | 23:59 |
| Wizzup | huckg: did you manage with the bionic? | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!