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 08:10 On Mon, Sep 7, 2009 at 3:03 PM, Pavel Machek<pavel(a)ucw.cz> wrote: > 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. I'd vote for it. -- 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: Stanislav Brabec on 7 Sep 2009 09:20 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. > > 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. 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 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 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) When I measured my battery, Linux 2.6.26 went to emergency sleep at 3.4V. Note that battery thresholds probably should not be hardwired in spitz_pm.c but read from the NAND configuration instead (Andrea Adami knows, how it can be done). Here is the datasheet of the charging circuit: http://www.penguin.cz/~utx/zaurus/datasheets/power/charging/sc801.pdf There were more problems in the charging code even before: - The measurement code should work without turning LED on (bootloader can do it). SPITZ_SCP_JK_A should connect dummy load. I guess it should be enough for measurement. But comments in the source tree say that is did not work. I am not sure why. - 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. - 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. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarsk� 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- 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 7 Sep 2009 10:10 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 measurement code should work without turning LED on (bootloader > can do it). SPITZ_SCP_JK_A should connect dummy load. I guess it should > be enough for measurement. But comments in the source tree say that is > did not work. I am not sure why. If you find out let me know. The need for that still puzzles me but it wouldn't work without it! > - 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. > > - 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. All nice to have if we can get the original code working again first! Cheers, 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 7 Sep 2009 10:50 2009/9/7 Stanislav Brabec <utx(a)penguin.cz>: > 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. > Nope. The CONFIG_CORGI_SSP_DEPRECATED is not supposed to work. -- 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 7 Sep 2009 11:00
On Mon, Sep 7, 2009 at 10: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. > That simple SSP API made a lot of headaches as well. Now there are three clearly separated individual drivers even on a single SPI bus controlling the LCD, backlight and the MAX1111 sensor instead of all those dirty tricks messing up. And it was really a painful memory to touch that part of the code and get it cleaned up. -- 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/ |