[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090906052653.GB1324@ucw.cz>
Date: Sun, 6 Sep 2009 07:26:53 +0200
From: Pavel Machek <pavel@....cz>
To: rpurdie@...ys.net, lenz@...wisc.edu,
kernel list <linux-kernel@...r.kernel.org>,
Dirk@...er-Online.de, arminlitzel@....de,
Cyril Hrubis <metan@....cz>, thommycheck@...il.com,
linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>,
dbaryshkov@...il.com, omegamoon@...il.com, eric.miao@...vell.com,
utx@...guin.cz
Subject: Zaurus suspend saga
Hi!
Even with mtd regression fixed, spitz will still not suspend/resume
correctly.
I got hint that SPI suspend may be responsible...
With 2.6.31-rc7:
with corgi_enter_suspend stubbed out and parts of spitz_should_wakeup
disabled, it suspends/resumes ok.
spitz_pm.c parts -- yes it controls wakeup, but it only seems to read GPIOs?
spitz_should_wakeup: printks do not signal this triggers, perhaps
change is not strictly neccessary.
sharpsl_fatal_check seems to trigger, sending machine to sleep :-(.
fatal reads invalid values -- -108 -- probably because spi is not ready?
is spi suspend/resume required? yes.; and yes spi is resumed too late
in the sequence. Or perhaps fatal battery check is way too early.
Could someone confirm that simply removing sharpsl_fatal_check() fixes
zaurus suspend on 2.6.31?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists