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: Dmitry Eremin-Solenikov on 7 Sep 2009 16:40 On Mon, Sep 7, 2009 at 6:07 PM, Richard Purdie<rpurdie(a)rpsys.net> wrote: > On Mon, 2009-09-07 at 15:10 +0200, Stanislav Brabec wrote: >> Pavel Machek wrote: >> > >> > > 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? >> >> In past, MAX1111 driver was embedded in the Zaurus specific code. Now >> MAX1111 is a generic SPI driver and spitz_pm.c calls it. >> >> Maybe it will still work with CONFIG_CORGI_SSP_DEPRECATED. > > I was thinking about this. The SSP interface is ridiculously simple and > it might be worth just adding some SSP access code into the Zaurus > offline code so it can access the MAX1111 without the rest of the system > running. That would solve a lot of the problems. > > Its not as if any other hardware is going to come along and reuse this > as the Zaurus hardware line is dead. The major source of problems w/ tosa suspend/resume (hangs, instant resume, etc.) was connected to the second driver for ac97 bus beings present just for "touch ADC when all other parts are asleep". It was really PITA to even try to debug that. The "simple SSP" driver "just for being suspended" would be a nightmare also (IMO). -- With best wishes Dmitry -- 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 8 Sep 2009 17:20 Hi! > > > 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 think that online charging works, but it seems to be slower. I am not > sure, whether it is a hardware or software issue. You can control > charging speed by software, but the final word has the charging > chip. Well, overnight charge (online) seems to result in pretty much empty battery... > Here are control wires: > SPITZ_SCP_JK_A: output = turns dummy load to 1 kOhm resistor > SPITZ_SCP_JK_B: output = high charging current > SPITZ_SCP_CHRG_ON: output = charging on > SPITZ_SCP_ADC_TEMP_ON: output = turns battery sensor on/off > SPITZ_GPIO_CHRG_FULL input = charging complete > SPITZ_GPIO_AC_IN input = AC adapter is present Is CHRG_ON pin reversed? static void spitz_charge(int on) { if (on) { if (sharpsl_pm.flags & SHARPSL_SUSPENDED) { gpio_set_value(SPITZ_GPIO_JK_B, 1); gpio_set_value(SPITZ_GPIO_CHRG_ON, 0); } else { gpio_set_value(SPITZ_GPIO_JK_B, 0); gpio_set_value(SPITZ_GPIO_CHRG_ON, 0); } } else { gpio_set_value(SPITZ_GPIO_JK_B, 0); gpio_set_value(SPITZ_GPIO_CHRG_ON, 1); } } > MAX1111 inputs: > MAX1111_ACIN_VOLT: Voltage in AC input (after pass of input circuit, > before tha final diode) > MAX1111_BATT_TEMP: Battery temperature sensor > MAX1111_BATT_VOLT: Battery voltage > > Here are notes from the design: > Pre-charge = 102mA > Fast charge = 680mA > Fast charge set ON = 105mA I'm quite confused: > SPITZ_SCP_JK_B: output = high charging current Is JK_B active low? > Iterm = 55mA > > Thresholds: > SPITZ_GPIO_AC_IN: 4.2V (IC charging circuit) > SPITZ_GPIO_FATAL_BAT: 3.0V (voltage detector IC on battery) > PXA270 batt fault: 2.8V (voltage on the main non-regulated power) > CF/SD: 2.8V (voltage required for CF/SD activation, I am > not sure, why it is done, because 2.8V is > outside of spec anyway) > - It would be nice to have "small travel charger heuristic": Turn fast > charging on, charger "disappears", switch to slow charging, charger > "appears" => stay in slow charging mode, and retry after some time, or > after going to suspend, reset the flag when charger is removed. Yes, I have similar "travel charger" (from single AA in fact), too, and yes getting that heuristic would be cool. But for now, I'd settle with /sys control enabling that. > - sysfs interface for charging would be nice. For example: Cyril has an > external battery pack and he wants to disable charging of internal > battery from the external battery. Yes, more debug info in sysfs and some controls would be nice. BTW... /sys/class/leds/spitz:amber:charge seems to have life of its own. I can't manually change the brightness; also changing trigger does not work -- it still displays charging status. What is going on? 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 16 Sep 2009 08:30 Russell King - ARM Linux wrote: > 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. I sent a possible fix of this problem to LKML: http://lkml.org/lkml/2009/9/15/206 -- 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 2 Oct 2009 03:20 On Mon 2009-09-07 13:34:29, Stanislav Brabec wrote: > 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): Yep :-(. More developers/testers needed. People breaking zaurus all the time, probably because they don't have the hw. Should I get listed as zaurus maintainer so that I get to see zaurus-breaking patches before they hit the mainline? -- (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: Joe Perches on 2 Oct 2009 03:40
On Fri, 2009-10-02 at 06:13 +0200, Pavel Machek wrote: > Should I get listed as zaurus maintainer so that I get to see > zaurus-breaking patches before they hit the mainline? So add a Zaurus section to MAINTAINERS but maybe make the S: line something like: S: Not maintained but at least I have hardware... -- 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/ |