Re: exynos5800-peach-pi: suspend/resume (still) broken
Hello Abhilash,
On 03/20/2015 06:40 PM, Abhilash Kesavan wrote:
Regarding the mdma0 disablement, it looks like for the system to
suspend properly the mdma0 pclk needs to stay on.
I had time today again to work on this issue and the best
place I found to enable and disable the mdma0 clock is in
exynos5420_pm_{prepare,resume}. Please let me know if you
have a better idea of where the clock should be managed.
I'll send a RFC patch-set soon.
Regards,
Abhilash
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hello Abhilash,
On 03/27/2015 03:06 PM, Abhilash Kesavan wrote:
Hello Javier,
On Fri, Mar 27, 2015 at 6:59 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hello Abhilash,
On 03/20/2015 06:40 PM, Abhilash Kesavan wrote:
Regarding the mdma0 disablement, it looks like for the system to
suspend properly the mdma0 pclk needs to stay on.
I had time today again to work on this issue and the best
place I found to enable and disable the mdma0 clock is in
exynos5420_pm_{prepare,resume}. Please let me know if you
have a better idea of where the clock should be managed.
Modifying exynos5420_clk_suspend in
drivers/clk/samsung/clk-exynos5420.c would be another way to go,
however I have not tested if this actually works.
Sorry, I just posted the series: [RFC PATCH 0/2] ARM: EXYNOS: Fix
Suspend-to-RAM on Exynos5420 before reading your email...
Please let me know if you think that is not the best appraoch and
I can come up with another one to modify the clk-exynos5420 suspend
and resume callbacks.
Another option is to use Lee Jone's clocks always on support [0]
that has been posted.
I'll send a RFC patch-set soon.
Thanks for the effort.
Thanks to you for all the help.
Regards,
Abhilash
Best regards,
Javier
[0]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/326616.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hello Javier,
On Fri, Mar 27, 2015 at 6:59 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hello Abhilash,
On 03/20/2015 06:40 PM, Abhilash Kesavan wrote:
Regarding the mdma0 disablement, it looks like for the system to
suspend properly the mdma0 pclk needs to stay on.
I had time today again to work on this issue and the best
place I found to enable and disable the mdma0 clock is in
exynos5420_pm_{prepare,resume}. Please let me know if you
have a better idea of where the clock should be managed.
Modifying exynos5420_clk_suspend in
drivers/clk/samsung/clk-exynos5420.c would be another way to go,
however I have not tested if this actually works.
I'll send a RFC patch-set soon.
Thanks for the effort.
Regards,
Abhilash
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hello, On Wed, Mar 18, 2015 at 4:01 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: +people involved in Exynos5420 S2R support (Abhilash, Vikas and Pankaj) Hello Kevin, On 03/17/2015 06:35 PM, Kevin Hilman wrote: I've tried suspend/resume on peach-pi using v4.0-rc4, next/master and samsung/for-next, and it doesn't seem to work on any of them. The first problem was the exynos DRM driver is faulting so I had to set CONFIG_\ DRM_EXYNOS=n for testing in mainline, this is fixed in -next. Note that RTC wake from suspend to idle seems to work, which suggests that the RTC wake alarms are working fine. I tried with both the s3c and the max77802 RTC drivers (e.g. rtcwake -d rtc0 -m freeze -s4) Indeed, both max77802 and S3C RTCs wake alarm IRQ are being triggered: # echo +1 /sys/class/rtc/rtc0/wakealarm # echo +1 /sys/class/rtc/rtc1/wakealarm # grep alarm /proc/interrupts 62: 1 0 0 0 PMU 43 s3c2410-rtc alarm 124: 0 0 1 0 max77802-rtc 1 rtc-alarm1 and also as you said suspend-to-idle and resume works: # echo +5 /sys/class/rtc/rtc1/wakealarm echo freeze /sys/power/state However, trying suspend to RAM (rtcwake -d rtc0 -m mem -s4), it never resumes, and adding no_console_suspend doesn't give anything useful. Anyone else having better luck with suspend/resume on peach-pi? # echo +2 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Suspend and CPUs shutdown seems to succeed according to [0] but the system never wakes up... I also tried to wakeup the system with the keyboard and the trackpad that is a wake up source but it does not work either. I remember that when the 5420 s2r support series were posted, aclk200_disp1 and aclk300_disp1 clocks needed to be marked as CLK_IGNORE_UNUSED but afaiu that was only because display support was not yet merged but it is now. I tried anyways both marking those clocks as CLK_IGNORE_UNUSED and passing the clk_ignore_unused to the kernel command line but did not work either. Abhilash, Vikas, Pankaj, Any ideas of what could be causing this regression? It seems that by the time the Exynos5420 S2R support landed in mainline, it was already not working which makes it hard to bisect what caused the issue. I remember the Pi power LED changing color from blue on suspend. Does that happen ? I'll try reproducing the issue and then probably use an old working s2r branch in one of my local repos to track this down. Regards, Abhilash I also tried on exynos5422-odroid-xu3, but that doesn't seem to have any working RTC drivers. :( Kevin Best regards, Javier [0]: [ 517.448354] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 517.453827] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 517.547922] wake enabled for irq 123 [ 517.551373] wake enabled for irq 120 [ 518.285645] wake enabled for irq 129 [ 518.287762] wake enabled for irq 130 [ 518.291901] PM: suspend of devices complete after 827.494 msecs [ 518.297218] ldo_35: No configuration [ 518.300769] ldo_34: No configuration [ 518.304327] ldo_33: No configuration [ 518.307899] ldo_32: No configuration [ 518.311513] ldo_29: No configuration [ 518.315000] ldo_28: No configuration [ 518.318554] ldo_27: No configuration [ 518.322090] ldo_26: No configuration [ 518.325667] ldo_25: No configuration [ 518.329224] ldo_24: No configuration [ 518.332780] ldo_23: No configuration [ 518.336317] ldo_21: No configuration [ 518.339894] ldo_20: No configuration [ 518.343451] ldo_19: No configuration [ 518.346988] ldo_18: No configuration [ 518.351369] vdd_1v8_7: No configuration [ 518.354739] vdd_1v2_2: No configuration [ 518.362718] PM: late suspend of devices complete after 3.781 msecs [ 518.371062] PM: noirq suspend of devices complete after 3.631 msecs [ 518.375863] Disabling non-boot CPUs ... [ 518.380035] IRQ50 no longer affine to CPU1 [ 518.380266] CPU1: shutdown [ 518.399253] IRQ51 no longer affine to CPU2 [ 518.399472] CPU2: shutdown [ 518.418914] IRQ52 no longer affine to CPU3 [ 518.419121] CPU3: shutdown ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hello Abhilash, On 03/20/2015 06:40 PM, Abhilash Kesavan wrote: I have made some progress on this. This is the current state: If I use next-20141114 (which was when the S2R code first appeared in linux-next), then all is good. next-20141117 is fine too but things are broken in next-20141118. I have narrowed it down to the commit: ae43b32 ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12. The only way I see this impacting s2r is because it disables the dma pclk while suspending or before. Checking further, will update in a bit. OK, so disabling the mdma0 node in arch/arm/boot/dts/exynos5420.dtsi gets things working. Like Kevin mentioned in the initial report, I need to disable DRM else there is a crash while suspending. With these two changes, on linus' tree and kgene's for-next s2r works fine. Awesome, thanks a lot for digging this out! On linux-next, I need to disable CONFIG_MWIFIEX too. Yes, I also saw that issue with mwfiex when suspend-to-idle (which works in -next) due the MMC_PM_KEEP_POWER flag being set in the host pm caps. But I don't see that being set in the host driver. Also, I observe cros-ec-spi transfer failures during resume and sometimes it is unable to re-enable the tps fets causing a crash. However, that would be a driver specific issue. Indeed, I can take a look to that issue as well. Regarding the mdma0 disablement, it looks like for the system to suspend properly the mdma0 pclk needs to stay on. It seems so, I remember we had other issues with the mentioned commit due clocks being gated. For example the mau_epll clock that was needed to access the audss block registers and caused a boot hang on Exyos5420. That specific issue was fixed by f1e9203e2366 (clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated) which solves it by enabling the mau_epll on probe. Regards, Abhilash Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hi,
On Fri, Mar 20, 2015 at 9:59 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Javier,
On Fri, Mar 20, 2015 at 9:46 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hello Abhilash,
On 03/20/2015 03:23 PM, Abhilash Kesavan wrote:
On 03/17/2015 06:35 PM, Kevin Hilman wrote:
Anyone else having better luck with suspend/resume on peach-pi?
# echo +2 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state
Suspend and CPUs shutdown seems to succeed according to [0] but the system
never wakes up...
I also tried to wakeup the system with the keyboard and the trackpad that
is
a wake up source but it does not work either.
I remember that when the 5420 s2r support series were posted, aclk200_disp1
and aclk300_disp1 clocks needed to be marked as CLK_IGNORE_UNUSED but afaiu
that was only because display support was not yet merged but it is now.
I tried anyways both marking those clocks as CLK_IGNORE_UNUSED and passing
the clk_ignore_unused to the kernel command line but did not work either.
Abhilash, Vikas, Pankaj,
Any ideas of what could be causing this regression? It seems that by the
time the Exynos5420 S2R support landed in mainline, it was already not
working which makes it hard to bisect what caused the issue.
I remember the Pi power LED changing color from blue on suspend. Does
Thanks a lot for answering. Who manages that LED? is the kernel or the
firwmare in the EC? I tried suspend to ram using ChromeOS 3.8 kernel and
I see that the blue LED is indeed turned off on suspend but that does not
happen in mainline.
I am not too sure. It was just something I remembered from earlier.
that happen ? I'll try reproducing the issue and then probably use an
old working s2r branch in one of my local repos to track this down.
If I checkout mainline with HEAD in your commit adc548d77c22
(ARM: EXYNOS: Use MCPM call-backs to support S2R on exynos5420) + the
patch you mentioned back then to keep the aclk200_disp1 and aclk300_disp1
clocks enabled even when not used [0], I have S2R working. But even with
that commit, I don't see the blue LED to be turn off like is the case in
the ChromeOS 3.8 kernel.
So I think you can use that as a base. I tried bisecting but it is tricky
due other issues masking the S2R regression. I also tried to compare the
diff between adc548d77c22 and v3.19-rc1 that is the first known bad afaict
but didn't find any relevant either.
By adding printouts I can tell that all the CPUs enter exynos_power_down()
in arch/arm/mach-exynos/mcpm-exynos.c and also the last man disables the
cluster for both Cortex A-15 and A-7 clusters.
So it seems that the problem is on the resume path.
I have made some progress on this. This is the current state:
If I use next-20141114 (which was when the S2R code first appeared in
linux-next), then all is good. next-20141117 is fine too but things
are broken in next-20141118.
I have narrowed it down to the commit: ae43b32 ARM: 8202/1:
dmaengine: pl330: Add runtime Power Management support v12. The only
way I see this impacting s2r is because it disables the dma pclk while
suspending or before.
Checking further, will update in a bit.
OK, so disabling the mdma0 node in arch/arm/boot/dts/exynos5420.dtsi
gets things working. Like Kevin mentioned in the initial report, I
need to disable DRM else there is a crash while suspending. With these
two changes, on linus' tree and kgene's for-next s2r works fine.
On linux-next, I need to disable CONFIG_MWIFIEX too.
Also, I observe cros-ec-spi transfer failures during resume and
sometimes it is unable to re-enable the tps fets causing a crash.
However, that would be a driver specific issue.
Regarding the mdma0 disablement, it looks like for the system to
suspend properly the mdma0 pclk needs to stay on.
Regards,
Abhilash
Regards,
Abhilash
Best regards,
Javier
[0]:
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 848d602efc06..d8b66339d564 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -932,14 +932,14 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
__initdata = {
GATE(0, aclk400_mscl, mout_user_aclk400_mscl,
GATE_BUS_TOP, 17, 0, 0),
GATE(0, aclk200_disp1, mout_user_aclk200_disp1,
- GATE_BUS_TOP, 18, 0, 0),
+ GATE_BUS_TOP, 18, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_MPHY_IXTAL24, sclk_mphy_ixtal24,
mphy_refclk_ixtal24,
GATE_BUS_TOP, 28, 0, 0),
GATE(CLK_SCLK_HSIC_12M, sclk_hsic_12m, ff_hsic_12m,
GATE_BUS_TOP, 29, 0, 0),
GATE(0, aclk300_disp1, mout_user_aclk300_disp1,
- SRC_MASK_TOP2, 24, 0, 0),
+ SRC_MASK_TOP2, 24, CLK_IGNORE_UNUSED, 0),
GATE(CLK_MAU_EPLL, mau_epll, mout_mau_epll_clk,
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hello Abhilash,
On 03/20/2015 03:23 PM, Abhilash Kesavan wrote:
On 03/17/2015 06:35 PM, Kevin Hilman wrote:
Anyone else having better luck with suspend/resume on peach-pi?
# echo +2 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state
Suspend and CPUs shutdown seems to succeed according to [0] but the system
never wakes up...
I also tried to wakeup the system with the keyboard and the trackpad that is
a wake up source but it does not work either.
I remember that when the 5420 s2r support series were posted, aclk200_disp1
and aclk300_disp1 clocks needed to be marked as CLK_IGNORE_UNUSED but afaiu
that was only because display support was not yet merged but it is now.
I tried anyways both marking those clocks as CLK_IGNORE_UNUSED and passing
the clk_ignore_unused to the kernel command line but did not work either.
Abhilash, Vikas, Pankaj,
Any ideas of what could be causing this regression? It seems that by the
time the Exynos5420 S2R support landed in mainline, it was already not
working which makes it hard to bisect what caused the issue.
I remember the Pi power LED changing color from blue on suspend. Does
Thanks a lot for answering. Who manages that LED? is the kernel or the
firwmare in the EC? I tried suspend to ram using ChromeOS 3.8 kernel and
I see that the blue LED is indeed turned off on suspend but that does not
happen in mainline.
that happen ? I'll try reproducing the issue and then probably use an
old working s2r branch in one of my local repos to track this down.
If I checkout mainline with HEAD in your commit adc548d77c22
(ARM: EXYNOS: Use MCPM call-backs to support S2R on exynos5420) + the
patch you mentioned back then to keep the aclk200_disp1 and aclk300_disp1
clocks enabled even when not used [0], I have S2R working. But even with
that commit, I don't see the blue LED to be turn off like is the case in
the ChromeOS 3.8 kernel.
So I think you can use that as a base. I tried bisecting but it is tricky
due other issues masking the S2R regression. I also tried to compare the
diff between adc548d77c22 and v3.19-rc1 that is the first known bad afaict
but didn't find any relevant either.
By adding printouts I can tell that all the CPUs enter exynos_power_down()
in arch/arm/mach-exynos/mcpm-exynos.c and also the last man disables the
cluster for both Cortex A-15 and A-7 clusters.
So it seems that the problem is on the resume path.
Regards,
Abhilash
Best regards,
Javier
[0]:
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 848d602efc06..d8b66339d564 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -932,14 +932,14 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
__initdata = {
GATE(0, aclk400_mscl, mout_user_aclk400_mscl,
GATE_BUS_TOP, 17, 0, 0),
GATE(0, aclk200_disp1, mout_user_aclk200_disp1,
- GATE_BUS_TOP, 18, 0, 0),
+ GATE_BUS_TOP, 18, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_MPHY_IXTAL24, sclk_mphy_ixtal24, mphy_refclk_ixtal24,
GATE_BUS_TOP, 28, 0, 0),
GATE(CLK_SCLK_HSIC_12M, sclk_hsic_12m, ff_hsic_12m,
GATE_BUS_TOP, 29, 0, 0),
GATE(0, aclk300_disp1, mout_user_aclk300_disp1,
- SRC_MASK_TOP2, 24, 0, 0),
+ SRC_MASK_TOP2, 24, CLK_IGNORE_UNUSED, 0),
GATE(CLK_MAU_EPLL, mau_epll, mout_mau_epll_clk,
SRC_MASK_TOP7, 20, 0, 0),
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
Hi Javier,
On Fri, Mar 20, 2015 at 9:46 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hello Abhilash,
On 03/20/2015 03:23 PM, Abhilash Kesavan wrote:
On 03/17/2015 06:35 PM, Kevin Hilman wrote:
Anyone else having better luck with suspend/resume on peach-pi?
# echo +2 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state
Suspend and CPUs shutdown seems to succeed according to [0] but the system
never wakes up...
I also tried to wakeup the system with the keyboard and the trackpad that is
a wake up source but it does not work either.
I remember that when the 5420 s2r support series were posted, aclk200_disp1
and aclk300_disp1 clocks needed to be marked as CLK_IGNORE_UNUSED but afaiu
that was only because display support was not yet merged but it is now.
I tried anyways both marking those clocks as CLK_IGNORE_UNUSED and passing
the clk_ignore_unused to the kernel command line but did not work either.
Abhilash, Vikas, Pankaj,
Any ideas of what could be causing this regression? It seems that by the
time the Exynos5420 S2R support landed in mainline, it was already not
working which makes it hard to bisect what caused the issue.
I remember the Pi power LED changing color from blue on suspend. Does
Thanks a lot for answering. Who manages that LED? is the kernel or the
firwmare in the EC? I tried suspend to ram using ChromeOS 3.8 kernel and
I see that the blue LED is indeed turned off on suspend but that does not
happen in mainline.
I am not too sure. It was just something I remembered from earlier.
that happen ? I'll try reproducing the issue and then probably use an
old working s2r branch in one of my local repos to track this down.
If I checkout mainline with HEAD in your commit adc548d77c22
(ARM: EXYNOS: Use MCPM call-backs to support S2R on exynos5420) + the
patch you mentioned back then to keep the aclk200_disp1 and aclk300_disp1
clocks enabled even when not used [0], I have S2R working. But even with
that commit, I don't see the blue LED to be turn off like is the case in
the ChromeOS 3.8 kernel.
So I think you can use that as a base. I tried bisecting but it is tricky
due other issues masking the S2R regression. I also tried to compare the
diff between adc548d77c22 and v3.19-rc1 that is the first known bad afaict
but didn't find any relevant either.
By adding printouts I can tell that all the CPUs enter exynos_power_down()
in arch/arm/mach-exynos/mcpm-exynos.c and also the last man disables the
cluster for both Cortex A-15 and A-7 clusters.
So it seems that the problem is on the resume path.
I have made some progress on this. This is the current state:
If I use next-20141114 (which was when the S2R code first appeared in
linux-next), then all is good. next-20141117 is fine too but things
are broken in next-20141118.
I have narrowed it down to the commit: ae43b32 ARM: 8202/1:
dmaengine: pl330: Add runtime Power Management support v12. The only
way I see this impacting s2r is because it disables the dma pclk while
suspending or before.
Checking further, will update in a bit.
Regards,
Abhilash
Regards,
Abhilash
Best regards,
Javier
[0]:
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 848d602efc06..d8b66339d564 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -932,14 +932,14 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
__initdata = {
GATE(0, aclk400_mscl, mout_user_aclk400_mscl,
GATE_BUS_TOP, 17, 0, 0),
GATE(0, aclk200_disp1, mout_user_aclk200_disp1,
- GATE_BUS_TOP, 18, 0, 0),
+ GATE_BUS_TOP, 18, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_MPHY_IXTAL24, sclk_mphy_ixtal24,
mphy_refclk_ixtal24,
GATE_BUS_TOP, 28, 0, 0),
GATE(CLK_SCLK_HSIC_12M, sclk_hsic_12m, ff_hsic_12m,
GATE_BUS_TOP, 29, 0, 0),
GATE(0, aclk300_disp1, mout_user_aclk300_disp1,
- SRC_MASK_TOP2, 24, 0, 0),
+ SRC_MASK_TOP2, 24, CLK_IGNORE_UNUSED, 0),
GATE(CLK_MAU_EPLL, mau_epll, mout_mau_epll_clk,
SRC_MASK_TOP7, 20, 0, 0),
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5800-peach-pi: suspend/resume (still) broken
+people involved in Exynos5420 S2R support (Abhilash, Vikas and Pankaj) Hello Kevin, On 03/17/2015 06:35 PM, Kevin Hilman wrote: I've tried suspend/resume on peach-pi using v4.0-rc4, next/master and samsung/for-next, and it doesn't seem to work on any of them. The first problem was the exynos DRM driver is faulting so I had to set CONFIG_\ DRM_EXYNOS=n for testing in mainline, this is fixed in -next. Note that RTC wake from suspend to idle seems to work, which suggests that the RTC wake alarms are working fine. I tried with both the s3c and the max77802 RTC drivers (e.g. rtcwake -d rtc0 -m freeze -s4) Indeed, both max77802 and S3C RTCs wake alarm IRQ are being triggered: # echo +1 /sys/class/rtc/rtc0/wakealarm # echo +1 /sys/class/rtc/rtc1/wakealarm # grep alarm /proc/interrupts 62: 1 0 0 0 PMU 43 s3c2410-rtc alarm 124: 0 0 1 0 max77802-rtc 1 rtc-alarm1 and also as you said suspend-to-idle and resume works: # echo +5 /sys/class/rtc/rtc1/wakealarm echo freeze /sys/power/state However, trying suspend to RAM (rtcwake -d rtc0 -m mem -s4), it never resumes, and adding no_console_suspend doesn't give anything useful. Anyone else having better luck with suspend/resume on peach-pi? # echo +2 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Suspend and CPUs shutdown seems to succeed according to [0] but the system never wakes up... I also tried to wakeup the system with the keyboard and the trackpad that is a wake up source but it does not work either. I remember that when the 5420 s2r support series were posted, aclk200_disp1 and aclk300_disp1 clocks needed to be marked as CLK_IGNORE_UNUSED but afaiu that was only because display support was not yet merged but it is now. I tried anyways both marking those clocks as CLK_IGNORE_UNUSED and passing the clk_ignore_unused to the kernel command line but did not work either. Abhilash, Vikas, Pankaj, Any ideas of what could be causing this regression? It seems that by the time the Exynos5420 S2R support landed in mainline, it was already not working which makes it hard to bisect what caused the issue. I also tried on exynos5422-odroid-xu3, but that doesn't seem to have any working RTC drivers. :( Kevin Best regards, Javier [0]: [ 517.448354] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 517.453827] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 517.547922] wake enabled for irq 123 [ 517.551373] wake enabled for irq 120 [ 518.285645] wake enabled for irq 129 [ 518.287762] wake enabled for irq 130 [ 518.291901] PM: suspend of devices complete after 827.494 msecs [ 518.297218] ldo_35: No configuration [ 518.300769] ldo_34: No configuration [ 518.304327] ldo_33: No configuration [ 518.307899] ldo_32: No configuration [ 518.311513] ldo_29: No configuration [ 518.315000] ldo_28: No configuration [ 518.318554] ldo_27: No configuration [ 518.322090] ldo_26: No configuration [ 518.325667] ldo_25: No configuration [ 518.329224] ldo_24: No configuration [ 518.332780] ldo_23: No configuration [ 518.336317] ldo_21: No configuration [ 518.339894] ldo_20: No configuration [ 518.343451] ldo_19: No configuration [ 518.346988] ldo_18: No configuration [ 518.351369] vdd_1v8_7: No configuration [ 518.354739] vdd_1v2_2: No configuration [ 518.362718] PM: late suspend of devices complete after 3.781 msecs [ 518.371062] PM: noirq suspend of devices complete after 3.631 msecs [ 518.375863] Disabling non-boot CPUs ... [ 518.380035] IRQ50 no longer affine to CPU1 [ 518.380266] CPU1: shutdown [ 518.399253] IRQ51 no longer affine to CPU2 [ 518.399472] CPU2: shutdown [ 518.418914] IRQ52 no longer affine to CPU3 [ 518.419121] CPU3: shutdown -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
