* [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: Simon Horman, Magnus Damm Cc: Rafael J. Wysocki, linux-sh, linux-pm, linux-arm-kernel, Geert Uytterhoeven 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: Geert Uytterhoeven Cc: Magnus Damm, Rafael J. Wysocki, linux-sh, linux-pm, 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: Simon Horman Cc: Geert Uytterhoeven, Magnus Damm, Rafael J. Wysocki, Linux-sh list, Linux PM list, linux-arm-kernel@lists.infradead.org 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: Geert Uytterhoeven Cc: Geert Uytterhoeven, Magnus Damm, Rafael J. Wysocki, Linux-sh list, Linux PM list, linux-arm-kernel@lists.infradead.org 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: Geert Uytterhoeven Cc: Geert Uytterhoeven, Magnus Damm, Rafael J. Wysocki, Linux-sh list, Linux PM list, linux-arm-kernel@lists.infradead.org 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: Simon Horman Cc: Geert Uytterhoeven, Magnus Damm, Rafael J. Wysocki, Linux-sh list, Linux PM list, linux-arm-kernel@lists.infradead.org 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: Geert Uytterhoeven Cc: Geert Uytterhoeven, Magnus Damm, Rafael J. Wysocki, Linux-sh list, Linux PM list, linux-arm-kernel@lists.infradead.org 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).