devfreq: Make cpubw_hwmon governor reusable and hardware agnostic

Since various hardware platforms might have different ways of monitoring
the CPU bandwidth, make the cpubw_hwmon governor hardware agnostic so that
it can be reused across these hardware platforms.

Change-Id: If7af01537dbf1df66551bea2bc73232d9e9264f7
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
PM / devfreq: Check for GPU busy time before sending the sample

Sometimes GPU busy time is very low during sampling. Accumulate
the statistics and send them with the next sample.

Change-Id: I77e568b48afc3a4922c7c341d9478705b7ae3a30
Signed-off-by: Suman Tatiraju <sumant@codeaurora.org>
PM / devfreq: Add cache HW monitor governor

The cache HW monitor devfreq governor uses the hardware counters to
determine the load on the cache and the appropriate frequency needed to
support that load. This governor can be used in conjunction with the cache
devfreq device to dynamically scale the cache frequency based on the
demand/actual usage from the CPU subsystem.

The governor is written to be agnostic of the actual counters used to
determine the load. On Krait based CPUs, the governor uses the Krait L2 PM
counters which can conflict with certain profiling tools.

The Krait L2 performance monitor counters have the capability to count
different types of requests going to the L2 cache. They also have the
capability to raise interrupts when they overflow. This driver uses those
counters to determine the true usage of L2 from the Krait processor
subsystem and then recommends L2 frequency based on the measured values and
the following tunable parameters.

The driver provides various tunables that allow it to be tuned more in
favor of power or performance:

- cycles_per_high_req: The no. of cache clock cycles that are necessary to
  efficiently process a high-work request to the cache. A higher value
  means higher power and potentially higher performance. A lower value
  means lower power and potentially lower performance.

- cycles_per_med_req: The no. of cache clock cycles that are necessary to
  efficiently process a medium-work request to the cache. A higher value
  means higher power and potentially higher performance. A lower value
  means lower power and potentially lower performance.

- polling_ms: The sampling period in milliseconds. This only affects the
  sampling period when cache use is ramping down or is increasing very
  slowly (See tolerance_mrps).

- min_busy: The minimum percentage of time the cache should be busy. This
  is also applied as a lower bound to the measured busy percentage before
  it's used in calculations. This has to be lower than or equal to
  max_busy. Lower values will make the scaling more aggressive.

- max_busy: The maximum percentage of time the cache should be busy. This
  is also applied as an upper bound to the measured busy percentage before
  it's used in calculations. This has to be greater than or equal to
  min_busy. Lower values will make the scaling more aggressive.

- tolerance_mrps: The minimum increase (in millions of requests per second)
  in cache requests, compared to previous sample, that will trigger an IRQ
  to immediately re-evaluate the cache frequency.

- decay_rate: The parameter controls the rate at which the history is
  forgotten when ramping down. This is expressed as a percentage of history
  to be forgotten. So 100% means ignore history, 0% means never forget the
  historical max. The default 90% means forget 90% of history each time.

- guard_band_mhz: This is a margin that's added to the computed cache
  frequency to account for the time it takes between the load increasing
  and the governor/device finishes ramping up the cache frequency.

Change-Id: I918ae178cd3c9d14cb7714d7eb312cbbbb0d977b
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
PM / devfreq: Refactor CPUBW HWmon governor to be more generic

The refactored governor will be called bw_hwmon since it's no longer
limited to monitoring the CPU BW in hardware.

The refactor allows the governor to support multiple devfreq devices. This
is done by having different HW monitor instances register their capability
to monitor different devfreq devices and then picking the right HW monitor
based on which devfreq device is using this governor.

The refactor also fixes a very unlikely race condition that can happen when
starting/stopping the governor.

Change-Id: Ifeeeb256115f6ae3075f391d9b4b02666e06f737
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
PM / devfreq: bw_hwmon: Move IRQ handling to device specific drivers

The bandwidth monitoring devices might have more than one IRQ to handle or
might have notifications from other drivers instead of using actual IRQs.
So, refactor the governor to move the IRQ handling to the bandwidth
monitoring device specific drivers and just provide an API that can be used
to request a re-evaluation.

The device specific driver can call this API to request an immediate
re-evaluation whenever the bandwidth has exceeded the previously set limit
instead of waiting for the periodic update.

Change-Id: I8bfd85d0cb59a1fd0116000aac430680e483b422
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
msm: devfreq: Enable cpubw_hwmon
arm/dts: msm8974: Disable second crypto device
Revert "arm/dts: msm8974: Disable clk-mgmt-sus-res for qcrypto"

Using a single crypto device fixes the underlying issue.

This reverts commit 57b4d49c2d698dfebd90a1844c71207fc168e326.
Crypto: Update reaper timeout to 10ms

Reaper timeout for bus bandwidth allocation/release
is changed to 10ms from 1sec to allow device to go
to suspend before 1sec.

Change-Id: I810cebf0f1b3f3de990f92d8f9576b20da9a0037
Signed-off-by: AnilKumar Chimata <anilc@codeaurora.org>