<freemangordon>
tmlind_: hi! do you have any idea if there is any poweroff/reboot cpcap code in upstream kernel?
<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
<freemangordon>
*inited
xmn has quit [Ping timeout: 260 seconds]
akossh has joined #maemo-leste
Gary_M has quit [Read error: Connection reset by peer]
Gary_M has joined #maemo-leste
<sicelo>
freemangordon: believe it or not ... adding the delay in schedule_delayed_wor() caused it to not work at all. no more uevent :-p
<sicelo>
but i'm recompiling just in case i botched it earlier
Anasko has joined #maemo-leste
branon has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
branon has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
leste has quit [Remote host closed the connection]
<freemangordon>
sicelo: do you still have cancel_delayed_work()?
<sicelo>
yes
Juest has quit [Ping timeout: 265 seconds]
Daanct12 has quit [Quit: WeeChat 4.4.2]
Juest has joined #maemo-leste
xmn has joined #maemo-leste
mdz has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<freemangordon>
sicelo: that does not make sense :)
<freemangordon>
may I see the exact code?
<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
<freemangordon>
tmlind_: so you think if I disable modem poweroff/reboot should work fine?
<freemangordon>
but why we lack the code that sets cpcap regs then? CPCAP_REG_PC2 that is
<freemangordon>
also, I don;t see how modem can hang gpio-poweroff, unless we have oops
<freemangordon>
but ok, I'll disable modem stuff and check
<tmlind_>
freemangordon: hmm the poweroff gpio is on the soc? but yeah maybe the register configuration on cpcap is incomplete
f_ is now known as funderscore
funderscore is now known as f_
<freemangordon>
gpio-poweroff is on cpcap, like gpio50 is connected to cpcap WDI pin, IIUC
<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
<tmlind_>
so that goes to some power pin on the cpcap likely
<freemangordon>
yes, WDI pin should be it
<freemangordon>
but in order for WDI to function properly, PCEN bit in Power Control 1 register must be set, IIUC
<freemangordon>
at least that's how I read "5.2.5 Turn Off Events"
<freemangordon>
"The phone is powered off upon software initiative based on this interrupt, by pulling WDI low"
<tmlind_>
ok, i recall there was a tiny difference in shutdown power consumption compared to powering off from bootloader or android
<freemangordon>
I wonder how/why powering off/reboot was working at all with 6.1
<tmlind_>
from what i recall mainline linux poweroff causes the device to consume about 1mw, while poweroff from android is a bit less
<tmlind_>
sounds like the PCEN might shut down some power supply after poweroff
<freemangordon>
mhm
<freemangordon>
still, why is poweroff working at all with 6.1? :)
<tmlind_>
why would it not?
<freemangordon>
because according to docs nothing should happen if PCEN is 0
<freemangordon>
see MC13783UG.pdf
<tmlind_>
well give it a try without the modem stuff, sounds like PCEN is optional
<freemangordon>
5.2.5
<freemangordon>
ok
<freemangordon>
though it is easier to first try with PCEN set
<tmlind_>
possibly having a serial console might also make poweroff behave, don't know, but i suspect something uart related
<freemangordon>
with serial console it seems to work
<tmlind_>
heh ok
<tmlind_>
serial console keeps the uart from runtime idling
<freemangordon>
mhm
<tmlind_>
anyways worth checking the PCEN, maybe that's the missing extra saving when powered off
<freemangordon>
yep, going to do it
<freemangordon>
with PCEN on it didn't poweroff, but didn't restart either
<tmlind_>
heh maybe it does powercut when the soc hits idle now..
<freemangordon>
don't follow
<tmlind_>
maybe try unidling the uarts on shutdown to see if that's the issue
<freemangordon>
ok
<tmlind_>
looks like the PCEN might be also related to cutting off some regulators during idle depending on the configuration?
<freemangordon>
echo on > 4806a000.serial/power/control
<freemangordon>
and so on for the others, right?
<freemangordon>
yeah, it powered off
<freemangordon>
tmlind_: ^^^
<freemangordon>
thanks!
<freemangordon>
so, we shall unidle on poweroff/reboot?
<freemangordon>
or some fix must be implemented?
<tmlind_>
heh ok cool :) i guess that would be a short term workaround
<freemangordon>
in the kernel that is
<freemangordon>
pm_runtime_get?
<tmlind_>
yeah i'll try to fix it when it starts raining more
<freemangordon>
heh :)
<tmlind_>
yeah pm_runtime_get, but i think some drivers may call the mctrl stuff directly too
<freemangordon>
lemme see what that mctll is
<tmlind_>
yeah narrowing it down would help, i would try uart_update_mctrl() first
<freemangordon>
it calls port->ops->set_mctrl()
<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
<tmlind_>
well we can't do it but could return an error possibly
<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?
<tmlind_>
hmm yeah worth trying yeah
<tmlind_>
see current mainline kernel though if you're on v6.1
<freemangordon>
no, I am on 6.6
<freemangordon>
ok, checking mainline
<tmlind_>
still behind likely, mainline now has serial core with a struct device hierarchy
<freemangordon>
how's that related?
<tmlind_>
well the runtime_pm calls propagate to the serial port driver device which is the parent
<tmlind_>
so in theory serial_core.c could eventually handle all runtime pm
<freemangordon>
I have the feeling you are looking for a proper fix :)
<tmlind_>
except that's not exactly clear yet.. see commit 5555980571cc ("serial: core: Fix regression when runtime PM is not enabled")
<freemangordon>
we still have that in 6.6
<freemangordon>
I mean - 5555980571cc is not in 6.6
<freemangordon>
so, you mean that if PM runtime cannot be enabled in uart_update_mctrl(), we can't do much but to error out?
<tmlind_>
or maybe what you suggested similar to __uart_start, not sure if they are really called directly though
<tmlind_>
it might be also related to multiple mctrl calls don't know
<tmlind_>
sorry i mean other like uart_port_dtr_rts and carrier_raised
<tmlind_>
does not consider the direct calls but worth trying, at least it built and booted for me
<tmlind_>
sounds like v6.6 already has port->port_dev
<freemangordon>
ok, lemme check
<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..
<tmlind_>
heh disabling runtime_pm with a shutdown call might be the m-l short term fix :)
<tmlind_>
for the uarts i mean
<freemangordon>
I tried it
<freemangordon>
but it didn;'t work
<tmlind_>
hmm
<freemangordon>
maybe service does not get stopped
<freemangordon>
or is stopped too late
<tmlind_>
or it happens before shutdown
<freemangordon>
there is openrc service that idles uarts on bootup
<tmlind_>
the hang might happen before the shutdown calls are run
<freemangordon>
when it starts
<freemangordon>
hmm, right
<freemangordon>
ok, lemme try your patch
<tmlind_>
ok
<tmlind_>
the alternative i was thinking was adding .shutdown call to 8250_omap
<tmlind_>
so with that poweroff worked for me on d4, still consuming 1 - 3 mw though but seems shut down
<freemangordon>
which kernel?
<tmlind_>
i don't have the modem patches applied though, plain v6.12-rc1
<freemangordon>
ah, ok
<freemangordon>
how to prevent kernel version being appended with some SHA id?
<tmlind_>
LOCALVERSION_AUTO=n
<freemangordon>
in config?
<tmlind_>
yeah
<freemangordon>
ok, thanks
<tmlind_>
need to go offline here, ttyl
<freemangordon>
thanks!
<tmlind_>
thank you
<freemangordon>
I'll play with CPCAP as well
<freemangordon>
ok, that patch fixes poweroff on 6.6 as well
<freemangordon>
reboot works as well
<freemangordon>
arno11: ok, now poweroff works on d4, I see similar behaviour in regards to h-s-m
Twig has quit [Remote host closed the connection]
<Wizzup>
what behaviour is that?
<Wizzup>
(also: nice!)
mdz has quit [Ping timeout: 244 seconds]
Anasko has joined #maemo-leste
akossh has quit [Quit: Leaving.]
Juesto has joined #maemo-leste
Juest has quit [Ping timeout: 260 seconds]
Juesto is now known as Juest
System_Error has quit [Remote host closed the connection]