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

Joerg Reisenweber joerg at openmoko.org
Sun Jun 15 11:49:27 CEST 2008

Am Sa  14. Juni 2008 schrieb Andy Green:
> 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 :-)

Andy, I wonder whether it's a good decision to have R1545 NC. Though it's 
maybe the wrong guy to kill this issue.
When I had a short glance to the 50633-man, I've also seen something about 
programmable delays on shutdown. Didn't read the whole story jet.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080615/2e948738/attachment.pgp 

More information about the openmoko-kernel mailing list