search

PabloPL / linux

Linux kernel source tree
Other
17 stars 0 forks source link

Suspend to RAM #26

Closed xc-racer99 closed 2 years ago

xc-racer99 commented 5 years ago

Appears to sleep, doesn't wake up. Need to try with no_console_suspend

xc-racer99 commented 5 years ago

Need to investigate http://git.infradead.org/users/kmpark/linux-2.6-samsung/commit/d6c839b078487dc00211d50d3e027ecb26f4ed0c and see if it helps/works

xc-racer99 commented 5 years ago

Looking into things a bit, it appears that there's something wrong with the setting of S5PV210_EINT_WAKEUP_MASK as introduced in a8be2af0218cf037704dc2e733bf56d6560fa324 as here's a dmesg snipper:

samsung-pinctrl e0200000.pinctrl: Setting external wakeup interrupt mask: 0xff0fff7f
suspend_one_vic: suspending vic at (ptrval)
suspend_one_vic: suspending vic at (ptrval)
suspend_one_vic: suspending vic at (ptrval)
suspend_one_vic: suspending vsc at (ptrval)
5pv210_suspend_enter: suspending the system...
s5pv210_suspend_enter: wakeup masks: ffffffff,00000000

Note that pinctl is setting the eint mask to 0xff0fff7f while the s5pv210/pm.c is reading 0 (which good news for us is that 0 is pass based on vendor driver)

Have added https://github.com/xc-racer99/android_kernel_samsung_aries/commit/d7620a5b43864b2cac04cb1762f3537b30842871 as it doesn't appear to be present right now in mainline but doesn't help.

Logs at https://gist.github.com/xc-racer99/fc3933f91408413820f343da1c258218 branch at https://github.com/xc-racer99/linux/tree/suspend-test

xc-racer99 commented 5 years ago

Ok, after doing a bit of debugging and bisecting; I've found that wakeup works* up until f9b9a6217cf10fd5d3002627cc13c4789a777213 - why this commit breaks things I have no idea whatsoever. It may be that it needs a fixup somewhere else and git bisect happened to drop upon it first as opposed to the actual commit that is somewhere between 3.12 and 3.13

xc-racer99 commented 5 years ago

Finally getting back to this a bit, it looks as if the culprit bit of f9b9a6217cf10fd5d3002627cc13c4789a777213 is at https://github.com/PabloPL/linux/blob/f9b9a6217cf10fd5d3002627cc13c4789a777213/fs/sysfs/file.c#L59 - if I remove the sysfs_type(sd) and just return false, resume works again. Notably, if I leave the check in there as a no-op and still return false all of the time, resume is broken.

Even switching it up to manually check ->s_flags, resume is broken. So we somehow have something wrong with a bit of sysfs, presumably a nullptr happening on resume. I suspect this is just a manifestation of some larger issue, possibly with a sysfs failing to register and then not getting properly removed.

xc-racer99 commented 5 years ago

This workaround stops working as of f6acf8bb6a40ba3bfcf542e4c4c9e8968c8cb57a - note that I can access other members of sd (notably s_name as the one I tested) with resume still working.

xc-racer99 commented 5 years ago

Haven't really worked on this again, but did some testing on the 3.0 kernel. Looks like we need to make sure that UART2 clock is enabled when suspending as this more or less allows the FIQ debugger to be disabled without a SoD.

xc-racer99 commented 5 years ago

Ok, testing again on v5.3-rc2, I can suspend/resume without a problem when I have clk_ignore_unused in the cmdline. Removing it, and I can't resume. So need to figure out which clock it is. Edit: This is with stock IBL/SBL, not with u-boot's SPL Edit2: It doesn't appear to be the UART clocks either. Need to check status of PLLs. Edit3: Simply restoring the registers as they are with still disabling the clocks doesn't work. So need to add CLK_IGNORE_UNUSED to some of the clocks until I figure out which one(s) it is... Edit4: Guilty clock is sclk_uart2. With a diff of

diff --git a/drivers/clk/samsung/clk-s5pv210.c b/drivers/clk/samsung/clk-s5pv210.c
index e7b68ffe36de..7eb6265a53ad 100644
--- a/drivers/clk/samsung/clk-s5pv210.c
+++ b/drivers/clk/samsung/clk-s5pv210.c
@@ -594,7 +594,7 @@ static const struct samsung_gate_clock gate_clks[] __initconst = {
        GATE(SCLK_SPI0, "sclk_spi0", "dout_spi0", CLK_SRC_MASK0, 16,
                        CLK_SET_RATE_PARENT, 0),
        GATE(SCLK_UART2, "sclk_uart2", "dout_uart2", CLK_SRC_MASK0, 14,
-                       CLK_SET_RATE_PARENT, 0),
+                       CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
        GATE(SCLK_UART1, "sclk_uart1", "dout_uart1", CLK_SRC_MASK0, 13,
                        CLK_SET_RATE_PARENT, 0),
        GATE(SCLK_UART0, "sclk_uart0", "dout_uart0", CLK_SRC_MASK0, 12,

resume works just fine.

xc-racer99 commented 5 years ago

Ok, further to the above, it appears that CONFIG_PM_DEBUG breaks suspend... To get around this problem, apply the diff from https://gist.github.com/xc-racer99/f40a3d59d6a73545596aa238fc387be4

Don't know if this is a known v5.3-rc3 bug or if there's still something weird on our platform...

xc-racer99 commented 5 years ago

Ok, I have some initial fixes at https://github.com/xc-racer99/linux/tree/for-upstream/pm-fixes

Still todo:

xc-racer99 commented 4 years ago

Ok, GPIO pinctrl changes have been accepted upstream. Kernel should be built with CONFIG_SERIAL_SAMSUNG_CONSOLE=n as our bootloader does something weird with the clocks when resuming and then suspend should just work!

Leaving issue open until a nice workaround for CONFIG_SERIAL_SAMSUNG_CONSOLE is found. Note that https://github.com/xc-racer99/linux/commit/f61187424131d015053280d7e526177463e1714b works as well, but is suboptimal.

xc-racer99 commented 2 years ago

Closing this, it's a bootloader issue.