| lel | clort81 opened an issue: https://github.com/maemo-leste/bugtracker/issues/580 (Droid4: USB Charging bounces. (threshold too high?)) | 03:24 |
|---|---|---|
| freemangordon | merging letux-pvrsrvkm-5.10-rc1 on top of letux-pvrsrvkm-5.9-rc2+linux-5.10.y, still works, I am starting to suspect tmlind's patches :) | 08:33 |
| freemangordon | tmlind: mystery is solved: with -DSYS_USING_INTERRUPTS removed 5.15 kmscube does not hang | 09:46 |
| freemangordon | tmlind: this is 7db47dbf1e1b539b8880b4a1d68fa05f674d419b | 09:50 |
| tmlind | freemangordon: ok so maybe the interrupt is misconfigured if it's not firing for omap3? bbl later tonight.. | 10:11 |
| freemangordon | trying to find which interrupt no it is trying to use | 10:13 |
| freemangordon | tmlind: just a second, please | 10:18 |
| freemangordon | interrupts = <21> | 10:18 |
| freemangordon | does not sound correct to me, IIRC we shall add some value to that | 10:18 |
| freemangordon | I knew I already had that issue https://github.com/pali/linux-n900/commit/7cf4ffa3897a914ec2d9cf86ca02a39725ec6031#diff-0e2abbc7386ac889a343ab8076e9bbcb8807d778ff20bd355d9ec406cc4fb25cR45 | 10:20 |
| Wizzup | freemangordon: you found it? great | 10:53 |
| freemangordon | no | 11:00 |
| freemangordon | I mean - I just build modules with traces enabled and IRQ no is 37, which is the correct one (21 + 16) | 11:00 |
| freemangordon | oh, yeah, I found what is causing the issue | 11:01 |
| freemangordon | but still no solution | 11:01 |
| freemangordon | Wizzup: do you want me to provide the kernel for you to capture traces over the serial? | 11:03 |
| freemangordon | "Installing device LISR SGX ISR on IRQ 37 with cookie 1b3c8529" | 11:03 |
| freemangordon | looks correct | 11:03 |
| Wizzup | freemangordon: sure I can capture something, so it still hangs? | 11:12 |
| Wizzup | freemangordon: yeah sure @ kernel + mods | 11:24 |
| freemangordon | yes, it hangs with -DSYS_USING_INTERRUPTS | 11:26 |
| freemangordon | ok, just a second and will provide archive | 11:26 |
| freemangordon | Wizzup: http://46.249.74.23/leste/pvr_hang.tar.gz | 11:29 |
| Wizzup | https://wizzup.org/panic-new.txt | 11:49 |
| Wizzup | freemangordon: do I need to set any control/power value or something? | 12:12 |
| freemangordon | no, but, is there any additional traces in dmegs? | 12:17 |
| freemangordon | there should be | 12:17 |
| freemangordon | like "PVR: EnableSystemClocks: Enabling System Clocks" | 12:18 |
| freemangordon | Wizzup: ^^^ | 12:18 |
| freemangordon | Wizzup: this log is like no traces were enabled, are you sure you've booted the correct kernel? | 12:29 |
| freemangordon | tmlind: why is SUPPORT_ACTIVE_POWER_MANAGEMENT enabled? without it, it works fine with -DSYS_USING_INTERRUPTS | 12:48 |
| freemangordon | root@devuan-n900:/sys/kernel/irq/37# cat per_cpu_count | 12:53 |
| freemangordon | 64234 | 12:53 |
| freemangordon | root@devuan-n900:/sys/kernel/irq/37# cat per_cpu_count | 12:53 |
| freemangordon | 66336 | 12:53 |
| freemangordon | root@devuan-n900:/sys/kernel/irq/37# | 12:53 |
| uvos | thats a hack to allow the device to ilde when the display is off | 12:53 |
| uvos | or part of it anyways | 12:53 |
| uvos | ti disabled all powermanagement in ddk1.14+ | 12:54 |
| uvos | thus sgx never idles | 12:54 |
| uvos | this is in the blobs | 12:54 |
| uvos | by lieing to pvr_k and enableing active powermangement the device can idle again | 12:54 |
| freemangordon | doesn't seem to work properly though | 12:54 |
| bencoh | "thus sgx never idles" this sounds ... terrible, tbh | 12:54 |
| uvos | this works on the d4 blobs | 12:54 |
| uvos | but it might be broken on the omap3 blobs yeah | 12:55 |
| freemangordon | uvos: who is supposed to enable the clocks? | 12:55 |
| freemangordon | I would rather say that on d4 it is broken as well, but for some reason clocks are always running | 12:55 |
| uvos | it works on d4 | 12:55 |
| freemangordon | [build] use-vbo=false: FPS: 56 FrameTime: 17.857 ms | 12:55 |
| freemangordon | [build] use-vbo=true: FPS: 57 FrameTime: 17.544 ms | 12:55 |
| uvos | the clock register changes | 12:55 |
| uvos | not sure who disables the clocks sorry | 12:56 |
| uvos | ask tmlind he wrote the hack | 12:56 |
| uvos | if this hack dosent work witht he omap3 blobs its over basicly | 12:56 |
| freemangordon | yeah, I am waiting for him :evil_grin: | 12:56 |
| uvos | no powermangement of any kind is possible then | 12:56 |
| freemangordon | not really | 12:56 |
| uvos | hmm? | 12:56 |
| uvos | sgx will block the whole chip from entering ret | 12:57 |
| freemangordon | driver manages the clocks and idles the device as needed | 12:57 |
| uvos | no this is disabled in the blobs | 12:57 |
| uvos | at least the omap4 ones | 12:57 |
| freemangordon | but, is enabled in the driver | 12:57 |
| uvos | right due to the hack | 12:57 |
| freemangordon | SgxClocksEnable/Disable | 12:57 |
| bencoh | any idea why TI did that? | 12:58 |
| freemangordon | lets wait for tony | 12:58 |
| Wizzup | freemangordon: I think I did yeah, let me check | 12:58 |
| freemangordon | Wizzup: no need | 12:58 |
| Wizzup | ok | 12:58 |
| freemangordon | I know what happens | 12:58 |
| freemangordon | we have SUPPORT_ACTIVE_POWER_MANAGEMENT enabled, which basically tells the driver:"do not manage the clocks", thus we hit ISR with clocks disabled | 12:59 |
| freemangordon | I disabled SUPPORT_ACTIVE_POWER_MANAGEMENT and it works perfectly so far, will post glmark score as soon as it finishes | 13:00 |
| freemangordon | IRQ counter incerments | 13:00 |
| freemangordon | also, I think I know th reason for bad use-vbo=true performance with 5.9 and earlier - it was that IRQs were not used | 13:01 |
| freemangordon | now I am waiting to discuss with tmlind what SUPPORT_ACTIVE_POWER_MANAGEMENT is expected to do | 13:02 |
| freemangordon | omg, 14fps on jellyfish | 13:02 |
| uvos | https://github.com/tmlind/linux_openpvrsgx/commit/a20e7866242dde42bb5692c2611f862385c395b5 | 13:03 |
| freemangordon | I read that and I don;t agree :) | 13:05 |
| freemangordon | SUPPORT_ACTIVE_POWER_MANAGEMENT *disables* clocks being controlled by the driver, IIUC | 13:05 |
| uvos | well on d4 not having this dose break sgx ever ideling | 13:05 |
| uvos | and the whole chip by extension | 13:05 |
| uvos | but yeah we need to ask tmlind | 13:06 |
| freemangordon | glmark results https://pastebin.com/hXWt4HPP | 13:06 |
| freemangordon | I am impressed actually | 13:06 |
| uvos | kind of wierd that vbo makes no difference still | 13:09 |
| uvos | bottelneck some else i gues | 13:09 |
| uvos | i mean vbos breaking perf was even wierder | 13:10 |
| uvos | but yeah looks like ok ish numberws | 13:10 |
| freemangordon | uvos: sorry, but we can;t have more than 60 fps | 13:11 |
| freemangordon | unless I am misunderstanding what you say | 13:11 |
| uvos | ok i thought it wasent limited by vsync | 13:11 |
| uvos | becasue 57fps is a bit wierd | 13:11 |
| uvos | but yeah ok | 13:12 |
| uvos | makes sense then | 13:12 |
| freemangordon | with 5.9 use-vbo=true fps was like 1.5 | 13:12 |
| uvos | yeah i know | 13:13 |
| freemangordon | now it is 57 | 13:13 |
| freemangordon | also, we need to check sgx fck runs on the correct rate | 13:14 |
| freemangordon | but that's not so important now | 13:14 |
| uvos | did you figure out whats causeign the boot problems too? | 13:18 |
| freemangordon | no | 13:19 |
| uvos | :( ok | 13:20 |
| freemangordon | probably it is unrelated | 13:20 |
| freemangordon | but we have oops trace so should be easily fixable | 13:20 |
| freemangordon | hmm, wait, seems I got it wrong | 14:07 |
| freemangordon | SUPPORT_ACTIVE_POWER_MANAGEMENT disables clocks management in some parts of the driver but enables in other parts | 14:08 |
| freemangordon | so, it looks like there is a bug somewhere | 14:35 |
| freemangordon | :D | 14:35 |
| Wizzup | so, apart from fixing those kernel bugs, the next parts are potentially to go through all of glamor and replace EGL_KHR_image into glTexSubImage2D with something that works with the blobs? | 15:00 |
| Wizzup | or is this still valid: | 15:01 |
| Wizzup | 22:29 < uvos> on n900 nothing works for some reason, wrt rendering to gbm textures from gles, fmg mentioned. | 15:01 |
| Wizzup | 22:29 < uvos> but idk what the state is there | 15:01 |
| Wizzup | 22:30 < uvos> thats pretty mutch all i have | 15:01 |
| uvos | just 2 places need changeing | 15:18 |
| uvos | the n900 bug is the bug fmg is currently on | 15:19 |
| uvos | just 2 places need changeing wrt the KHR_image problem | 15:19 |
| uvos | but then there is the additional problems with chomeos mesa | 15:19 |
| uvos | wrt reported texture formats | 15:19 |
| uvos | fix all of those and glamor works | 15:20 |
| uvos | maybe you also need the shim we dont know if thats needed at all with chromeos mesa, at least egl reports x11 support if you use it | 15:21 |
| uvos | but it might not work beacuse maybe this goes nowhere in blobs | 15:21 |
| uvos | side note on d4 we gain 350 ish mW unavoidable additionaly power usage with ddk1.17 | 15:23 |
| Wizzup | in addition to what | 15:23 |
| uvos | over ddk1.9 | 15:24 |
| uvos | beacsue ti disabled all pm in the blobs | 15:24 |
| uvos | so the gpu dosent clock down or gate | 15:24 |
| uvos | (except when the display is off) | 15:24 |
| uvos | (with the hack) | 15:25 |
| Wizzup | uhh | 15:25 |
| Wizzup | no working around that? | 15:35 |
| uvos | you could ignore the blobs and clock down/ gate the gpu anyhow | 15:35 |
| uvos | no idea how they would react | 15:35 |
| uvos | its imo not that bad since the gating was kind of broken in ddk1.9 too | 15:36 |
| uvos | ts only more power consumption if the display was totaly static | 15:37 |
| uvos | *its | 15:37 |
| uvos | otherwise if anything was going on on the display the gpu was active anyhow | 15:37 |
| Wizzup | mm | 15:37 |
| uvos | this is different from the android driver | 15:37 |
| uvos | it gates the gpu as soon as the frame is finished rendering | 15:37 |
| uvos | untill it needs the next frame | 15:38 |
| uvos | that saves a bounch of power | 15:38 |
| uvos | so ddk 1.9 was pretty suboptimal allready | 15:38 |
| Wizzup | mhm | 15:58 |
| Wizzup | well if we can hit RET (and OFF) with 1.17 on n900 and d4 that will already be huge, with modern X/modesetting | 15:58 |
| Wizzup | uvos: are those serial device files useful? | 16:02 |
| uvos | well... | 16:07 |
| uvos | 1. i dont like the design in generall 2. the single dxf file he gave us is really incompleat | 16:08 |
| uvos | 3. i dont understand some of the features the file has | 16:08 |
| uvos | like whats up with the 3 big holes | 16:08 |
| uvos | and it has the big central ejection hole for the battery holder but has the holes for the pogo pins too | 16:09 |
| uvos | so what part is this supposed to be | 16:09 |
| uvos | the battery holder or the fake battery | 16:09 |
| uvos | the outer perimiter can be the same | 16:09 |
| uvos | *cant | 16:09 |
| uvos | makes no sense as is, also where is the frame that goes around the bottom plate of the battery holder? | 16:10 |
| uvos | Wizzup: so no | 16:10 |
| uvos | its not usefull | 16:10 |
| Wizzup | the frame that goes around the battery doesn't really matter, right? | 16:10 |
| uvos | no | 16:10 |
| uvos | but the dxf file has bits of both pieces | 16:10 |
| Wizzup | regarding liking the design or not, it's more about it being useful/functional I think :p | 16:10 |
| uvos | so idk what part is supposed to be | 16:11 |
| Wizzup | I think he said that wrt 'puzzle' | 16:11 |
| uvos | i would not construct it like that | 16:11 |
| uvos | if all you have is a laser cutter it make some sense | 16:11 |
| uvos | but otherwise its pretty insane | 16:11 |
| uvos | if i where to do this i would maybe take his mesurements | 16:12 |
| uvos | but otherwise i would machine the battery bit out of some pom | 16:13 |
| uvos | and a pcb to mount the contacts | 16:13 |
| uvos | proparly | 16:13 |
| uvos | or do the flat flex thing | 16:14 |
| uvos | since thats really easy | 16:14 |
| uvos | for others to repoduce by odering it from a pcb house | 16:14 |
| uvos | can we promote profilesx to core | 16:29 |
| uvos | and install it by default? | 16:29 |
| Wizzup | I'm not super happy with profilex, would maybe rather have the RE version, but I suppose | 16:30 |
| uvos | i think its indefintly better than having no way to setup the settings sphone and mis use | 16:31 |
| uvos | the ui is not great ill give you that | 16:31 |
| uvos | also adding profiles fails | 16:31 |
| uvos | not sure why | 16:31 |
| Wizzup | yeah | 16:32 |
| Wizzup | didn't debug that either, but did notice it | 16:32 |
| sicelo | wow, amazing work freemangordon :-) | 16:42 |
| sicelo | "Never fear. I is here" | 16:44 |
| Wizzup | we don't have glamor/h-d yet, but hey, it's progress for sure :) | 16:49 |
| uvos | btw | 16:53 |
| uvos | wrt vm behavior | 16:53 |
| uvos | we should have leste-config for vm/desktop style devices | 16:53 |
| uvos | you can configure mce to enforce sane bahvior (ie xorg style lock only) | 16:54 |
| uvos | also would allow configureing more sane shortcuts for h-d | 16:54 |
| uvos | ie alt-f4 for close window etc | 16:54 |
| freemangordon | so, basically, what I see so far is that on n900 with enabled SUPPORT_ACTIVE_POWER_MANAGEMENT, when ISR gets called, ther is a check if SGX is powered on or not. So (and that's something I should verify), it seems on init driver assumes that SGX is powered on, but I am not sure that's the case | 16:56 |
| freemangordon | ... | 16:57 |
| freemangordon | so, it thinks the device is powered on (clocks are running) and does not call SGXClocksEnable() | 16:57 |
| freemangordon | but, because clocks are nit running, we have that abort | 16:57 |
| freemangordon | Wizzup: OTOH - I managed to enable all the logs (this time for real :) ), do you mind if I provide that kernel for you to gather traces on abort? | 16:59 |
| freemangordon | that way I'll have hard evidence that clocks are not enabled because driver thinks they are already enabled | 16:59 |
| freemangordon | ont the question what remains - the issue we have is with glTexSubImage2D - this is not allowed on BO backed textures, but glamor does it | 17:01 |
| freemangordon | so, we need to somehow workaround that - the lame solution I came up with is to have another texture that BO texture is copied to | 17:02 |
| freemangordon | unfortunately, this will ruin the performance dramatically | 17:02 |
| freemangordon | re X support - blobs have that compiled out, period | 17:03 |
| uvos | no | 17:03 |
| freemangordon | pvr_dri is just a wrapper | 17:03 |
| uvos | i know | 17:03 |
| uvos | but this isent where x support is required at all | 17:03 |
| freemangordon | uvos: been there done that, I'd love to prove me wrong, but I am afraid this is the situation - no X support in the blobs | 17:05 |
| freemangordon | uvos: in blobs eglGetDisplay implementation, only gbm and wl are supported | 17:06 |
| uvos | last time we disscussed this in pm we both agreed in the end that we dont know atm, so unless something changed there the only places we know the blobs have x compiled out | 17:06 |
| uvos | are those that are compleatly replaced by mesas | 17:06 |
| uvos | in the mesa path | 17:06 |
| freemangordon | no | 17:06 |
| uvos | and eglGetDisplay is implemented by mesa | 17:06 |
| uvos | in the chomeos path | 17:06 |
| uvos | with x support intact | 17:06 |
| freemangordon | it is not, it is just a wrapper | 17:06 |
| freemangordon | again, I would really love to be proved wrong | 17:08 |
| Wizzup | freemangordon: sure, can run whatever, let me know | 17:08 |
| freemangordon | uvos: if you have ideas how to test X support, please share, I will cooperate | 17:08 |
| freemangordon | Wizzup: sec | 17:08 |
| uvos | no since | 17:09 |
| uvos | you would have to have x running on the same dri node first | 17:09 |
| freemangordon | Wizzup: same link | 17:10 |
| freemangordon | it is a no issue, as X runs with MS/glamor | 17:11 |
| Wizzup | $ md5sum pvr_hang.tar.gz | 17:12 |
| Wizzup | b6f6b9f21d7750def25c8c97ad1a5455 pvr_hang.tar.gz | 17:12 |
| Wizzup | ok? | 17:12 |
| freemangordon | sec | 17:13 |
| freemangordon | b6f6b9f21d7750def25c8c97ad1a5455 | 17:13 |
| freemangordon | so yeah | 17:13 |
| freemangordon | Wizzup: keep in mind it takes lots of time to init/hang | 17:13 |
| freemangordon | 2-3 minutes maybe | 17:14 |
| freemangordon | please capture serial in a file | 17:14 |
| uvos | freemangordon: so here is why i belive its quite possible it works | 17:15 |
| freemangordon | hmm, how do we know SGX starts in PVRSRV_SYS_POWER_STATE_D0 (fully powered)? | 17:16 |
| uvos | https://github.com/IMbackK/mesa/blob/288032a87316f8542d1d5de8b8e1d3a20359ceab/src/egl/main/eglapi.c#L363 | 17:16 |
| uvos | thats the implementation of eglGetDisplay | 17:16 |
| uvos | it goes here: | 17:16 |
| uvos | https://github.com/IMbackK/mesa/blob/8206053e95d326d4833f70c65d26527b3a8f1607/src/egl/main/egldisplay.c#L120 | 17:17 |
| uvos | note that here there is no x11 support at all | 17:17 |
| freemangordon | exactly | 17:17 |
| uvos | even though this is the code for radeon | 17:17 |
| uvos | that HAS x11 support | 17:17 |
| uvos | you know why | 17:17 |
| uvos | because its emulated by fakeglx | 17:17 |
| uvos | i suspect it uses gbm behind the seans | 17:18 |
| freemangordon | which makes sense | 17:18 |
| uvos | right | 17:18 |
| uvos | so that code might work fine on pvr | 17:18 |
| uvos | might | 17:18 |
| uvos | idk but might | 17:18 |
| freemangordon | maybe it does the same my shim does | 17:18 |
| freemangordon | which makes sense too | 17:18 |
| uvos | ofc | 17:18 |
| uvos | less paths to implement | 17:18 |
| freemangordon | but well, how do you get native X display without having support? | 17:19 |
| uvos | well on desktop glx is used instead of egl | 17:19 |
| uvos | how egl manages to work i dont know | 17:19 |
| freemangordon | do we have the code? | 17:19 |
| freemangordon | is it foss? | 17:19 |
| uvos | for what now? | 17:20 |
| freemangordon | egl code I mean | 17:20 |
| uvos | for radeon | 17:20 |
| uvos | ? | 17:20 |
| uvos | sure thats mesa | 17:20 |
| uvos | part of mesa | 17:20 |
| freemangordon | for pvr | 17:20 |
| uvos | chomeos pvr uses mesa egl | 17:20 |
| freemangordon | uvos: do we have that compiled? | 17:20 |
| freemangordon | for leste | 17:20 |
| freemangordon | oh, ok, lemme rephrase | 17:21 |
| uvos | https://github.com/IMbackK/mesa/tree/mesa-pvr-meamo | 17:21 |
| uvos | its a dpkg-buildpackage away | 17:21 |
| freemangordon | did you try it? | 17:21 |
| uvos | yes it works fine | 17:21 |
| freemangordon | works fine with wayland I guess | 17:21 |
| uvos | yes | 17:21 |
| freemangordon | could you try it wit X? | 17:22 |
| uvos | i have | 17:22 |
| uvos | it fails to even try startig because of texture formats availble | 17:22 |
| uvos | chomeos mesa has wierd bugs | 17:22 |
| uvos | https://github.com/IMbackK/pvr-omap4/tree/master/usr/lib/arm-linux-gnueabihf | 17:22 |
| uvos | these are the compainon blobs | 17:22 |
| uvos | note whats missing | 17:22 |
| uvos | no libgbm and no libegl | 17:23 |
| freemangordon | mhm | 17:23 |
| freemangordon | you must use libgbm | 17:23 |
| uvos | those are provided by mainline mesa | 17:23 |
| freemangordon | IMG provide their own implmentation that must be used, afaik | 17:23 |
| uvos | the mesa one works | 17:24 |
| uvos | in this setup | 17:24 |
| freemangordon | hmm | 17:24 |
| uvos | btw your test app also works in this setup | 17:24 |
| freemangordon | which one of the many? :) | 17:24 |
| uvos | http://uvos.xyz/maserati/testapps/gbmPvrTest.c | 17:25 |
| uvos | but glmark dosent work | 17:25 |
| uvos | there and some other wierd problems | 17:25 |
| freemangordon | glmark-gbm I guess | 17:26 |
| uvos | yeah | 17:26 |
| uvos | gbm might be partally broken idk i dident investigate as sutch | 17:26 |
| uvos | at least your usage works | 17:26 |
| freemangordon | ok, could you create a simple test app that opens :0 and calls eglGetDisplay( (EGLNativeDisplayType) xdpy ); .ofc you have to have Xorg running | 17:29 |
| uvos | well there is no way to start xorg with accel | 17:30 |
| uvos | so it will end up in dri2 | 17:30 |
| freemangordon | why? | 17:30 |
| uvos | with will end up in llvmpipe | 17:30 |
| uvos | it dosent start | 17:30 |
| freemangordon | I was able to start it | 17:30 |
| uvos | on plain pvr yeah | 17:30 |
| uvos | on chomeos mesa | 17:30 |
| freemangordon | yeah | 17:30 |
| uvos | it bails immidatly | 17:30 |
| uvos | it complains it cant find a valid textureformat | 17:31 |
| uvos | and just bails | 17:31 |
| freemangordon | you can start Xorg on IMG blobs and then run test app on mesa blobs | 17:31 |
| uvos | i gues | 17:31 |
| uvos | but it dont have a working img blobs settup | 17:32 |
| uvos | rn | 17:32 |
| freemangordon | sure, no hurry | 17:32 |
| freemangordon | I can share my blobs dir from my d4 | 17:32 |
| freemangordon | uvos: OTOH, do you have any idea why pvr driver assumes SGX is powered-up (and with clocks running) on loading? | 17:35 |
| uvos | no | 17:35 |
| Wizzup | freemangordon: will do it in a bit, sry, something came up | 17:36 |
| freemangordon | NP | 17:36 |
| tmlind | freemangordon: oh cool you narrowed it down that pm hack patch | 18:25 |
| tmlind | strange that the devices behave in a different way | 18:26 |
| freemangordon | tmlind: I don't think it is the patch itself that brings the problem. it is either DTS or the driver itself that is buggy | 18:28 |
| freemangordon | d4 dts has some stuff in dts that is missing form omap3 | 18:28 |
| freemangordon | *for | 18:28 |
| freemangordon | some ti,sysc stuff | 18:28 |
| freemangordon | no idea what it is or if it should be there | 18:29 |
| freemangordon | I am waiting Wizzup to capture traces via serial before deciding what to do | 18:29 |
| tmlind | freemangordon: let me check the dts config | 18:30 |
| freemangordon | ok | 18:31 |
| tmlind | freemangordon: well the 34xx pvr module sysconfig is either broken or write-only and i recall it's best to not mess with it | 18:33 |
| tmlind | it could be that omap4 is working because we have configured SYSC_IDLE_SMART_WKUP | 18:33 |
| tmlind | i'll try again with the omap36xx.dtsi gpu config | 18:35 |
| Wizzup | freemangordon: need another 30mins then I'll do it | 18:42 |
| Wizzup | freemangordon: https://wizzup.org/panic-log.txt | 19:21 |
| freemangordon | tmlind: look at ^^^ | 19:50 |
| freemangordon | actually driver tries to enable the clocks | 19:50 |
| freemangordon | something wrong with pm_runtime_get_sync()? | 19:51 |
| tmlind | yeah ok, i'll take a look | 20:03 |
| Wizzup | freemangordon: tmlind: just a heads up I catted the wrong two files together, it doesn't really matter for the panic log (the second file was already correct, first was not) but here's the proper one https://wizzup.org/panic-log-2.txt | 21:11 |
| Wizzup | this page will need some updating hehe https://wiki.maemo.org/Porting/Closed_Packages | 21:57 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste/profiled/pull/2 (add support for the touchscreen.vibration.enabled key) | 22:15 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste/maemo-input-sounds/pull/1 (remove gconf usage by adding support for the touchscreen.vibration.enabled profiled key) | 22:17 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste-extras/profilesx/pull/1 (add support for touchscreen.vibration.enabled) | 22:19 |
| uvos | https://github.com/maemo-leste-extras/profilesx/pull/1 | 22:19 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste/osso-applet-display/pull/1 (Port to new mce interfaces) | 22:31 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!