| chartreuse | Can't wait for the better wifi antennas to arrive, but these cheap ebay ones that I had for a previous laptop aren't entirely useless. Though I think they're only designed for 2.4GHz | 00:00 |
|---|---|---|
| mntmn | very possible | 00:05 |
| mntmn | bluerise: very good progress btw! i believe that breakthrough is not very far off... | 00:06 |
| chartreuse | Looking at the keyboard schematics it seems there's two switch's free in the matrix. Gives me an idea to maybe add a lid switch of some kind for entering standby | 00:09 |
| chartreuse | Though no pins directly free on the micro so it'd have to be something self contained that just connects two pins when closed, like maybe a reed relay or such | 00:10 |
| chartreuse | Wonder if I could position one close enough to the lid magnets to go off when closed, but not just from the magnets in the base half | 00:10 |
| mntmn | you could maybe solder to the back of the motherboard's LPC expansion port pins instead | 00:11 |
| mntmn | a wire that is | 00:11 |
| mntmn | (saying this because it has free gpios) | 00:12 |
| mntmn | messing with lpc is a bit more risky though | 00:12 |
| mntmn | chartreuse: but the biggest problem is that sleep/wake gets stuck pretty often. we need to solve that first | 00:12 |
| mntmn | chartreuse: https://source.mnt.re/reform/reform/-/issues/8 | 00:13 |
| chartreuse | I've only had an issue once where it woke but didn't reset the wifi correctly. But I haven't done it too much | 00:13 |
| chartreuse | I still might at least modify the controller so there is a sleep option in the circle menu that sends a suspend key event over the keyboard. | 00:13 |
| chartreuse | I'll take a look into suspend and see what I can find, I guess I have to just try it a bunch to see how it fails for myself | 00:16 |
| mntmn | yeah | 00:16 |
| mntmn | you are using an nvme right? | 00:16 |
| chartreuse | I was liking the idea of putting it on the keyboard controller rather than the LPC because there is a keyboard scancode for suspend, and then userspace could handle it from there | 00:17 |
| chartreuse | Yeah I've got an nvme as the boot drive now, though with the SD card providing the init rather than the eMMC right now | 00:17 |
| mntmn | chartreuse: ok makes sense! | 00:17 |
| chartreuse | Oh the trackball has its own micro as well, maybe I could look into if a USB HID mouse can send a suspend event somehow, doubt it, plus the keyboard seems a better place | 00:21 |
| ephase | mntmn: What is the normal temperature of the SoM? | 00:24 |
| mntmn | ephase: 50-60 degrees | 00:25 |
| chartreuse | It takes a fairly long time to get up to that temperature, right now mines still at 30, but it got to 55C last night | 00:25 |
| mntmn | are you in a cool place? | 00:27 |
| ephase | mntmn: ok I have 56 degres here while browsing and editing markdown file | 00:28 |
| mntmn | ephase: that's pretty normal tthen | 00:28 |
| mntmn | then | 00:28 |
| ephase | ok thanks | 00:28 |
| chartreuse | Not too much, it's around 20C here, guess I've just been doing very light usage at the moment. Yesterday was a bit warmer | 00:28 |
| mntmn | it tends to get hotter when charing or using the GPU a lot | 00:28 |
| mntmn | charging | 00:29 |
| ephase | ok | 00:32 |
| ephase | mine not charging actually | 00:32 |
| ephase | mntmn: I can use your MNT Reform from your presskit for my blog article? | 00:33 |
| mntmn | ephase: yes, absolutely | 00:33 |
| - chartreuse (QUIT: Ping timeout: 240 seconds) (~chartreus@199-7-158-226.eng.wind.ca) | 00:34 | |
| ephase | mntmn: thanks, minea are not so good ^^ | 00:34 |
| ephase | mntmn: without compiling xwayland gimp interface is messy | 00:53 |
| mntmn | ephase: yes. | 00:56 |
| mntmn | ephase: glFinish() patch is required for gtk2 apps | 00:56 |
| mntmn | ephase: the next gen version of gimp uses gtk3 though. | 00:57 |
| mntmn | (2.99) | 00:57 |
| ephase | yes I know, so Iuse convet instead :) | 01:03 |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 01:16 | |
| ephase | Goning to sleep, good night | 01:30 |
| mntmn | n8n8 | 01:43 |
| - ephase (QUIT: Quit: WeeChat 3.0.1) (~ephase@2a01:e0a:168:1211::885) | 01:53 | |
| - wagga (QUIT: Quit: Client closed) (~wagga@node-1w7jra22ildhv9tkri23jpmvy.ipv6.telus.net) | 02:42 | |
| - chartreuse (QUIT: Quit: leaving) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 02:44 | |
| - alex4nder (QUIT: Ping timeout: 245 seconds) (~alexander@172.56.42.59) | 03:27 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 06:22 | |
| + alex4nder (~alexander@172.58.43.141) | 06:25 | |
| chartreuse | Made a script to toggle the pulse output between headphones and speaker and bound that to Super+F6 in sway. | 06:34 |
| chartreuse | Though now I'm looking at the schematic and I see that the jack detect is hooked up to the DAC and the headphone jack. So there should be a way of making it work automatically | 06:34 |
| chartreuse | In the Wolfson DAC datasheet there's a register to have it automatically switch when the jack is inserted, though not sure if that'd play nicely with Pulse and also change the volume level to the headphone level | 06:35 |
| - alex4nder (QUIT: *.net *.split) (~alexander@172.58.43.141) | 06:58 | |
| - chartreuse (QUIT: *.net *.split) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 06:58 | |
| - TadeusTaD (QUIT: *.net *.split) (tadeustad@fulu.psifactor.pl) | 06:58 | |
| - scops (QUIT: *.net *.split) (~scopstchn@2001:470:69fc:105::8da) | 06:58 | |
| - jryans (QUIT: *.net *.split) (~jryans@2001:470:69fc:105::1d) | 06:58 | |
| - emery (QUIT: *.net *.split) (~quassel@2a03:3b40:fe:ab::1) | 06:58 | |
| - Asmadeus (QUIT: *.net *.split) (~asmadeus@240b:13:8c80:d300:e:98c:8000:d300) | 06:58 | |
| + alex4nder (~alexander@172.58.43.141) | 06:59 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 06:59 | |
| + TadeusTaD (tadeustad@fulu.psifactor.pl) | 06:59 | |
| + scops (~scopstchn@2001:470:69fc:105::8da) | 06:59 | |
| + jryans (~jryans@2001:470:69fc:105::1d) | 06:59 | |
| + emery (~quassel@2a03:3b40:fe:ab::1) | 06:59 | |
| + Asmadeus (~asmadeus@240b:13:8c80:d300:e:98c:8000:d300) | 06:59 | |
| - tarxvf (QUIT: *.net *.split) (~tarxvf@mail.tarxvf.tech) | 07:01 | |
| - jackhill (QUIT: *.net *.split) (~jackhill@kalessin.dragonsnail.net) | 07:01 | |
| - skalk (QUIT: *.net *.split) (~skalk@vond.sysret.de) | 07:01 | |
| - sknebel (QUIT: *.net *.split) (~quassel@v22016013254630973.happysrv.de) | 07:01 | |
| - marex (QUIT: *.net *.split) (~marex@195.140.253.37) | 07:01 | |
| + jackhill_ (~jackhill@kalessin.dragonsnail.net) | 07:01 | |
| + marex_ (~marex@195.140.253.37) | 07:01 | |
| + tarxvf_ (~tarxvf@mail.tarxvf.tech) | 07:01 | |
| + skalk_ (~skalk@vond.sysret.de) | 07:01 | |
| - scops (QUIT: Ping timeout: 272 seconds) (~scopstchn@2001:470:69fc:105::8da) | 07:03 | |
| + sknebel (~quassel@v22016013254630973.happysrv.de) | 07:03 | |
| - jryans (QUIT: Ping timeout: 272 seconds) (~jryans@2001:470:69fc:105::1d) | 07:03 | |
| + reformer (~reformer@softboy.mntmn.com) | 07:07 | |
| - erlehmann (QUIT: Quit: Just say no, then the virus can not enter your body without your consent.) (~erle@dynamic-046-114-034-077.46.114.pool.telefonica.de) | 07:11 | |
| Asmadeus | pulseaudio handles that pretty well afaik (both switch and different sound level) | 07:29 |
| * swivel_ -> swivel | 07:32 | |
| + cryptix (~cryptxxma@2001:470:69fc:105::94a) | 07:33 | |
| + nio (~nio@2001:470:69fc:105::172d) | 07:33 | |
| + scops (~scopstchn@2001:470:69fc:105::8da) | 07:40 | |
| chartreuse | Pulse does it yeah, but I guess it'd be more how is the driver handling it and is it communicating it to linux. Because looking at the datasheet it seemed internal. | 08:00 |
| chartreuse | Though I haven't looked at the driver source yet | 08:00 |
| chartreuse | Since right now it doesn't auto switch on the Reform | 08:01 |
| * marex_ -> marex | 08:11 | |
| + jryans (~jryans@2001:470:69fc:105::1d) | 08:34 | |
| + indefini[m] (~indefinim@2001:470:69fc:105::1e2a) | 08:35 | |
| mntmn | chartreuse: that is correct, the hardware support is there but i haven't investigated how to make the driver & pulse handle it. | 10:20 |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 11:45 | |
| - alex4nder (QUIT: Ping timeout: 272 seconds) (~alexander@172.58.43.141) | 13:33 | |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 13:45 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 13:46 | |
| + wagga (~wagga@node-1w7jra22ildhwu44kvuq39uhc.ipv6.telus.net) | 13:56 | |
| - wiedi (QUIT: Read error: Connection reset by peer) (~wiedi@37.228.191.159) | 14:01 | |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 15:46 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 15:47 | |
| + wiedi (~wiedi@37.228.191.159) | 16:05 | |
| - wiedi (QUIT: Read error: Connection reset by peer) (~wiedi@37.228.191.159) | 17:34 | |
| + wiedi (~wiedi@37.228.191.159) | 18:18 | |
| + alex4nde1 (~alexander@172.58.35.56) | 18:43 | |
| - alex4nde1 (QUIT: Ping timeout: 268 seconds) (~alexander@172.58.35.56) | 18:54 | |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 19:42 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 19:43 | |
| + erlehmann (~erle@dynamic-046-114-033-055.46.114.pool.telefonica.de) | 20:27 | |
| * jackhill_ -> jackhill | 20:40 | |
| bluerise | something was still bogus on the MIPI eDP bridge, pulse width was wrong | 20:56 |
| bluerise | now at least the colors look right | 20:56 |
| bluerise | still black, eh | 20:56 |
| mntmn | oh, interesting... horiz pulse width in the display timings? | 20:57 |
| bluerise | yeah, the community thread had it wrong | 20:57 |
| bluerise | - /* HSync pulse width 40 */ | 20:57 |
| bluerise | - sn65dsi86_write(dev, 0x2c, 0x28); | 20:57 |
| bluerise | - /* VSync pulse width 4 */ | 20:57 |
| bluerise | - sn65dsi86_write(dev, 0x30, 0x04); | 20:57 |
| bluerise | + /* HSync pulse width 80 */ | 20:57 |
| bluerise | + sn65dsi86_write(dev, 0x2c, 0x50); | 20:57 |
| bluerise | + /* VSync pulse width 24 */ | 20:57 |
| bluerise | + sn65dsi86_write(dev, 0x30, 0x18); | 20:57 |
| bluerise | I should replace the hardcoded settings anyway | 20:57 |
| bluerise | at some point | 20:57 |
| mntmn | alright! | 20:58 |
| bluerise | but for now it's more important to find out why it's still black / no MIPI packets | 20:58 |
| mntmn | what about tracing in the code if mipi packets are sent? | 20:58 |
| mntmn | in the dsi driver | 20:58 |
| mntmn | or actually that's probably only for some kind of auxiliary packets? i guess the engine should run without any active driver support | 20:59 |
| mntmn | the hdmi stuff is not running at the same time, right? | 20:59 |
| bluerise | no HDMI stuff | 21:00 |
| mntmn | ok | 21:00 |
| mntmn | my guess is they never tested dcss+dsi in u-boot | 21:00 |
| mntmn | so there might be a tiny detail wrong | 21:00 |
| mntmn | i mean, some we already found | 21:01 |
| mntmn | i could try to bulk dump the relevant registers on a working booted system maybe and then compare | 21:01 |
| mntmn | but idk if it is a "wrong register values" or "wrong order of things" or "wrong clocks" problem | 21:02 |
| bluerise | could be all of them ;) | 21:02 |
| mntmn | true | 21:03 |
| bluerise | that's why it's hard to turn one knob | 21:04 |
| mntmn | for example, lcdif goes black if it is starved for like 1 second and does not recover | 21:04 |
| mntmn | but dcss is probably different | 21:04 |
| bluerise | because you might actually turn a knob that makes it worse heh | 21:04 |
| bluerise | too many permutations | 21:04 |
| mntmn | yeah. | 21:04 |
| mntmn | we would need to have some confirmation of things working or not at all points in the chain | 21:05 |
| bluerise | well at least the display works ;) | 21:05 |
| mntmn | yes | 21:05 |
| bluerise | and the clk dump looks promising | 21:06 |
| mntmn | yes | 21:06 |
| mntmn | can you pastebin/gist a complete clk dump? | 21:09 |
| mntmn | bluerise: here's a register dump from the working systems' DTG (display timing generator) http://dump.mntmn.com/dcss_dtg.txt | 21:14 |
| bluerise | http://ix.io/3vuQ | 21:18 |
| - rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 21:19 | |
| mntmn | ok, some interesting differences | 21:19 |
| mntmn | so, if i write your value 0xff005184 to 0x32e20000, nothing changes, but writing a zero there kills the display output (it stays at a single color) | 21:24 |
| mntmn | (on working linux system) | 21:25 |
| bluerise | '// LCDIF is not used, but has to be active or DCSS won't work' | 21:27 |
| bluerise | what does 'active' mean? | 21:27 |
| bluerise | clock? | 21:27 |
| mntmn | well, i don't know in detail but if the dts node is disabled (i.e. not "okay") i wouldn't get display output on dcss in linux | 21:27 |
| mntmn | could be some clock or clock gating or power thing | 21:28 |
| bluerise | it's written twice | 21:28 |
| bluerise | reg32_write(priv->addr + 0x20000, 0xff005084); | 21:28 |
| bluerise | one | 21:28 |
| bluerise | reg32_write(priv->addr + 0x20000, 0xff005184); | 21:29 |
| bluerise | two | 21:29 |
| bluerise | /*reg32_write(priv->addr + 0x20000, 0xff000484); */ | 21:29 |
| bluerise | and one masked lol | 21:29 |
| bluerise | wonder what the diff is | 21:29 |
| mntmn | yes it's written twice | 21:31 |
| mntmn | because it is first turned off | 21:31 |
| mntmn | and then turned on | 21:31 |
| mntmn | that's the 0x100 | 21:31 |
| mntmn | that's the GO flag for the display timing generator | 21:31 |
| mntmn | so they turn it off, make all the settings and then turn it on | 21:31 |
| mntmn | the display timings in the register dump are the same as on my working system | 21:33 |
| mntmn | i.e. the stuff that looks like 0457081f 001f0077 and so on | 21:33 |
| mntmn | this is different: reg32_write(priv->addr + 0x20028, 0x000b000a); | 21:33 |
| mntmn | ok that is really strange, because that is the context loader register | 21:42 |
| mntmn | the first 16bits are single buffered line counts and the second 16bits are double buffered line counts | 21:43 |
| mntmn | that's why on linux i have 0000044B | 21:43 |
| mntmn | that's 1099, so at the end of the blank area of the 1080p screen i guess | 21:44 |
| mntmn | > Line Count in the raster table where the CTX_LD is triggered for loading context | 21:44 |
| mntmn | so it probably doesn't matter, it's just a very strange value (0xa / 0xb) | 21:44 |
| mntmn | well ok it makes sense if that is a front porch or something | 21:45 |
| technomancy | is it possible that I have network-manager fighting with ... some other network thing? I've noticed that the wifi AP listing I get from nmtui is often completely different from the listing I get from whatever runs when I click "NET" in the top bar of sway | 21:48 |
| mntmn | technomancy: yes, network-manager is not used by default | 21:56 |
| mntmn | technomancy: instead we use connman | 21:56 |
| mntmn | i mean, network-manager is not even installed by default | 21:56 |
| technomancy | huh, I never heard of connman before today | 21:58 |
| technomancy | my dotfiles script must have brought in network-manager in order to get the tray icon thingy | 21:58 |
| mntmn | it's kind of more compact | 21:58 |
| mntmn | you can of course switch everything to network manager but then you have to remove connman and change the waybar config to show some network manager UI instead | 21:59 |
| technomancy | I wonder if that's why my wifi has kept dropping out, if the two systems have been conflicting over the two | 21:59 |
| mntmn | yes, very possible | 21:59 |
| technomancy | I don't have any preference; I'll get rid of network-manager and see what happens with just connman | 21:59 |
| mntmn | bluerise: haha i found the "opacity" slider in dcss | 22:01 |
| mntmn | which explains the 0xff | 22:01 |
| technomancy | hm; so connman doesn't seem to be able to work with my mobile's USB tethering | 22:01 |
| technomancy | (but network-manager didn't either, on this machine) | 22:01 |
| mntmn | technomancy: probably missing a kernel driver for that | 22:01 |
| technomancy | but for wifi only it seems fine | 22:01 |
| technomancy | I've never needed special drivers on any other machine for USB tethering, but maybe? | 22:02 |
| mntmn | the reform kernel does not have all those drivers by default, i missed that one because it has a weird name, microsoft something something | 22:02 |
| mntmn | bluerise: ok so the 0xff in 0xff005184 is the alpha value of that channel | 22:03 |
| mntmn | bluerise: and 0x400 (active in linux, but not in that uboot thing) enables per pixel alpha instead of per channel alpha | 22:04 |
| mntmn | bluerise: those are interrupt coordinates. but they are turned off in u-boot. 0x32E20050: 03E70000 | 22:06 |
| mntmn | bluerise: i am concluding that the DTG setup part of DCSS should be OK. | 22:08 |
| + darth-cheney (~user@135.84.167.9) | 22:15 | |
| darth-cheney | yo, for whatever reason I don't seem to have the reform-migrate script on my system | 22:16 |
| darth-cheney | (the one described in 10.3 of the manual) | 22:16 |
| darth-cheney | Is that because it shouldn't be used anymore? | 22:16 |
| mntmn | darth-cheney: maybe you have to use sudo | 22:17 |
| mntmn | should be /usr/sbin/reform-migrate | 22:17 |
| mntmn | memtool 0x32e1b060=1 makes everything tinted red. | 22:18 |
| mntmn | so those are color space registers | 22:18 |
| darth-cheney | mntmn: aha I see it there | 22:21 |
| darth-cheney | manual says /sbin/reform-migrate | 22:21 |
| darth-cheney | ok sweet, I'm gonna see if I can boot from the internal | 22:21 |
| bluerise | mntmn: http://ix.io/3vvb | 22:23 |
| mntmn | bluerise: thanks | 22:24 |
| mntmn | darth-cheney: sorry, bug in the manual | 22:25 |
| mntmn | bluerise: i would like the respective 32bit values in 0x32e1b010, 0x32e1b020, 0x32e1b030, 0x32e1b040, 0x32e1b050 | 22:27 |
| mntmn | bluerise: these are important for the display timing/blanking signals | 22:28 |
| mntmn | bluerise: they should be 0457081f, 0027081f, 00070003, 80200077, 045707f7 | 22:29 |
| darth-cheney | mntmn: no sweat dude | 22:29 |
| bluerise | hm, maybe the code is wrong then? | 22:30 |
| bluerise | reg32_write(priv->addr + 0x1b010, | 22:30 |
| bluerise | (((priv->timings.vfront_porch.typ + priv->timings.vback_porch.typ + priv->timings.vsync_len.typ + | 22:30 |
| bluerise | priv->timings.vactive.typ -1) << 16) | | 22:30 |
| bluerise | (priv->timings.hfront_porch.typ + priv->timings.hback_porch.typ + priv->timings.hsync_len.typ + | 22:30 |
| bluerise | priv->timings.hactive.typ - 1))); | 22:30 |
| mntmn | bluerise: what is wrong? do you have other values? | 22:32 |
| bluerise | ah wait sorry | 22:32 |
| bluerise | I looked at the DTG stuff | 22:32 |
| bluerise | 1s | 22:32 |
| mntmn | ok | 22:32 |
| mntmn | also, the framebuffer address is in 0x32e180c0 | 22:33 |
| mntmn | in linux the address is 0xdf200000... and i can see the correct pixels there, which is fun | 22:33 |
| bluerise | 0457081f, 004f081f, 001b0003, 80200077, 045707f7 | 22:33 |
| mntmn | bluerise: ok some slight differences there, let me check | 22:34 |
| bluerise | ah, you got 40, I got 80 in the 0x20 one | 22:35 |
| bluerise | reg32_write(priv->addr + 0x1b020, | 22:35 |
| bluerise | (((priv->timings.hsync_len.typ - 1) << 16) | priv->hpol << 31 | (priv->timings.hfront_porch.typ + | 22:35 |
| bluerise | priv->timings.hback_porch.typ + priv->timings.hsync_len.typ + priv->timings.hactive.typ -1))); | 22:35 |
| bluerise | mine writes hsync-len | 22:35 |
| bluerise | and yours has hfront/hback porch? | 22:35 |
| mntmn | let me check the linux driver | 22:35 |
| bluerise | need to check dcss code | 22:35 |
| bluerise | hehehe | 22:35 |
| bluerise | yes | 22:35 |
| mntmn | ok i found the right file at least... | 22:38 |
| mntmn | hsync_start = vm->hfront_porch + vm->hback_porch + vm->hsync_len + vm->hactive - 1; | 22:39 |
| mntmn | hsync_end = vm->hsync_len - 1; | 22:39 |
| bluerise | dcss_ss_write(ss, (phsync ? SYNC_POL : 0) | | 22:39 |
| bluerise | ((u32)hsync_end << SYNC_END_POS) | hsync_start, | 22:39 |
| bluerise | DCSS_SS_HSYNC); | 22:39 |
| mntmn | yeah | 22:39 |
| bluerise | but wait, is my hsync_len then wrong? | 22:39 |
| bluerise | ../../drm_modes.c: vm->hsync_len = dmode->hsync_end - dmode->hsync_start; | 22:40 |
| mntmn | should be 40 | 22:40 |
| mntmn | 0x28 | 22:41 |
| bluerise | sure? | 22:41 |
| mntmn | that's what's in my register at least ;) i can try to see what happens if i change it | 22:41 |
| bluerise | .hsync_start = 1920 + 40, | 22:42 |
| bluerise | .hsync_end = 1920 + 40 + 40, | 22:42 |
| bluerise | .htotal = 1920 + 40 + 40 + 80, | 22:42 |
| bluerise | oh it really is 40 | 22:42 |
| bluerise | vnd vsync_len is 4 | 22:42 |
| mntmn | also your vsync len is 0x1c instead of 8? | 22:42 |
| mntmn | ah yeah wait | 22:42 |
| mntmn | what's the 0007 vs 001b | 22:43 |
| bluerise | but, isn't that just hback/hfront porch or so | 22:43 |
| bluerise | okokok, let's look at this | 22:44 |
| bluerise | vm->hfront_porch = dmode->hsync_start - dmode->hdisplay; | 22:44 |
| bluerise | vm->hsync_len = dmode->hsync_end - dmode->hsync_start; | 22:44 |
| bluerise | vm->hback_porch = dmode->htotal - dmode->hsync_end; | 22:44 |
| mntmn | the 0x30 is the vsync register | 22:44 |
| mntmn | 0x20 the hsync | 22:44 |
| bluerise | 40 is hfront porch then, 40 is hsync len, 80 is hback porch | 22:45 |
| bluerise | aahhhhh | 22:45 |
| bluerise | so *that* is flipped | 22:45 |
| bluerise | actually | 22:48 |
| bluerise | now the video bar looks horrible | 22:48 |
| mntmn | haha | 22:48 |
| swivel | ACTION notes someone really has to replace all these magic numbers with symbolic constants like #defines using meaningful names ;) | 22:48 |
| mntmn | swivel: well that's vendor drivers for ya... | 22:49 |
| mntmn | the one for linux is more cleaned up | 22:49 |
| bluerise | mntmn: didn't make it better, but I'm looking into it | 22:49 |
| bluerise | and now I need to play a round of OpenRA | 22:49 |
| mntmn | ok | 22:49 |
| mntmn | mmmm OpenRA, good choice | 22:49 |
| mntmn | bluerise: last question, do you get color bars if you don't enable dtg in the end? | 22:50 |
| mntmn | i mean when not doing that last | 22:50 |
| mntmn | reg32_write(priv->addr + 0x20000, 0xff005184); | 22:51 |
| mntmn | (my guess is you still get color bars because it's probably independent) | 22:51 |
| bluerise | found another typo | 22:51 |
| bluerise | th ecolour bars look crappy now btw | 22:51 |
| bluerise | with the switch of back porch and sync len | 22:52 |
| bluerise | but I found a typo in the sn65dsi86 code | 22:52 |
| mntmn | ok | 22:52 |
| bluerise | ah yes, the typo fixed the colour bars ok | 22:52 |
| bluerise | so that looks good now with colour bars | 22:53 |
| mntmn | oh! | 22:53 |
| bluerise | without it, black | 22:53 |
| bluerise | ok let me give you the updated numbers | 22:53 |
| mntmn | and if you don't turn on dtg, still color bars (i would suspect yes)? | 22:53 |
| bluerise | 0457081f 0027081f 00070003 80200077 045707f7 | 22:53 |
| mntmn | these numbers are now exactly correct | 22:54 |
| - darth-cheney (QUIT: Remote host closed the connection) (~user@135.84.167.9) | 22:58 | |
| mntmn | register 0x32e1c000 is fun, too... if you turn off bit 4 you can display only 1 frame and then stop by feeding it with bit 1... | 22:58 |
| mntmn | bit 4 makes it do a continuous job. so the scaler needs to be on. they also turn it on in the u-boot driver. | 22:59 |
| mntmn | the huge register blob with 0x1cxxx is the scaler configuration. | 22:59 |
| mntmn | funky, dcss can do 8 bit per pixel, yuv, gpu and vpu detiling, all kinds of stuff. | 23:07 |
| bluerise | 32e1c000: 00000010 | 23:11 |
| bluerise | well, I see you're looking at the u-boot code, you can compare that I guess | 23:11 |
| mntmn | yeah that's ok | 23:24 |
| mntmn | i think DCSS config is ok | 23:24 |
| mntmn | clocks are ok, the only difference, which i don't understand yet, is dsi_phy_ref | 23:25 |
| mntmn | 23760000 vs 24074075 | 23:25 |
| mntmn | both are somewhere around 24mhz though | 23:26 |
| mntmn | that's probably connected to my lower pixelclock i guess | 23:27 |
| bluerise | hm, don't think so, I think that's just set to 24M | 23:33 |
| mntmn | hm | 23:34 |
| bluerise | assigned-clocks = <&clk IMX8MQ_VIDEO_PLL1_REF_SEL>, | 23:34 |
| bluerise | <&clk IMX8MQ_VIDEO_PLL1_BYPASS>, | 23:34 |
| bluerise | <&clk IMX8MQ_CLK_DSI_PHY_REF>, | 23:34 |
| bluerise | <&clk IMX8MQ_VIDEO_PLL1>; | 23:34 |
| bluerise | assigned-clock-parents = <&clk IMX8MQ_CLK_25M>, | 23:34 |
| bluerise | <&clk IMX8MQ_VIDEO_PLL1>, | 23:34 |
| bluerise | <&clk IMX8MQ_VIDEO_PLL1_OUT>; | 23:34 |
| bluerise | assigned-clock-rates = <0>, <0>, <24000000>, <594000000>; | 23:34 |
| bluerise | and that's just the reference clock | 23:34 |
| mntmn | ok weird | 23:34 |
| bluerise | So I'd say I'm closer to 24M than you :D | 23:34 |
| mntmn | haha | 23:34 |
| mntmn | btw i didn't find anything that sets dsi_flags | 23:35 |
| mntmn | probably the defaults are ok, but just some oddity. | 23:35 |
| mntmn | ok so the nwl-dsi driver in u-boot does polling for completion (nwl_dsi_poll_for_completeion incl this typo) | 23:52 |
| mntmn | linux uses init_completion | 23:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!