* [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
@ 2014-10-23 11:31 Geert Uytterhoeven
2014-10-27 1:08 ` Simon Horman
0 siblings, 1 reply; 7+ messages in thread
From: Geert Uytterhoeven @ 2014-10-23 11:31 UTC (permalink / raw)
To: linux-arm-kernel
The D4 power domain contains the Coresight-ETM hardware block.
As long as the ARM debug/perf code doesn't use resource management with
runtime PM support, the D4 power domain must be kept powered to avoid a
crash during resume from s2ram (dbg_cpu_pm_notify() calls
reset_ctrl_regs() unconditionally, causing an undefined instruction
oops).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Untested on real hardware, but a similar workaround is needed on r8a7740.
arch/arm/mach-shmobile/pm-sh7372.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index 7e5c2676c48902f1..cedffdd4b476adb4 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -77,6 +77,16 @@
#define PM_DOMAIN_ON_OFF_LATENCY_NS 250000
+static int sh7372_d4_pd_suspend(void)
+{
+ /*
+ * The D4 domain contains the Coresight-ETM hardware block and
+ * therefore it should only be turned off if the debug module is
+ * not in use.
+ */
+ return -EBUSY;
+}
+
static int sh7372_a4r_pd_suspend(void)
{
sh7372_intcs_suspend();
@@ -131,6 +141,8 @@ static struct rmobile_pm_domain sh7372_pm_domains[] = {
.genpd.power_on_latency_ns = PM_DOMAIN_ON_OFF_LATENCY_NS,
.genpd.power_off_latency_ns = PM_DOMAIN_ON_OFF_LATENCY_NS,
.bit_shift = 3,
+ .gov = &pm_domain_always_on_gov,
+ .suspend = sh7372_d4_pd_suspend,
},
{
.genpd.name = "A4R",
--
1.9.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
2014-10-23 11:31 [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered Geert Uytterhoeven
@ 2014-10-27 1:08 ` Simon Horman
2014-10-27 8:23 ` Geert Uytterhoeven
0 siblings, 1 reply; 7+ messages in thread
From: Simon Horman @ 2014-10-27 1:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 23, 2014 at 01:31:14PM +0200, Geert Uytterhoeven wrote:
> The D4 power domain contains the Coresight-ETM hardware block.
> As long as the ARM debug/perf code doesn't use resource management with
> runtime PM support, the D4 power domain must be kept powered to avoid a
> crash during resume from s2ram (dbg_cpu_pm_notify() calls
> reset_ctrl_regs() unconditionally, causing an undefined instruction
> oops).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Untested on real hardware, but a similar workaround is needed on r8a7740.
I have hardware in the form of a Mackerel board and I'm happy
to test this if it would help and you give me some guidance on how to do so.
> arch/arm/mach-shmobile/pm-sh7372.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
> index 7e5c2676c48902f1..cedffdd4b476adb4 100644
> --- a/arch/arm/mach-shmobile/pm-sh7372.c
> +++ b/arch/arm/mach-shmobile/pm-sh7372.c
> @@ -77,6 +77,16 @@
>
> #define PM_DOMAIN_ON_OFF_LATENCY_NS 250000
>
> +static int sh7372_d4_pd_suspend(void)
> +{
> + /*
> + * The D4 domain contains the Coresight-ETM hardware block and
> + * therefore it should only be turned off if the debug module is
> + * not in use.
> + */
> + return -EBUSY;
> +}
> +
> static int sh7372_a4r_pd_suspend(void)
> {
> sh7372_intcs_suspend();
> @@ -131,6 +141,8 @@ static struct rmobile_pm_domain sh7372_pm_domains[] = {
> .genpd.power_on_latency_ns = PM_DOMAIN_ON_OFF_LATENCY_NS,
> .genpd.power_off_latency_ns = PM_DOMAIN_ON_OFF_LATENCY_NS,
> .bit_shift = 3,
> + .gov = &pm_domain_always_on_gov,
> + .suspend = sh7372_d4_pd_suspend,
> },
> {
> .genpd.name = "A4R",
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
2014-10-27 1:08 ` Simon Horman
@ 2014-10-27 8:23 ` Geert Uytterhoeven
2014-10-28 0:16 ` Simon Horman
0 siblings, 1 reply; 7+ messages in thread
From: Geert Uytterhoeven @ 2014-10-27 8:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon,
On Mon, Oct 27, 2014 at 2:08 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Oct 23, 2014 at 01:31:14PM +0200, Geert Uytterhoeven wrote:
>> The D4 power domain contains the Coresight-ETM hardware block.
>> As long as the ARM debug/perf code doesn't use resource management with
>> runtime PM support, the D4 power domain must be kept powered to avoid a
>> crash during resume from s2ram (dbg_cpu_pm_notify() calls
>> reset_ctrl_regs() unconditionally, causing an undefined instruction
>> oops).
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Untested on real hardware, but a similar workaround is needed on r8a7740.
>
> I have hardware in the form of a Mackerel board and I'm happy
> to test this if it would help and you give me some guidance on how to do so.
That would be great!
Test procedure:
1. echo 0 > /sys/module/printk/parameters/console_suspend
2. echo mem > /sys/power/state
3. [ Wake up by pressing a key on the serial console.
There's no other wake-up source on mackerel? ]
Without my patch, I expect it to crash during resume in reset_ctrl_regs().
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
2014-10-27 8:23 ` Geert Uytterhoeven
@ 2014-10-28 0:16 ` Simon Horman
2014-10-28 0:44 ` Simon Horman
2014-10-28 8:15 ` Geert Uytterhoeven
0 siblings, 2 replies; 7+ messages in thread
From: Simon Horman @ 2014-10-28 0:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 27, 2014 at 09:23:14AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Mon, Oct 27, 2014 at 2:08 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Oct 23, 2014 at 01:31:14PM +0200, Geert Uytterhoeven wrote:
> >> The D4 power domain contains the Coresight-ETM hardware block.
> >> As long as the ARM debug/perf code doesn't use resource management with
> >> runtime PM support, the D4 power domain must be kept powered to avoid a
> >> crash during resume from s2ram (dbg_cpu_pm_notify() calls
> >> reset_ctrl_regs() unconditionally, causing an undefined instruction
> >> oops).
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> Untested on real hardware, but a similar workaround is needed on r8a7740.
> >
> > I have hardware in the form of a Mackerel board and I'm happy
> > to test this if it would help and you give me some guidance on how to do so.
>
> That would be great!
>
> Test procedure:
> 1. echo 0 > /sys/module/printk/parameters/console_suspend
I seemed to also need:
echo enabled > /sys/devices/platform/sh-sci.0/tty/ttySC0/power/wakeup
> 2. echo mem > /sys/power/state
> 3. [ Wake up by pressing a key on the serial console.
> There's no other wake-up source on mackerel? ]
usbhs seems like a candidate, it has a wakeup node in sysfs.
> Without my patch, I expect it to crash during resume in reset_ctrl_regs().
With the patch and the mackerel defconfig I see this:
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.005 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
dpm_run_callback(): pm_genpd_suspend+0x0/0x44 returns -16
PM: Device sh_mobile_sdhi.2 failed to suspend: error -16
PM: Some devices failed to suspend, or early wake event detected
PM: resume of devices complete after 0.323 msecs
Restarting tasks ... done.
-bash: echo: write error: Device or resource busy
#
So I turned of SDHI support in the kernel config and tried again:
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.008 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
renesas_usbhs renesas_usbhs.1: remove, state 4
usb usb1: USB disconnect, device number 1
renesas_usbhs renesas_usbhs.1: USB bus 1 deregistered
PM: suspend of devices complete after 28.959 msecs
PM: late suspend of devices complete after 0.357 msecs
PM: noirq suspend of devices complete after 0.512 msecs
[keypress]
sh_tmu sh-tmu.0: ch0: used for periodic clock events
PM: noirq resume of devices complete after 0.420 msecs
PM: early resume of devices complete after 0.209 msecs
PM: resume of devices complete after 0.327 msecs
Restarting tasks ...
renesas_usbhs renesas_usbhs.1: USB Host Controller
renesas_usbhs renesas_usbhs.1: new USB bus registered, assigned bus number 1
done.
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
asoc-simple-card asoc-simple-card.0: ASoC: CODEC DAI ak4642-hifi not registered
platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
Without the patch I see the same as above, module slightly different msec
values:
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.004 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
renesas_usbhs renesas_usbhs.1: remove, state 4
usb usb1: USB disconnect, device number 1
renesas_usbhs renesas_usbhs.1: USB bus 1 deregistered
PM: suspend of devices complete after 27.306 msecs
PM: late suspend of devices complete after 0.343 msecs
PM: noirq suspend of devices complete after 0.503 msecs
[keypress]
sh_tmu sh-tmu.0: ch0: used for periodic clock events
PM: noirq resume of devices complete after 0.420 msecs
PM: early resume of devices complete after 0.204 msecs
PM: resume of devices complete after 0.308 msecs
Restarting tasks ...
renesas_usbhs renesas_usbhs.1: USB Host Controller
renesas_usbhs renesas_usbhs.1: new USB bus registered, assigned bus number 1
done.
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
asoc-simple-card asoc-simple-card.0: ASoC: CODEC DAI ak4642-hifi not registered
platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
> Thanks!
Any time.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
2014-10-28 0:16 ` Simon Horman
@ 2014-10-28 0:44 ` Simon Horman
2014-10-28 8:15 ` Geert Uytterhoeven
1 sibling, 0 replies; 7+ messages in thread
From: Simon Horman @ 2014-10-28 0:44 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 28, 2014 at 09:16:43AM +0900, Simon Horman wrote:
> On Mon, Oct 27, 2014 at 09:23:14AM +0100, Geert Uytterhoeven wrote:
> > Hi Simon,
> >
> > On Mon, Oct 27, 2014 at 2:08 AM, Simon Horman <horms@verge.net.au> wrote:
> > > On Thu, Oct 23, 2014 at 01:31:14PM +0200, Geert Uytterhoeven wrote:
> > >> The D4 power domain contains the Coresight-ETM hardware block.
> > >> As long as the ARM debug/perf code doesn't use resource management with
> > >> runtime PM support, the D4 power domain must be kept powered to avoid a
> > >> crash during resume from s2ram (dbg_cpu_pm_notify() calls
> > >> reset_ctrl_regs() unconditionally, causing an undefined instruction
> > >> oops).
> > >>
> > >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >> ---
> > >> Untested on real hardware, but a similar workaround is needed on r8a7740.
> > >
> > > I have hardware in the form of a Mackerel board and I'm happy
> > > to test this if it would help and you give me some guidance on how to do so.
> >
> > That would be great!
> >
> > Test procedure:
> > 1. echo 0 > /sys/module/printk/parameters/console_suspend
>
> I seemed to also need:
>
> echo enabled > /sys/devices/platform/sh-sci.0/tty/ttySC0/power/wakeup
>
> > 2. echo mem > /sys/power/state
> > 3. [ Wake up by pressing a key on the serial console.
> > There's no other wake-up source on mackerel? ]
>
> usbhs seems like a candidate, it has a wakeup node in sysfs.
>
> > Without my patch, I expect it to crash during resume in reset_ctrl_regs().
For the record the tests below were performed using
renesas-devel-20141028-v3.18-rc2 with and without your patch.
> With the patch and the mackerel defconfig I see this:
>
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.005 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> dpm_run_callback(): pm_genpd_suspend+0x0/0x44 returns -16
> PM: Device sh_mobile_sdhi.2 failed to suspend: error -16
> PM: Some devices failed to suspend, or early wake event detected
> PM: resume of devices complete after 0.323 msecs
> Restarting tasks ... done.
> -bash: echo: write error: Device or resource busy
> #
>
> So I turned of SDHI support in the kernel config and tried again:
>
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.008 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> renesas_usbhs renesas_usbhs.1: remove, state 4
> usb usb1: USB disconnect, device number 1
> renesas_usbhs renesas_usbhs.1: USB bus 1 deregistered
> PM: suspend of devices complete after 28.959 msecs
> PM: late suspend of devices complete after 0.357 msecs
> PM: noirq suspend of devices complete after 0.512 msecs
>
> [keypress]
>
> sh_tmu sh-tmu.0: ch0: used for periodic clock events
> PM: noirq resume of devices complete after 0.420 msecs
> PM: early resume of devices complete after 0.209 msecs
> PM: resume of devices complete after 0.327 msecs
> Restarting tasks ...
>
> renesas_usbhs renesas_usbhs.1: USB Host Controller
> renesas_usbhs renesas_usbhs.1: new USB bus registered, assigned bus number 1
> done.
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> asoc-simple-card asoc-simple-card.0: ASoC: CODEC DAI ak4642-hifi not registered
> platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
>
>
> Without the patch I see the same as above, module slightly different msec
> values:
>
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.004 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> renesas_usbhs renesas_usbhs.1: remove, state 4
> usb usb1: USB disconnect, device number 1
> renesas_usbhs renesas_usbhs.1: USB bus 1 deregistered
> PM: suspend of devices complete after 27.306 msecs
> PM: late suspend of devices complete after 0.343 msecs
> PM: noirq suspend of devices complete after 0.503 msecs
>
> [keypress]
>
> sh_tmu sh-tmu.0: ch0: used for periodic clock events
> PM: noirq resume of devices complete after 0.420 msecs
> PM: early resume of devices complete after 0.204 msecs
> PM: resume of devices complete after 0.308 msecs
> Restarting tasks ...
>
> renesas_usbhs renesas_usbhs.1: USB Host Controller
> renesas_usbhs renesas_usbhs.1: new USB bus registered, assigned bus number 1
> done.
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> asoc-simple-card asoc-simple-card.0: ASoC: CODEC DAI ak4642-hifi not registered
> platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
>
>
> > Thanks!
>
> Any time.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
2014-10-28 0:16 ` Simon Horman
2014-10-28 0:44 ` Simon Horman
@ 2014-10-28 8:15 ` Geert Uytterhoeven
2014-10-29 0:14 ` Simon Horman
1 sibling, 1 reply; 7+ messages in thread
From: Geert Uytterhoeven @ 2014-10-28 8:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon,
On Tue, Oct 28, 2014 at 1:16 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Oct 27, 2014 at 09:23:14AM +0100, Geert Uytterhoeven wrote:
>> On Mon, Oct 27, 2014 at 2:08 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Thu, Oct 23, 2014 at 01:31:14PM +0200, Geert Uytterhoeven wrote:
>> >> The D4 power domain contains the Coresight-ETM hardware block.
>> >> As long as the ARM debug/perf code doesn't use resource management with
>> >> runtime PM support, the D4 power domain must be kept powered to avoid a
>> >> crash during resume from s2ram (dbg_cpu_pm_notify() calls
>> >> reset_ctrl_regs() unconditionally, causing an undefined instruction
>> >> oops).
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >> Untested on real hardware, but a similar workaround is needed on r8a7740.
>> >
>> > I have hardware in the form of a Mackerel board and I'm happy
>> > to test this if it would help and you give me some guidance on how to do so.
>>
>> That would be great!
>>
>> Test procedure:
>> 1. echo 0 > /sys/module/printk/parameters/console_suspend
>
> I seemed to also need:
>
> echo enabled > /sys/devices/platform/sh-sci.0/tty/ttySC0/power/wakeup
Interesting. On Koelsch and Armadillo receiving a serial interrupt
is sufficient to wake up:
root@armadillo:~# cat /sys/devices/e6c50000.serial/tty/ttySC1/power/wakeup
disabled
root@armadillo:~#
Probably the more advanced wake up sources code on sh7372 honours that.
>> 2. echo mem > /sys/power/state
>> 3. [ Wake up by pressing a key on the serial console.
>> There's no other wake-up source on mackerel? ]
>
> usbhs seems like a candidate, it has a wakeup node in sysfs.
>
>> Without my patch, I expect it to crash during resume in reset_ctrl_regs().
>
> With the patch and the mackerel defconfig I see this:
>
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.005 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> dpm_run_callback(): pm_genpd_suspend+0x0/0x44 returns -16
> PM: Device sh_mobile_sdhi.2 failed to suspend: error -16
> PM: Some devices failed to suspend, or early wake event detected
> PM: resume of devices complete after 0.323 msecs
> Restarting tasks ... done.
> -bash: echo: write error: Device or resource busy
> #
>
> So I turned of SDHI support in the kernel config and tried again:
That's the SDHI QoS value, which is lower than the PM domain
suspend/resume time. An alternative should be:
echo 501 > /sys/devices/platform/sh_mobile_sdhi.2/power/pm_qos_resume_latency_us
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.008 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> renesas_usbhs renesas_usbhs.1: remove, state 4
> usb usb1: USB disconnect, device number 1
> renesas_usbhs renesas_usbhs.1: USB bus 1 deregistered
> PM: suspend of devices complete after 28.959 msecs
> PM: late suspend of devices complete after 0.357 msecs
> PM: noirq suspend of devices complete after 0.512 msecs
>
> [keypress]
>
> sh_tmu sh-tmu.0: ch0: used for periodic clock events
> PM: noirq resume of devices complete after 0.420 msecs
> PM: early resume of devices complete after 0.209 msecs
> PM: resume of devices complete after 0.327 msecs
> Restarting tasks ...
>
> renesas_usbhs renesas_usbhs.1: USB Host Controller
> renesas_usbhs renesas_usbhs.1: new USB bus registered, assigned bus number 1
> done.
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> asoc-simple-card asoc-simple-card.0: ASoC: CODEC DAI ak4642-hifi not registered
> platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
>
>
> Without the patch I see the same as above, module slightly different msec
> values:
OK, so my patch is not needed (yet[*]), please drop it.
Either the Cortex A8 has a different debug module than A9, or what the kernel
uses right now is not in the same D4 PM domain as the Coresight-ETM.
Thanks for testing!
[*] This may change when the full Coresight-ETM patches by Mathieu Poirier
are in.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
2014-10-28 8:15 ` Geert Uytterhoeven
@ 2014-10-29 0:14 ` Simon Horman
0 siblings, 0 replies; 7+ messages in thread
From: Simon Horman @ 2014-10-29 0:14 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 28, 2014 at 09:15:56AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, Oct 28, 2014 at 1:16 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Oct 27, 2014 at 09:23:14AM +0100, Geert Uytterhoeven wrote:
> >> On Mon, Oct 27, 2014 at 2:08 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Thu, Oct 23, 2014 at 01:31:14PM +0200, Geert Uytterhoeven wrote:
> >> >> The D4 power domain contains the Coresight-ETM hardware block.
> >> >> As long as the ARM debug/perf code doesn't use resource management with
> >> >> runtime PM support, the D4 power domain must be kept powered to avoid a
> >> >> crash during resume from s2ram (dbg_cpu_pm_notify() calls
> >> >> reset_ctrl_regs() unconditionally, causing an undefined instruction
> >> >> oops).
> >> >>
> >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> >> ---
> >> >> Untested on real hardware, but a similar workaround is needed on r8a7740.
> >> >
> >> > I have hardware in the form of a Mackerel board and I'm happy
> >> > to test this if it would help and you give me some guidance on how to do so.
> >>
> >> That would be great!
> >>
> >> Test procedure:
> >> 1. echo 0 > /sys/module/printk/parameters/console_suspend
> >
> > I seemed to also need:
> >
> > echo enabled > /sys/devices/platform/sh-sci.0/tty/ttySC0/power/wakeup
>
> Interesting. On Koelsch and Armadillo receiving a serial interrupt
> is sufficient to wake up:
>
> root@armadillo:~# cat /sys/devices/e6c50000.serial/tty/ttySC1/power/wakeup
> disabled
> root@armadillo:~#
>
> Probably the more advanced wake up sources code on sh7372 honours that.
>
> >> 2. echo mem > /sys/power/state
> >> 3. [ Wake up by pressing a key on the serial console.
> >> There's no other wake-up source on mackerel? ]
> >
> > usbhs seems like a candidate, it has a wakeup node in sysfs.
> >
> >> Without my patch, I expect it to crash during resume in reset_ctrl_regs().
> >
> > With the patch and the mackerel defconfig I see this:
> >
> > # echo mem > /sys/power/state
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.005 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> > Suspending console(s) (use no_console_suspend to debug)
> > dpm_run_callback(): pm_genpd_suspend+0x0/0x44 returns -16
> > PM: Device sh_mobile_sdhi.2 failed to suspend: error -16
> > PM: Some devices failed to suspend, or early wake event detected
> > PM: resume of devices complete after 0.323 msecs
> > Restarting tasks ... done.
> > -bash: echo: write error: Device or resource busy
> > #
> >
> > So I turned of SDHI support in the kernel config and tried again:
>
> That's the SDHI QoS value, which is lower than the PM domain
> suspend/resume time. An alternative should be:
>
> echo 501 > /sys/devices/platform/sh_mobile_sdhi.2/power/pm_qos_resume_latency_us
Thanks, I wasn't aware of that.
> > # echo mem > /sys/power/state
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.008 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> > renesas_usbhs renesas_usbhs.1: remove, state 4
> > usb usb1: USB disconnect, device number 1
> > renesas_usbhs renesas_usbhs.1: USB bus 1 deregistered
> > PM: suspend of devices complete after 28.959 msecs
> > PM: late suspend of devices complete after 0.357 msecs
> > PM: noirq suspend of devices complete after 0.512 msecs
> >
> > [keypress]
> >
> > sh_tmu sh-tmu.0: ch0: used for periodic clock events
> > PM: noirq resume of devices complete after 0.420 msecs
> > PM: early resume of devices complete after 0.209 msecs
> > PM: resume of devices complete after 0.327 msecs
> > Restarting tasks ...
> >
> > renesas_usbhs renesas_usbhs.1: USB Host Controller
> > renesas_usbhs renesas_usbhs.1: new USB bus registered, assigned bus number 1
> > done.
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 1 port detected
> > asoc-simple-card asoc-simple-card.0: ASoC: CODEC DAI ak4642-hifi not registered
> > platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
> >
> >
> > Without the patch I see the same as above, module slightly different msec
> > values:
>
> OK, so my patch is not needed (yet[*]), please drop it.
> Either the Cortex A8 has a different debug module than A9, or what the kernel
> uses right now is not in the same D4 PM domain as the Coresight-ETM.
Done.
> Thanks for testing!
>
> [*] This may change when the full Coresight-ETM patches by Mathieu Poirier
> are in.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-10-29 0:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-23 11:31 [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered Geert Uytterhoeven
2014-10-27 1:08 ` Simon Horman
2014-10-27 8:23 ` Geert Uytterhoeven
2014-10-28 0:16 ` Simon Horman
2014-10-28 0:44 ` Simon Horman
2014-10-28 8:15 ` Geert Uytterhoeven
2014-10-29 0:14 ` Simon Horman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).