[PATCH 0/9] various mainly pcf50633 resume improvements / Ooooh

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> Despite we made some real progress in fact the whole suspend / resume
|> thing remains extremely fragile due to probably just one or two more
|> monsters in the deep shadows we never understood yet.  And they're the
|> kind of monsters that attack if you go hunting for them:
|> no_console_suspend on the kernel commandline kills resume the same way
|> as mdelay() in glamo suspend stuff, and equally with no real trace of
|> how or why it blew chunks.

| It works for a few times, then seems to crash. If I comment out the
| dev_info ()and msleep() calls in pcf50633_work it seems to be OK. Also,

OK I think I just had a "major breakthrough in understanding" why
suspend action can be time-critical :-)

We turn off our CPU core voltage quite early during suspend :-)))
basically after pcf50633 suspends we are "running on fumes" for core_1v3
in 23.3uF of capacitance for the rest of the suspend action. :-)))   So
this is why the odd dev_info() (which has to be flushed on serial
console) and msleep() can make a difference to if you are gonna resume.

I'm going to meditate on this a bit, it is a serious issue because
pcf50633 being an i2c peripheral from Linux's POV, it is suspended very
early, and the i2c bus goes down a little while after so deferral is not
really possible (unless we bitbang it ourselves I suppose).  But surely
sawing off the branch you are sitting on by turning off your CPU core
voltage is something your should preferably be doing at the END of
suspend action not the start :-)


Also I went back to look at why I could never make any change to the
white flash that happens on suspend, I stuck mdelay(1000) in various
places up the chain of suspends starting from Glamo going backwards,
until I was able to delay the flash coming, which was when the delay was
in pcf50633 suspend.  Further examination showed it was when we take the
regulators down in preparation for suspend.

I checked mach_gta02.c and I had told it to leave the lcm regulator up,
but I could see it was taking it down.  When I told it to leave them all
up, it still took lcm and some others down.  After some head scratching
I saw that it meddles with that platform struct at runtime elsewhere in
the file, so I forced it up there too.  Now there is no white flash (and
I believe this will solve the monochrome LCM issue, since the power was
getting taken until now).

So that's up on andy branch now.

| I still have it resuming as greyscale and the audio pops are still
present.

Greyscale I think will be fixed now.

Audio pops... can you clarify where they come from... the earpiece or
the sounder at the back / side.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhTj8kACgkQOjLpvpq7dMrtDwCfewGjH49Rcav1RObMdLLga8Rt
EpYAoJB0xL7OXfIdk3YT9W8f2USS0hO3
=HtFM
-----END PGP SIGNATURE-----