| freemangordon | uvos: I don;t see how was reboot/poweroff ever working | 08:06 |
|---|---|---|
| freemangordon | d4 does poweroff through a gpio, however, a bit in CPCAP_REG_PC1 must be set, I guess | 08:08 |
| freemangordon | for proper poweroff | 08:08 |
| freemangordon | vendor kernel does a long reboot sequence I can find nowhere in our kernel: https://github.com/NotKit/android_kernel_motorola_omap4-common/blob/hybris-11.0/drivers/mfd/cpcap-core.c#L125 | 08:09 |
| freemangordon | tmlind_: hi! do you have any idea if there is any poweroff/reboot cpcap code in upstream kernel? | 08:13 |
| freemangordon | uvos: so, I suspect the reason why device reboots when power-off is issued and hangs when reboot is requested is simply that cpcap regs are not properly initied | 08:14 |
| freemangordon | *inited | 08:14 |
| sicelo | freemangordon: believe it or not ... adding the delay in schedule_delayed_wor() caused it to not work at all. no more uevent :-p | 08:59 |
| sicelo | but i'm recompiling just in case i botched it earlier | 09:00 |
| freemangordon | sicelo: do you still have cancel_delayed_work()? | 13:36 |
| sicelo | yes | 13:41 |
| freemangordon | sicelo: that does not make sense :) | 17:26 |
| freemangordon | may I see the exact code? | 17:28 |
| tmlind_ | freemangordon: i suspect the system hangs on poweroff and does a watchdog reset, i think it's a serial issue as i recall it works fine without the modem stuff | 17:40 |
| freemangordon | tmlind_: so you think if I disable modem poweroff/reboot should work fine? | 17:41 |
| freemangordon | but why we lack the code that sets cpcap regs then? CPCAP_REG_PC2 that is | 17:42 |
| freemangordon | also, I don;t see how modem can hang gpio-poweroff, unless we have oops | 17:43 |
| freemangordon | but ok, I'll disable modem stuff and check | 17:43 |
| tmlind_ | freemangordon: hmm the poweroff gpio is on the soc? but yeah maybe the register configuration on cpcap is incomplete | 18:30 |
| freemangordon | gpio-poweroff is on cpcap, like gpio50 is connected to cpcap WDI pin, IIUC | 19:00 |
| tmlind_ | i guess i don't follow you.. for mapphone dts has gpio-poweroff as gpios = <&gpio2 18 GPIO_ACTIVE_LOW> so gpio_50 on the soc | 19:13 |
| tmlind_ | so that goes to some power pin on the cpcap likely | 19:14 |
| freemangordon | yes, WDI pin should be it | 19:14 |
| freemangordon | but in order for WDI to function properly, PCEN bit in Power Control 1 register must be set, IIUC | 19:15 |
| freemangordon | at least that's how I read "5.2.5 Turn Off Events" | 19:15 |
| freemangordon | "The phone is powered off upon software initiative based on this interrupt, by pulling WDI low" | 19:16 |
| tmlind_ | ok, i recall there was a tiny difference in shutdown power consumption compared to powering off from bootloader or android | 19:16 |
| freemangordon | I wonder how/why powering off/reboot was working at all with 6.1 | 19:16 |
| tmlind_ | from what i recall mainline linux poweroff causes the device to consume about 1mw, while poweroff from android is a bit less | 19:17 |
| tmlind_ | sounds like the PCEN might shut down some power supply after poweroff | 19:17 |
| freemangordon | mhm | 19:18 |
| freemangordon | still, why is poweroff working at all with 6.1? :) | 19:18 |
| tmlind_ | why would it not? | 19:18 |
| freemangordon | because according to docs nothing should happen if PCEN is 0 | 19:19 |
| freemangordon | see MC13783UG.pdf | 19:19 |
| tmlind_ | well give it a try without the modem stuff, sounds like PCEN is optional | 19:19 |
| freemangordon | 5.2.5 | 19:19 |
| freemangordon | ok | 19:20 |
| freemangordon | though it is easier to first try with PCEN set | 19:20 |
| tmlind_ | possibly having a serial console might also make poweroff behave, don't know, but i suspect something uart related | 19:20 |
| freemangordon | with serial console it seems to work | 19:20 |
| tmlind_ | heh ok | 19:20 |
| tmlind_ | serial console keeps the uart from runtime idling | 19:21 |
| freemangordon | mhm | 19:21 |
| tmlind_ | anyways worth checking the PCEN, maybe that's the missing extra saving when powered off | 19:22 |
| freemangordon | yep, going to do it | 19:23 |
| freemangordon | with PCEN on it didn't poweroff, but didn't restart either | 19:33 |
| tmlind_ | heh maybe it does powercut when the soc hits idle now.. | 19:34 |
| freemangordon | don't follow | 19:35 |
| tmlind_ | maybe try unidling the uarts on shutdown to see if that's the issue | 19:35 |
| freemangordon | ok | 19:35 |
| tmlind_ | looks like the PCEN might be also related to cutting off some regulators during idle depending on the configuration? | 19:36 |
| freemangordon | I doubt | 19:37 |
| freemangordon | see https://github.com/NotKit/android_kernel_motorola_omap4-common/blob/hybris-11.0/drivers/mfd/cpcap-core.c#L240 | 19:37 |
| tmlind_ | looking at the "user off power cut" in the mc13783ug | 19:37 |
| freemangordon | that's the only place this bit is referenced | 19:37 |
| freemangordon | and ofc in default values | 19:37 |
| freemangordon | https://github.com/NotKit/android_kernel_motorola_omap4-common/blob/hybris-11.0/arch/arm/mach-omap2/board-mapphone-spi.c#L47 | 19:38 |
| tmlind_ | hmm is CPCAP_BIT_PC1_PCEN ever set high when system is running? | 19:40 |
| freemangordon | no, it defaults to 0 in our kernel | 19:41 |
| freemangordon | 021c: 0000 | 19:41 |
| tmlind_ | also in the stock andriod kernel? | 19:42 |
| freemangordon | on vendor kernel it is set to 0x010A in board file | 19:42 |
| freemangordon | thats PC1 register | 19:43 |
| freemangordon | which means PCEN is set to 1 | 19:43 |
| freemangordon | and power cut timer is set to 0x0A, whatever that means in seconds | 19:44 |
| freemangordon | ok, docs say ~32ms steps | 19:45 |
| freemangordon | so ~300 ms | 19:45 |
| freemangordon | lemme set that and try | 19:45 |
| tmlind_ | oh interesting | 19:48 |
| freemangordon | see https://github.com/NotKit/android_kernel_motorola_omap4-common/blob/hybris-11.0/arch/arm/mach-omap2/board-mapphone-spi.c#L47 | 19:49 |
| tmlind_ | ok | 19:49 |
| freemangordon | with that set to 010a still no dice, lemme unidle the uarts | 19:51 |
| tmlind_ | so i suspect some mctrl call gets called on idle uart(s) and hangs | 19:53 |
| freemangordon | ok | 19:53 |
| freemangordon | mctrl? | 19:53 |
| tmlind_ | if unidling all the uarts fixes the issue the that's it likely | 19:53 |
| freemangordon | trying it | 19:53 |
| freemangordon | what devices are those? ttyS0 etc? | 19:55 |
| tmlind_ | yeah ttyS0 to 3 or 4 | 19:55 |
| tmlind_ | git grep mctrl drivers/tty/serial/serial_core.c | 19:55 |
| freemangordon | echo on > 4806a000.serial/power/control | 20:01 |
| freemangordon | and so on for the others, right? | 20:01 |
| freemangordon | yeah, it powered off | 20:02 |
| freemangordon | tmlind_: ^^^ | 20:02 |
| freemangordon | thanks! | 20:03 |
| freemangordon | so, we shall unidle on poweroff/reboot? | 20:03 |
| freemangordon | or some fix must be implemented? | 20:04 |
| tmlind_ | heh ok cool :) i guess that would be a short term workaround | 20:04 |
| freemangordon | in the kernel that is | 20:04 |
| freemangordon | pm_runtime_get? | 20:04 |
| tmlind_ | yeah i'll try to fix it when it starts raining more | 20:04 |
| freemangordon | heh :) | 20:04 |
| tmlind_ | yeah pm_runtime_get, but i think some drivers may call the mctrl stuff directly too | 20:05 |
| freemangordon | lemme see what that mctll is | 20:05 |
| tmlind_ | yeah narrowing it down would help, i would try uart_update_mctrl() first | 20:06 |
| freemangordon | it calls port->ops->set_mctrl() | 20:06 |
| tmlind_ | but see also #define uart_set_mctrl and uart_clear_mctrl so pm_runtime_resume_and_get() may not always be the right solution | 20:07 |
| tmlind_ | well we can't do it but could return an error possibly | 20:07 |
| freemangordon | sorry, I don't understand that PM stuff, but, if we do the same in uart_update_mctrl() like what is done in __uart_start in regards to calling PM functions, wouln't that fix the issue? | 20:09 |
| tmlind_ | hmm yeah worth trying yeah | 20:10 |
| tmlind_ | see current mainline kernel though if you're on v6.1 | 20:10 |
| freemangordon | no, I am on 6.6 | 20:11 |
| freemangordon | ok, checking mainline | 20:11 |
| tmlind_ | still behind likely, mainline now has serial core with a struct device hierarchy | 20:12 |
| freemangordon | how's that related? | 20:13 |
| tmlind_ | well the runtime_pm calls propagate to the serial port driver device which is the parent | 20:13 |
| tmlind_ | so in theory serial_core.c could eventually handle all runtime pm | 20:14 |
| freemangordon | I have the feeling you are looking for a proper fix :) | 20:14 |
| tmlind_ | except that's not exactly clear yet.. see commit 5555980571cc ("serial: core: Fix regression when runtime PM is not enabled") | 20:15 |
| freemangordon | we still have that in 6.6 | 20:17 |
| freemangordon | I mean - 5555980571cc is not in 6.6 | 20:17 |
| freemangordon | so, you mean that if PM runtime cannot be enabled in uart_update_mctrl(), we can't do much but to error out? | 20:19 |
| tmlind_ | or maybe what you suggested similar to __uart_start, not sure if they are really called directly though | 20:24 |
| tmlind_ | it might be also related to multiple mctrl calls don't know | 20:25 |
| tmlind_ | sorry i mean other like uart_port_dtr_rts and carrier_raised | 20:25 |
| tmlind_ | maybe see if this helps, this is against v6.12-rc1 http://muru.com/linux/mctrl.patch | 20:30 |
| tmlind_ | does not consider the direct calls but worth trying, at least it built and booted for me | 20:30 |
| tmlind_ | sounds like v6.6 already has port->port_dev | 20:32 |
| freemangordon | ok, lemme check | 20:32 |
| tmlind_ | otherwise you could call it on port->dev, but that's not going work in general as you never know what the port->dev runtime_pm configuraion might be.. | 20:33 |
| tmlind_ | heh disabling runtime_pm with a shutdown call might be the m-l short term fix :) | 20:35 |
| tmlind_ | for the uarts i mean | 20:35 |
| freemangordon | I tried it | 20:35 |
| freemangordon | but it didn;'t work | 20:35 |
| tmlind_ | hmm | 20:35 |
| freemangordon | maybe service does not get stopped | 20:35 |
| freemangordon | or is stopped too late | 20:35 |
| tmlind_ | or it happens before shutdown | 20:36 |
| freemangordon | there is openrc service that idles uarts on bootup | 20:36 |
| tmlind_ | the hang might happen before the shutdown calls are run | 20:36 |
| freemangordon | when it starts | 20:36 |
| freemangordon | hmm, right | 20:36 |
| freemangordon | ok, lemme try your patch | 20:36 |
| tmlind_ | ok | 20:36 |
| tmlind_ | the alternative i was thinking was adding .shutdown call to 8250_omap | 20:37 |
| tmlind_ | so with that poweroff worked for me on d4, still consuming 1 - 3 mw though but seems shut down | 20:43 |
| freemangordon | which kernel? | 20:44 |
| tmlind_ | i don't have the modem patches applied though, plain v6.12-rc1 | 20:44 |
| freemangordon | ah, ok | 20:44 |
| freemangordon | how to prevent kernel version being appended with some SHA id? | 20:45 |
| tmlind_ | LOCALVERSION_AUTO=n | 20:45 |
| freemangordon | in config? | 20:46 |
| tmlind_ | yeah | 20:47 |
| freemangordon | ok, thanks | 20:47 |
| tmlind_ | need to go offline here, ttyl | 20:47 |
| freemangordon | thanks! | 20:47 |
| tmlind_ | thank you | 20:48 |
| freemangordon | I'll play with CPCAP as well | 20:48 |
| freemangordon | ok, that patch fixes poweroff on 6.6 as well | 21:26 |
| freemangordon | reboot works as well | 21:41 |
| freemangordon | arno11: ok, now poweroff works on d4, I see similar behaviour in regards to h-s-m | 21:54 |
| Wizzup | what behaviour is that? | 22:43 |
| Wizzup | (also: nice!) | 22:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!