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

[Sergei Shtylyov]

Hello.

On 06/14/2016 03:43 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.
>
> That seems promising but it seems curious that there is no wakeup file.
>
> On Lager the following procedure works for me using
> renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.
>
> 0. Add wakeup-source property to serial at e6ce0000 node in DT

    Ah, stupid me, it was the piece that I'd overlooked!

> 1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
> 2. echo mem > /sys/power/state
> 3. Provide input on serial console
>
> * Success! *

    Yeah, works now!
    Sorry, I had no previous experience with the PM. Was unsupported feature 
back in MontaVista... :-)

>>> How did testing CPU hotplug go? Did it work for all CPUs?
>>
>>    Sure!
>
> Great!
>
>>    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.
>
> Is this resolved? If not perhaps you could consider removing the node
> in question for now.

    That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole 
node)...

MBR, Sergei