This is something I implemented on a Blackfin system (Blackfin is a DSP architecture that runs the Linux kernel), which can enter suspend and get out of suspend in about 3-4 milliseconds.
So I modified the idle loop of the kernel so that if the next timer expiration event is enough far away in the future (say, 20 or 30ms), then I program the RTC to wake-up a few milliseconds before the scheduled expiration and then enter suspend. When I come back from suspend, I tweak the clocksource to make the system think that the time has continued to pass while the system was suspended, which has the effect of rescheduling the timer events so that the interrupt fires at the correct expected date, as if the system didn't enter suspend. It has been checked with an external scope that looks at GPIO toggling triggered by userspace Linux timers *and* the CPU voltage, and the frequency of the GPIO toggling was correct, and the CPU was completely off during the waiting periods.
I feel that suspend and idle are considered as two very separate things by many kernel developers, because on x86, suspend is such a slow operation that it can only be started explicitly by the user. But on many embedded architectures, suspend can just be a specific type of idle state.