| bencoh | Wizzup: gpio-keys misbehaving in OFF mode might (?) be an invalid pullup configuration issue | 10:05 |
|---|---|---|
| bencoh | assuming it uses a different pin configuration for sleep modes (some chips do) | 10:05 |
| sicelo | Wizzup: yay @wl1251. you also had made nice writeup really :-) | 10:21 |
| bencoh | Wizzup: see TRM Chapter 7.4.4 Pad Functional Multiplexing, bit OFFPULLUDENABLE | 10:22 |
| sicelo | are we going to handle CVE-2021-39685 in Leste kernels? | 10:22 |
| Wizzup | we'll pull in latest 5.15-stable or so | 10:31 |
| Wizzup | bencoh: hm, could be the same for ssi-protocol then | 10:31 |
| Wizzup | basically what I am seeing is that it wakes up every few seconds (gpio_keys), sends slider press/unpress, and then sleep again for a bit | 10:32 |
| bencoh | Wizzup: can you try devmem 0x480020de 16 ? | 10:43 |
| bencoh | I'd like to compare the result with what I see on fremantle | 10:43 |
| bencoh | (spoiler: on fremantle OFF-related bits are all 0, meaning I was wrong) | 10:44 |
| bencoh | (I get 0x4114 for the records) | 10:46 |
| Wizzup | bencoh: just to check, you have devmem on fremantle? | 10:47 |
| bencoh | Wizzup: yeah | 10:50 |
| Wizzup | bencoh: you just compiled it in scratchbox or something | 10:51 |
| Wizzup | ? | 10:51 |
| bencoh | I don't think so | 10:51 |
| bencoh | wait, where does it come from .... | 10:51 |
| Wizzup | I need to read some regs for Tony as well, which is why I am asking | 10:51 |
| bencoh | dpkg says not found | 10:51 |
| bencoh | wth | 10:52 |
| bencoh | alright lemme check my sb vm | 10:52 |
| bencoh | aaah, symlink to /bin/busybox :) | 10:53 |
| bencoh | you just need busybox-power | 10:54 |
| bencoh | (I still think you should check 0x480020de on leste btw, just to make sure) | 10:54 |
| sicelo | bencoh: i also got zeros the other day too, but then wondered if it wasn't just what Pali mentioned, that userspace isn't allowed to read them | 10:55 |
| sicelo | in fremantle, that is | 10:55 |
| Wizzup | is it sane to just apt install busybox-power ? | 10:55 |
| Wizzup | s/sane/safe/ | 10:55 |
| bencoh | sicelo: no, I get 0x4114; you just need to run it as root | 10:55 |
| sicelo | ah :-) | 10:56 |
| bencoh | sicelo: also, unpowered components may return 0s or bus error, depending on the SoC | 10:56 |
| bencoh | Wizzup: I think so | 10:56 |
| sicelo | well i was doing it with sudo (but not the addresses you're checking. i was checking the ones from tony) | 10:56 |
| Pali | sicelo: if userspace cannot read /dev/mem then process either segfault or open fails with EPERM | 10:56 |
| bencoh | (the n900 schematics are a blessing) | 10:57 |
| Wizzup | ftr | 10:58 |
| Wizzup | # devmem 0x480020de | 10:58 |
| Wizzup | Illegal instruction | 10:58 |
| Wizzup | devmem 0x48004a08 | 10:58 |
| Wizzup | 0x00000000 | 10:58 |
| Wizzup | tmlind: so 0x48004a08 seems to be 0x00000000 | 10:59 |
| bencoh | Wizzup: devmem 0x480020de 16 | 10:59 |
| bencoh | otherwise it's unaligned :) | 11:00 |
| Wizzup | oh | 11:00 |
| Wizzup | # sleep 5 ; devmem 0x480020de 16 | 11:00 |
| Wizzup | 0x4114 | 11:00 |
| bencoh | Wizzup: on leste or fremantle? | 11:00 |
| Wizzup | fremantle | 11:00 |
| Wizzup | I need to compile devmem on leste still | 11:00 |
| bencoh | ah, I was asking about leste :) | 11:00 |
| bencoh | to compile it? can't you just install it? | 11:00 |
| Wizzup | yeah, ok, but I'm still just being happy that I can do this on fremantle since Tony asked about wrt bandgap | 11:00 |
| Wizzup | bencoh: from where? | 11:00 |
| bencoh | memdump | 11:01 |
| bencoh | I think | 11:01 |
| Wizzup | memdump - utility to dump memory contents to standard output | 11:01 |
| bencoh | hmm, that's not devmem actually, but good enough I guess | 11:01 |
| Wizzup | omg, just running 'memdump' without args causes it to dump memory | 11:02 |
| bencoh | haha | 11:02 |
| bencoh | you can also try memtool if you prefer | 11:02 |
| bencoh | memtool md -w 0x480020de | 11:03 |
| Wizzup | it reads a pretty big region | 11:05 |
| Wizzup | maybe adding +0x4 makes sense? | 11:06 |
| Wizzup | # memtool md -w 0x480020de+0x4 | 11:06 |
| Wizzup | 480020de: 0114 0104 | 11:06 |
| * bencoh headscratches | 11:07 | |
| bencoh | what's the +0x4 ? | 11:07 |
| bencoh | ah, bytes | 11:08 |
| Wizzup | Memory regions can be specified in two different forms: START+SIZE | 11:08 |
| bencoh | so it would be +0x2 | 11:08 |
| Wizzup | # memtool md -w 0x480020de+0x2 | 11:08 |
| bencoh | looks like it is 0x0114 anyway | 11:08 |
| Wizzup | 480020de: 0114 | 11:08 |
| bencoh | so different from fremantle | 11:08 |
| bencoh | the missing bit is the WAKEUP_EN flag | 11:08 |
| bencoh | you could try setting it, see if it stays there even after hitting OFF mode, and see if it makes a difference, I guess | 11:09 |
| Wizzup | every time I start to think I understand how this works even a bit I get lost again | 11:10 |
| Wizzup | ok, let me see where to set thatr | 11:10 |
| Wizzup | it looks that in dts it mostly goes in pinctrl | 11:10 |
| bencoh | ah, if you want to do it properly, then yes, it goes in one of the pinmuxes | 11:11 |
| bencoh | the gpio-keys node doesn't refer to any pinctrl yet | 11:11 |
| Wizzup | what is the non-proper way to do it? | 11:11 |
| uvos | just write to the register with rwmem/devmem whatever | 11:11 |
| bencoh | yeah | 11:13 |
| Wizzup | so in omap3-n900.dts gpio_keys refers to &gpio3, &gpio4, &gpio6 | 11:13 |
| Wizzup | this pin doesn't fall in any of their regs | 11:14 |
| bencoh | the pinmux entry should look like that | 11:14 |
| bencoh | OMAP3_CORE1_IOPAD(0x20de, WAKEUP_EN | INPUT_EN | PULL_UP | MUX_MODE4) | 11:14 |
| bencoh | the gpio-keys entry for the slider is keypad_slide | 11:14 |
| bencoh | but that part is fine | 11:14 |
| bencoh | assuming gpio3 7 is indeed gpio_71, but I'm pretty sure it is, otherwise slider would never work | 11:15 |
| Wizzup | but wait, why do you assume the problem is slider only? | 11:15 |
| Wizzup | what I see is that gpio_keys wakes up and fires *all* gpio_keys events | 11:15 |
| Wizzup | not just slider, also camera button, etc | 11:15 |
| bencoh | wait, what? | 11:16 |
| Wizzup | right. | 11:16 |
| Wizzup | let me demonstrate | 11:16 |
| Wizzup | oh, this time the device just reset :) | 11:17 |
| Wizzup | https://dpaste.com/8LSHRGVT4 | 11:17 |
| Wizzup | normalle the screen keeps going on and off after a few seconds | 11:17 |
| bencoh | hm, I wonder why I assumed you were referring to slider back then | 11:17 |
| Wizzup | well I did mention the slider earlier | 11:17 |
| Wizzup | maybe that wasn't clear in the gpio keys context | 11:18 |
| Wizzup | but the slider is the most visible part because it makes mce wake up the device/screen | 11:18 |
| bencoh | ah | 11:18 |
| uvos | you can disable that with mce-lockgeneric if that makes testing idle easier | 11:19 |
| Wizzup | uvos: I mean sure but that's not really the problem here | 11:19 |
| uvos | right | 11:19 |
| uvos | but the device waking up might make testing the problem itself harder | 11:19 |
| uvos | since it dosent off again then | 11:19 |
| Wizzup | it does turn off the display as well | 11:19 |
| Wizzup | since this repeats every few seconds | 11:19 |
| uvos | ok | 11:19 |
| Wizzup | but sure just testing idle stuff I can just rmmod gpio_keys | 11:20 |
| Wizzup | but something is quite wrong there I think | 11:20 |
| uvos | no doubt | 11:20 |
| uvos | but setting the reg dosent fix it for gpio3 7? | 11:20 |
| bencoh | Wizzup: what do you get for memtool md -w 0x480020d8+0x4 on leste? | 11:21 |
| Wizzup | uvos: the device just reset | 11:21 |
| Wizzup | and they all fire at once | 11:21 |
| Wizzup | I can try in a bit for sure | 11:21 |
| Wizzup | bencoh: with off mode not turned on, and gpio keys probed I guess? | 11:21 |
| bencoh | Wizzup: for a start yes | 11:22 |
| Wizzup | ok, just a second, I need a coffee | 11:22 |
| bencoh | :) | 11:22 |
| bencoh | damn, I forgot how messy the pre-devicetree board drivers could be ... | 11:26 |
| bencoh | having a look at arch/arm/mach-omap2/board-rx51* (fremantle kernel) ... it's awful | 11:26 |
| Wizzup | bencoh: do you have a git link for it? | 11:49 |
| Wizzup | I don't know what the canonical place is | 11:49 |
| bencoh | hmm, lemme check | 11:50 |
| Wizzup | # memtool md -w 0x480020d8+0x4 | 11:51 |
| Wizzup | 480020d8: 0104 0104 .... | 11:51 |
| bencoh | I get 4104 4104 | 11:53 |
| bencoh | looks like all gpio-keys are missing the WAKEUP_EN bit | 11:53 |
| bencoh | to be honest I don't fully understand the TRM 7.4.4 chapter, nor the System Off mode subchapter | 11:54 |
| bencoh | (I only had a quick look thus far) | 11:54 |
| bencoh | but something tells me keeping the fremantle values might help | 11:55 |
| bencoh | Wizzup: https://vcs.maemo.org/git/kernel-power I think | 11:56 |
| bencoh | that's the latest kernel-power (Pali's fork of the fremantle kernel) | 11:57 |
| Wizzup | https://vcs.maemo.org/git/?p=kernel-power;a=shortlog | 11:57 |
| Wizzup | ok | 11:57 |
| bencoh | (actually someone else started the fork, but P.ali eventually became the main maintainer/contributor :)) | 12:00 |
| Wizzup | ok, so I can write the memory with memtool mw | 12:02 |
| Wizzup | so should I write to all the addresses then? | 12:05 |
| Wizzup | (for all the gpio keys) | 12:05 |
| bencoh | you could try changing only one of those first | 12:06 |
| bencoh | to see if it makes a difference | 12:06 |
| Wizzup | ok, let me boot to a more minimal system in case some other subsystem causes resets | 12:06 |
| Wizzup | hm... interesting | 12:11 |
| Wizzup | so just enabling off mode is not the problem | 12:11 |
| Wizzup | the problem starts occuring when I idle the serial devices | 12:12 |
| Wizzup | (which of course are what prevents it from entering off mode) | 12:12 |
| bencoh | ? | 12:12 |
| bencoh | "the problem" being? the gpio-keys thing, or the device resetting? | 12:12 |
| Wizzup | gpio keys | 12:12 |
| Wizzup | and they wake up 'with' the serial | 12:12 |
| bencoh | hmm ... | 12:14 |
| Wizzup | getting the reg didn't help fwiw | 12:14 |
| Wizzup | maybe the n900-pm script is too agressive in the sysfs stuff it changes perhaps | 12:14 |
| bencoh | everytime the device wakes from serial you get events in /dev/input ? | 12:14 |
| Wizzup | yes | 12:15 |
| bencoh | well, at least it should be a non-issue on production devices | 12:15 |
| bencoh | that's interesting though, and it might hint at some issue too :) | 12:15 |
| Wizzup | actually it is only three keys: | 12:16 |
| Wizzup | KEY_SCREENLOCK, KEY_CAMERA_FOCUS, KEY_CAMERA | 12:16 |
| Wizzup | so that is &gpio3 | 12:17 |
| Wizzup | huh, no, both | 12:17 |
| Wizzup | (3 and 4) | 12:17 |
| Wizzup | unrelated but debugging these resets is incredibly hard because to hit them we have to detach the kernel console from serial | 12:18 |
| Wizzup | so the crucial messages are basically always lost | 12:18 |
| bencoh | you can always check dmesg afterwards | 12:19 |
| Wizzup | that doesn't help when it has reset :) | 12:19 |
| bencoh | ? | 12:19 |
| bencoh | ah, *reset* | 12:19 |
| Wizzup | yeah | 12:19 |
| bencoh | nevermind | 12:19 |
| Wizzup | like, hard device resets | 12:19 |
| bencoh | don't we have that ... pmem thing (was it pmem?) on n900? | 12:20 |
| Wizzup | ramoops/pstore alike? | 12:23 |
| Wizzup | bencoh: btw I got it wrong, it also happens sometimes when I don't type in serial | 12:24 |
| Wizzup | sorry, finding this stuff out as I go along :) | 12:24 |
| Wizzup | it could be some other wakeup that causes it to leave OFF mode for a bit though | 12:24 |
| bencoh | could be ... | 12:26 |
| bencoh | I guess we should really read those OFF mode chapters ... | 12:26 |
| Wizzup | mhm | 12:29 |
| Wizzup | rmmod gpio_keys also causes device not to idle again | 12:29 |
| Wizzup | probing it again helps | 12:30 |
| bencoh | that's ... interesting | 13:04 |
| Wizzup | probably some things aren't deinitialised properly or something | 13:05 |
| Wizzup | freemangordon: hm I got this for xorgproto: | 18:09 |
| Wizzup | Making all in bigreqsproto | 18:09 |
| Wizzup | make[3]: Entering directory '/mnt/merlijn/maemo-leste/xorgproto/build/specs/bigreqsproto' | 18:09 |
| Wizzup | make[3]: *** No rule to make target 'bigreq.xml', needed by 'all-am'. Stop. | 18:09 |
| Wizzup | there are nothing but makefiles hm.. | 18:13 |
| Wizzup | must be one of the weird debian things again | 18:14 |
| Wizzup | truly breaks the brain | 18:17 |
| Wizzup | freemangordon: I guess you also got libxi ? | 18:21 |
| Wizzup | freemangordon: really wonder how you did this | 18:38 |
| Wizzup | I had to pull in xorgproto, libxi, and now I need this weird libxcvt which wants debhelper-compat = 13 | 18:38 |
| Wizzup | which we don't have | 18:39 |
| Wizzup | maybe this is a xwayland only dep? | 18:40 |
| Wizzup | the debian/ I have already drops xwayland, so I'm not sure waht is up | 18:40 |
| Wizzup | I downloaded it from debian unstable and now it built at least | 18:50 |
| Wizzup | lol, great ... I built everything for armhf | 18:55 |
| Wizzup | and pine64 is arm64 of course | 18:55 |
| Wizzup | *flips table* | 18:56 |
| freemangordon | sorry, being busy | 19:16 |
| freemangordon | and sill am | 19:16 |
| freemangordon | *still | 19:16 |
| Wizzup | I figured it out I think | 19:17 |
| Wizzup | although I don't know how we will do this in CI | 19:17 |
| uvos | updating x properly is a lot of work since the api levels also chainged so xf86-* modules also must be rebuilt | 19:31 |
| Wizzup | let's see | 19:36 |
| uvos | https://gitlab.freedesktop.org/xorg/xserver/-/commit/7759743c6387f72faa9eb8602ea3f2777c0e0d17 | 19:37 |
| uvos | https://gitlab.freedesktop.org/xorg/xserver/-/commit/0886254f96f40e59193ccbb0e3acbd5ae92dbaa3 | 19:37 |
| Wizzup | not a problem though | 19:38 |
| Wizzup | also the xrandr stuff is np for modesetting | 19:38 |
| uvos | it bumps the abi version | 19:38 |
| uvos | so you have to rebuild video-* plugins | 19:39 |
| uvos | except modesetting ofc | 19:39 |
| Wizzup | uvos: yeah we only use modesetting on pp | 19:41 |
| uvos | well if you want to update x in tge repo you have to rebuild all plugins | 19:42 |
| Wizzup | sure | 19:42 |
| Wizzup | if it doesn't make glamor better, I won't | 19:42 |
| Wizzup | uvos: looks like the same problems | 20:16 |
| Wizzup | maybe it's time to force the gles/egl path | 20:16 |
| Wizzup | actually it does feel better | 20:29 |
| Wizzup | it happens only once on boot now it looks like | 20:36 |
| Wizzup | uvos: does pp need a change to rotate h-d somehow? monitor-sensor picks it up | 20:38 |
| Wizzup | but it doesn't rotate | 20:38 |
| Wizzup | iio-accelerometer is loaded I think | 20:39 |
| Wizzup | matrix is 90 degrees off | 20:44 |
| Wizzup | hm monitor-sensor is correct | 20:46 |
| Wizzup | it's really nice and fast in portrait mode :) | 20:49 |
| uvos | Wizzup: monitor sensor should have Normal as landscape | 21:39 |
| uvos | and left up as protrait | 21:39 |
| Wizzup | uvos: hm, then it is wrong | 21:58 |
| Wizzup | uvos: so 'normal' is currently reported when I hold it in portrait | 21:59 |
| uvos | right | 21:59 |
| uvos | so parazyd did this | 21:59 |
| Wizzup | and 'left-up' for landscape | 22:00 |
| uvos | it worked at some point, maybe the kernel changed | 22:00 |
| uvos | https://github.com/maemo-leste/leste-config/blob/master/leste-config-pinephone/lib/udev/rules.d/50-iio-sensors.rules.leste | 22:00 |
| Wizzup | SUBSYSTEM=="iio", ENV{OF_NAME}=="mpu6050", ENV{ACCEL_MOUNT_MATRIX}="1, 0, 0; 0, 1, 0; 0, 0, 1" | 22:01 |
| Wizzup | this doesn't seem like it is touchscreen matrix | 22:01 |
| Wizzup | comment might be wrong there | 22:01 |
| Wizzup | right? | 22:01 |
| uvos | oh yeah | 22:01 |
| uvos | the comment is wrong | 22:02 |
| Wizzup | mpu6050 is accelerometer | 22:02 |
| Wizzup | OF_FULLNAME=/soc/i2c@1c2b000/accelerometer@68 | 22:02 |
| Wizzup | OF_COMPATIBLE_0=invensense,mpu6050 | 22:02 |
| Wizzup | # cat in_accel_mount_matrix | 22:03 |
| Wizzup | 0, 1, 0; -1, 0, 0; 0, 0, -1 | 22:03 |
| Wizzup | hm, it sure has a lot of matrices | 22:03 |
| Wizzup | uvos: I don't see any changes in leste-config recently | 22:07 |
| uvos | so in_accel_mount_matrix comes from kernel | 22:07 |
| uvos | this is wrong (for us) we dont want iio-s-p to use it | 22:07 |
| uvos | so we override it with the udev rule | 22:08 |
| uvos | now the rule is not applieing or the axies changed in the driver (unlikely) | 22:08 |
| uvos | so plase checkout the udev entry | 22:08 |
| uvos | so is the matrix applied to the right device? | 22:16 |
| uvos | udevadm info `readlink -f /sys/bus/iio/devices/iio\:device3` | 22:17 |
| uvos | replace device3 with whatever is the acell on pp ofc | 22:17 |
| Wizzup | I think it might not be yeah | 22:20 |
| Wizzup | https://dpaste.com/BES85Y4AZ | 22:21 |
| Wizzup | E: OF_NAME=accelerometer | 22:22 |
| Wizzup | so it doesn't match | 22:22 |
| uvos | right so someone changed dts | 22:23 |
| Wizzup | ok I have a fix | 22:23 |
| Wizzup | will make sure it's in sync with kernel | 22:23 |
| Wizzup | btw it's really smooth in portrait | 22:23 |
| uvos | to bad hildon is ergonomically terrible in protrait | 22:25 |
| Wizzup | so new X seems better | 22:40 |
| Wizzup | I only see the keyboard now being draw correctly once | 22:40 |
| Wizzup | per orientation | 22:40 |
| Wizzup | on pp | 22:40 |
| uvos | with gl or gles | 22:42 |
| uvos | ? | 22:42 |
| Wizzup | gl | 22:44 |
| Wizzup | I didn't try the gles part yet | 22:44 |
| Wizzup | that's next | 22:45 |
| Wizzup | hmm let me try another build tomorrow | 23:02 |
| Wizzup | lol I was building 1.20 :-) | 23:03 |
| Wizzup | man | 23:03 |
| Wizzup | I guess that's good news | 23:04 |
| Wizzup | the dpi is messed up | 23:44 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!