| lel | IMbackK closed an issue: https://github.com/maemo-leste/bugtracker/issues/413 (Provide our patched libsdl) | 12:20 |
|---|---|---|
| lel | IMbackK closed an issue: https://github.com/maemo-leste/bugtracker/issues/562 (Droid4 gl4es fullscreen error) | 12:21 |
| tmlind | freemangordon: i think i implemented that thalia int fix as a quirk for drivers/bus/ti-sysc.c to bring up the module, no idea why it's needed | 12:25 |
| tmlind | hmm looks like commit d7f563d it's needed for 36xx though, maybe 34xx needs it too or some other quirks | 12:26 |
| tmlind | or i mistyped 36xx instead of 34xx | 12:27 |
| tmlind | freemangordon: oh the quirk you found is also for 36xx so it should be ok, afaik 34xx has those regs somehow broken | 12:28 |
| tmlind | uvos: so you mentioned bionic gets way better power consumption compared to d4 when idle? what's the difference in average mw if you run droid4-pm status once a minute? | 12:29 |
| tmlind | maybe it's some external i2c device on d4 that should be powered down | 12:30 |
| uvos | tmlind: so my d4 sometimes manages 90mW but often it just uses 120mW-180mW with no explanation i can find, this is unrelated to the modem related touch ttyUSB workaround. | 12:31 |
| uvos | the bionic allways idles at 70mW | 12:31 |
| uvos | pretty mutch no matter what | 12:31 |
| tmlind | weird | 12:32 |
| tmlind | do you have omap4-keypad loaded on bionic also? | 12:32 |
| uvos | yeah | 12:32 |
| uvos | its needed for vol-up/down | 12:32 |
| tmlind | ok | 12:33 |
| tmlind | that's a big difference for the idle consumption | 12:33 |
| uvos | ok interesting | 12:33 |
| uvos | should we be suspending that? | 12:33 |
| uvos | the only one keeping it open on leste is mce | 12:33 |
| uvos | i could have mce close it | 12:33 |
| tmlind | droid4-keypad should autoidle itself when no input | 12:34 |
| uvos | ok | 12:34 |
| tmlind | no need to do anything unless there's a bug | 12:34 |
| uvos | ok | 12:34 |
| tmlind | could it be some mismuxed line on d4? | 12:34 |
| uvos | maybe | 12:35 |
| tmlind | i'd suspect one of the different i2c devices | 12:35 |
| tmlind | maybe we need to toggle gpio reset for one of them on droid4 | 12:35 |
| uvos | sure the sensors are different for instance | 12:35 |
| tmlind | the easy way to test would be to temporarily disable them in the dts, then toggle their reset gpios vi /sys/kernel/debug | 12:36 |
| uvos | yeah | 12:37 |
| tmlind | i guess it could be some difference in the lcd panel too | 12:37 |
| uvos | i doubt | 12:37 |
| uvos | the cpcap firmware is clearly different | 12:37 |
| uvos | on bionic i manages the button backlight for instance | 12:37 |
| uvos | (problematic because it isent fully turned off when the mainline kernel powers down) | 12:38 |
| tmlind | have you tried bionic fw on d4 and see if that brings down the power consumption? | 12:38 |
| uvos | no | 12:38 |
| tmlind | i guess there could be some config issue with the different voltage regulators on d4 | 12:39 |
| uvos | true bionic has different voltage config in android | 12:39 |
| uvos | generaly higher tho | 12:39 |
| tmlind | i mean the of_machine_is_compatible() different config done in arch/arm/mach-omap2/pmic-cpcap.c | 12:40 |
| uvos | ah right | 12:40 |
| uvos | yeah some regulators move around | 12:40 |
| tmlind | you do have phy-cpcap-loaded or unloaded on both? | 12:40 |
| uvos | let me check | 12:41 |
| tmlind | that's a power hog for the serial port | 12:41 |
| uvos | unloaded on d4 | 12:41 |
| uvos | unloaded on bionic too | 12:41 |
| tmlind | ok | 12:41 |
| uvos | the bionic runs from internal mmc the d4 from sdcard | 12:45 |
| uvos | that might be some of the difference | 12:45 |
| tmlind | yeah maybe | 12:47 |
| uvos | to test the sensors | 12:50 |
| uvos | should it not be enough to blacklist the drivers and then trigger a reset | 12:50 |
| tmlind | should work | 12:52 |
| uvos | Wizzup: i cant install any of the libicd-provider-{tor,openvpn,wireguard} | 13:55 |
| uvos | ERROR: requested network_type DUMMY does not exist in /system/osso/connectivity/network_type (['WLAN_ADHOC', 'WLAN_INFRA', 'GPRS']) | 13:55 |
| uvos | tmlind: its not the keypad | 14:24 |
| uvos | it idles the same with it blacklisted | 14:25 |
| uvos | it = xt894 | 14:25 |
| tmlind | ok | 15:54 |
| Wizzup | uvos: check @ dummy, will fix | 16:41 |
| Wizzup | (in a few hrs) | 16:41 |
| Wizzup | ty for trying | 16:41 |
| freemangordon | tmlind: this? https://elixir.bootlin.com/linux/v5.15-rc5/source/drivers/bus/ti-sysc.c#L1498 | 18:20 |
| freemangordon | IIUC, for SGX 121 no quirk will be applied, but I am not really sure how SYSC_QUIRK() is supposed to work | 18:23 |
| freemangordon | however, I would say that if THALIA_INT_BYPASS is applied to 3430, this is a bug, unless you have some access to docs that are not publicly available that describe 0xff00 - 0xffff registers in SGX address spaces | 18:25 |
| freemangordon | also, I was not able to find anything in Nokia (fremantle) kernel that touches those addresses | 18:26 |
| freemangordon | later on I will dump 0xff08 on fremantle while some 3d application is runnig | 18:27 |
| tmlind | yeah that's the quirk, no i don't have special docs, just guessing based on the earlier reference code | 20:49 |
| tmlind | checking the sgx rev register would show if that quirk is wrongly applied to 34xx also | 20:50 |
| tmlind | so that would be reg 0x5000fe00, and hopefully it's not 0x40000000 | 20:55 |
| freemangordon | ok, but even if sysc does not apply it, SGX driver does the same quirk | 20:56 |
| freemangordon | unconditionally | 20:57 |
| freemangordon | OTOH, I am not sure I grok what that quirk does | 20:58 |
| tmlind | ok we should just leave out the sgx quirk then, the ti-sysc quirk also works for cases when there is not sgx driver | 20:58 |
| tmlind | like the mainline kernel | 20:58 |
| tmlind | i think it configures some interrupt routing register | 20:58 |
| tmlind | freemangordon: so what's your ddk-1.17 kernel branch like now, do you have some reverts on the pvrsgx tree? | 21:01 |
| tmlind | i'm still seeing crashes for omap3 with the prm sgx patch applied and no SUPPORT_ACTIVE_POWER_MANAGEMENT | 21:02 |
| freemangordon | I see crashes with your omap3-prm-gfx.patch | 21:04 |
| freemangordon | applied that is | 21:04 |
| freemangordon | so I removed it and now am trying to figure out what is wrong, besides it | 21:05 |
| freemangordon | a057d283a8926e5f9824ae41798d41bfbbd56a0d (HEAD -> pvr-5.15) gpu: pvr: Enable runtime PM autosuspend for pvr-drv | 21:06 |
| freemangordon | 614eb7536d3adad342b04fd1666bb3880e660dab gpu: pvr: Use PVR_LINUX_MEM_AREA_USE_VMAP to load driver properly | 21:06 |
| freemangordon | 4a75f05f070785db5ffcbe21bd45b1482ef99e37 ARM: omap2plus_defconfig: Use ddk-1.17 by default | 21:06 |
| freemangordon | f7b5e1683a28c6ecb7ce3a32ba9d7c12364868e9 gpu: pvr: Drop all old ddk versions | 21:06 |
| freemangordon | b98125a4f1287bc29df93c43abe49cc661030ff4 Merge tag 'v5.15-rc2' into droid4-pending-pvr-omapdrm-v5.15 | 21:06 |
| freemangordon | e4e737bb5c170df6135a127739a9e6148ee3da82 (tag: v5.15-rc2) Linux 5.15-rc2 | 21:06 |
| freemangordon | this^^^ | 21:06 |
| freemangordon | this works stable with SUPPORT_ACTIVE_POWER_MANAGEMENT disabled | 21:06 |
| freemangordon | SYS_USING_INTERRUPTS is enabled | 21:06 |
| freemangordon | didn't have chance to spend time trying to find what's wrong with clocks/prcm/whatever with SUPPORT_ACTIVE_POWER_MANAGEMENT enabled though, hopefully will have spare time during the weekend | 21:08 |
| tmlind | ok yeah so something else is still broken somewhere | 21:09 |
| freemangordon | mhm | 21:09 |
| tmlind | hmm so are you saying v5.15-rc1 is not good and v5.15-rc2 must be merged in? | 21:10 |
| freemangordon | not, I just pulled your tree | 21:10 |
| tmlind | ok | 21:10 |
| freemangordon | pity I didn;t have chance to play more with that, but RL job took all my time/power the last few days :) | 21:11 |
| tmlind | that PVR_LINUX_MEM_AREA_USE_VMAP is the mystery patch as you probably noticed too | 21:11 |
| freemangordon | yeah | 21:11 |
| freemangordon | but I think it is of lower prio compared to PM | 21:12 |
| tmlind | yup | 21:13 |
| tmlind | well the sgx registers are readable after echo on > control for sgx module, so the pm should be pretty close | 21:16 |
| tmlind | something in the pvrsgx driver code goes wrong for sgx530 somewhere | 21:16 |
| freemangordon | my gut feeling tells me it is the kernel, not the driver :) | 21:17 |
| freemangordon | because SUPPORT_ACTIVE_POWER_MANAGEMENT enables only small code segments that call PM kernel functions | 21:17 |
| tmlind | intuition is a good path to follow :) | 21:17 |
| freemangordon | but yeah, I need to prove that by comparing fremantle kernel CM/PRCM regs with usptream when clocks are enabled | 21:18 |
| tmlind | a shell script toggling between on and auto for the pvr sgx sysfs entry should be tested | 21:18 |
| freemangordon | s/I need/I have to | 21:18 |
| freemangordon | I suspect there is some small interval in which clocks are still disabled after pm_runtime_get _sync() | 21:19 |
| freemangordon | and I plan to test that as soon as I find spare time | 21:20 |
| freemangordon | tmlind: also, please, if you *grok* what THALIA_INT_BYPASS does, explain it to me, it seems my English is not good enough for me to understand the explanation in the TRM | 21:22 |
| freemangordon | what is IPG register? | 21:22 |
| tmlind | no idea, my guess it's some interrupt routing register in the target module for sgx | 21:23 |
| freemangordon | which gets set by the driver? | 21:23 |
| tmlind | yeah it needs to be set on enable, i think otherwise the interrupt won't trigger | 21:24 |
| tmlind | for 36xx | 21:24 |
| freemangordon | hmm, ok | 21:24 |
| tmlind | on 34xx, i think the whole ocp target module registers are broken and should not be touched at all | 21:25 |
| freemangordon | yeah, but the driver does it | 21:25 |
| freemangordon | that might be the issue | 21:25 |
| tmlind | for 34xx? | 21:25 |
| freemangordon | unconditionally | 21:25 |
| freemangordon | sec | 21:26 |
| tmlind | ok yeah sounds like it might be a problem then, should be removed from the driver as ti-sysc does it for 36xx | 21:26 |
| freemangordon | see EnableSGXClocksWrap() | 21:27 |
| freemangordon | and SGX_OCP_REGS_ENABLED define in general | 21:27 |
| tmlind | looks like toggling sgx sysfs control in a loop between on and auto works reliably btw | 21:28 |
| freemangordon | how do you know? by reading regs from userspace? | 21:28 |
| tmlind | afaik based on the ti-syc enable/disable tinkering a while back we should not touch the OCP regs like SYSCONFIG at all for 34xx, so SGX_OCP_REGS_ENABLED sounds like should not be set | 21:29 |
| freemangordon | mhm | 21:30 |
| freemangordon | but, that gets defined as soon as SYS_USING_INTERRUPTS is defines | 21:30 |
| tmlind | yeah ok might be a problem | 21:31 |
| tmlind | #!/bin/sh | 21:32 |
| tmlind | module="50000014.target-module" | 21:32 |
| tmlind | driver="/sys/bus/platform/drivers/ti-sysc" | 21:32 |
| tmlind | while true; do echo ${module} > ${driver}/bind echo ${module} > ${driver}/unbind | 21:32 |
| tmlind | done | 21:32 |
| tmlind | oh sorry bad formatting, needs to be on separate lines or needs ; | 21:32 |
| tmlind | so actually not toggling between on and auto, but re-enabling in a loop | 21:33 |
| freemangordon | anyway, I will spend more time on it during the weekend, if you find something in the meanwhile, please LMK | 21:34 |
| tmlind | yeah ok, zzz time here, ttyl | 21:34 |
| freemangordon | ttyl | 21:34 |
| freemangordon | oh, ok, commenting SGX_OCP_REGS_ENABLED make it work with SUPPORT_ACTIVE_POWER_MANAGEMENT and SYS_USING_INTERRUPTS | 23:10 |
| freemangordon | uvos: do you know how to check if SGX module is powered down? | 23:10 |
| freemangordon | sgx_pwrdm (OFF),OFF:6,RET:0,INA:0,ON:6,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 | 23:14 |
| freemangordon | I guess this means it is off, no? | 23:14 |
| uvos | there is a register for it | 23:14 |
| uvos | i dont know it by heart sorry | 23:14 |
| uvos | omapconf can read it for omap3 (but not omap4) | 23:14 |
| uvos | also there is the clock gating reigster in the dpll/devider section | 23:15 |
| uvos | depends on what you mean by "off" | 23:15 |
| freemangordon | but kernel provides all this info already, no? in /sys/kernel/debug | 23:15 |
| uvos | er omap4 but not omap3 i mean | 23:15 |
| uvos | freemangordon: yeah probubly | 23:15 |
| freemangordon | ok, I'll wait tmlind to confirm | 23:16 |
| freemangordon | lemme check clocks | 23:16 |
| uvos | on omap4 its just more conveniant/definitive to use omapconf most of the time | 23:16 |
| freemangordon | clk_enable_count is 0 | 23:17 |
| uvos | ok | 23:17 |
| freemangordon | so I am almost sure SGX is powered down | 23:17 |
| uvos | know what cat /sys/kernel/debug/clk/ it is? | 23:17 |
| freemangordon | /sys/kernel/debug/clk/sgx_fck | 23:17 |
| uvos | ok | 23:17 |
| freemangordon | and /sys/kernel/debug/clk/sgx_ick | 23:17 |
| uvos | check the idle blockers PMI-CM2 in omap4 TRM | 23:20 |
| freemangordon | while glmark runs clocks enable count changes to 1 | 23:21 |
| freemangordon | and sgx_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 | 23:21 |
| uvos | sounds like it works yeah | 23:23 |
| freemangordon | mhm | 23:23 |
| uvos | the way they made register adresses unsearchable in the TRM is evil | 23:24 |
| freemangordon | https://pastebin.com/x3qT4jM9 | 23:25 |
| freemangordon | this is with SUPPORT_ACTIVE_POWER_MANAGEMENT and SYS_USING_INTERRUPTS enabled | 23:25 |
| uvos | great | 23:25 |
| uvos | what was the problem? | 23:25 |
| uvos | ah commenting SGX_OCP_REGS_ENABLED make it work with SUPPORT_ACTIVE_POWER_MANAGEMENT and SYS_USING_INTERRUPTS | 23:26 |
| uvos | net | 23:26 |
| uvos | neat | 23:26 |
| freemangordon | pvr driver touching OCP registers | 23:26 |
| uvos | also know why vbo underperforms on omap4? | 23:27 |
| freemangordon | it should not with SYS_USING_INTERRUPTS enabled | 23:27 |
| freemangordon | define "underperforms" | 23:27 |
| uvos | 2 fps | 23:27 |
| freemangordon | last time I tried it is was > 100 fps | 23:27 |
| freemangordon | oh | 23:27 |
| freemangordon | then SYS_USING_INTERRUPTS is disabled | 23:28 |
| freemangordon | it behaves the same on n900 with SYS_USING_INTERRUPTS disabled | 23:28 |
| uvos | ok but only on -drm | 23:28 |
| freemangordon | yeah | 23:28 |
| uvos | works fine on wayland | 23:28 |
| freemangordon | same on n900 | 23:28 |
| uvos | perf wise | 23:28 |
| uvos | ok | 23:28 |
| freemangordon | but, we must have SYS_USING_INTERRUPTS enabled | 23:28 |
| uvos | ok ill check tomorrow | 23:29 |
| uvos | for omap4 kernel | 23:29 |
| freemangordon | I should also pester tmlind to fix tiler patch to not break omap3 | 23:29 |
| freemangordon | but anyway, this is great progress | 23:29 |
| uvos | yeah | 23:29 |
| uvos | neat | 23:30 |
| freemangordon | and I think I deserve some rest :D | 23:30 |
| uvos | good work :) | 23:30 |
| freemangordon | yeah. good night! | 23:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!