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. cheers jOERG
signature.asc
Description: This is a digitally signed message part.
