CPUfreq: hotplug: offline aux CPUs below min freq

Previous offlining logic in cpufreq-hotplug would check if the current
frequency of the CPU matched its minimum frequency in the cpufreq_policy
structure.  In rare circumstances it is possible to run at a lower frequency
than the minimum and it is still desirable to take CPUs offline in these
circumstances.  Fixed by converting this checking from an exact match (==)
to a ranged match (<=).

Change-Id: Id3dfcf49be0fb3fe42e57f571827f7027fd6dc1d
Signed-off-by: Mike Turquette <mturquette@ti.com>
cpufreq: hotplug: Allow safe usage of cpufreq_update_policy

With the current implementation of hotplug do_dbs_timer,
the usage of cpufreq standard API cpufreq_update_policy
may generate lockups.

The scenario is like this -
1. thread A --
   |__ cpufreq_update_policy()  --> calls lock_policy_rwsem_write()
        |__ __cpufreq_set_policy()
             |__ __cpufreq_governor() --> with CPUFREQ_GOV_STOP
                  |__ cpufreq_governor_dbs()
                        |__mutex_lock(&this_dbs_info->timer_mutex);

2. CPU1 boot up thread --
do_dbs_timer() --> mutex_lock(&dbs_info->timer_mutex);
   |__ dbs_check_cpu()
        |__ cpu_up(1)
             |__ _cpu_up()
                  |__ cpu_notify() --
                      |__ cpufreq_cpu_callback()
                           |__ cpufreq_add_dev()  --> lock_policy_rwsem_write()

The function call graph shows that the do_dbs_timer from hotplug governor
does locking sequence exactly in the opposite order as the
cpufreq_update_policy does. This may cause a deadlock if both threads
are scheduled in the middle of each lock call, just to highlight one
possibility.

What this patch does is to defer the cpu_up and cpu_down operations,
removing them from the locking of the timer_mutex.

Change-Id: I59dacde1e84459037d13ed045539fd58041db191
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

Conflicts:

	drivers/cpufreq/cpufreq_hotplug.c
PM:CPUFREQ:Hotplug boost cpufreq support

This patch hooks into cpufreq boost api. Supports
boosting cpu freq to max and online cpu1 if not already ON.
The timeout of the boost is configurable through userspace
as was done on ondemand.

Set the timeout first:
 *by default 3sec is set for the duration of boost affect.  .
echo <in usec> > /sys/devices/system/cpu/cpufreq/hotplug/boost_timeout

Now boost cpufreq using below command:
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/boost_cpufreq

This patch depends on the earlier version posted for ondemand, recap below:
    CPUFREQ governors as of today doesn't scale up the freq fast enough
    to match up the system load. The latency is of the order of few msecs
    This would hamper the user interactiveness. There are different ways to fix this;

    This patch introduces boost sysfs interface which would enable the
    govenor to ack any request for running the system at max freq just before
    the system is going to be loaded. The next sample time would be decided
    based on the user configured timeout value or the default (samplerate * 10) usec.

Change-Id: Ib307e456cce2acc2f371a586bf6f65258e240aab
Signed-off-by: Girish S G <girishsg@ti.com>

Conflicts:

	drivers/cpufreq/cpufreq_hotplug.c
PM:CPUFREQ: Fix dbs_timer_init() delay setup.

Fixed condition for delay setting depending on boost request

Change-Id: Ie781d73abf3ab6c63159c153cfda943bd97a6a40
Signed-off-by: Andrii Guriev <x0160204@ti.com>