This adds the freq_map device attribute to the mem_latency governor in
order to display a given device's core frequency to device bandwidth.
The output should be printed in the formatted in the same way as the
example:
Core freq (MHz) Device BW
300 1525
480 3143
900 4173
1017 7759
1296 9887
1555 11863
1804 13763
Change-Id: I6bef33a1239329f0687ee3983c2c02d84e984284
Signed-off-by: David Keitel <dkeitel@codeaurora.org>
Add a core to memory frequency mapping table, which establishes
a relationship between the core frequency and its corresponding
bandwidth vote.
The governor expects a "qcom,core-dev-table" table as part of a given
memlat hardware monitor's device tree node.
This table is read upon registration of the memlat governor. The table
is then used to determine the memory bandwidth vote corresponding to the
maximum of the core frequencies.
CRs-Fixed: 1054146
Change-Id: I9df118da1433125b02c937bf1799a0944b110fac
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: David Keitel <dkeitel@codeaurora.org>
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
The return value of kstrtouint is erroneously checked while setting
the tunables for mem_latency governor due to which the tunables
cannot be changed from their default values.
This change rectifies that behavior.
Change-Id: Ief7dda4638ede2c97b26229f1188a1559b238920
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Use performance counters to detect the memory latency sensitivity
of CPU workloads and vote for higher DDR frequency if required.
Change-Id: Ie77a3523bc5713fc0315bd0abc3913f485a96e0e
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
[junjiew@codeaurora.org: dropped changes in arch/arm64/Kconfig]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>