| freemangordon | ok, I have a fix for the so-called "HildonPannableArea bug", but I still don't know why it works | 09:51 |
|---|---|---|
| freemangordon | the bug is actually in GtkRange or in gdk_event_request_motions() | 09:52 |
| freemangordon | uvos: it is 7871e095605332ce1cfb15e19a06f36b05604d0b that breaks it | 10:02 |
| freemangordon | ok, this is the clue: | 10:11 |
| freemangordon | (gdb) p range->event_window | 10:11 |
| freemangordon | $8 = 0x55555577aa20 [GdkWindow] | 10:11 |
| freemangordon | (gdb) p event->window | 10:11 |
| freemangordon | $9 = 0x55555577a5a0 [GdkWindow] | 10:11 |
| freemangordon | uvos: I think GtkRange is broken even without hildon, but don;t have a way to test it | 12:07 |
| Wizzup | good find | 12:45 |
| freemangordon | Wizzup: do you know how to build gtk or I shall ping parazyd? | 12:47 |
| freemangordon | WTF? why my gtk tree differs from leset? | 12:49 |
| freemangordon | *leste | 12:49 |
| Wizzup | freemangordon: do you mean on the ci? | 12:50 |
| Wizzup | I can help you with it | 12:50 |
| freemangordon | yes | 12:50 |
| freemangordon | but hold on till I find why I cannot push | 12:50 |
| freemangordon | ah, I have to force-push | 12:51 |
| Wizzup | did you check the changes that you forcep ushed to | 12:53 |
| freemangordon | yeah | 12:54 |
| Wizzup | ok | 12:54 |
| freemangordon | it is one patch only I pushed few days ago (GtkRange one) I updated today | 12:54 |
| freemangordon | with the fix | 12:54 |
| freemangordon | maybe I should have split that to 2, but is too late already :) | 12:55 |
| Wizzup | git branch is it in? | 12:57 |
| Wizzup | what branch | 12:57 |
| freemangordon | maemo/beowulf-devel | 12:57 |
| freemangordon | Wizzup: it is ready | 12:58 |
| freemangordon | I guess I shall only build it, as the changes are in debian/patches dir only | 12:58 |
| freemangordon | no need to tag or something, no? | 12:58 |
| freemangordon | Wizzup: hmm, what about changelog? | 12:59 |
| Wizzup | freemangordon: better to do changelog | 13:01 |
| Wizzup | maybe just go for 2:2.24.32-4 | 13:02 |
| freemangordon | not sure, that's why better wait for parazyd :) | 13:03 |
| Wizzup | no need to wait | 13:03 |
| Wizzup | I know you can do this np | 13:03 |
| freemangordon | Wizzup: look at the changelog | 13:03 |
| Wizzup | what about it? | 13:03 |
| Wizzup | do you want me to do it? | 13:03 |
| freemangordon | we have gtk+2.0 (2:2.24.32-3) version twice | 13:04 |
| freemangordon | and that's on purpose | 13:04 |
| Wizzup | no, we don't | 13:04 |
| Wizzup | we have epoch | 13:04 |
| Wizzup | or whatever the thing at the start is | 13:04 |
| freemangordon | oh, right | 13:04 |
| Wizzup | pretty sure the -3 and the end can safely be increased to -4 with no affects on anything else | 13:04 |
| Wizzup | effects* even | 13:05 |
| freemangordon | not sure, becaue this is upstream version | 13:05 |
| freemangordon | not ours | 13:05 |
| freemangordon | upstream == debian | 13:05 |
| freemangordon | so, I think it is better to add entries to the current last changelog entry and rebuild | 13:05 |
| freemangordon | the new version will become 2:2.24.32-3+2m7.10 or something | 13:06 |
| freemangordon | current is 2:2.24.32-3+2m7.9 | 13:06 |
| freemangordon | Wizzup: please do it as you think is right | 13:09 |
| Wizzup | ok | 13:12 |
| Wizzup | freemangordon: fine as well, we'll still add a version in the repo I think | 13:12 |
| Wizzup | freemangordon: then just issue a buiild | 13:12 |
| freemangordon | Wizzup: are you going to do it? | 13:23 |
| freemangordon | ah, you already did :) | 13:24 |
| freemangordon | hmm, you didn;t do changelog it seems | 13:25 |
| freemangordon | Wizzup: how often is -devel pulled in -stable? | 13:29 |
| Wizzup | freemangordon: whenever we decide to, and it can be done perpackage | 13:32 |
| Wizzup | it's basically a rebuild anyway | 13:32 |
| Wizzup | freemangordon: yeah I'd need to force push changelog, can do that though | 13:32 |
| freemangordon | why force-push? | 13:32 |
| Wizzup | oh, right, doesn't need to be | 13:33 |
| freemangordon | just add some lines to the current | 13:33 |
| Wizzup | want me to do it? | 13:33 |
| freemangordon | no, I will | 13:33 |
| freemangordon | do we have an issure for that GtkRange bug? | 13:36 |
| freemangordon | *issue | 13:36 |
| freemangordon | done | 13:37 |
| Wizzup | freemangordon: let me check | 13:38 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/582 | 13:39 |
| freemangordon | ok | 13:39 |
| freemangordon | will close it | 13:39 |
| lel | freemangordon closed an issue: https://github.com/maemo-leste/bugtracker/issues/582 (Gtk2 sliders are broken) | 13:40 |
| Wizzup | btw, what do you think we should do wrt bandgap | 14:01 |
| freemangordon | did you try tmlind's patch? | 14:13 |
| Wizzup | freemangordon: I will do that now, but it doesn't relate to the oops and I've heard folks here say that bandgap on the n900 is just broken | 14:24 |
| Wizzup | but I guess it would be good to see if it idles even if we don't want to use it | 14:24 |
| freemangordon | Wizzup: bandgap being broken in fremantle kernel doesn;t mean the driver shall oops, no? | 14:28 |
| freemangordon | and "broken" means you can;t rely on it to measure battery temp | 14:29 |
| Wizzup | freemangordon: sure, but what I mean is that iiuc it's not even active on fremantle | 14:31 |
| Wizzup | freemangordon: we read the bandgap register and it wasn't active | 14:31 |
| freemangordon | which kernel? | 14:32 |
| freemangordon | KP or omap1? | 14:33 |
| Wizzup | 2.6.28.10-sssu3 | 14:34 |
| Wizzup | cssu* | 14:34 |
| freemangordon | IIRC, it is not active because: 1. it is not kept active continuously and 2. noone reads it | 14:34 |
| freemangordon | hmm, I don;t remember if bandgap driver is active in cssu kernel | 14:34 |
| Wizzup | there was some talk about it just a few days ago | 14:35 |
| Wizzup | I just wanted to check what we're thinking of doing, mostly | 14:35 |
| bencoh | freemangordon: I can probably check, if you know how to | 14:35 |
| bencoh | I have a kp53 at hand | 14:35 |
| freemangordon | me too | 14:35 |
| Wizzup | n900 is stable on 5.15 for me now without off mode enabled | 14:35 |
| freemangordon | devmem I guess | 14:35 |
| bencoh | ah :) | 14:35 |
| Wizzup | (the only bug is X11 segfaults) | 14:35 |
| Wizzup | off mode enabled though, there's more to fix for sure | 14:35 |
| freemangordon | Wizzup: I think it is good to have bandgap on n900, even if we don;t use it | 14:36 |
| Wizzup | why? | 14:36 |
| freemangordon | the oops we see most-probably is not bandgap's driver fault | 14:36 |
| bencoh | oh btw, regarding powertop and measuring wakeup events ... you should use powertop with html output | 14:36 |
| Wizzup | bencoh: what does that add? | 14:36 |
| freemangordon | also, it is possible that back then (fremantle) bandgap driver was buggy thus nokia gave up on it | 14:37 |
| freemangordon | they were saying thumb2 and 720p are impossible too ;) | 14:37 |
| bencoh | Wizzup: I don't know understand how/when powertop samples events when using the interactive view | 14:37 |
| freemangordon | Wizzup: do you have a link to the discussion? | 14:37 |
| Wizzup | no, it was like in the last few days | 14:38 |
| Wizzup | maybe just search for pali since he was active then | 14:38 |
| Wizzup | (in the logs I mean) | 14:38 |
| bencoh | (yeah, thumb2, usb host mode, 720p, overclocking, ...) | 14:38 |
| freemangordon | Wizzup: hmm, I took a part in sam discussion | 14:39 |
| freemangordon | *some | 14:39 |
| freemangordon | did I miss something important? | 14:39 |
| freemangordon | Wizzup: re x11 segfault - hopefully starting tomorrow I will have time to do the needed omapdmr patch | 14:39 |
| freemangordon | it shouldn't take me more than 3-4 days | 14:40 |
| freemangordon | I hope | 14:40 |
| louipc | wuzzzup | 14:41 |
| freemangordon | bencoh: do you know if bandgap is visible in sysfs? | 14:43 |
| freemangordon | on KP that is | 14:43 |
| bencoh | no idea, got a name to look for? | 14:43 |
| freemangordon | me neither, going to try to find it | 14:44 |
| bencoh | hm, no /sys/class/thermal | 14:44 |
| bencoh | that's a good start | 14:44 |
| Wizzup | freemangordon: ok | 14:44 |
| bencoh | (year 2009 is waiting on the other line ...) | 14:44 |
| freemangordon | :) | 14:44 |
| Wizzup | louipc: hi | 14:44 |
| louipc | Wizzup: hehe nice name | 14:45 |
| Wizzup | had it for 20 years by now I think | 14:45 |
| Wizzup | freemangordon: there is also an ocassional segfault on the d4 for me (once every couple days, shall I keep gdb attached to get you a bt) | 14:46 |
| louipc | wouldnt it be cool to be able to run random programs from dubious sources and not have it affect your system at all security wise? | 14:46 |
| Wizzup | is this some flatpak plug? :p | 14:46 |
| louipc | even programs with unknown exploits | 14:46 |
| louipc | no im just curious | 14:47 |
| bencoh | freemangordon: /sys/class/power_supply/rx51-battery/temp ? | 14:47 |
| louipc | if this would be like an 'ultimate' perhaps unattainable goal security-wise | 14:47 |
| Wizzup | louipc: I mean there are a lot of things you can do but it'll likely never be entirely 100% | 14:48 |
| freemangordon | bencoh: no | 14:48 |
| louipc | as far as i know flatpak is fundamentally flawed | 14:48 |
| freemangordon | /sys/class/hwmon | 14:48 |
| louipc | Wizzup: yea its a constant cat-mouse game | 14:48 |
| freemangordon | Wizzup: bandgap seems to be enabled on KP | 14:49 |
| Wizzup | did you use the same command to read it? | 14:49 |
| louipc | but i'm thinking would this kinda be something that people would like to move towards in the pursuit of security | 14:49 |
| freemangordon | it is exported in sysfs | 14:49 |
| Wizzup | freemangordon: ok, but is it active and in use | 14:49 |
| Wizzup | iirc I used devmem to read the reg and it was 0000 | 14:50 |
| louipc | lemme know if im goin offtopic | 14:50 |
| bencoh | freemangordon: I didn't see much in hwmon | 14:50 |
| louipc | im mainly here because there was chat about debian vs android security model | 14:50 |
| Wizzup | louipc: not so much, it's just that we probably don't have much to contribute, there's the full-virt approach and there's load of different rbacs and namespaces work, but a kernel exploit will still just kill that | 14:50 |
| bencoh | louipc: do you mean, from a pure software point of you? | 14:51 |
| freemangordon | /sys/devices/platform/omap34xx_temp | 14:51 |
| Wizzup | louipc: if it was up to me the first things we'd integrate would be some rbac (apparmor probably) and later look at perhaps using containers (just namespaces) for some things | 14:51 |
| louipc | well android is increasingly integrating hardware as part of the security model too | 14:51 |
| Wizzup | freemangordon: want me to check on non-kp? | 14:51 |
| freemangordon | /sys/devices/platform/omap34xx_temp # cat temp1_input | 14:51 |
| freemangordon | 20 | 14:51 |
| louipc | with titan m chip, and such | 14:51 |
| Wizzup | freemangordon: and you're sure this is bandgap btw? | 14:51 |
| freemangordon | Wizzup: I guess it gets enabled only when you read it | 14:51 |
| bencoh | freemangordon: nice catch. 20 here as well | 14:51 |
| freemangordon | omap34xx_temp? | 14:51 |
| bencoh | yeah | 14:52 |
| freemangordon | sure it is | 14:52 |
| louipc | Wizzup: cool. good to hear that its a consideration | 14:52 |
| bencoh | but if we both read 20 ... sounds bogus :> | 14:52 |
| Wizzup | freemangordon: that is also present on my kernel | 14:52 |
| Wizzup | it reports 13 degrees | 14:52 |
| louipc | but i understand the limited dev resources | 14:52 |
| buZz | louipc: containers/namespaces is literally what i suggested, apt install firejail | 14:52 |
| Wizzup | which is very inaccurate fwiw | 14:52 |
| Wizzup | louipc: yeah we want the phone aspect working well first :) | 14:53 |
| freemangordon | lemme check int the KP source what omap34xx_temp | 14:53 |
| freemangordon | is | 14:53 |
| louipc | buZz: right. its not well integrated tho. and firejail has its flaws too | 14:53 |
| louipc | android sandboxing is not an 'addon' | 14:53 |
| louipc | its part of the system inherently | 14:53 |
| buZz | android sandboxing has flaws too | 14:53 |
| buZz | you just dont hear about them as often as they're often quickly safeguarded into a TLA's arsenal | 14:54 |
| buZz | louipc: its literally a kernel feature | 14:54 |
| Wizzup | firejail looks interesting | 14:54 |
| louipc | as a 1st class feature they get get flaws will get dwindled down much faster | 14:54 |
| Wizzup | buZz: want to lead the efforts to integrating this and apparmor in leste? ;) | 14:54 |
| buZz | gladly not :D | 14:54 |
| dsc_ | louipc: hi :) | 14:55 |
| louipc | https://madaidans-insecurities.github.io/linux.html#sandboxing | 14:55 |
| Wizzup | freemangordon: I can confirm that the gtk fix works | 14:55 |
| louipc | consider this | 14:55 |
| Wizzup | freemangordon: thanks | 14:55 |
| louipc | dsc_: wuddup. | 14:55 |
| freemangordon | :) | 14:55 |
| louipc | dsc_: u maemo dev? :D | 14:55 |
| dsc_ | I think so? | 14:56 |
| dsc_ | :P | 14:56 |
| louipc | sweet | 14:56 |
| buZz | lol @ that website | 14:56 |
| buZz | > You can contact me on various platforms, including Reddit, Matrix and Telegram. | 14:56 |
| louipc | anyway thanks for your perspective Wizzup.. and buZz too ;) | 14:56 |
| buZz | https://madaidans-insecurities.github.io/messengers.html | 14:56 |
| buZz | lol | 14:56 |
| Wizzup | louipc: if it was up to me I'd want to use the grsec rbac but that's not available anymore unfortunately | 14:57 |
| dsc_ | louipc: I'm working on the `conversations` app (uses telepathy as backend) for SMS, IRC, XMPP, Telegram | 14:57 |
| bencoh | (RIP opensource grsec </3 :'( ) | 14:57 |
| louipc | theres the kernel self protection project | 14:58 |
| bencoh | compared to grsec, it's some kind of joke :( | 14:58 |
| louipc | hehe ye | 14:58 |
| freemangordon | hmm, I don;t have kp sources around anymore?!? The fuck, I am one of its maintainers :( | 14:58 |
| bencoh | freemangordon: :D | 14:58 |
| freemangordon | :) | 14:58 |
| louipc | also https://github.com/anthraxx/linux-hardened | 14:58 |
| bencoh | freemangordon: https://vcs.maemo.org/git/kernel-power | 14:58 |
| freemangordon | yeah | 14:58 |
| bencoh | louipc: that thing is no longer up to date | 14:58 |
| bencoh | well, I think he stopped updating it at least | 14:59 |
| louipc | bencoh: just select the correct branch | 14:59 |
| bencoh | ah, nevermind | 14:59 |
| louipc | https://github.com/anthraxx/linux-hardened/tree/5.15 | 14:59 |
| bencoh | yeah | 14:59 |
| bencoh | they only dropped the grsec porting effort I guess then | 15:00 |
| louipc | dsc_: nioce mang | 15:00 |
| louipc | grsec ppl are a bit nasty i hear | 15:00 |
| Wizzup | oh, didn't know folks still maintain it | 15:00 |
| Wizzup | that is off topic and no they're not | 15:00 |
| louipc | ok sorry :p | 15:00 |
| bencoh | :) | 15:00 |
| Wizzup | also just my opinion, but yeah | 15:01 |
| freemangordon | hmm, I forgot how to clone from vce.maemo.org :( | 15:01 |
| freemangordon | *vcs | 15:01 |
| bencoh | freemangordon: just clone the address I gave you iirc | 15:01 |
| bencoh | if you just want to fetch | 15:02 |
| freemangordon | yueah, will try | 15:02 |
| bencoh | watch out for the debian patches there | 15:02 |
| bencoh | (I freaking hate that thing) | 15:02 |
| freemangordon | sure, patches must be applied | 15:02 |
| freemangordon | ugh, I need apt-get source actually | 15:04 |
| louipc | im running linux-hardened everyday no probs | 15:04 |
| bencoh | freemangordon: let's say it's easier yeah | 15:05 |
| bencoh | not mandatory though | 15:05 |
| freemangordon | it is, as I need .orig source anyway | 15:05 |
| bencoh | ? | 15:06 |
| freemangordon | however, downloading | 15:06 |
| freemangordon | on vcs there is only /debian | 15:06 |
| bencoh | hmm, lemme check, I might be wrong | 15:06 |
| bencoh | right | 15:07 |
| freemangordon | source downloaded and patches applied, lets see | 15:08 |
| freemangordon | to me this is bandgap driver https://pastebin.com/QDhZGrmc | 15:11 |
| freemangordon | Wizzup: IIUC reading 0x48002524 should return 0000, unless we are in A/d conversion cycle | 15:19 |
| freemangordon | hmm, actually it should contain the last measurement in the last 6 bits | 15:22 |
| freemangordon | Wizzup: so, if you disable bandgap in CONFIG, device enters OFF mode with no issues? | 15:23 |
| Wizzup | freemangordon: so | 15:24 |
| Wizzup | I do not know the relation between bandgap and CONFIG_OMAP3_THERMAL | 15:25 |
| Wizzup | first of all OMAP3_THERMAL was causing it to basically never enter OFF mode | 15:25 |
| Wizzup | secondly I have to disable cpu_thermal and bandgap in dts to not make the device reset in OFF mode with (for example) mmc access | 15:25 |
| Wizzup | I do not know if these separate problems interact | 15:25 |
| * bencoh headscratches | 15:25 | |
| Wizzup | I do know that afaik we were seeing the oopses/resets also with OMAP3_THERMAL enablec | 15:26 |
| Wizzup | (and also with it disabled) | 15:27 |
| Wizzup | freemangordon: so 'with no issues' is vague: yes it enters off mode, but there are issues until we also disable cpu_thermal and bandgap in dts | 15:30 |
| Wizzup | with those gone, the device idles stable with no modules loaded (others can interact) | 15:30 |
| freemangordon | CONFIG_OMAP3_THERMAL should be bandgap driver | 15:31 |
| freemangordon | we may have oopses because bandgap driver has fclk | 15:31 |
| freemangordon | fclk being disabled when CONTROL.CONTROL_TEMP_SENSOR is being accesses might cause oops we see | 15:32 |
| freemangordon | also, it can generate TSHUT signal for thermal shutdown | 15:33 |
| freemangordon | that's gpio 127, iiuc | 15:34 |
| freemangordon | there is an interesting note on p. 3341 in regards to TSHUT generating an interrupt | 15:35 |
| Wizzup | freemangordon: ok @ it being bandgap | 16:15 |
| freemangordon | Wizzup: shall I first look at that issue before omapdrm? | 17:02 |
| freemangordon | this should be pretty easy to identify | 17:02 |
| bencoh | I'm about to say something stupid (maybe), but err ... afaiu, no code can run while in OFF mode | 17:05 |
| bencoh | ah, nevermind, it's non-relevant | 17:06 |
| freemangordon | sure, but IIRC there comes an interrupt while we are in OFF mode | 17:06 |
| bencoh | and? | 17:06 |
| freemangordon | l3_app_irq | 17:06 |
| bencoh | once you try to read a register, you're already not in OFF mode | 17:06 |
| bencoh | meaning that if some clock is missing, it should be enabled | 17:07 |
| bencoh | (clk_enable(), whatever) | 17:07 |
| freemangordon | but, if clocks of that particular IP is not running you get oops | 17:07 |
| freemangordon | yes, exactly | 17:07 |
| bencoh | (or some restore sequence in the idle exit code) | 17:07 |
| bencoh | so you mean entering OFF mode disables that specific clock ? | 17:07 |
| bencoh | and it is never restored? | 17:07 |
| freemangordon | could be | 17:08 |
| bencoh | :) | 17:08 |
| freemangordon | because the context seems to be saved/restored | 17:08 |
| freemangordon | https://elixir.free-electrons.com/linux/v5.15.10/source/arch/arm/mach-omap2/control.c#L520 | 17:08 |
| bencoh | iiuc part of the context is saved/restored by hardware, but I don't know how much of it, btw | 17:08 |
| bencoh | OMAP343X_CONTROL_TEMP_SENSOR interesting | 17:09 |
| freemangordon | me neither, but now I am looking at thermal driver, to see how is power/clocks controlled | 17:09 |
| freemangordon | yes, this is 0x48002524 | 17:10 |
| bencoh | no I mean, interesting that it is saved/restored as well | 17:10 |
| freemangordon | sure, why not? | 17:10 |
| freemangordon | why do you think it should not be saved/restored? | 17:10 |
| bencoh | oh, I just didn't expect it, that's all. but if it's flushed during idle, it definitely should :) | 17:12 |
| bencoh | hm, arm_pm_idle() is the default arm idle handler right? | 17:13 |
| freemangordon | no idea | 17:14 |
| bencoh | looks like it is | 17:14 |
| Wizzup | freemangordon: I'd prefer the omapdrm stuff tbh, we have more off mode stuyff to do anyway | 17:15 |
| Wizzup | but whatever you want to work on :p | 17:15 |
| bencoh | unrelated, but has the latest droid4 kernel hit -devel? | 17:16 |
| Wizzup | yeah | 17:16 |
| bencoh | can I install only kernel from -devel, or is something expected to break? | 17:16 |
| Wizzup | that will break | 17:17 |
| bencoh | alright | 17:17 |
| Wizzup | why would you only get kernel? | 17:17 |
| bencoh | to toy with powersaving | 17:17 |
| Wizzup | you would miss out on the important bits: xf86-video-omap and new sgx userspace | 17:17 |
| Wizzup | I use -devel daily and it's stable imho | 17:17 |
| bencoh | oh | 17:17 |
| bencoh | well, maybe I'll just move to -devel then | 17:18 |
| Wizzup | hm.... I need to triple check if new mesa is in -devel | 17:18 |
| Wizzup | just a second | 17:18 |
| freemangordon | bencoh: could you have a look in TRM and tell me if you understand the difference between CONTCONV = 1 and CONTCONV = 0 | 17:18 |
| bencoh | I still need to find out what's wrong with usb, so using this device for serious dev stuff is kind of a pain :( | 17:18 |
| bencoh | freemangordon: lemme check | 17:18 |
| bencoh | freemangordon: omap3 right? | 17:18 |
| freemangordon | 7.4.6.2.1 that is | 17:18 |
| freemangordon | yes | 17:19 |
| Wizzup | bencoh: maybe just add -experimental and not -devel | 17:19 |
| bencoh | oh, I dont have the omap3 TRM on that host, fun | 17:19 |
| Wizzup | sounds more dangerious but it isn't really | 17:19 |
| bencoh | Wizzup: :D | 17:20 |
| Wizzup | btw, this would be for droid4 pm stuff right, not n900? | 17:20 |
| freemangordon | ah, it seems you should not assert SoC to start another a/d cycle | 17:21 |
| freemangordon | Wizzup: BTW, do you still see "eocz timed out waiting high" ? | 17:23 |
| bencoh | freemangordon: basically with CONTCONV==1 ADC keeps converting and writing to CONTROL_TEMP_SENSOR | 17:25 |
| freemangordon | yeah | 17:25 |
| freemangordon | I wonder how do you stop that :) | 17:25 |
| freemangordon | anyway | 17:25 |
| bencoh | probably by clearing CONTCONV | 17:25 |
| freemangordon | mhm | 17:26 |
| Wizzup | freemangordon: oh, uh, when should I check for this exactly (what enabled), and do you mean on n900? | 17:26 |
| bencoh | I'm not super happy with lacking Samsung/Exynos documentations, but heck, TI/OMAP documentation is unreadable | 17:26 |
| bencoh | I get this impression every single time I open one of those TRMs ... | 17:27 |
| freemangordon | Wizzup: in dmesg | 17:27 |
| bencoh | their SoCs are a mess :( | 17:27 |
| freemangordon | we were seeing that on d4 iirc | 17:27 |
| freemangordon | do you see that on n900? | 17:27 |
| freemangordon | Wizzup: also, it seems tshut gpio is not defined for omap3 | 17:28 |
| freemangordon | in dts that is | 17:28 |
| freemangordon | tmlind: ping | 17:29 |
| sicelo | Wizzup: xf86-video-omap ... what's the correct package name? pvr-omap4-xf86? or xserver-xorg-video-omap? | 17:29 |
| bencoh | CONTROL_TEMP_SENSOR returns 0x0 on kp53 here btw, is that expected? | 17:29 |
| freemangordon | no idea | 17:29 |
| freemangordon | but driver seems to work | 17:30 |
| bencoh | ah, now it shows 0x2e | 17:31 |
| bencoh | (I devmem'ed it in a loop and cat'ed the temp1_input sysfs at the same time) | 17:31 |
| freemangordon | mhm | 17:32 |
| freemangordon | makes sense | 17:32 |
| bencoh | 0x2E != 20, but whatever | 17:32 |
| freemangordon | oh, no | 17:32 |
| bencoh | no idea what they do there | 17:32 |
| freemangordon | this is adc reading | 17:32 |
| bencoh | it's reprocessed? | 17:32 |
| freemangordon | there is a table, look in the TRM | 17:32 |
| bencoh | ah :) | 17:32 |
| bencoh | oh right | 17:32 |
| bencoh | yay, 46 == 19.4 | 17:33 |
| Wizzup | sicelo: look at git repo of xf86-video-omap debian/control | 17:33 |
| sicelo | thanks. will do | 17:33 |
| bencoh | (ie 0x2E -> 19.4) | 17:33 |
| bencoh | looks like it works then | 17:33 |
| freemangordon | try to find omap34xx_adc_to_temp over the inet | 17:34 |
| freemangordon | this is what is used in KP | 17:34 |
| bencoh | I'll check in my kp tree | 17:34 |
| freemangordon | umm | 17:34 |
| freemangordon | in upstream, sorry :) | 17:34 |
| bencoh | ah | 17:34 |
| freemangordon | in kp it is adc_to_temp | 17:35 |
| bencoh | yeah there is a nice LUT | 17:35 |
| freemangordon | mhm | 17:35 |
| freemangordon | hmm: | 17:37 |
| freemangordon | .bgap_dtemp_mask = 0x7f, | 17:37 |
| freemangordon | this is rather 3f | 17:38 |
| freemangordon | this looks wrong to me https://elixir.free-electrons.com/linux/v5.15.10/source/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c#L33 | 17:39 |
| bencoh | I suppose core_l4_clkdm is the default clock domain? | 17:39 |
| sicelo | Wizzup: not to derail convo - but looks like there's some unexpected dependency issues with xserver-xorg-video-omap (which comes from xf86-video-omap) ... installing it forces removal of sgx-um-ti443x and installs ti343x instead. anyway, maybe something for later. i'm more interested in this bandgap stuff :-) | 17:39 |
| bencoh | freemangordon: yeah it should be 0x3f | 17:40 |
| Wizzup | sicelo: I think that depends on the -meta file | 17:40 |
| freemangordon | https://elixir.free-electrons.com/linux/v5.15.10/source/drivers/thermal/ti-soc-thermal/ti-bandgap.c#L181 | 17:40 |
| Wizzup | if you are asking for n900, I didn't fix those yet | 17:40 |
| sicelo | i'm on d4. that's why i find it odd | 17:40 |
| Wizzup | for droid4 it should work with dist-upgrade and -experimental | 17:40 |
| freemangordon | and I guess this leads to wrong temp being calculated | 17:40 |
| * bencoh nods | 17:40 | |
| freemangordon | not only that, but this could potentially lead to writing to EOCZ, which is RO bit | 17:41 |
| bencoh | freemangordon: although I'm not sure EOCZ is high when they try to read it | 17:42 |
| bencoh | well, I dunno how the mainline driver does it, but I didn't see CONTCONV==1 on kp53 | 17:42 |
| bencoh | (when dumping regs) | 17:42 |
| freemangordon | it is in single conv mode | 17:42 |
| bencoh | then they probably don't read the temp register before EOCZ returns to 0 | 17:43 |
| freemangordon | right | 17:43 |
| bencoh | so it shouldn't affect it | 17:43 |
| bencoh | (but you're right that it's wrong) | 17:43 |
| freemangordon | mhm | 17:44 |
| freemangordon | what worries me more is that tshut gpio is ignored | 17:44 |
| freemangordon | I think that potentially may lead to what Wizzup is seeing | 17:44 |
| freemangordon | because it seems gpios have issues in OFF mode | 17:45 |
| bencoh | fucking firefox preventing me from opening non-https files -_- wtf | 17:45 |
| bencoh | getlost mozilla | 17:45 |
| bencoh | freemangordon: what is tshut gpio? | 17:46 |
| bencoh | camera shut? | 17:46 |
| bencoh | (I guess not, but ...) | 17:46 |
| freemangordon | thermal shutdown | 17:47 |
| bencoh | I don't see it in schems | 17:47 |
| bencoh | is it a real gpio, or an internal interrupt? | 17:47 |
| freemangordon | it is internal | 17:47 |
| freemangordon | gpio 127 | 17:47 |
| bencoh | hmm | 17:47 |
| freemangordon | bencoh: search for gpio_127 | 17:49 |
| bencoh | I only see it in omap3-pandora and a few non-omap3 boards ... lemme update my tree | 17:50 |
| freemangordon | I don;t see it at all | 17:51 |
| freemangordon | ah, the search is for TRM | 17:51 |
| bencoh | afaiu tshut != gpio_127 | 17:53 |
| bencoh | tshut is an input-only internal signal | 17:53 |
| freemangordon | hmm, my bad, 7f is ok | 17:53 |
| bencoh | how so? | 17:53 |
| bencoh | ah, 0:6 | 17:53 |
| bencoh | huhu | 17:53 |
| freemangordon | yeah :) | 17:54 |
| bencoh | tbf I made the same mistake when checking the regs manually :) | 17:54 |
| freemangordon | so, what do you mean about gpio 127? | 17:54 |
| freemangordon | it *is* gpio 127 if connected to a ball | 17:55 |
| freemangordon | look at p. 3341 | 17:55 |
| bencoh | it took me some time to understand that gpio_127 can either be gpio_127 (external gpio) or TSHUT | 17:55 |
| bencoh | (see the GPIO Integration Overview figure) | 17:56 |
| freemangordon | mhm | 17:56 |
| bencoh | no wonder it doesn't show up in schems then | 17:56 |
| freemangordon | do you see any threshold for tshut activation? | 17:57 |
| bencoh | I see 160C | 17:59 |
| bencoh | but that sounds high (wrong?) | 17:59 |
| bencoh | see 7.4.6.2 Temperature Sensor | 18:00 |
| bencoh | freemangordon: do we get "invalid gpio for tshut" at boot? | 18:04 |
| freemangordon | no idea | 18:05 |
| freemangordon | only Wizzup knows | 18:05 |
| bencoh | ohwell, actually, nevermind .... omap3-thermal-data.c doesn't features TI_BANDGAP_FEATURE_TSHUT | 18:05 |
| freemangordon | mhm | 18:05 |
| freemangordon | which is weird | 18:05 |
| bencoh | so the driver doesn't even try | 18:05 |
| freemangordon | yes | 18:05 |
| bencoh | either they didn't deem it necessary, or they missed omap3 when adding support for omap4/omap5 | 18:05 |
| freemangordon | thats strange, given that 3630 even has control over whether to enable or not TSHUT functionality | 18:06 |
| bencoh | yeah | 18:06 |
| freemangordon | (I am looking at 3630 TRM) | 18:06 |
| bencoh | well, maybe they got lazy :> | 18:06 |
| freemangordon | mhm | 18:06 |
| freemangordon | So, maybe what happens is: | 18:09 |
| freemangordon | 1. omap3 bangap driver doesn't attach irq routine for TSHUT interrupt(gpio) | 18:09 |
| freemangordon | 2. in OFF mode gpios go crazy | 18:09 |
| freemangordon | 3. TSHUT is generated because of 2 | 18:09 |
| freemangordon | 4. we have unhandled irq | 18:09 |
| freemangordon | nice theory, but doesn;t explain why there is no oops with bangap driver disabled :) | 18:09 |
| freemangordon | so, I think the highest prio is to see what happens with GPIOs in OFF mode | 18:10 |
| * freemangordon is afk | 18:10 | |
| freemangordon | ttyl | 18:10 |
| Wizzup | 18:04 < bencoh> freemangordon: do we get "invalid gpio for tshut" at boot? | 18:21 |
| Wizzup | 18:05 < freemangordon> no idea | 18:21 |
| Wizzup | 18:05 < freemangordon> only Wizzup knows | 18:21 |
| Wizzup | ? | 18:21 |
| bencoh | Wizzup: the answer is probably no, but the question was whether we get that error at boot (dmesg) | 18:21 |
| bencoh | (on n900) | 18:21 |
| freemangordon | Wizzup: also, there is some SiErr it seems, look at sprz278f.pdf | 18:23 |
| bencoh | (the omap4 devicetrees probably define the gpio/interrupt, btw) | 18:23 |
| freemangordon | 3.1.1.186 | 18:23 |
| bencoh | ohright | 18:23 |
| Wizzup | yeah that's also a comment in kernel: | 18:24 |
| Wizzup | * Note * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" | 18:24 |
| bencoh | I was reading the omap34xx TRM btw, I just realized n900 is ... omap35xx right? | 18:24 |
| freemangordon | no | 18:24 |
| freemangordon | it is 3430 | 18:24 |
| bencoh | ah alright | 18:24 |
| bencoh | the errata is 35xx then | 18:24 |
| freemangordon | hmm? | 18:24 |
| freemangordon | 3430 is HS version | 18:25 |
| bencoh | sprz278f.pdf mentions 3530 | 18:25 |
| bencoh | oh | 18:25 |
| bencoh | nevermind ) | 18:25 |
| bencoh | :) | 18:25 |
| bencoh | freemangordon: I wouldn't be surprised if the tshut "omission" was related to that erradata | 18:26 |
| bencoh | since on omap3 gpio_127 is mmc_whatever mode4 | 18:26 |
| bencoh | control_padconf_mmc1_dat4 / mmc1_dat5 / gpio_127 | 18:27 |
| bencoh | oh, erm ... mmc1 is in use on n900 right? | 18:27 |
| bencoh | if so, then tshut cannot be used no matter what :) | 18:28 |
| bencoh | the workaround in the errata is quite hilarious :'( | 18:30 |
| bencoh | but we probably shouldn't be affected since our mmc IS in use | 18:30 |
| bencoh | (unless it gets disabled from one of the pm_runtime handlers) | 18:31 |
| Wizzup | sicelo: did -experimental work | 18:32 |
| Wizzup | sicelo: if it didn't can you share the output of apt dist-upgrade | 18:32 |
| bencoh | Wizzup: what's the recommended way to upgrade leste these days btw? HAM? apt-get in a screen/tmux? disabling some mce/dsme flag? | 18:32 |
| Wizzup | I don't think leste usually restarts during an upgrade, but it does happen sometimes | 18:35 |
| Wizzup | I just run 'apt-get update' and 'apt-get dist-upgrade' | 18:36 |
| Wizzup | from osso-xterm | 18:36 |
| bencoh | Wizzup: it hapenned to me last time :> | 18:36 |
| bencoh | (actually it didn't even manage to poweroff iirc, I had to force-reboot :>) | 18:36 |
| Wizzup | I don't have a specific recommendation, but you can touch the /etc/no_lg_reboots file or something | 18:36 |
| Wizzup | (check name) | 18:36 |
| bencoh | alright | 18:37 |
| bencoh | thx | 18:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!