Re: Zaurus suspend saga

[Richard Purdie <rpurdie@rpsys.net>]

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