| freemangordon | hmm, xf86-video-omap loads, but there is nothing on the screen, even for 2d stuff | 08:37 |
|---|---|---|
| freemangordon | weird | 08:37 |
| freemangordon | oh, ok, finally I was able to mmap gbm bo for writing :) | 10:06 |
| freemangordon | the same bo EGL renders to | 10:06 |
| freemangordon | uvos: so, how that helps us with dri3? :) hack modesetting to not use glamor and do 2D SW render to back buffer? | 10:07 |
| freemangordon | the other option is to use dri2 driver and do a PVR blit of gbm EGL bo | 10:09 |
| freemangordon | weh have to teach dri2 driver on dri3 ofc | 10:10 |
| freemangordon | but thats simple, more or less | 10:10 |
| tmlind | freemangordon: nice :) fyi, things are moving towards the /dev/dri/cardX being used only for allocation with the rest using the render node, but current pvr mesa seems to only work using the /dev/dri/card0 node | 10:12 |
| tmlind | that's to avoid all the permission issues | 10:13 |
| tmlind | if there are other reasons for doing it, i don't know what they might be | 10:13 |
| freemangordon | tmlind: I don;t understand how's that relevant, sorry. all this dri/drm/ whatever stuff is still in a тхицк фог фор ме :) | 10:14 |
| freemangordon | oos | 10:14 |
| freemangordon | *still in thick fog for me | 10:15 |
| freemangordon | if you have an idea how thing should work (given that I can read/write bo's EGL renders to), please share | 10:15 |
| freemangordon | I mean - in terms of xorg that is | 10:16 |
| freemangordon | I would really love if we have zero-copy but not sure what rendering pipeline should look like | 10:16 |
| tmlind | yeah i don't know how it works either :) | 10:18 |
| freemangordon | tmlind: BTW, definitely there is something wrong with the kernel, xf86-video-omap driver renders nothing on the screen, but pretends to work. *but* - it worked couple of times. 3 of 20, for example | 10:19 |
| tmlind | weird | 10:19 |
| freemangordon | the same happened yesterday with glmark | 10:19 |
| tmlind | which hardware? | 10:19 |
| freemangordon | d4 | 10:19 |
| freemangordon | on n900 it seems there is no issue | 10:19 |
| tmlind | yeah ok d4 needs to update the command mode lcd also to refresh it | 10:19 |
| tmlind | that patch you reverted might fix it for d4? | 10:20 |
| freemangordon | but I have "drm/omap: Fix page fault handling and flush what framebuffe wants flushed" reverted there (on n900) | 10:20 |
| freemangordon | yeah, lemme try it | 10:20 |
| freemangordon | while we are at it :) | 10:20 |
| tmlind | ok, not sure what might be broken with that patch for n900.. and not even sure if that's the right fix for d4 | 10:20 |
| tmlind | heading out here, bbl today at some point | 10:22 |
| freemangordon | ttyl, will let you know if it is better with that patch reverted | 10:22 |
| tmlind | yeah ok hopefully it works on d4, then we can figure out what's wrong with that patch | 10:24 |
| freemangordon | mhm | 10:27 |
| freemangordon | unfortunately it does not: | 10:32 |
| freemangordon | [ 148.602752] PVR_K: HWRecoveryResetSGX: SGX Hardware Recovery triggered | 10:32 |
| freemangordon | fullscreen PVR2DBlt color clear operation over EGL allocated BO uses ~15% CPU | 12:58 |
| freemangordon | good news - I was able to make PVR2DBlt work | 12:59 |
| freemangordon | on d4 that is | 12:59 |
| lel | MerlijnWajer deleted a repository: https://github.com/maemo-leste/clown-boot-kernel | 13:00 |
| Wizzup | freemangordon: sweet | 13:03 |
| freemangordon | basically I do GlClear on the surface and then PVR2DBlt on top (screen height - 64, to see that GLClear actually works) | 13:04 |
| freemangordon | if I calculate FPS correctly, this should render with 80 fps | 13:04 |
| Wizzup | it's not zero copy but quit egood | 13:13 |
| freemangordon | it is | 13:14 |
| freemangordon | seems that CPU load comes from a leaking /me calling PVRSRVMapFullDmaBuf on every swap | 13:16 |
| Wizzup | ah | 13:16 |
| freemangordon | for sure I am doing this wrong, as after couple of seconds PVRSRVMapFullDmaBuf fails | 13:16 |
| freemangordon | somehow I am leaking something :D | 13:17 |
| Wizzup | uvos: ugh I can't push the stable stuff to github because it rejects it over size | 13:17 |
| * Wizzup bbiab | 13:17 | |
| freemangordon | Wizzup: with that leak fixed, cpu load is ~ 3.5% | 13:44 |
| freemangordon | yep, FPS is 78 :D | 13:50 |
| bencoh | neat! | 13:54 |
| bencoh | wait, 78 is more than 60 ... do you render to screen? | 13:54 |
| freemangordon | yes | 13:54 |
| freemangordon | this is d4 | 13:54 |
| * bencoh headscratches | 13:54 | |
| freemangordon | glmark reports same fps | 13:55 |
| freemangordon | d4 is manually updated display | 13:55 |
| freemangordon | will try on n900 in a minute | 13:55 |
| bencoh | yeah, but it still means it can reach more than 60fps, which is ... slightly surprising | 13:55 |
| bencoh | either that, or it silently drops frames | 13:55 |
| freemangordon | no idea | 13:55 |
| bencoh | anyway, nice work :) | 13:56 |
| freemangordon | but, it should be able to render with 80 fps, why not< | 13:56 |
| freemangordon | ? | 13:56 |
| freemangordon | I mean - we don;t really have vsync here | 13:56 |
| bencoh | even with no vsync, the max rate depends on the DSI clock speed and lanes number | 13:57 |
| bencoh | but I dunno how that was configured on d4, so ... :) | 13:57 |
| freemangordon | so, it seems it is capable fo doing refresh 80 times per second | 13:58 |
| bencoh | well, unless it really renders to some internal buffer and frames are dropped | 13:58 |
| freemangordon | I doubt | 13:58 |
| freemangordon | see CPU load | 13:58 |
| freemangordon | 3% means this is done in HW | 13:59 |
| freemangordon | earlier today I was doing the same with mmap, CPU load was about 50% | 13:59 |
| freemangordon | but yeah, who knows | 13:59 |
| sicelo | i know the primary goal of this work is for hildon/x11, but side question - will this improve things wayland side? | 14:00 |
| freemangordon | no | 14:00 |
| freemangordon | next step is to write DDX/EXA, but this is not related to WL | 14:01 |
| bencoh | out of curiosity, how does WL do it? | 14:01 |
| freemangordon | no idea | 14:01 |
| sicelo | ah, okay. | 14:03 |
| freemangordon | n900: | 14:03 |
| freemangordon | Current Frames Per Second: 57 | 14:03 |
| freemangordon | :D | 14:03 |
| sicelo | :-) | 14:03 |
| freemangordon | this is 3D+2D rendering | 14:03 |
| freemangordon | well, 3D rendering is glClear(GL_COLOR_BUFFER_BIT); and 2D rendering is PVR2DPATROPcopy (solid fill rectangle), but still | 14:05 |
| freemangordon | oh, lemme check cpu usage on n900 | 14:05 |
| freemangordon | 7.5% | 14:05 |
| freemangordon | wow | 14:05 |
| freemangordon | ok, now we know what HW is capable of | 14:07 |
| bencoh | do you know what fremantle does? | 14:09 |
| freemangordon | something similar AFAIK | 14:09 |
| bencoh | and/or whether it gets similar perf results? ah | 14:09 |
| freemangordon | but, it is missing GBM stuff, so I doubt it is as fast | 14:09 |
| freemangordon | fremantle uses omapfb | 14:10 |
| bencoh | I wonder if the pvr2d engine includes scaling functions | 14:10 |
| freemangordon | I think yes | 14:10 |
| freemangordon | lemme check | 14:10 |
| bencoh | if so it might speedup a lot of things | 14:11 |
| bencoh | like video playback, among others | 14:11 |
| freemangordon | mhm | 14:11 |
| freemangordon | for sure it supports blitting of YUV etc | 14:12 |
| freemangordon | not sure this is zero-copy, but still | 14:12 |
| freemangordon | bencoh: https://github.com/TexasInstruments/dri3wsegl/blob/master/SGX_DDK_REL_1.14%404004414_API_headers_MIT/eurasia/pvr2d/pvr2d.h#L416 | 14:13 |
| freemangordon | PVR2DBLTINFO has src and dst sizes | 14:15 |
| bencoh | PVR2D_3DBLT_EXT mentions scaling as well | 14:15 |
| bencoh | (at least in comments) | 14:15 |
| freemangordon | maybe it scales when you set different dst size | 14:15 |
| bencoh | so it looks like PVR2DBlt3DExt might allow scaling | 14:15 |
| freemangordon | mhm | 14:15 |
| bencoh | yeah | 14:15 |
| bencoh | which is pretty nice | 14:15 |
| freemangordon | I don;t think we want 3d blits | 14:15 |
| bencoh | I was about to ask if it was really "3d" | 14:16 |
| freemangordon | 3d stuff isa lready fast enough through gbm/egl | 14:16 |
| freemangordon | no idea | 14:16 |
| freemangordon | how am I supposed to know | 14:16 |
| freemangordon | :) | 14:16 |
| bencoh | :) | 14:16 |
| freemangordon | I really wonder why IMG don;t want to open the documentation | 14:16 |
| freemangordon | but yeah, corporate mindset | 14:17 |
| bencoh | "trade secret" (sigh) | 14:17 |
| freemangordon | yeah, sure | 14:17 |
| bencoh | (I guess) | 14:17 |
| sicelo | :-( | 14:17 |
| freemangordon | anyway, I am impressed that n900 is capable of rendering 2d+3d with such speed | 14:17 |
| sicelo | old warrior | 14:18 |
| freemangordon | yeah | 14:18 |
| freemangordon | hmm, lemme record a video to show you what it looks like | 14:19 |
| sicelo | yay, that'll be really great | 14:19 |
| bencoh | :) | 14:19 |
| bencoh | surprisingly enough those old GPUs could do "a lot" | 14:20 |
| freemangordon | http://46.249.74.23/leste/20211020_001.mp4 | 14:25 |
| freemangordon | varying green color is 2d rendered | 14:25 |
| freemangordon | red on is 3d | 14:25 |
| freemangordon | *red one | 14:26 |
| freemangordon | ttyl | 14:26 |
| bencoh | awesome :) | 14:28 |
| uvos | bencoh: i dimly remember some android applications also reporting 70 ish fps | 14:29 |
| uvos | i think the pannel might be able to refesh slightly faster then 60 | 14:29 |
| bencoh | ah, interesting | 14:30 |
| Wizzup | neat | 14:30 |
| uvos | witch makes it a high refresh rate variable refresh rate display | 14:30 |
| uvos | gamerz creed | 14:30 |
| Wizzup | lol | 14:30 |
| bencoh | yeah, I was about to joke about that | 14:30 |
| bencoh | actually it would be pretty neat for arcade games | 14:31 |
| bencoh | I should try fiddling with that :] | 14:31 |
| bencoh | (many many games need a non-standard refresh rate) | 14:32 |
| bencoh | seriously though, does the DSI subsystem gets in some kinda of low-power mode between frames? | 14:33 |
| bencoh | (assuming there are no frequent updates, for instance) | 14:33 |
| freemangordon | uvos: so, what way shall we go? make modesetting not rely on glamor or add dri3 support tom opam_drv? | 14:35 |
| freemangordon | *omap_drv | 14:36 |
| uvos | no idea, surely you have the better understanding fo the details rn. | 14:36 |
| Wizzup | if you can make it work with modesetting that would be better IMHO | 14:36 |
| uvos | i assume that bringing 2d the buffer to the display would involve pvr2d? | 14:37 |
| Wizzup | or maybe I misunderstood | 14:37 |
| bencoh | Wizzup: that's assuming the change is generic enough for it to be at least seemingly upstreamable though | 14:37 |
| Wizzup | but I'd prefer not to use xf86-video-omap | 14:37 |
| bencoh | why not? | 14:37 |
| Wizzup | bencoh: even so rebasing on maintained code is better than being the sole maintainer | 14:37 |
| bencoh | hmm | 14:37 |
| uvos | if you can do it without using pvr2d or special omapdrm ioctls modesetting would be better | 14:37 |
| uvos | otherwise -omap is the better choise | 14:38 |
| uvos | Wizzup: -omap is not that large | 14:38 |
| uvos | and the xf86-video api is very stable | 14:38 |
| Wizzup | uvos: true it's not large | 14:38 |
| uvos | also xf86-video-omap is part of xorg | 14:38 |
| Wizzup | where do they host it? | 14:39 |
| Wizzup | I suppose that can work yeah | 14:39 |
| Wizzup | I didn't realise it was that small (~2000 lines including headers) | 14:39 |
| Wizzup | still it seems to carry quite some kludges | 14:39 |
| Wizzup | stuff like the output_names | 14:40 |
| uvos | https://gitlab.freedesktop.org/xorg/driver/xf86-video-omap | 14:40 |
| Wizzup | I suppose that could work | 14:41 |
| bencoh | do we have a properly working version of -omap? | 14:41 |
| uvos | sure | 14:41 |
| Wizzup | the d4 uses it now | 14:41 |
| bencoh | ah, alright | 14:41 |
| uvos | it works on d4 with sgx 1.9 | 14:41 |
| Wizzup | but it has no DRI3 | 14:41 |
| bencoh | yeah | 14:41 |
| uvos | and it works on just omapdrm | 14:41 |
| Wizzup | omap_dri.c is 672 lines | 14:42 |
| bencoh | I'd say it's the way to go | 14:42 |
| bencoh | especially if we plan on adding more omap-specific features at some point | 14:42 |
| bencoh | (video decoding anyone? :) ) | 14:42 |
| uvos | lets not get ahead of ourselves | 14:42 |
| uvos | besides the ddx dosent do decoding | 14:43 |
| uvos | presentation maybe | 14:43 |
| Wizzup | I think exa can help with scaling but yeah | 14:44 |
| Wizzup | not the actual decode pipeline | 14:44 |
| Wizzup | but also the hw video decoders are kind of at the bottom of my list, I never watch videos on my phone | 14:44 |
| Wizzup | (but yeah, *my* list) | 14:44 |
| Wizzup | anyway | 14:44 |
| bencoh | right, but I vaguely remember it playing a role in the presentation part, and iirc one of the devs working on it had the ddx patched for that purpose | 14:44 |
| bencoh | but yeah, anyway :) | 14:45 |
| Wizzup | grepping for gri3 in glamor/ makes it look easy | 14:45 |
| Wizzup | dri3* even | 14:45 |
| uvos | modern ddx dont do video presenstaion either | 14:46 |
| uvos | opengl is used | 14:46 |
| bencoh | uvos: I'm talking about 2012 code :) | 14:46 |
| bencoh | (and I might be wrong) | 14:46 |
| Wizzup | uvos: you mean glamor does xv | 14:46 |
| Wizzup | X-Video Extension version 2.2 | 14:46 |
| Wizzup | screen #0 Adaptor #0: "GLAMOR Textured Video" | 14:46 |
| uvos | Wizzup: xv is depricated nothig uses it anymore | 14:47 |
| uvos | Wizzup: but yeah it dose have it as a fallback | 14:47 |
| Wizzup | oh, what replaced it? | 14:47 |
| uvos | nothing | 14:47 |
| uvos | gl | 14:47 |
| Wizzup | :D | 14:47 |
| bencoh | plain gl, you just have it render to a surface | 14:47 |
| bencoh | or something similar | 14:47 |
| uvos | yeah | 14:47 |
| Wizzup | freemangordon: great work, hope we can get it all the way there | 14:47 |
| Wizzup | uvos: any other PRs you need me to look at? | 14:50 |
| freemangordon | uvos: I will get rid of omap-specific ioctls | 14:50 |
| freemangordon | this is easy | 14:50 |
| freemangordon | my test program uses only non-omap stuff | 14:51 |
| uvos | freemangordon: that wasent about omap-sepcifc icotls in -video-omap | 14:51 |
| uvos | its about if you can make dri3 work on sgx without using sgx or omap specific code | 14:51 |
| freemangordon | but what? | 14:51 |
| uvos | if you can | 14:51 |
| uvos | then change modesetting | 14:51 |
| freemangordon | I can, for 3d | 14:51 |
| uvos | if you cant chagne -omap | 14:51 |
| uvos | right 2d is a different story | 14:51 |
| freemangordon | I can for 2d too (by using mmap), but it will be slow | 14:52 |
| bencoh | (just for the records / logs, regarding video decoding on omap: https://github.com/robclark/libdce ) | 14:52 |
| freemangordon | sure, 3d is through gbm | 14:52 |
| uvos | but i thought mmap only worked through prv2d? | 14:52 |
| uvos | libpvr2d that is | 14:52 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/clown-boot-kernel | 14:53 |
| uvos | Wizzup: "uvos: any other PRs you need me to look at?" no | 14:53 |
| uvos | btw if command mode display is giveing you grief you can work around it / check if this is the case by connecting a hdmi display | 14:54 |
| uvos | that makes both displays fall to video mode | 14:54 |
| bencoh | oh, that'd be interesting | 14:55 |
| freemangordon | uvos: no | 14:55 |
| bencoh | just to see if refresh rate falls down to 60fps | 14:55 |
| freemangordon | pvr2d doesn't do mmap | 14:55 |
| freemangordon | mmap is done through DRM_IOCTL_MODE_MAP_DUMB | 14:56 |
| lel | MerlijnWajer edited a repository: https://github.com/maemo-leste/clown-boot-kernel | 14:56 |
| Wizzup | uvos: https://github.com/maemo-leste/clown-boot-kernel hope this works for you | 14:56 |
| uvos | sure | 14:58 |
| uvos | wheres the defconfig | 14:58 |
| Wizzup | didn | 14:58 |
| Wizzup | t push that yet | 14:58 |
| Wizzup | I had to fight github or an hour first | 14:58 |
| uvos | ok | 14:58 |
| Wizzup | is there some tool to create a defconfig, or shall I just commit my .config ? | 14:58 |
| Wizzup | I also need to push the dts, etc | 14:58 |
| bencoh | make savedefconfig? | 14:58 |
| uvos | indeed | 14:59 |
| Wizzup | ok | 14:59 |
| uvos | freemangordon: ok so sounds like adding a dri3 fallback path for modesetting using mmap is possible for its AccelMethod "none" case | 15:00 |
| uvos | adding this would be a great service to others | 15:00 |
| uvos | it would for instance also slove the pps issues | 15:00 |
| freemangordon | uvos: pvr2d does PVRSRVMapFullDmaBuf | 15:00 |
| uvos | so i twould do that | 15:00 |
| freemangordon | ok | 15:00 |
| freemangordon | PVRSRVMapFullDmaBuf just sets SGX MMU | 15:00 |
| Wizzup | uvos: didn't he say it would be slower though? | 15:01 |
| Wizzup | (but yeah I suppose it could still be useful) | 15:01 |
| uvos | well its mmaping and rendering via cpu | 15:01 |
| uvos | thats slow | 15:01 |
| uvos | but short of implementing exa on pvr2d i dont see how anything would be faster | 15:01 |
| uvos | and ofc thats something to be done later and not now | 15:02 |
| uvos | also current d4 works exactly like this | 15:02 |
| uvos | so it should not be unusably slow | 15:02 |
| Wizzup | the current d4 is kinda slow in 2d | 15:02 |
| uvos | i mean 2d on d4 is slow | 15:02 |
| Wizzup | esp scrolling is painful | 15:02 |
| uvos | but its not usage breaking | 15:02 |
| uvos | yeah | 15:02 |
| Wizzup | depends on who you ask | 15:02 |
| Wizzup | freemangordon might disagree :P | 15:03 |
| bencoh | terminal scrolling is atrocious | 15:03 |
| Wizzup | any scrolling is atrocious | 15:03 |
| Wizzup | there's many seconds in delay | 15:03 |
| uvos | well other than gpu accel | 15:03 |
| uvos | like qt stuff scrolls fine | 15:03 |
| uvos | because it uses gl instead of xorg primitves | 15:03 |
| Wizzup | I mean it's a good first step if we have a way to als omake 2d fast | 15:04 |
| Wizzup | otherwise perhaps the path makes less sense | 15:04 |
| uvos | it makes plenty of sense for pp i think, no one cares about xorg on it, we dont have the bandwith to also fix its 3d driver and its cpu is fast enough to make this ok | 15:04 |
| uvos | gets the mapphones working right now, and we can still investigate resurecting -video-omap or adding a accel plugin to replace glamor for modesetting-pvr | 15:05 |
| freemangordon | guys, we can implement it through mmap initially and then to pvr2d accel where possible | 15:07 |
| Wizzup | ok | 15:09 |
| Wizzup | I do not have a strong opinion, just trying to help | 15:10 |
| Wizzup | feel free to do what makes sense | 15:10 |
| sicelo | is there a big x11 issue with PP? there's sxmo, so i guess it's working reasonably okay for them | 15:10 |
| Wizzup | uvos: https://github.com/maemo-leste/clown-boot-kernel/commits/clown-boot-5.10.y dts is untested, I need to check if me adding the memory{} and &dsi1 there directly works | 15:11 |
| Wizzup | but at least no changes to motorola-mapphone-common.dtsi atm | 15:12 |
| Wizzup | (again untested) | 15:12 |
| Wizzup | we can probably trim that defconfig some more | 15:12 |
| Wizzup | (we don't need the modem, etc) | 15:12 |
| uvos | wait what if i want to take a call in the bootloader | 15:13 |
| Wizzup | :D | 15:13 |
| Wizzup | I needed a few seconds to realise | 15:13 |
| uvos | probubly a feature they considerd for uefi | 15:14 |
| uvos | anthow ok | 15:14 |
| uvos | yeah that looks fine | 15:14 |
| uvos | 509 MB? whats in the upper 3MB region? | 15:20 |
| uvos | why are we disabeling aes | 15:20 |
| Wizzup | uvos: this is just omap2plus_defconfig with m->y and dvb removed | 15:27 |
| Wizzup | feel free to cut more in that config | 15:27 |
| uvos | Wizzup: no i mean this https://github.com/maemo-leste/clown-boot-kernel/blob/96b2525f1fa10bca22d40549e8bdc8973881452f/arch/arm/boot/dts/omap4-droid3-xt862.dts#L88 | 15:29 |
| Wizzup | hm this is from bionic or d4 I think | 15:34 |
| Wizzup | hm | 15:34 |
| Wizzup | I don't see it in either. | 15:34 |
| Wizzup | uvos: that can probably go then | 15:35 |
| uvos | yes its new i assume your forgeting the reason you placed it there | 15:35 |
| Wizzup | yeah | 15:36 |
| Wizzup | can probably remove it | 15:36 |
| Wizzup | &i2c4 is in there twice too | 15:39 |
| uvos | heh | 15:40 |
| uvos | yeah | 15:40 |
| uvos | Wizzup: parazyd: cant build profilesx | 15:41 |
| uvos | i assume the pacakge still wants to pull from extras | 15:41 |
| Wizzup | checking | 15:44 |
| Wizzup | uvos: try again? | 15:45 |
| uvos | Unauthorized | 15:47 |
| Wizzup | hmm | 15:49 |
| uvos | Wizzup: yeah that was it | 16:15 |
| uvos | works now | 16:15 |
| Wizzup | cool | 16:16 |
| uvos | Wizzup: maemo/beowulf buils in a stable enviroment wrt dependancies right | 16:16 |
| Wizzup | yes | 16:16 |
| uvos | and beowulf-devel in a devel enviroment | 16:17 |
| uvos | ok | 16:17 |
| Wizzup | yes | 16:17 |
| uvos | dose simple-brightness and the new cp applet work for you btw? | 16:18 |
| uvos | im sortof afraid i missed some patch since i have lots of dirty pacakges on my device | 16:18 |
| Wizzup | I will check in a bit | 16:21 |
| Wizzup | uvos: can you add the src for the modules here? https://github.com/maemo-leste/clown-boot-kexec | 19:51 |
| Wizzup | (maybe also with binaries?) | 19:51 |
| uvos | Wizzup: we need 2 repos | 19:52 |
| uvos | Wizzup: one for 3.0 kernel and one for 2.6 kernel | 19:53 |
| uvos | or do you want to do it in 2 branches? | 19:53 |
| uvos | i gues that makes sense too | 19:53 |
| Wizzup | branches or even directories | 19:53 |
| uvos | ok | 19:53 |
| uvos | ill do it as branches later | 19:53 |
| uvos | binaries makes no sense | 19:53 |
| uvos | those are in the main clownboot repo anyhow | 19:53 |
| Wizzup | ok, since I was not able to compile it ;-) | 19:54 |
| uvos | compileing it remains tough yeah | 19:55 |
| uvos | i have old gcc installed on my main machine but its not something i can easly just export | 19:55 |
| freemangordon | how old? | 19:56 |
| Wizzup | uvos: yeah so I commented out the aes disabled thing and now it suspiciously doesn't seem to boot | 19:56 |
| freemangordon | as the one in scratchbox is old too ;) | 19:56 |
| Wizzup | uvos: let me add it back in.. | 19:56 |
| uvos | Wizzup: wierd | 19:57 |
| uvos | Wizzup: maybe there is some errata tmlind told you about | 19:57 |
| uvos | on old omap4 chips | 19:57 |
| Wizzup | uvos: yes that is what I recall vaguely | 19:57 |
| Wizzup | I can grep logs | 19:57 |
| uvos | ok would make sense | 19:57 |
| Wizzup | 06:17 < tmlind> Wizzup: oh cool, you got it booting :) looks like aes2 is not accessible on those devices, try setting: | 19:57 |
| uvos | the d3 is a really early omap4 device | 19:57 |
| uvos | ok so what about the high 3mb | 19:58 |
| Wizzup | one by one please | 19:59 |
| uvos | the android kernel parameters sugesst all 512 are useable on d3 | 19:59 |
| Wizzup | ok | 19:59 |
| Wizzup | something funny I think I have noticed, if serial is not in by the time the kexec mod probes (before actually calling kexec), the serial output is not visible until after the kexec | 20:03 |
| uvos | freemangordon: 4.4.1 | 20:03 |
| uvos | freemangordon: (ggc version) | 20:03 |
| uvos | gcc even | 20:03 |
| freemangordon | sbox-arm-none-linux-gnueabi-gcc (GCC) 4.2.1 | 20:04 |
| freemangordon | this is scratchbox | 20:04 |
| uvos | ok | 20:04 |
| uvos | scratchbox is easy to install on modern linux? | 20:04 |
| Wizzup | is that the right version? | 20:04 |
| uvos | should work | 20:05 |
| freemangordon | sbox-arm-none-linux-gnueabi-gcc (Linaro GCC 4.7-2012.07) 4.7.2 20120701 (prerelease) | 20:05 |
| freemangordon | this is scratchbox with cssu-thumb | 20:05 |
| uvos | thats to new | 20:05 |
| uvos | cut off is 4.6 iirc | 20:05 |
| uvos | for 3.0 | 20:05 |
| freemangordon | ok, "vanilla" SB then | 20:05 |
| uvos | and 4.4 for 2.6 | 20:05 |
| Wizzup | uvos: I think your suggestion to rotate 180 degrees over z didn't quite have the right effect | 20:05 |
| uvos | scratchbox is easy to install on modern linux? | 20:06 |
| Wizzup | for portrait rotation I still have to keep it upside down, but for landscape it's now fine | 20:06 |
| freemangordon | uvos: no idea, but in a VM should be easy | 20:06 |
| Wizzup | what about just some old debian? | 20:06 |
| uvos | well then its not superior to booting realy old debian | 20:06 |
| Wizzup | are the repos not still avail? | 20:06 |
| uvos | yeah | 20:06 |
| freemangordon | sure | 20:07 |
| freemangordon | on marmo.org :p | 20:07 |
| freemangordon | *maemo.org | 20:07 |
| Wizzup | I mean the old debian ones | 20:07 |
| Wizzup | not the maemo ones | 20:07 |
| freemangordon | I don't understand | 20:09 |
| freemangordon | Maemo_Ubuntu_Lucid_Desktop_SDK_Virtual_Image_Final.7z ? | 20:10 |
| Wizzup | freemangordon: both uvos and I are suggesting to take say debian 6 or so | 20:11 |
| Wizzup | (I made that number up) | 20:11 |
| Wizzup | as opposed to using the maemo specific SB just to build a motorola kernel module | 20:11 |
| Wizzup | to be clear if it works I suppose it can be fine | 20:11 |
| freemangordon | ah | 20:11 |
| freemangordon | well yeah, you can install old debian in a VM | 20:11 |
| Wizzup | right | 20:12 |
| freemangordon | but, you can take the pre-build maemo SDK images | 20:12 |
| uvos | btw you can also use the android sdk to emerge the exact gcc version motorola used to complie the kernel | 20:12 |
| uvos | never done it | 20:12 |
| uvos | but should work | 20:12 |
| Wizzup | emerge - gentoo based? | 20:12 |
| uvos | no | 20:12 |
| freemangordon | as I am not sure old debian will still have repos alive | 20:12 |
| Wizzup | I think that's just kind of confusing to suggest using scratchbox since it has for the most part outlived it's usefulnes and it mighr confuse people | 20:13 |
| Wizzup | quite some maemo folk I also speak to don't like sb | 20:13 |
| Wizzup | but yeah | 20:13 |
| freemangordon | that's why we us VM on leste :) | 20:13 |
| uvos | build/tools/make_standalone_toolchain.py | 20:14 |
| uvos | in android NDK | 20:14 |
| Wizzup | uvos: any way I can dump the accelerometer data? | 20:14 |
| uvos | Wizzup: cat /sys/bus/iio/somedvice/acell_x_raw | 20:14 |
| uvos | something like that | 20:14 |
| Wizzup | ok | 20:14 |
| uvos | dont forget to remove the bionic matrix btw | 20:14 |
| uvos | since its 180deg from the resulting values with the bionic matrix | 20:15 |
| uvos | not 180deg from the I matrix | 20:15 |
| Wizzup | I multiplied the bionic matrix with the rotation matrix | 20:16 |
| uvos | https://developer.android.com/ndk/downloads/revision_history | 20:16 |
| uvos | should be able to get the correct sdk here | 20:16 |
| uvos | that contains the gcc used by moto themselves | 20:17 |
| Wizzup | uvos: https://dpaste.com/GCN5FKB5P | 20:17 |
| Wizzup | was that not what you meant? | 20:17 |
| uvos | lol | 20:17 |
| uvos | & using np | 20:17 |
| uvos | *@ | 20:17 |
| uvos | sure that looks sane | 20:18 |
| Wizzup | hmmmm | 20:18 |
| Wizzup | I think it doesn't get picked up in the kernel, perhaps | 20:18 |
| uvos | ? | 20:18 |
| Wizzup | root@devuan-bionic:/sys/bus/iio/devices/iio:device2# cat in_accel_mount_matrix | 20:19 |
| uvos | the kernel dose not | 20:19 |
| Wizzup | 1, 0, 0; 0, 1, 0; 0, 0, 1 | 20:19 |
| Wizzup | unless this is a different file | 20:19 |
| Wizzup | oh, this is a udev thing? | 20:19 |
| uvos | i repleat not have anything to do with this | 20:19 |
| Wizzup | ok, let me read backlog | 20:19 |
| Wizzup | I changed it in the dts, yeah, ok, my bad. | 20:19 |
| uvos | the matrix is used by iio-sensor-proxy | 20:19 |
| uvos | from udev | 20:19 |
| uvos | accel_mount_matrix is not supported by our driver | 20:19 |
| uvos | if it where the kernel would simply tell udev about the matrix | 20:20 |
| uvos | and the config file would be unessecary | 20:20 |
| uvos | i have yet to come across a driver that implements this tho | 20:20 |
| uvos | the kernel never applies the matrix iteself in any circumstances | 20:20 |
| uvos | ( a grave error in interface design imo) | 20:21 |
| Wizzup | this should make it pick up the changes, right: udevadm control --reload-rules && udevadm trigger | 20:21 |
| uvos | yes | 20:21 |
| uvos | devadm info -e | grep WHATEVER_THE_MOUNT_MATRIX_IS_CALLED | 20:22 |
| uvos | or if you know the device path you can give udevadm that to just dump its pops | 20:22 |
| Wizzup | so it looks like at least it shows up with the new matrix there but nothing is picked up | 20:23 |
| uvos | picked up where? | 20:23 |
| Wizzup | by mce I suspect | 20:23 |
| Wizzup | i.e. the rotation of the device is not affected | 20:23 |
| Wizzup | regardless of what I set | 20:24 |
| uvos | you have to restart iio-sensor-proxy | 20:24 |
| Wizzup | ah... | 20:24 |
| Wizzup | now it works | 20:25 |
| uvos | great | 20:26 |
| Wizzup | it is just I | 20:26 |
| Wizzup | that's nice | 20:26 |
| Wizzup | or is this matrix applied on top of the matrix in the dts? | 20:26 |
| Wizzup | (in which case I might need to change it once more) | 20:27 |
| uvos | no the matrix in dts in impotent | 20:27 |
| Wizzup | impotent, not important, ok | 20:27 |
| Wizzup | shall I sync it with udev matrix anyhow? | 20:27 |
| uvos | yeah | 20:27 |
| uvos | the driver might start supporting this feature some time in the future | 20:27 |
| Wizzup | it's this atm: | 20:28 |
| Wizzup | rotation-matrix = "0", "-1", "0", | 20:28 |
| Wizzup | "1", "0", "0", | 20:28 |
| Wizzup | "0", "0", "1"; | 20:28 |
| Wizzup | so I'll just make it I as well? | 20:28 |
| uvos | why I isent your matrix | 20:28 |
| uvos | 0 1 0 | 20:29 |
| uvos | -1 0 0 | 20:29 |
| uvos | 0 0 1 | 20:29 |
| uvos | ? | 20:29 |
| Wizzup | in the dts? | 20:29 |
| uvos | in udev | 20:29 |
| Wizzup | udev is identity matrix | 20:29 |
| uvos | and its correct? | 20:29 |
| Wizzup | yes | 20:29 |
| uvos | in monitor-sensor | 20:29 |
| Wizzup | uh, let me check monitor-sensor specifically | 20:29 |
| Wizzup | yes, it is | 20:30 |
| uvos | ok | 20:30 |
| uvos | then you can remove the udev rule | 20:30 |
| uvos | and the dts entry | 20:30 |
| Wizzup | ok | 20:30 |
| uvos | or leave it I | 20:30 |
| uvos | but its redundant | 20:30 |
| Wizzup | I'll leave it I I think | 20:31 |
| uvos | ok | 20:31 |
| Wizzup | (ok the I usage gets onfusing now lol) | 20:31 |
| Wizzup | let me try to decipher your i2c suggestions from yesterday | 20:31 |
| uvos | $I$ | 20:31 |
| uvos | we speek latex :P | 20:31 |
| Wizzup | hehe | 20:32 |
| Wizzup | this command verifies led chip is on the same i2c place and present, right: | 20:33 |
| Wizzup | i2cdetect -r 0 0x38 0x38 | 20:33 |
| Wizzup | (with UU showing) | 20:33 |
| uvos | yes | 20:33 |
| uvos | also the kernel is using it | 20:33 |
| uvos | UU | 20:33 |
| Wizzup | but that is not the backlight, I assume | 20:33 |
| Wizzup | just the rgb led controller | 20:33 |
| uvos | well it is | 20:33 |
| Wizzup | hmm | 20:33 |
| uvos | its changeing the wrong channel | 20:33 |
| uvos | probubly | 20:33 |
| uvos | the chip has 3 channels iirc | 20:33 |
| Wizzup | yeah you suggested I try 0x16, 0x18 or 0x1A, but I don't know where exactly | 20:33 |
| uvos | on d4 i is the backlight | 20:33 |
| Wizzup | (I don't speak i2c much) | 20:33 |
| uvos | one is the keyboard | 20:34 |
| uvos | and one is unused iirc | 20:34 |
| uvos | those are addresses to write to voer i2c | 20:34 |
| Wizzup | at the 0x38 range? | 20:34 |
| uvos | no | 20:34 |
| uvos | so 0x38 is the chip address | 20:34 |
| uvos | or chip id | 20:34 |
| uvos | you wirte that to the bus if you want to talk to that chip | 20:35 |
| uvos | then 0x16 is the register address on the chip you want to write | 20:35 |
| Wizzup | ok | 20:35 |
| uvos | so i2cget 0x38 0x16 | 20:35 |
| uvos | should provide you some value | 20:35 |
| uvos | and then use i2cset to slightly change it | 20:36 |
| Wizzup | # i2cget 0x38 0x16 | 20:36 |
| Wizzup | Error: Could not open file `/dev/i2c-56' or `/dev/i2c/56': No such file or directory | 20:36 |
| Wizzup | # ls /dev/i2c-* | 20:36 |
| Wizzup | /dev/i2c-0 /dev/i2c-1/dev/i2c-2 /dev/i2c-3 | 20:36 |
| uvos | oh right | 20:36 |
| Wizzup | I guess I need to provide the bus | 20:36 |
| uvos | bus first | 20:36 |
| uvos | so i2cget 0 0x38 0x16 | 20:36 |
| Wizzup | so i2c1 in dts would be .. | 20:36 |
| uvos | not 0 nessecarly | 20:36 |
| uvos | i dont remember what bus | 20:36 |
| uvos | i2c1 in dts is 0 | 20:37 |
| Wizzup | oh | 20:37 |
| uvos | dts starts at 1 and kernel starts at 0 | 20:37 |
| uvos | someone hates us | 20:37 |
| Wizzup | lol | 20:37 |
| Wizzup | hm, all busses at 0x38 and the various channel fail with 'Error: read failed' | 20:38 |
| Wizzup | actually bus 0 says 'device of resource busy' | 20:38 |
| uvos | right | 20:38 |
| Wizzup | could be because driver is loaded? | 20:38 |
| uvos | you have to remvoe the module | 20:38 |
| Wizzup | leds_lm3532 ? | 20:39 |
| uvos | that would be my assumption yes | 20:39 |
| Wizzup | the reads also fail on that bus on 0x38 with 0x16, 0x18 or 0x1a | 20:40 |
| uvos | the driver owns the device | 20:40 |
| uvos | the register address is immaterial | 20:40 |
| Wizzup | what I mean is that the driver is now gone, there is no more busy | 20:40 |
| Wizzup | and now I get the same error as on the other busses | 20:40 |
| Wizzup | i.e. | 20:41 |
| Wizzup | # i2cget 0 0x38 0x16 | 20:41 |
| Wizzup | WARNING! This program can confuse your I2C bus, cause data loss and worse! | 20:41 |
| Wizzup | I will read from device file /dev/i2c-0, chip address 0x38, data address | 20:41 |
| Wizzup | 0x16, using read byte data. | 20:41 |
| Wizzup | Continue? [Y/n] y | 20:41 |
| Wizzup | Error: Read failed | 20:41 |
| Wizzup | maybe I need to run some command to wake up the chip, maybe the driver unload disables it | 20:42 |
| Wizzup | since it's '--' now in i2cdetect as well | 20:42 |
| uvos | try reading from 0x71 | 20:42 |
| uvos | 0x71 as chip addres | 20:42 |
| uvos | also yeah might be an enable pin | 20:43 |
| Wizzup | same output on 0x71 for the three data addresses you gave | 20:43 |
| uvos | should say in dts | 20:43 |
| Wizzup | enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>; | 20:43 |
| uvos | right | 20:43 |
| uvos | so enable the gpio then | 20:43 |
| Wizzup | mhm | 20:43 |
| uvos | datasheet contains ADDRESS: 0x38 (7 bit), 0x70 for Write and 0x71 for Read | 20:44 |
| uvos | not sure what it means | 20:44 |
| uvos | oh ofc | 20:45 |
| uvos | nvm its fine | 20:45 |
| uvos | 0x38 | 20:45 |
| Wizzup | enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>; I am not sure which gpiochip this is in /sys/class/gpio | 20:47 |
| Wizzup | (yeah I really know little about this) | 20:47 |
| uvos | cat /sys/kernel/debug/gpio | 20:48 |
| uvos | tells you | 20:48 |
| Wizzup | ah! | 20:48 |
| Wizzup | gpiochip6: GPIOs 508-511, parent: platform/50000000.gpmc, omap-gpmc: | 20:48 |
| Wizzup | only three gpios there it looks like | 20:48 |
| Wizzup | I guess I should load the driver again | 20:49 |
| Wizzup | hm, nope, didn't change much | 20:50 |
| Wizzup | my confusion is that I was expecting to find at least 12 gpios there | 20:50 |
| Wizzup | (under gpiochip6) | 20:50 |
| Wizzup | oh, maybe this is also off by one thing | 20:51 |
| Wizzup | so <&gpio6 12> == gpiochip 5, 12 | 20:51 |
| uvos | right | 20:52 |
| Wizzup | looks like | 20:52 |
| uvos | so export pin 12 | 20:52 |
| Wizzup | yeah that is 140 | 20:52 |
| Wizzup | root@devuan-bionic:/sys/class/gpio/gpio140# echo 1 > value | 20:53 |
| Wizzup | -bash: echo: write error: Operation not permitted | 20:53 |
| Wizzup | truly has to fail every step of the way :P | 20:54 |
| uvos | heh | 20:54 |
| Wizzup | ah I guess I might need to set the direction | 20:55 |
| Wizzup | right | 20:55 |
| uvos | not sure on the interface sorry | 20:55 |
| uvos | but yeah makes sense | 20:55 |
| Wizzup | yeah, echo out > direction worked | 20:56 |
| Wizzup | not that it helped with i2c, but hey :) | 20:56 |
| uvos | is the chip on the bus | 20:56 |
| uvos | hmm | 20:56 |
| uvos | wait you did change value too | 20:57 |
| uvos | not just direction | 20:57 |
| uvos | its active high | 20:57 |
| Wizzup | value set to 1, with active_low set to 0 | 20:57 |
| uvos | pulling it low wont help | 20:57 |
| uvos | ok | 20:57 |
| uvos | hmm | 20:57 |
| Wizzup | I think it might make more sense to look at android at this point | 20:58 |
| Wizzup | of course there we have the problem that the dts had the wrong endianness ;) | 20:58 |
| uvos | Heresy | 20:58 |
| Wizzup | maybe this is for another time then | 20:59 |
| Wizzup | what should i2cdetect show if it's present but not in use? | 21:00 |
| uvos | yes | 21:00 |
| Wizzup | literally "yes"? | 21:00 |
| tmlind | freemangordon: nice work, so you probably figured out ddk-1.17 no longer uses any of those proxied ioctls in omapdrm driver ddk-1.9 was using, whatever you do let's not add those back :) | 21:06 |
| tmlind | that was a pain to maintain with a big pile of extra patches against the mainline kernel | 21:07 |
| Wizzup | uvos: heh the kbd brightness is the screen | 21:07 |
| Wizzup | or something like that it seems.. | 21:07 |
| Wizzup | this turns on the screen brightness: echo 1 > /sys/class/leds/lm3532\:\:kbd_backlight/brightness | 21:08 |
| Wizzup | (no diff between 1 and 255) | 21:08 |
| uvos | ok | 21:10 |
| uvos | just swap the channels in dts then | 21:10 |
| Wizzup | right | 21:10 |
| Wizzup | uvos: so that's the reg = <> or led-sources = <> ? | 21:11 |
| uvos | tmlind: btw reading the above | 21:11 |
| uvos | led-sources should be swaped | 21:11 |
| uvos | ie in the end | 21:12 |
| uvos | leds for backlight | 21:12 |
| uvos | the leds phandle should link to the one currently used by the keyboard backlight | 21:13 |
| Wizzup | right so https://dpaste.com/GX9WGHC5J.txt | 21:13 |
| uvos | ? | 21:15 |
| uvos | just swap the backlight_led identifier over to led@1 | 21:15 |
| uvos | and label = ":backlight"; | 21:15 |
| uvos | then leds = <&backlight_led>; phandle will grab the right one | 21:16 |
| Wizzup | ah | 21:17 |
| Wizzup | uvos: did the swap, but it doesn't give any granularity still | 21:22 |
| uvos | hmm | 21:23 |
| uvos | in datasheet granularity depends on other regs | 21:24 |
| uvos | not sure how is controled in lm3532 driver | 21:24 |
| Wizzup | hmm | 21:24 |
| uvos | led-sources means something different than i expected | 21:26 |
| uvos | led->num_leds | 21:26 |
| uvos | its not the channel it seams | 21:26 |
| Wizzup | ah | 21:26 |
| uvos | Required child properties: | 21:28 |
| uvos | - led-sources : see Documentation/devicetree/bindings/leds/common.txt | 21:28 |
| uvos | List of device current outputs the LED is connected to. The outputs are | 21:28 |
| uvos | identified by the numbers that must be defined in the LED device binding | 21:28 |
| uvos | documentation. | 21:28 |
| uvos | so led device is defined somewhere else in dts | 21:29 |
| Wizzup | ok | 21:31 |
| uvos | just swap led-sources too | 21:31 |
| uvos | but id like to know where this is defined exactly | 21:32 |
| Wizzup | rebooting | 21:33 |
| uvos | no wait | 21:36 |
| uvos | it is the ouput channel i read that wrong | 21:37 |
| * uvos slight confusion | 21:37 | |
| Wizzup | in any case I need to go now, the backlight always worked in the sense that it at least turned *on* so that I could see the screen | 21:37 |
| uvos | ok | 21:37 |
| Wizzup | but I noticed that writing to the kbd backlight sysfs file changed the backligt too | 21:37 |
| Wizzup | so there's something wrong there for sure | 21:37 |
| Wizzup | uvos: thx for your help btw | 21:50 |
| uvos | Wizzup: yw | 22:44 |
| uvos | Wizzup: also the faster you stop messing with the d3 the faster your back on things that benefit me more directly :P | 22:45 |
| Wizzup | hehe | 23:10 |
| bencoh | :] | 23:24 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!