[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

Sergei Shtylyov sergei.shtylyov at cogentembedded.com
Fri Jun 10 12:29:17 PDT 2016


On 06/10/2016 04:02 AM, Simon Horman wrote:

>> [...]
>>
>>>>> And that the system behaves sanely on suspend/resume.
>>>>
>>>>   I'd be thankful if you told me how to test that. :-)
>>>
>>> System suspend:
>>>
>>>    echo mem > /sys/power/state
>>
>>    Oh. I know that one! :-)
>>
>>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
>>> Serial should work too, echo "enabled" to the corresponding wakeup
>>> file in /sys first.
>>
>>    I'm afraid I couldn't find that file. All I saw were RPM controls...
>>
>>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
>>
>>    There's no problems suspending, it's the resuming that's a problem for me.
>>
>>> Good luck!
>>
>>    As usual, there was no luck. :-)
>>
>> WBR, Sergei
>
> Does resume work for UP (i.e. without SMP)?

    No. My problem with resume is I can't wake up the remote system. I don't 
see the needed 'wakeup' file in /sys/devices/platform/soc/e6e60000.serial/...
     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do

$ echo -n core /sys/.power/pm_test

the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.

> How did testing CPU hotplug go? Did it work for all CPUs?

    Sure!
    The only problem I'm seeing (again) is the RCAN clock failing to register:

rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)

    I was going to look at it yesterday but (wrongly) thought it somehow cured 
itself... I'll look at it now.

MBR, Sergei




More information about the linux-arm-kernel mailing list