From: Pavel Machek on
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on
On Sunday 06 September 2009, Pavel Machek wrote:
> Hi!
>
> Even with mtd regression fixed, spitz will still not suspend/resume
> correctly.

Is the regression fixed in the Linus' tree, or do you still need to apply the
revert patch?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stanislav Brabec on
Rafael J. Wysocki wrote:
> On Sunday 06 September 2009, Pavel Machek wrote:
> > Hi!
> >
> > Even with mtd regression fixed, spitz will still not suspend/resume
> > correctly.
>
> Is the regression fixed in the Linus' tree, or do you still need to apply the
> revert patch?

I just tested kernel without this revert, and it seems to work. I did it
because Pavel mentioned it and some time ago it did not work (see thread
"2.6.31-rc1: zaurus suspend regressing" from August 2009).

Please ignore the crash I reported it the last mail. It was caused by
the eject on the PCMCIA slot from my 2.6.26 system (in 2.6.27 order of
PCMCIA slots swapped).

And here is my new console output with just plain vanilla (e07cccf4...)
with Pavel's patch.

apm-power: Requesting system suspend...
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.06 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
hostap_cs: CS_EVENT_PM_SUSPEND
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
sharpsl-pm sharpsl-pm: Error: AC check failed.
sharpsl-pm sharpsl-pm: Offline Charger: Error occurred.
sharpsl-pm sharpsl-pm: Charging Error!


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Richard Purdie on
On Sun, 2009-09-06 at 07:26 +0200, Pavel Machek wrote:
> 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?

Sadly lack of time means I've lost track of the Zaurus kernels but this
sounds like all accesses to the SSP buses now go through the SPI layer
and when it was converted nobody thought about the impact this would
have on the Zaurus charger code.

If suspend/resume is broken in this way, it also means the charger code
is also likely to be totally broken/malfunctioning since it won't be
able to read from the ADC either.

Either:

a) Someone steps up and finds a way to partially resume the kernel so
the "offline" charging code can work and access SPI
b) We find some other way to allow the SPI interface to be accessed by
the charger code without resuming the whole kernel (the way it used to
work)
c) We rip the whole thing out and stop supporting "offline" charging.

I'd hate to see c) happen but I doubt I'm going to find time to rewrite
that code any time soon and nobody else even seems to have grasped how
deep this problem really is :(.

Richard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric Miao on
On Mon, Sep 7, 2009 at 6:29 AM, Richard Purdie<rpurdie(a)rpsys.net> wrote:
> On Sun, 2009-09-06 at 07:26 +0200, Pavel Machek wrote:
>> 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?
>
> Sadly lack of time means I've lost track of the Zaurus kernels but this
> sounds like all accesses to the SSP buses now go through the SPI layer
> and when it was converted nobody thought about the impact this would
> have on the Zaurus charger code.
>
> If suspend/resume is broken in this way, it also means the charger code
> is also likely to be totally broken/malfunctioning since it won't be
> able to read from the ADC either.
>
> Either:
>
> a) Someone steps up and finds a way to partially resume the kernel so
> the "offline" charging code can work and access SPI
> b) We find some other way to allow the SPI interface to be accessed by
> the charger code without resuming the whole kernel (the way it used to
> work)
> c) We rip the whole thing out and stop supporting "offline" charging.
>
> I'd hate to see c) happen but I doubt I'm going to find time to rewrite
> that code any time soon and nobody else even seems to have grasped how
> deep this problem really is :(.
>

Yeah, I'd agree that to rebuild the charger code on top of SPI, and possibly
as individual driver in the resume process (so order can be arranged) might
be the final solution, however, that's not an easy job indeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/