From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered
Date: Tue, 28 Oct 2014 00:16:43 +0000 [thread overview]
Message-ID: <20141028001642.GA20702@verge.net.au> (raw)
In-Reply-To: <CAMuHMdVFTjy5UZEU6azEuXQSKF1msQrQ-cOe2jZzevcpAPfAjw@mail.gmail.com>
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.
next prev parent reply other threads:[~2014-10-28 0:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2014-10-28 0:44 ` Simon Horman
2014-10-28 8:15 ` Geert Uytterhoeven
2014-10-29 0:14 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141028001642.GA20702@verge.net.au \
--to=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).