Hi Pavan, Usual Linux PM would follow the below steps: 1) Freezing Tasks [enter_state() calls suspend_prepare() which calls suspend_freeze_processes()] 2) each driver's suspend routine is then invoked (In this case wifi driver's suspend gets called here) 3) This is followed by calling device suspend routines move devices to low power mode
However as you pointed in case of Android, before all above steps happen, the early suspend routines of drivers get called & a check is made to see if any wakelocks are held. (echo mem > /sys/power/state from PowerManagerService) If no wakelocks are held only then the usual linux routine described above is then followed. So to answer your questions: 1. Android power management gets into action first by calling early suspend routines & checks if any wakelocks are held which can block the suspend resume. [So the userspace wifi daemon cannot hold a wakelock here because it will not let the first step of suspend routine take place. Its not premature for this to happen in this case] 2.Secondly, following normal linux suspend routine, Freezing of processes takes place. [Thus the userspace wifi daemon also gets freezed here to ram since no wakelocks are held by PowerManagerService or any other module] 3. Now the wifi driver specific suspend routine gets invoked. But as I discussed it cannot finish on time since it has to post a message to the userspace wifi daemon to move it to the proper state) In this case since the userspace wifi daemon is already freezed in step(2) above, the driver's suspend doesnot complete on time given by android to finish the device suspend routine. Hence, I'm looking for a way to see if the use space daemon in this case can somehow be marked as non-freezable task.I'm not sure if there is a proper way in which this situation can be handled!! Hope this makes my problem more clear. Regards, Sunil On Sep 19, 4:46 pm, Pavan Savoy <pavan.sa...@gmail.com> wrote: > On Mon, Sep 19, 2011 at 6:42 AM, Sunil Pillai <sunilpillai....@gmail.com> > wrote: > > > Hello All, > > > I have this situation in my system where the android kernel suspend > > procedure fails due to below sequence: > > > 1. suspend invoked by the android > > 2. All user space processses get freezed including my android > > userspace deamon process-X which has wifi userspace component > > Shouldn't this be happening, only if the "suspend" is a success ? > Seems like the "freezing all process" - is happening prematurely in this case > ? > > Also, the user-space process can always register/communicate with > PowerManagerService in Android - to prevent suspend - wake-lock unless > the WiFi - tells that it is alright to go into suspend. > > > > > > > > > > > 3. Wifi suspend driver gets trigerred; But this in has to call a > > routine in userspace process-X (to suspend userspace Wifi component) > > which is already freezed and this call (sync call) times out after > > some time(10 ms) > > > This basically fails the suspend procedure for the Wifi driver. A > > possible solution I feel is that the userspace process-X doesnot get > > freezed unless the Wifi driver suspends itself successfully (including > > suspending the userspace Wifi component) > > > Is this possible & if not how can I handle such a situation? > > > Regards, > > Sunil > > > -- > > unsubscribe: android-kernel+unsubscr...@googlegroups.com > > website:http://groups.google.com/group/android-kernel > > -- > --Pavan Savoy -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
