Zaurus suspend saga

Zaurus suspend saga

[Pavel Machek]

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

Re: Zaurus suspend saga

[Rafael J. Wysocki]

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

Re: Zaurus suspend saga

[Stanislav Brabec]

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

Re: Zaurus suspend saga

[Pavel Machek]

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

Re: Zaurus suspend saga

[Richard Purdie]

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

Re: Zaurus suspend saga

[Eric Miao]

On Mon, Sep 7, 2009 at 6:29 AM, Richard Purdie<rpurdie@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.

Re: Zaurus suspend saga

[Pavel Machek]

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

Re: Zaurus suspend saga

[Stanislav Brabec]

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@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

Re: Zaurus suspend saga

[Russell King - ARM Linux]

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.

Re: Zaurus suspend saga

[Stanislav Brabec]

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

Re: Zaurus suspend saga

[Pavel Machek]

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@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

Re: Zaurus suspend saga

[Joe Perches]

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...

Re: Zaurus suspend saga

[Dmitry Eremin-Solenikov]

On Mon, Sep 7, 2009 at 3:03 PM, Pavel Machek<pavel@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

Re: Zaurus suspend saga

[Pavel Machek]

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

Re: Zaurus suspend saga

[Stanislav Brabec]

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@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/

Re: Zaurus suspend saga

[Richard Purdie]

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

Re: Zaurus suspend saga

[Eric Miao]

On Mon, Sep 7, 2009 at 10:07 PM, Richard Purdie<rpurdie@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.

Re: Zaurus suspend saga

[Dmitry Eremin-Solenikov]

On Mon, Sep 7, 2009 at 6:07 PM, Richard Purdie<rpurdie@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

Re: Zaurus suspend saga

[Eric Miao]

2009/9/7 Stanislav Brabec <utx@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.

Re: Zaurus suspend saga

[Pavel Machek]

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

Re: Zaurus suspend saga

[Pavel Machek]

Hi!

> - 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.

Can you try to get that working?

With my AA charger, I get "AC Status: 0", as long as battery is not
full. It draws power for it (and battery percentage goes higher) but
it is not even detected as charger :-(. [But charge LED is lit. WTF?]
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Zaurus suspend saga

[Stanislav Brabec]

Pavel Machek wrote:

>Well, overnight charge (online) seems to result in pretty much empty
>battery...

Which kernel? I did the same in 2.6.26-RP and the battery was charged
overnight from about 60% to 100%.

I think that it is not possible to drain battery if an AC adapter
provides a sufficient voltage. But it's possible to disable charging by
a bad setting of the software.

>Is CHRG_ON pin reversed?

I am not sure, but it looks so. Both CHRG_ON resp. JK_B travel from
SCOOP PA pins to the gate of FET transistors with pull-up (probably
acts as an invertor and voltage converter) and end in EN resp. PRGM pins
of in the charging chip (SC801). You have to consult SC801 data sheet.

You can also verify both with a voltmeter connected to the battery.
CHRG_ON should cause rise of voltage on the battery pins. The rise
value should be dependent on JK_B.

Also both CP resp. STAT pins of SC801 travel through FET transistors
before it become AC_IN and CHRG_FULL.

> With my AA charger, I get "AC Status: 0", as long as battery is not
> full. It draws power for it (and battery percentage goes higher) but
> it is not even detected as charger :-(.

You have to have about 4.2V on the AC connector to get AC_IN. When
trying fast online charging, your AA charger must provide more than 4.2V
at possibly more than 1A current. Switching to slow charging, it
decreases to say >500mA online and 120mA offline. In the worst case,
your Zaurus may need nearly 2A.

You can hack the kernel to send CHRG_ON even if AC_IN is 0. But I am not
sure what will charging chip do then (data sheet will probably tell it
to you).

You can try to set SPITZ_SCP_JK_B to slow charging. Maybe voltage will
become sufficient.

> [But charge LED is lit. WTF?]

One pole of the LED is connected to AC power input, the seconds one to
the GPIO. So the logic is following:

IF (kernel says that LED should light) AND (there is sufficient voltage
on AC input) THEN (LED lights)


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