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.