[Bug] ARM: mxs: STI: console can't wake up from freeze
Russell King - ARM Linux
linux at armlinux.org.uk
Sat Nov 5 11:05:42 PDT 2016
On Sat, Nov 05, 2016 at 04:28:37PM +0100, Stefan Wahren wrote:
> As i wrote in my email before, i added a pr_info() into freeze_wake.
> But i never see the output of this message. So i assume freeze_wake
> is never called. Again, how could this happen?
Hmm, so the bit that you're getting stuck on is:
wait_event(suspend_freeze_wait_head,
suspend_freeze_state == FREEZE_STATE_WAKE);
Now there's two things about this here - it's a non-interruptible wait,
so I think the hung task detection may trigger on that (I'm not entirely
sure on that point though, and I don't have time this evening to read
the code to find out.)
The second thing is, that in order to pass this point, something has to
call freeze_wake().
There's not that many possibilities for that:
$ git grep freeze_wake drivers kernel
drivers/base/power/wakeup.c: freeze_wake();
drivers/base/power/wakeup.c: freeze_wake();
kernel/power/suspend.c:void freeze_wake(void)
kernel/power/suspend.c:EXPORT_SYMBOL_GPL(freeze_wake);
One of those is pm_system_wakeup(), the other is wakeup_source_activate()
via wakeup_source_report_event() via __pm_stay_awake() or
__pm_wakeup_event().
Looking at the results of:
$ grep 'pm_wakeup_event\|pm_stay_awake\|pm_system_wakeup' drivers kernel -r
it looks like for freeze support to work, various drivers need to call
one of these functions.
The iMX serial driver doesn't call any of these functions, so I can't
see how we'd get past this point - and from that grep you'll see nothing
in kernel/irq touches any of these functions.
Documentation/power/suspend-and-interrupts.txt does a very poor job
(which is typical) of describing what the requirements are for
"suspend-to-idle", it doesn't really say that any of the above
functions must be called and it doesn't say who's responsible for
calling these functions. It does talk about "pm_system_wakeup()"
for "rare cases".
So my conclusion, based on the poor documentation and the results of
my greps, is that "freeze" aka "suspend-to-idle" is not supported on
the majority of hardware, and attempting to use it will result in the
system locking up in exactly the way you're seeing.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
More information about the linux-arm-kernel
mailing list