[PATCH v8 0/2] Adds PMU and S2R support for exynos5420

Hello Vikas,

On Thu, Oct 2, 2014 at 4:24 PM, Vikas Sajjan [off-list ref] wrote:

Hi Javier,

On Wed, Oct 1, 2014 at 7:20 PM, Javier Martinez Canillas
[off-list ref] wrote:

quoted

Hello Vikas,

On Wed, Oct 1, 2014 at 12:23 PM, Vikas Sajjan [off-list ref] wrote:

quoted

My git log looks like below on top of Kukjin's for-next branch,

d861ddd clk: exynos: Add CLK_IGNORE_UNUSED to aclk200_disp1 and aclk300_disp1
adc14dc POSTED: ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
d61fc43 ARM: exynos5: Add Suspend-to-RAM support for 5420
3d1d7bd ARM: exynos5: Add PMU support for 5420
a8887b3 mfd: syscon: Decouple syscon interface from platform devices
072e2bc ARM: EXYNOS: Move PMU specific definitions from common.h
ec2f950 ARM: EXYNOS: Add platform driver support for Exynos PMU

I tested Kukjin's for-next branch (HEAD in commit a84aaa7) + the
patches you mentioned and the system enters in suspend mode but the
RTC alarm IRQ does not make it resume. Is the branch you are using to
test public so I can give it a try?

Not yet, but as I mentioned, I have only above mentioned 7 patches
atop kukjin's for-next.
only difference is the patch " ARM: EXYNOS: Use MCPM call-backs to
support S2R on Exynos5420"
which I had rebased myself.

Yeah, I still don't know why is behaving differently.

I am out of office till 7th October, once I am back, I can send you
all those 7 patches, config file and S2R log.

Ok, thanks a lot.

quoted

quoted

recently I noticed that, without the CLK_IGNORE_UNUSED flag for
aclk200_disp1 and aclk300_disp1 CLK,  the system is NOT suspending,
which was NOT the case when i had posted my previous revisions.

I tried both with and without your patch that adds the
CLK_IGNORE_UNUSED to aclk200_disp1 and aclk300_disp1 and in both cases
it behaves the same, the system seems to go into suspend mode but
never resumes:

Can you confirm that the system has really suspended, I mean can you
measure VDD_EGL or VDD_KFC and check or by any other method you know
of.

I'll see how I can measure but it seems the system is suspended
correctly and the problem is on resuming (more on that below).

quoted

# echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > /sys/power/state
[  105.376596] PM: Syncing filesystems ... done.
[  105.383207] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  105.388681] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[  105.488589] wake enabled for irq 281
[  105.491609] wake enabled for irq 280
[  105.498102] wake enabled for irq 284
[  105.554736] PM: suspend of devices complete after 155.406 msecs
[  105.562572] PM: late suspend of devices complete after 3.361 msecs
[  105.570389] PM: noirq suspend of devices complete after 3.102 msecs
[  105.575185] Disabling non-boot CPUs ...
[  105.579706] IRQ153 no longer affine to CPU1
[  105.580008] CPU1: shutdown
[  105.587230] IRQ154 no longer affine to CPU2
[  105.587472] CPU2: shutdown
[  105.594953] IRQ155 no longer affine to CPU3
[  105.595190] CPU3: shutdown
[  105.602464] IRQ160 no longer affine to CPU4
[  105.602979] CPU4: shutdown
[  105.609996] IRQ161 no longer affine to CPU5
[  105.610424] CPU5: shutdown
[  105.617116] IRQ162 no longer affine to CPU6
[  105.617557] CPU6: shutdown
[  105.625163] IRQ163 no longer affine to CPU7
[  105.625596] CPU7: shutdown

I'm testing on a Exynos5420 Peach Pit using exynos_defconfig and
disabling CONFIG_BL_SWITCHER as you suggested. My bootargs is:

I too tested on 5420 based peach-pit board with exynos_defconfig +
disabled CONFIG_BL_SWITCHER.

It did suspend and resume gracefully.

I did further testing by enabling some PM debug options
(CONFIG_PM_DEBUG and  CONFIG_PM_ADVANCED_DEBUG) and tested different
suspend modes (freezer, devices, processors and core).

With the three first modes, s2r worked correctly but when trying the
core mode the non-boot CPUs failed to come online again. I tested that
this works on other Exynos SoCs (5250 and 4412):

# grep -c processor /proc/cpuinfo
8
# echo core > /sys/power/pm_test
# echo mem > /sys/power/state
...
Enabling non-boot CPUs ...
CPU1: failed to come online
Error taking CPU1 up: -5
CPU2: failed to come online
Error taking CPU2 up: -5
CPU3: failed to come online
Error taking CPU3 up: -5
CPU4: failed to come online
Error taking CPU4 up: -5
CPU5: failed to come online
Error taking CPU5 up: -5
CPU6: failed to come online
Error taking CPU6 up: -5
CPU7: failed to come online
Error taking CPU7 up: -5
...
# grep -c processor /proc/cpuinfo
1

The -5 (-EIO) error is because even though the call to
exynos_boot_secondary() succeeds in _cpu_up() [0],
secondary_start_kernel() [1] is never called so the CPU is not marked
as online nor the cpu_running completion handler is waked up. So
waiting for it in _cpu_up() times out and cpu_online(cpu) is false.

I still didn't figure out why the secondary CPUs are not jumping into
their expected entry point so any hints are welcomed.

quoted

console=ttySAC3,115200 debug earlyprintk root=/dev/mmcblk1p2 rootwait
rw no_console_suspend

looks fine.

quoted

And I'm booting using a chained nv-uboot with built version:

U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach

I shall update my U-Boot build version, once I am back at office.

Maybe that is the difference in our setups...

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/arch/arm/kernel/smp.c#L91
[1]: http://lxr.free-electrons.com/source/arch/arm/kernel/smp.c#L330