From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Subject: Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree Date: Tue, 14 Jun 2016 09:43:17 +0900 Message-ID: <20160614004317.GC6456@verge.net.au> References: <13205049.n7pM8utpHF@wasted.cogentembedded.com> <2539026.OyU5nvpxa6@wasted.cogentembedded.com> <20160601005751.GG20527@verge.net.au> <20160610010245.GA10152@verge.net.au> <8efb1c7e-5463-2556-744c-d327886d92d4@cogentembedded.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <8efb1c7e-5463-2556-744c-d327886d92d4-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sergei Shtylyov Cc: Geert Uytterhoeven , linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Magnus Damm , Russell King , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote: > 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. 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@e6ce0000 node in DT 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! * > >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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kirsty.vergenet.net ([202.4.237.240]:59262 "EHLO kirsty.vergenet.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753642AbcFNAnW (ORCPT ); Mon, 13 Jun 2016 20:43:22 -0400 Date: Tue, 14 Jun 2016 09:43:17 +0900 From: Simon Horman To: Sergei Shtylyov Cc: Geert Uytterhoeven , linux-renesas-soc@vger.kernel.org, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , Magnus Damm , Russell King , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree Message-ID: <20160614004317.GC6456@verge.net.au> References: <13205049.n7pM8utpHF@wasted.cogentembedded.com> <2539026.OyU5nvpxa6@wasted.cogentembedded.com> <20160601005751.GG20527@verge.net.au> <20160610010245.GA10152@verge.net.au> <8efb1c7e-5463-2556-744c-d327886d92d4@cogentembedded.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8efb1c7e-5463-2556-744c-d327886d92d4@cogentembedded.com> Sender: linux-renesas-soc-owner@vger.kernel.org List-ID: On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote: > 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. 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@e6ce0000 node in DT 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! * > >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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: horms@verge.net.au (Simon Horman) Date: Tue, 14 Jun 2016 09:43:17 +0900 Subject: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree In-Reply-To: <8efb1c7e-5463-2556-744c-d327886d92d4@cogentembedded.com> References: <13205049.n7pM8utpHF@wasted.cogentembedded.com> <2539026.OyU5nvpxa6@wasted.cogentembedded.com> <20160601005751.GG20527@verge.net.au> <20160610010245.GA10152@verge.net.au> <8efb1c7e-5463-2556-744c-d327886d92d4@cogentembedded.com> Message-ID: <20160614004317.GC6456@verge.net.au> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote: > 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. 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 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! * > >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.