One of the most common power management modes for ARM processors is the suspend mode. In this mode, peripherals are shut down when possible, the SDRAM is put into self-refresh, and the CPU is placed in a low power mode. A useful bit of information is to know how soon the system can respond to a resume (wake) event.
It turns out the answer to this question depends on where you want to do the work. In the first test, I created a simple application that continuously toggled a GPIO. This is an easy way to tell determine with a scope when the application was running. I then measured the time between the wake event, and when this application signal started toggling. It was a consistent 180ms.
For the next test I simply toggled a gpio in the omap3_pm_suspend() first thing after resume. This tells me roughly how fast I can execute code in the kernel after a wake event. This turned out to be 250uS.
So the good news is we can run kernel code very quickly after a resume event (250uS), but it currently takes a long time until user space processes start running again (180mS). The 180ms can likely be reduced with some work, but this at least gives us a baseline. 180ms is fairly quick from a human perspective (seems pretty much instant), but for industrial devices that are responding to real-world events, then 180mS can be a long time.
Good work. One add-on though. The 250us you are seeing is most likely limited by the GPIO module which is “rather slow”. You might therefore be able to execute kernel code much faster than 250us after wakeup.
One way to test this would be to i.e. access an address on a GPMC chip select (and measure this with a scope) instead of flipping aGPIO. In this way you will avoid the “rather slow” GPIO module…
Looking forward to an update 🙂
Best regards – Keep up the great work
Søren
Very interesting, thank you for sharing!
Very interesting research! During the 180ms, the kernel is likely calling all the resume() functions for all enabled devices drivers and this may take a while, depending on the drivers. Only after that is complete, the kernel will start to revive the rest of the system and finally unfreeze the normal tasks, including any user tasks.
To shorten the 180ms, you can try to disable or rmmod all devices/device drivers which you do not strictly need and look at the resume functions of the remaining drivers and minimize the time spent executing those.
Ultimatively, the kernel developers which are working in improving the suspend subsystem may try to take a look whether resume functions which have to wait for the hardware to answer could cooperatively allow to run other resume functions of other, unrelated hardware while it’s waiting, in order to paralellize the resume.