Wizzup | https://www.aliexpress.com/item/1005003272036569.html | 12:11 |
---|---|---|
Wizzup | these seem quite small | 12:11 |
uvos | not sure why you need sutch a thing | 12:25 |
uvos | https://www.aliexpress.com/item/1005001847849317.html?spm=a2g0o.productlist.0.0.5f522caeFjJgL8&algo_pvid=49986476-d1b2-4a56-9ea5-f4a5e56e21f8&algo_exp_id=49986476-d1b2-4a56-9ea5-f4a5e56e21f8-3&pdp_ext_f=%7B%22sku_id%22%3A%2212000017838609285%22%7D\ | 12:25 |
uvos | just one of these | 12:25 |
uvos | set it to 3.7v before you leave | 12:25 |
uvos | and have a usb cable feed it | 12:26 |
uvos | https://www.aliexpress.com/item/4000064597454.html?spm=a2g0o.productlist.0.0.5f522caeFjJgL8&algo_pvid=49986476-d1b2-4a56-9ea5-f4a5e56e21f8&algo_exp_id=49986476-d1b2-4a56-9ea5-f4a5e56e21f8-0&pdp_ext_f=%7B%22sku_id%22%3A%2210000000165416980%22%7D | 12:26 |
uvos | maybe rather this | 12:26 |
Wizzup | mhm | 12:26 |
uvos | transient current can be pretty high with these things | 12:26 |
Wizzup | I might be able to find those locally here now | 12:27 |
uvos | sure yeah | 12:27 |
uvos | but you need a multimeter too | 12:28 |
uvos | not sure what you have | 12:28 |
Wizzup | nothing, but there should be shops with that stuff here | 12:28 |
Wizzup | probably better if I just wait and focus on other stuff, but I don't like waiting :) | 12:28 |
uvos | probubly more sane just to work on userspace with the d4 | 12:29 |
Wizzup | mhm | 12:29 |
Wizzup | I'll work on the bootmenu+recovery-mode and omap-linux some, try to get that going | 12:30 |
bencoh | uvos: wait, is that thing reliable | 12:38 |
bencoh | uvos: it looks like a toy | 12:38 |
uvos | ofc its just a lm259 | 12:39 |
uvos | extreamly widly used in products | 12:39 |
bencoh | no I meant, your first link | 12:39 |
uvos | and the rest is just its referance implementation | 12:39 |
bencoh | the "power supply" with the lcd screen | 12:40 |
uvos | those work great too | 12:40 |
Wizzup | the one I linked? | 12:40 |
uvos | cant vautch for this exact one | 12:40 |
uvos | but i have several | 12:41 |
uvos | they are fine | 12:41 |
bencoh | Wizzup: ah right, that one too | 12:41 |
uvos | no match for a real lab supply on output ripple or regulation | 12:41 |
uvos | but perfectly fine otherwise | 12:41 |
bencoh | hm | 12:41 |
Wizzup | I mean I don't think I can find a lab psu here, that's the problem :p | 12:41 |
Wizzup | I'll just wait | 12:41 |
bencoh | Wizzup: what kind of voltage do you need anyway? | 12:42 |
bencoh | ~4V ? | 12:42 |
Wizzup | a bit less, but around that, yes | 12:44 |
Wizzup | found a local shop, will go there now I guess | 15:02 |
sicelo | :-) | 15:08 |
uvos | "[12:41] <Wizzup> I'll just wait" that lasted long :P | 15:12 |
Wizzup | hehe | 15:16 |
freemangordon | uvos: drmModePageFlip takes 6 ms | 18:12 |
freemangordon | according to docs it shall return immediately | 18:12 |
Wizzup | got it at least | 18:22 |
freemangordon | well, not sure | 18:23 |
uvos | freemangordon: thats wierd drmModePageFlip shouldent really do anything at all | 18:25 |
uvos | https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L1202 probubly waits for one of the locks | 18:31 |
uvos | plenty of reasons why drm_mode_page_flip_ioctl can stall for a while really | 18:31 |
freemangordon | I think in our case it is that it pins the framebuffer | 18:35 |
freemangordon | but I think we have more general issue here - it seems buffer is created for every frame | 18:36 |
freemangordon | not that I know how is that supposed to work | 18:36 |
freemangordon | but in armsoc we have ARMSOCDRI2ReuseBufferNotify() | 18:37 |
uvos | in our flipchain dri2 in x calls a function called check_resue_buffer (or something like that) | 18:38 |
uvos | it returns false | 18:38 |
uvos | maybe check whyy | 18:38 |
Wizzup | ok, I have a working serial. now to remember which string to use for kernel command line | 18:38 |
uvos | freemangordon: its allocate_or_reuse_buffer | 18:40 |
uvos | the ddx implements ReuseBufferNotify | 18:40 |
uvos | yeah looks like what armsoc probubly dose | 18:40 |
freemangordon | hmm, where do you see that? | 18:42 |
freemangordon | uvos: I don;t see such function | 18:43 |
uvos | hw/xfree86/dri2/dri.c | 18:44 |
uvos | hw/xfree86/dri2/dri2.c | 18:44 |
uvos | allocate_or_reuse_buffer | 18:44 |
uvos | line 503 | 18:44 |
uvos | gets called on every flip and returns false on d4 - i checked this yesterday | 18:45 |
freemangordon | I don;t understand what do you mean "the ddx implements ReuseBufferNotify" | 18:45 |
freemangordon | omap-video ddx does not implement that | 18:45 |
freemangordon | maybe this is one of the problems | 18:45 |
uvos | right | 18:45 |
uvos | thats why allocate_or_reuse_buffer returns false | 18:45 |
uvos | the ddx implements ReuseBufferNotify if it wants | 18:46 |
uvos | actually thats not what happens | 18:46 |
freemangordon | ah, yeah, sure | 18:46 |
uvos | it returns false for another reason | 18:46 |
uvos | actually false is reuse | 18:47 |
uvos | so no idea | 18:47 |
freemangordon | uvos: what about (both of us) try to find some time these days and debug this? | 18:50 |
freemangordon | I mean - to have a debug session | 18:51 |
freemangordon | not to say that it somehow manages to tear while doing page flip | 18:52 |
freemangordon | this is impossible on theory :) | 18:53 |
freemangordon | *in theory | 18:53 |
uvos | why would that be impossible, you can flip during hblank | 18:54 |
freemangordon | no, because the flip requested is "flip on next vblank" | 18:56 |
freemangordon | Wizzup: do we have some budget to spend on that? | 18:56 |
uvos | sure we can debug some time | 18:56 |
uvos | synconiously | 18:56 |
freemangordon | yeah | 18:56 |
uvos | idk if it makes sense but sure | 18:56 |
freemangordon | I am not sure too | 18:56 |
freemangordon | thus my question ^^^ to Wizzup | 18:57 |
freemangordon | if we can find someone who knows how all this is supposed to work | 18:57 |
Wizzup | freemangordon: probably depends on how much the person needs | 18:58 |
freemangordon | well, I guess we have to fina that 'person' first | 18:59 |
Wizzup | let's see if I can boot to recovery mode with serial now :) | 19:41 |
sicelo | :-) | 19:43 |
Wizzup | uvos: do we need to install something to make the recovery softlevel work? | 19:43 |
Wizzup | hm, ok, nevermind, it works I think | 19:43 |
Wizzup | uvos: btw since I attached serial I haven't bad any random boot failure ;) | 20:04 |
Wizzup | tmlind_: ok, I have a shell now with the uarts idled and no modules loaded | 20:14 |
Wizzup | the screen seems to be on still though | 20:14 |
Wizzup | I guess I'll load omapdrm and friends? | 20:15 |
Wizzup | uvos: ping | 20:27 |
uvos | Wizzup: hmm? | 20:27 |
Wizzup | uvos: how do I blank a display with drm | 20:28 |
Wizzup | I might not have enough modules loaded yet but it's also not clear to me | 20:28 |
Wizzup | uvos: as in, I have the n900 booted to init=/bin/bash and enabled off mode | 20:28 |
uvos | https://github.com/IMbackK/drm_blankscreen | 20:28 |
Wizzup | but I don't think the screen is off | 20:28 |
Wizzup | ok, I do not have /dev/dri/ yet | 20:29 |
Wizzup | so more is missing | 20:29 |
Wizzup | the panel is loaded though | 20:29 |
uvos | is omapdrm loaded? | 20:29 |
Wizzup | yes | 20:29 |
uvos | udev? | 20:30 |
Wizzup | https://dpaste.com/GXV7KEUQ8 | 20:30 |
Wizzup | no, definitely not udev since that loads all the modules | 20:30 |
Wizzup | which is the point: I don't want it to do that | 20:30 |
freemangordon | Wizzup: maybe mknod | 20:30 |
Wizzup | when I booted to init=/bin/bash the display was still on from u-boot | 20:30 |
uvos | Wizzup: well udev also creats lots of the files in /dev/ | 20:30 |
uvos | yeah mknod | 20:30 |
Wizzup | I ran busybox mdev -s and it didn't make it | 20:31 |
Wizzup | as you sure what's all that is needed? | 20:31 |
parazyd | You should mount devtmpfs first, no? | 20:31 |
parazyd | Then mdev | 20:31 |
uvos | module wise that looks correct | 20:31 |
Wizzup | oh you're right, even devtmpfs is not set up | 20:31 |
Wizzup | argh | 20:31 |
uvos | heh | 20:32 |
parazyd | Then also sys and proc manually | 20:32 |
Wizzup | maybe not, it says it's already mounted | 20:32 |
Wizzup | but it's not in mount | 20:32 |
Wizzup | parazyd: yes I did that | 20:32 |
freemangordon | Wizzup: I think you should mknod /dev/dri/card0 c 226,0 at some point | 20:32 |
Wizzup | # mount -t devtmpfs devtmpfs /dev | 20:32 |
Wizzup | mount: /dev: devtmpfs already mounted on /dev. | 20:32 |
freemangordon | sorry, it is mknod /dev/dri/card0 c 226 0 | 20:33 |
freemangordon | (no comma) | 20:33 |
Wizzup | still, I don't have internet so I can't build uvos tool anyway | 20:33 |
Wizzup | I'll have to reset/reboot | 20:33 |
Wizzup | kinda weird that kernel provides no way to do this | 20:34 |
parazyd | In my initramfs shell script I have: | 20:34 |
parazyd | mount -t devtmpfs none /dev | 20:34 |
parazyd | mount -t proc none /proc | 20:34 |
parazyd | mount -t sysfs none /sys | 20:34 |
parazyd | in that order | 20:34 |
Wizzup | ty | 20:35 |
freemangordon | glib upstream replied, finally :) | 20:35 |
Wizzup | tmlind_: this traces happens when n900 fails to boot randomly https://dpaste.com/GRWDBS2PA | 20:35 |
Wizzup | uvos: ^ | 20:36 |
freemangordon | pm runtime | 20:36 |
Wizzup | yes, as always | 20:36 |
Wizzup | :P | 20:36 |
freemangordon | :) | 20:37 |
freemangordon | lets hope tmlind_ know how to find the offending module | 20:38 |
freemangordon | *knows | 20:38 |
freemangordon | Wizzup: maybe post on linux-omap | 20:39 |
Wizzup | yeah, I'm just trying to catch a bunch | 20:39 |
Wizzup | I'll have to build nokia modem again later as well | 20:39 |
Wizzup | parazyd: btw kernel does it: | 21:00 |
Wizzup | # dmesg|grep devtmp | 21:00 |
Wizzup | [ 0.134277] devtmpfs: initialized | 21:00 |
Wizzup | [ 5.040222] devtmpfs: mounted | 21:00 |
Wizzup | so the mknod is not enough (or just wrong) since uvos drm tool gets Can not open drm device /dev/dri/card0: No such device | 21:02 |
freemangordon | maybe you need to mknod render node as well | 21:03 |
Wizzup | modprobe display_connector | 21:04 |
Wizzup | this was necessary | 21:04 |
Wizzup | alas, uvos https://dpaste.com/DN8678RA8 | 21:04 |
Wizzup | it looks like the touchscreen doesn't even support runtime pm? | 21:09 |
uvos | i mean it just calls perror() regardless | 21:11 |
uvos | so that dosent mean anything | 21:11 |
uvos | unless drmSetMaster is failing | 21:11 |
uvos | i should klean that thing up a bit | 21:11 |
uvos | dose it not work? | 21:12 |
Wizzup | https://github.com/maemo-leste/bugtracker/issues/321 | 21:12 |
Wizzup | uvos: well maybe I need to also disable the backlight manually? | 21:12 |
uvos | if the backlight is associated with the right output device in dts it should also turn off | 21:13 |
uvos | cat /sys/class/drm/*/dpms | 21:13 |
uvos | should tell you if the display is on or not | 21:14 |
uvos | according to drm | 21:14 |
Wizzup | ok | 21:14 |
Wizzup | it looks like you things turns off only one | 21:15 |
Wizzup | # cat /sys/class/drm/*/dpms | 21:15 |
Wizzup | On | 21:15 |
Wizzup | On | 21:15 |
uvos | obivously you need to have whatever module the baclight led is on loaded too | 21:15 |
uvos | btw | 21:15 |
Wizzup | (runs tool) | 21:15 |
Wizzup | # cat /sys/class/drm/*/dpms | 21:15 |
Wizzup | Off | 21:15 |
Wizzup | On | 21:15 |
Wizzup | yes, but I can control the backlight via sys so it is loaded with the panel | 21:15 |
Wizzup | I think probably it turns off the s-video/composite but not the lcd | 21:16 |
uvos | it should turn off both | 21:16 |
uvos | code wise | 21:16 |
Wizzup | # cat /sys/class/drm/card0-Composite-1/dpms | 21:16 |
Wizzup | Off | 21:16 |
Wizzup | t# cat /sys/class/drm/card0-DPI-1/dpms | 21:16 |
Wizzup | On | 21:16 |
Wizzup | right | 21:16 |
uvos | works on d4 with dsi and hdmi | 21:16 |
uvos | drmModeConnectorSetProperty also returns 0 for both displays | 21:17 |
uvos | so it not haveing any effect is wierd | 21:17 |
Wizzup | 't is what is happening though | 21:17 |
uvos | maybe something else is reneableing it, could you have drm_blankscreen not quit | 21:17 |
uvos | and not drop master | 21:17 |
uvos | that way nothing can renable | 21:18 |
uvos | so move drmSetMaster(device); out of the loop | 21:18 |
uvos | and add while(true) to the end | 21:18 |
uvos | after the loop | 21:18 |
uvos | and remove drmDropMaster(device); ofc | 21:19 |
Wizzup | the only process that runs is bash | 21:19 |
uvos | the kernel might for its console, it dident when i wrote the program but it might now | 21:20 |
Wizzup | in any case currently: # sleep 5; ./idle.sh | 21:20 |
Wizzup | ST_UART2,ST_MCSPI1 | 21:20 |
Wizzup | uvos: console=ttyS2 though | 21:20 |
uvos | Wizzup: ok | 21:20 |
uvos | Wizzup: no idea then | 21:20 |
Wizzup | spi1 = touchscreen as far as I can tell | 21:21 |
Wizzup | (and it's not loaded, and it doesn't do pm) | 21:21 |
uvos | and uart is undetached kernel console | 21:21 |
uvos | proubly | 21:21 |
Wizzup | it is detached actually | 21:22 |
Wizzup | uart2 seems to be bt | 21:22 |
Wizzup | [ 2.565093] printk: console [ttyS2] enabled | 21:22 |
Wizzup | [ 17.983398] printk: console [ttyS2] disabled | 21:22 |
Wizzup | uvos: maybe fbdev can be used to blank or something? | 21:31 |
uvos | you can try fbdev blanking | 21:34 |
uvos | but on d4 it dosent allow it it idle | 21:34 |
uvos | *to | 21:35 |
Wizzup | ok | 21:35 |
Wizzup | interesting, without drm loaded (just serials idled and off mode enabled) I get this: | 21:37 |
Wizzup | # sleep 5 ; ./idle.sh | 21:37 |
Wizzup | ST_MCSPI1 | 21:37 |
uvos | dose i2cdetect suggest you have any i2c devices in use by the kernel? | 21:38 |
Wizzup | it looks like RET increases though | 21:39 |
uvos | looking at /sys/class/i2c-dev/ should also work | 21:39 |
uvos | ah so its not blocked all the time | 21:39 |
Wizzup | yes, which is great, I haven't seen that before | 21:39 |
uvos | that might be the best you can do, tmlind mentioned that the kernel is too busy with timers to enter off mode with stock cost table | 21:40 |
Wizzup | hmm, ok | 21:40 |
uvos | dunno if it applies when you have so little modules loaded or not | 21:40 |
uvos | tmlind_: ? | 21:40 |
Wizzup | # sleep 5; ./idle.sh | 21:40 |
Wizzup | ST_MCSPI1 | 21:40 |
Wizzup | OFF:0,RET:458 | 21:40 |
Wizzup | uvos: fwiw no modules loaded at all atm | 21:41 |
Wizzup | well I guess this is some progress | 21:42 |
Wizzup | looks like loading just drm (not omapdrm) and panel adds uart2 as blocker, but allows me turn off backlight and it's not too bad ... | 21:44 |
Wizzup | 0.01A at 0.34V | 21:44 |
Wizzup | so like 71mW? | 21:49 |
uvos | 0.34v? | 21:49 |
Wizzup | # sleep 10 ; cat /sys/class/power_supply/bq27200-0/power_avg | 21:49 |
Wizzup | 71540 | 21:49 |
Wizzup | uvos: 3.4V | 21:49 |
Wizzup | sry | 21:49 |
Wizzup | my display is showing 03.4v ;) | 21:50 |
uvos | 0.01A at 0.34V =/= 71mW | 21:50 |
uvos | or 0.01A at 3.4V =/= 71mW even | 21:50 |
Wizzup | right, which is why I took the measure from bq27200 | 21:51 |
uvos | 71mW is the same as bionic at idle | 21:51 |
Wizzup | 71mW seems about right for hitting RET some time but not OFF, no | 21:51 |
uvos | also ret no off | 21:51 |
uvos | so that makes sense | 21:51 |
Wizzup | alright | 21:51 |
uvos | actually bionic is about 60 | 21:51 |
uvos | but ~ | 21:51 |
Wizzup | yeah maybe I need to let it settle some more | 21:51 |
uvos | roughly | 21:51 |
Wizzup | ok, I'll document all of this, but then there is a big task of loading modules one by one I guess | 21:52 |
Wizzup | seeing what causes what kind of blocks | 21:52 |
Wizzup | I suspect there's more than a few different ones | 21:52 |
Wizzup | also didn't tmlind_ say he fixed OFF not being hit? | 21:52 |
uvos | not that i remember | 21:52 |
uvos | but maybe | 21:53 |
uvos | i remember him hacking the cost table | 21:53 |
uvos | no idea how this ended up | 21:53 |
sicelo | Wizzup: https://libera.irclog.whitequark.org/maemo-leste/2021-09-28#30908647 | 21:55 |
Wizzup | sicelo: ok, so looks like we probably dn't have it yet | 21:55 |
Wizzup | thanks for digging that up :) | 21:56 |
sicelo | 18:40 <tmlind> uvos: yup trying with target_residency of 50000 and 60000 makes core ret work | 21:56 |
sicelo | 18:40 <tmlind> core_pwrdm (ON),OFF:19,RET:6,INA:0,ON:26,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 | 21:56 |
sicelo | so you could try that and see | 21:56 |
uvos | yeah | 21:57 |
uvos | but we need to mesure target_residency really | 21:57 |
uvos | and see if the current value is wrong | 21:57 |
Wizzup | so this would be replacing 15000 with 50000 and 30000 with 60000 ? | 21:58 |
Wizzup | in arch/arm/mach-omap2/cpuidle34xx.c | 21:58 |
uvos | you should lower it really | 21:59 |
uvos | if you want it to pick it more often | 21:59 |
Wizzup | well it looks like we're raising it atm? | 22:00 |
Wizzup | unless I am missing something? | 22:00 |
uvos | right | 22:01 |
uvos | that makes no sense | 22:01 |
uvos | thats why im mentioning it | 22:01 |
Wizzup | well I might do what tmlind said worked first | 22:01 |
Wizzup | and then see what better values we need? | 22:01 |
uvos | just set off to what ret is now | 22:01 |
uvos | there might not be better values | 22:01 |
Wizzup | https://dpaste.com/43AM6QRE4 | 22:01 |
uvos | so the point of target_residencey is that this is the minimum time the device must spend there for it to make sense to enter this state | 22:02 |
uvos | from a pm perspective | 22:02 |
uvos | off requries you to reload all registers | 22:02 |
Wizzup | hmm | 22:02 |
uvos | its expensive | 22:02 |
uvos | power wise | 22:02 |
Wizzup | then why does it only work for tmlind_ if he increases it? | 22:02 |
Wizzup | idgi | 22:02 |
uvos | his values must be wrong/typo, he must be looking at a different file or he/someone changed it to a lower value since | 22:03 |
uvos | https://www.kernel.org/doc/html/v5.15/admin-guide/pm/cpuidle.html | 22:04 |
Wizzup | last change Date: Wed Mar 4 14:54:30 2020 -0800 | 22:04 |
Wizzup | grepping for omap3_idle_driver only shows this file | 22:04 |
Wizzup | and these are the only target_residency mentions | 22:04 |
Wizzup | oh hmmmmm | 22:05 |
Wizzup | omap3_idle_driver vs omap3430_idle_driver | 22:05 |
Wizzup | ok I see what I should change now | 22:05 |
Wizzup | sorry for being slow | 22:06 |
uvos | np | 22:06 |
uvos | we are all slow sometimes | 22:06 |
lel | MerlijnWajer assigned an issue: https://github.com/maemo-leste/bugtracker/issues/545 (N900: Try to hit OFF mode (low power consumption)) | 22:17 |
Wizzup | ttps://github.com/maemo-leste/bugtracker/issues/545#issuecomment-980438141 posted some info here | 22:17 |
uvos | Terrorist Tactics and ProcedureS? | 22:18 |
Wizzup | https://github.com/maemo-leste/bugtracker/issues/545 | 22:19 |
Wizzup | ^_^ | 22:19 |
Wizzup | totally worth the 40 euro for this lab psu | 22:19 |
uvos | heh | 22:19 |
Wizzup | https://multi-com.eu/,details,id_pr,16969,key,laboratory-power-supply-powerlab-1502d-15v-2a-dc-led.html it's this I think | 22:20 |
Wizzup | any ideas about the best way to load specific modules and do off mode tests? | 22:21 |
Wizzup | to see which ones block idle | 22:21 |
Wizzup | I figured maybe I can make some script that one can set as init= that also sets up wifi and sshd, but I don't think I have job management in my bash shell currently | 22:22 |
uvos | not really | 22:23 |
uvos | omap3430 having its own special cost table probubly has a reason btw | 22:23 |
uvos | there is likley some bug that causes it to take forever to restore from idle or some errata that wastes a buch of power on wakeup | 22:24 |
Wizzup | mhm | 22:24 |
uvos | ie this numbers suggest something is broken hw wise | 22:25 |
Wizzup | well, what can we do :) | 22:25 |
uvos | no idea, we need to quiet down the kernel timers | 22:25 |
Wizzup | I meant we cannot fix the hw | 22:25 |
Wizzup | but yeah I guess you mean lowering the timers doesn't necessarily help | 22:26 |
Wizzup | maybe tmlind was also onto something when he said maybe they overflow | 22:26 |
Wizzup | # sleep 5; ./idle.sh | 22:49 |
Wizzup | ST_MCSPI1 | 22:49 |
Wizzup | OFF:13,RET:1 | 22:49 |
sicelo | that's beautiful sight :-) | 22:52 |
Wizzup | doesn't seem to matter much for power usage compared to ret though | 22:52 |
uvos | probubly the errata biteing | 22:53 |
uvos | maybe some value higher than what you have | 22:53 |
uvos | but lower than before would be better | 22:53 |
Wizzup | it looks like kernel also just wakes up more than before perhaps | 22:54 |
Wizzup | causing it not to be hit | 22:54 |
uvos | right yes thats true for sure | 22:54 |
uvos | its very busy | 22:54 |
uvos | increably so compeard to the motorola kernel for instance | 22:54 |
Wizzup | uvos: do you see that in powertop? | 23:13 |
uvos | yeah | 23:31 |
Wizzup | looks like tsc2005 just outright blocks idle when probed | 23:31 |
Wizzup | lol | 23:31 |
uvos | whats lol about that? | 23:31 |
uvos | if it dosent support runtimepm | 23:32 |
Wizzup | well I think it does in some form | 23:32 |
Wizzup | at least open/close do something | 23:32 |
Wizzup | uvos: well it's mostly lol in the sense that it's the first module I probed | 23:35 |
Wizzup | and it blocks idles right away | 23:35 |
uvos | not sure if suprising, ts on d4 also blocked idle at all times untill tmlind improved the driver | 23:36 |
uvos | fixing various drivers is likely going to be the story of your life for a while :P | 23:36 |
Wizzup | at least wifi does not block idle | 23:36 |
uvos | thats something | 23:37 |
Wizzup | https://github.com/maemo-leste/bugtracker/issues/545#issuecomment-980458784 keeping a list here | 23:57 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!