<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
<tmlind>
hmm looks like commit d7f563d it's needed for 36xx though, maybe 34xx needs it too or some other quirks
<tmlind>
or i mistyped 36xx instead of 34xx
<tmlind>
freemangordon: oh the quirk you found is also for 36xx so it should be ok, afaik 34xx has those regs somehow broken
<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?
<tmlind>
maybe it's some external i2c device on d4 that should be powered down
<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.
<uvos>
the bionic allways idles at 70mW
<uvos>
pretty mutch no matter what
<tmlind>
weird
<tmlind>
do you have omap4-keypad loaded on bionic also?
<uvos>
yeah
<uvos>
its needed for vol-up/down
<tmlind>
ok
<tmlind>
that's a big difference for the idle consumption
<uvos>
ok interesting
<uvos>
should we be suspending that?
<uvos>
the only one keeping it open on leste is mce
<uvos>
i could have mce close it
<tmlind>
droid4-keypad should autoidle itself when no input
<uvos>
ok
<tmlind>
no need to do anything unless there's a bug
<uvos>
ok
<tmlind>
could it be some mismuxed line on d4?
<uvos>
maybe
<tmlind>
i'd suspect one of the different i2c devices
<tmlind>
maybe we need to toggle gpio reset for one of them on droid4
<uvos>
sure the sensors are different for instance
<tmlind>
the easy way to test would be to temporarily disable them in the dts, then toggle their reset gpios vi /sys/kernel/debug
<uvos>
yeah
<tmlind>
i guess it could be some difference in the lcd panel too
<uvos>
i doubt
<uvos>
the cpcap firmware is clearly different
<uvos>
on bionic i manages the button backlight for instance
<uvos>
(problematic because it isent fully turned off when the mainline kernel powers down)
<tmlind>
have you tried bionic fw on d4 and see if that brings down the power consumption?
<uvos>
no
<tmlind>
i guess there could be some config issue with the different voltage regulators on d4
<uvos>
true bionic has different voltage config in android
<uvos>
generaly higher tho
<tmlind>
i mean the of_machine_is_compatible() different config done in arch/arm/mach-omap2/pmic-cpcap.c
<uvos>
ah right
<uvos>
yeah some regulators move around
<tmlind>
you do have phy-cpcap-loaded or unloaded on both?
<uvos>
let me check
<tmlind>
that's a power hog for the serial port
<uvos>
unloaded on d4
<uvos>
unloaded on bionic too
<tmlind>
ok
<uvos>
the bionic runs from internal mmc the d4 from sdcard
<uvos>
that might be some of the difference
<tmlind>
yeah maybe
<uvos>
to test the sensors
<uvos>
should it not be enough to blacklist the drivers and then trigger a reset
<tmlind>
should work
pere has quit [Ping timeout: 252 seconds]
xmn has quit [Ping timeout: 268 seconds]
<uvos>
Wizzup: i cant install any of the libicd-provider-{tor,openvpn,wireguard}
<uvos>
ERROR: requested network_type DUMMY does not exist in /system/osso/connectivity/network_type (['WLAN_ADHOC', 'WLAN_INFRA', 'GPRS'])
<uvos>
tmlind: its not the keypad
<uvos>
it idles the same with it blacklisted
<uvos>
it = xt894
_inky has quit [Ping timeout: 252 seconds]
inky has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
inky has joined #maemo-leste
_inky has joined #maemo-leste
inky has quit [Read error: Connection reset by peer]
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 252 seconds]
_inky has joined #maemo-leste
<tmlind>
ok
inky_ has quit [Ping timeout: 245 seconds]
inky_ has joined #maemo-leste
<Wizzup>
uvos: check @ dummy, will fix
<Wizzup>
(in a few hrs)
<Wizzup>
ty for trying
inky_ has quit [Ping timeout: 252 seconds]
_inky has quit [Ping timeout: 252 seconds]
_inky has joined #maemo-leste
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 252 seconds]
tvall has quit [Quit: Bridge terminating on SIGTERM]
argon has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
asriel_dreemurr has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam[m] has quit [Quit: Bridge terminating on SIGTERM]
<freemangordon>
IIUC, for SGX 121 no quirk will be applied, but I am not really sure how SYSC_QUIRK() is supposed to work
<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
<freemangordon>
also, I was not able to find anything in Nokia (fremantle) kernel that touches those addresses
<freemangordon>
later on I will dump 0xff08 on fremantle while some 3d application is runnig
Twig has joined #maemo-leste
amk has joined #maemo-leste
<tmlind>
yeah that's the quirk, no i don't have special docs, just guessing based on the earlier reference code
<tmlind>
checking the sgx rev register would show if that quirk is wrongly applied to 34xx also
<tmlind>
so that would be reg 0x5000fe00, and hopefully it's not 0x40000000
<freemangordon>
ok, but even if sysc does not apply it, SGX driver does the same quirk
<freemangordon>
unconditionally
<freemangordon>
OTOH, I am not sure I grok what that quirk does
<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
<tmlind>
like the mainline kernel
<tmlind>
i think it configures some interrupt routing register
<tmlind>
freemangordon: so what's your ddk-1.17 kernel branch like now, do you have some reverts on the pvrsgx tree?
<tmlind>
i'm still seeing crashes for omap3 with the prm sgx patch applied and no SUPPORT_ACTIVE_POWER_MANAGEMENT
<freemangordon>
I see crashes with your omap3-prm-gfx.patch
<freemangordon>
applied that is
<freemangordon>
so I removed it and now am trying to figure out what is wrong, besides it
<freemangordon>
614eb7536d3adad342b04fd1666bb3880e660dab gpu: pvr: Use PVR_LINUX_MEM_AREA_USE_VMAP to load driver properly
<freemangordon>
e4e737bb5c170df6135a127739a9e6148ee3da82 (tag: v5.15-rc2) Linux 5.15-rc2
<freemangordon>
4a75f05f070785db5ffcbe21bd45b1482ef99e37 ARM: omap2plus_defconfig: Use ddk-1.17 by default
<freemangordon>
b98125a4f1287bc29df93c43abe49cc661030ff4 Merge tag 'v5.15-rc2' into droid4-pending-pvr-omapdrm-v5.15
<freemangordon>
f7b5e1683a28c6ecb7ce3a32ba9d7c12364868e9 gpu: pvr: Drop all old ddk versions
<freemangordon>
this^^^
<freemangordon>
this works stable with SUPPORT_ACTIVE_POWER_MANAGEMENT disabled
<freemangordon>
SYS_USING_INTERRUPTS is enabled
<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
<tmlind>
ok yeah so something else is still broken somewhere
<freemangordon>
mhm
<tmlind>
hmm so are you saying v5.15-rc1 is not good and v5.15-rc2 must be merged in?
<freemangordon>
not, I just pulled your tree
<tmlind>
ok
<freemangordon>
pity I didn;t have chance to play more with that, but RL job took all my time/power the last few days :)
<tmlind>
that PVR_LINUX_MEM_AREA_USE_VMAP is the mystery patch as you probably noticed too
<freemangordon>
yeah
<freemangordon>
but I think it is of lower prio compared to PM
<tmlind>
yup
<tmlind>
well the sgx registers are readable after echo on > control for sgx module, so the pm should be pretty close
<tmlind>
something in the pvrsgx driver code goes wrong for sgx530 somewhere
<freemangordon>
my gut feeling tells me it is the kernel, not the driver :)
<freemangordon>
because SUPPORT_ACTIVE_POWER_MANAGEMENT enables only small code segments that call PM kernel functions
<tmlind>
intuition is a good path to follow :)
<freemangordon>
but yeah, I need to prove that by comparing fremantle kernel CM/PRCM regs with usptream when clocks are enabled
<tmlind>
a shell script toggling between on and auto for the pvr sgx sysfs entry should be tested
<freemangordon>
s/I need/I have to
<freemangordon>
I suspect there is some small interval in which clocks are still disabled after pm_runtime_get _sync()
<freemangordon>
and I plan to test that as soon as I find spare time
<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
<freemangordon>
what is IPG register?
<tmlind>
no idea, my guess it's some interrupt routing register in the target module for sgx
<freemangordon>
which gets set by the driver?
<tmlind>
yeah it needs to be set on enable, i think otherwise the interrupt won't trigger
<tmlind>
for 36xx
<freemangordon>
hmm, ok
<tmlind>
on 34xx, i think the whole ocp target module registers are broken and should not be touched at all
<freemangordon>
yeah, but the driver does it
<freemangordon>
that might be the issue
<tmlind>
for 34xx?
<freemangordon>
unconditionally
<freemangordon>
sec
<tmlind>
ok yeah sounds like it might be a problem then, should be removed from the driver as ti-sysc does it for 36xx
<freemangordon>
see EnableSGXClocksWrap()
<freemangordon>
and SGX_OCP_REGS_ENABLED define in general
<tmlind>
looks like toggling sgx sysfs control in a loop between on and auto works reliably btw
<freemangordon>
how do you know? by reading regs from userspace?
<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
<freemangordon>
mhm
<freemangordon>
but, that gets defined as soon as SYS_USING_INTERRUPTS is defines
<tmlind>
yeah ok might be a problem
<tmlind>
#!/bin/sh
<tmlind>
while true; do echo ${module} > ${driver}/bind echo ${module} > ${driver}/unbind