Zaurus suspend saga
in [Kernel]
|
Prev: PROBLEM: kernel reboot before Decompressing Linux, after setting video mode
Next: [PATCH] ieee1394: sbp2: remove a workaround for Momobay FX-3A
From: Pavel Machek on 7 Sep 2009 06:10 On Sun 2009-09-06 19:03:10, 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? mtd regression is fixed. battery vs. SPI regression is very very very old, and seems to be fixed by the one-liner. 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: Pavel Machek on 7 Sep 2009 07:10 Hi! > > 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. Yep, zaurus is currently pretty broken; I don't think charging from Linux works at all, so I simply power down back to bootloader for charge. Anyway, suspend/resume is currently more important for me than charge, and I'd like to get at least that to work. Could we apply the trivial patch from "zaurus c3000 aka spitz: fix resume" , and preferably push it to linus for 2.6.31? One version where kernel suspends/resumes would be good. 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: Stanislav Brabec on 7 Sep 2009 07:40 Pavel Machek wrote: > Yep, zaurus is currently pretty broken; I don't think charging from > Linux works at all, so I simply power down back to bootloader for > charge. > > Anyway, suspend/resume is currently more important for me than charge, > and I'd like to get at least that to work. > > Could we apply the trivial patch from "zaurus c3000 aka spitz: fix > resume" , and preferably push it to linus for 2.6.31? One version > where kernel suspends/resumes would be good. I vote for applying Pavel's patch, as it fixes suspend/resume. Emergency suspend may happen later, when SPI will be fully resumed. If future fixes provide early SPI resume, then this patch may be reverted. Tested-by: Stanislav Brabec <utx(a)penguin.cz> .... Remaining Zaurus SL-C3200 problems in the current vanilla (regressions are compared with 2.6.26-RP): Offline charging. (regression) Offline charging does not work. Richard provided exact analysis of the problem. Serial after resume. (regression) Resume on serial port does not work. Reason unknown. Call eject on HDD CF slot, then access. (probably in all kernels) Instead of an error, it causes overwriting of partition table. It does never happen in a normal work. USB host does not work (regression), USB OTG switching is not implemented (not yet implemented) Reason unknown, but it may be caused by a lacking or incomplete platform description. Noisy touchscreen. (at least partially regression) Touchscreen is noisy. I the latest versions, it even reads intermediate values before the new value settles. Possible fix: Do not read hundreds times in second, but only once in the gap between two display refreshes. Bad MTD partition table. (not yet implemented) SL-C3100 and SL-C3200 differs in the NAND partition table. To get a correct table, NAND config has to be read. Andrea Adami works on kexecboot, that will be able to provide the NAND-configured table instead of guessing using hardwired model->partition table list. Missing driver for remote. (outside vanilla tree) The driver exists outside the kernel tree, but it's ugly. I plan to finish my "resistor matrix keyboard device" driver. Sound codec on low frequencies. (not yet tested in 2.6.31) It works, but sound is very distorted. Possible reason: bad timing of chip auto suspend -- 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: Pavel Machek on 7 Sep 2009 07:40 Hi! > > 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. Unfortunately... Do you have any idea when this conversion took place? > 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. Yes. Seems like low-level zaurus code is FUBAR. > 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) Doing that in a hacky way should be rather easy... just calling spi resume manually. But... > c) We rip the whole thing out and stop supporting "offline" charging. How much faster is offline charge, compared to online charging? I have impression that online charging basically does not charge anything... > 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 :(. Well, I have a bit of time now and then... 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: Russell King - ARM Linux on 7 Sep 2009 07:50
On Mon, Sep 07, 2009 at 01:34:29PM +0200, Stanislav Brabec wrote: > Serial after resume. (regression) If you pass no_console_suspend, the console serial port doesn't have its state saved and restored upon resume. This is something I pointed out while I was serial maintainer and got ignored... I think you'll find that it'll work if you don't pass no_console_suspend, though you won't get the messages between the console itself being suspended and subsequently resumed. -- 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/ |