Revert "reapply: Removed 200MHz and 100MHz frequencies for now in order to resolve SODs"

This reverts commit e9d5f85d14dfeb3974bca61657d6080ccdadc324.

Conflicts:

	arch/arm/mach-s5pv210/include/mach/cpu-freq-v210.h
Revert "Removed 200MHz and 100MHz frequencies for now in order to resolve SODs"

This reverts commit 05d42d0635f0b492229853c4d70cb6e67a54f12d.

Conflicts:

	arch/arm/mach-s5pv210/include/mach/cpu-freq-v210.h
cpufreq: [SOD PATCH] Bring back 100/200MHz !

-Prerequisite info:
1. We get SOD(Sleep Of Death) when the cpu frequency falls
below 400Mhz during resume.
2. This patch is built on: https://github.com/Meticulus/nutella_kernel_samsung_venturi/commit/6adfe8e6375768a893c12c23fff91fe546d05008
3. PM_SUSPEND_PREPARE is were we get notified that we are about to
suspend.
4. PM_POST_SUSPEND is were we get notified that resume is complete.

-The idea here is simple. Before we suspend we record the min and
max cpu freqs, raise the minium freq to at least 400Mhz (in this case
SLEEP_FREQ (800Mhz)) so we don't get the SOD, then after resume is
complete we restore the min and max frequencies back.

-The problem was that resume is ansyncronous. So at the time we
recieve PM_POST_SUSPEND, not all devices are resumed! In fact,
they are just getting started! So on PM_POST_RESUME we reset
the min frequency causing the CPU freq to drop below 400Mhz!
SOD

-The solution here is to create a nonblocking thread and wait
a static 1 second (only takes about half that time) for resume
to complete, then we reset the CPU min and max freqs.

NOTE: The "interactive" governor was not co-operating with this
solution. I suspect that it's been highly optimized and is not
obeying the rules. I disabled it. I've tested this with "ondemand"
and "conservative"; both work fine.

NOTE: It would have been better, if I could have found a way
to be certain that resume was fully complete before reapplying
the stored min and max frequencies...

- @Meticulus