android/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
b8724a03cc
android_kernel_xiaomi_sm8450/drivers/devfreq/governor_bw_hwmon.h

81 lines
2.5 KiB
C
Raw Normal View History

devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
/* SPDX-License-Identifier: GPL-2.0-only */
/*
PM / devfreq: Fix CONFIG check for cache HW monitor prototype Commit 2094bed75267 ("PM / devfreq: Add cache HW monitor governor") brought in the cache HW monitor with an incorrect check for CONFIG_DEVFREQ_GOV_QCOM_CACHE_HWMON that fails when the governor is built as a module. Change-Id: Ic0dedbadefc4885486660d32226e6dd89e006a11 Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
2019-12-06 04:25:07 +09:00
* Copyright (c) 2014-2016, 2019-2020, The Linux Foundation. All rights reserved.
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
*/
#ifndef _GOVERNOR_BW_HWMON_H
#define _GOVERNOR_BW_HWMON_H
#include <linux/kernel.h>
#include <linux/devfreq.h>
/**
* struct bw_hwmon - dev BW HW monitor info
* @start_hwmon: Start the HW monitoring of the dev BW
* @stop_hwmon: Stop the HW monitoring of dev BW
PM / devfreq: bw_hwmon: Update to low latency, high sampling rate algorithm The existing bw_hwmon governor samples the bandwidth every polling_interval milliseconds and makes decisions. Polling interval of 50ms or even 10ms gives a very low resolution picture of the DDR/bus traffic. Due to the lower resolution picture, the existing governor algorithm has to be biased aggressively towards performance to avoid any performance degradation compared to using a static mapping between bus master (CPU, GPU, etc) frequency to DDR/bus BW votes. While the existing governor uses IRQ to get early notification of traffic increase, even a 4x early notification for a 50ms polling interval still takes 12.5ms. This kind of reaction time is still too slow for some bus masters like CPU. To take care of these limitations, rewrite the governor algorithm to take multiple short samples of BW within a decision window (polling interval) and use that higher resolution picture to make much better and faster decisions. Doing so allows the governor to have the following features: - Very low reaction time - Over voting to stay ahead of increasing traffic - Historic peak tracking to limit over voting - Being power aware when doing over voting - Pattern detection and intelligent hysteresis - Detection low traffic modes and being less aggressive about BW votes. Change-Id: I69886b7fbeea0b64d10b5a1fb23fcb5f3918f0ce Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions, made to_mbps_zone() static and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:33:34 +09:00
* @set_thres: Set the count threshold to generate an IRQ
* @get_bytes_and_clear: Get the bytes transferred since the last call
* and reset the counter to start over.
PM / devfreq: bw_hwmon: Expose a throttle adjust tunable Newer versions of bimc-bwmon counters have the capability to fake higher byte count than what's actually transferred between a bus master and DDR if the bus master is being throttled by QoS hardware logic. Add support to set the throttle adjust field that comes with this newer version of bimc-bwmon. Change-Id: I33376c825fb11ab2e378f828b1d2ae46dd582836 Signed-off-by: Rohit Gupta <rohgup@codeaurora.org> [aparnam@codeaurora.org: Renamed throttle_adj functions] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: resolved minor merge conflicts made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:56:01 +09:00
* @set_throttle_adj: Set throttle adjust field to the given value
* @get_throttle_adj: Get the value written to throttle adjust field
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
* @dev: Pointer to device that this HW monitor can
* monitor.
* @of_node: OF node of device that this HW monitor can
* monitor.
* @gov: devfreq_governor struct that should be used
* when registering this HW monitor with devfreq.
* Only the name field is expected to be
* initialized.
* @df: Devfreq node that this HW monitor is being
* used for. NULL when not actively in use and
* non-NULL when in use.
*
* One of dev, of_node or governor_name needs to be specified for a
* successful registration.
*
*/
struct bw_hwmon {
int (*start_hwmon)(struct bw_hwmon *hw,
unsigned long mbps);
void (*stop_hwmon)(struct bw_hwmon *hw);
PM / devfreq: governor_bw_hwmon: Add suspend/resume support Some devfreq devices using this governor might need suspend/resume support. When suspended, those devices won't need any bandwidth votes and there is no point in monitoring their bandwidth either. Therefore, upon suspend, vote for zero bandwidth and stop the HW monitor. Upon resume, vote for the previous bandwidth and start the HW monitor. Change-Id: I318449995d714959f0ebfe91961bc23fa8edbd04 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [avajid@codeaurora.org: resolved trival merge conflicts and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:18:37 +09:00
int (*suspend_hwmon)(struct bw_hwmon *hw);
int (*resume_hwmon)(struct bw_hwmon *hw);
PM / devfreq: bw_hwmon: Update to low latency, high sampling rate algorithm The existing bw_hwmon governor samples the bandwidth every polling_interval milliseconds and makes decisions. Polling interval of 50ms or even 10ms gives a very low resolution picture of the DDR/bus traffic. Due to the lower resolution picture, the existing governor algorithm has to be biased aggressively towards performance to avoid any performance degradation compared to using a static mapping between bus master (CPU, GPU, etc) frequency to DDR/bus BW votes. While the existing governor uses IRQ to get early notification of traffic increase, even a 4x early notification for a 50ms polling interval still takes 12.5ms. This kind of reaction time is still too slow for some bus masters like CPU. To take care of these limitations, rewrite the governor algorithm to take multiple short samples of BW within a decision window (polling interval) and use that higher resolution picture to make much better and faster decisions. Doing so allows the governor to have the following features: - Very low reaction time - Over voting to stay ahead of increasing traffic - Historic peak tracking to limit over voting - Being power aware when doing over voting - Pattern detection and intelligent hysteresis - Detection low traffic modes and being less aggressive about BW votes. Change-Id: I69886b7fbeea0b64d10b5a1fb23fcb5f3918f0ce Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions, made to_mbps_zone() static and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:33:34 +09:00
unsigned long (*set_thres)(struct bw_hwmon *hw,
unsigned long bytes);
PM / devfreq: bw_hwmon: Add HW offload support to governor Some HW monitors can do a better job of the sampling and the threshold checking than the SW implementation in the governor. Update the governor's API to add support for them. Change-Id: Id4b5593a5ed3290684ba43ebebe2466ba0b730b6 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [avajid@codeaurora.org: made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 12:02:43 +09:00
unsigned long (*set_hw_events)(struct bw_hwmon *hw,
unsigned int sample_ms);
PM / devfreq: bw_hwmon: Update to low latency, high sampling rate algorithm The existing bw_hwmon governor samples the bandwidth every polling_interval milliseconds and makes decisions. Polling interval of 50ms or even 10ms gives a very low resolution picture of the DDR/bus traffic. Due to the lower resolution picture, the existing governor algorithm has to be biased aggressively towards performance to avoid any performance degradation compared to using a static mapping between bus master (CPU, GPU, etc) frequency to DDR/bus BW votes. While the existing governor uses IRQ to get early notification of traffic increase, even a 4x early notification for a 50ms polling interval still takes 12.5ms. This kind of reaction time is still too slow for some bus masters like CPU. To take care of these limitations, rewrite the governor algorithm to take multiple short samples of BW within a decision window (polling interval) and use that higher resolution picture to make much better and faster decisions. Doing so allows the governor to have the following features: - Very low reaction time - Over voting to stay ahead of increasing traffic - Historic peak tracking to limit over voting - Being power aware when doing over voting - Pattern detection and intelligent hysteresis - Detection low traffic modes and being less aggressive about BW votes. Change-Id: I69886b7fbeea0b64d10b5a1fb23fcb5f3918f0ce Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions, made to_mbps_zone() static and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:33:34 +09:00
unsigned long (*get_bytes_and_clear)(struct bw_hwmon *hw);
PM / devfreq: bw_hwmon: Expose a throttle adjust tunable Newer versions of bimc-bwmon counters have the capability to fake higher byte count than what's actually transferred between a bus master and DDR if the bus master is being throttled by QoS hardware logic. Add support to set the throttle adjust field that comes with this newer version of bimc-bwmon. Change-Id: I33376c825fb11ab2e378f828b1d2ae46dd582836 Signed-off-by: Rohit Gupta <rohgup@codeaurora.org> [aparnam@codeaurora.org: Renamed throttle_adj functions] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: resolved minor merge conflicts made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:56:01 +09:00
int (*set_throttle_adj)(struct bw_hwmon *hw,
uint adj);
u32 (*get_throttle_adj)(struct bw_hwmon *hw);
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
struct device *dev;
struct device_node *of_node;
struct devfreq_governor *gov;
PM / devfreq: bw_hwmon: Add HW offload support to governor Some HW monitors can do a better job of the sampling and the threshold checking than the SW implementation in the governor. Update the governor's API to add support for them. Change-Id: Id4b5593a5ed3290684ba43ebebe2466ba0b730b6 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [avajid@codeaurora.org: made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 12:02:43 +09:00
unsigned long up_wake_mbps;
unsigned long down_wake_mbps;
unsigned int down_cnt;
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
struct devfreq *df;
};
PM / devfreq: Fix CONFIG check for cache HW monitor prototype Commit 2094bed75267 ("PM / devfreq: Add cache HW monitor governor") brought in the cache HW monitor with an incorrect check for CONFIG_DEVFREQ_GOV_QCOM_CACHE_HWMON that fails when the governor is built as a module. Change-Id: Ic0dedbadefc4885486660d32226e6dd89e006a11 Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
2019-12-06 04:25:07 +09:00
#if IS_ENABLED(CONFIG_DEVFREQ_GOV_QCOM_BW_HWMON)
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
int register_bw_hwmon(struct device *dev, struct bw_hwmon *hwmon);
int update_bw_hwmon(struct bw_hwmon *hwmon);
PM / devfreq: bw_hwmon: Update to low latency, high sampling rate algorithm The existing bw_hwmon governor samples the bandwidth every polling_interval milliseconds and makes decisions. Polling interval of 50ms or even 10ms gives a very low resolution picture of the DDR/bus traffic. Due to the lower resolution picture, the existing governor algorithm has to be biased aggressively towards performance to avoid any performance degradation compared to using a static mapping between bus master (CPU, GPU, etc) frequency to DDR/bus BW votes. While the existing governor uses IRQ to get early notification of traffic increase, even a 4x early notification for a 50ms polling interval still takes 12.5ms. This kind of reaction time is still too slow for some bus masters like CPU. To take care of these limitations, rewrite the governor algorithm to take multiple short samples of BW within a decision window (polling interval) and use that higher resolution picture to make much better and faster decisions. Doing so allows the governor to have the following features: - Very low reaction time - Over voting to stay ahead of increasing traffic - Historic peak tracking to limit over voting - Being power aware when doing over voting - Pattern detection and intelligent hysteresis - Detection low traffic modes and being less aggressive about BW votes. Change-Id: I69886b7fbeea0b64d10b5a1fb23fcb5f3918f0ce Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions, made to_mbps_zone() static and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:33:34 +09:00
int bw_hwmon_sample_end(struct bw_hwmon *hwmon);
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
#else
static inline int register_bw_hwmon(struct device *dev,
struct bw_hwmon *hwmon)
{
return 0;
}
PM / devfreq: bw_hwmon: Update to low latency, high sampling rate algorithm The existing bw_hwmon governor samples the bandwidth every polling_interval milliseconds and makes decisions. Polling interval of 50ms or even 10ms gives a very low resolution picture of the DDR/bus traffic. Due to the lower resolution picture, the existing governor algorithm has to be biased aggressively towards performance to avoid any performance degradation compared to using a static mapping between bus master (CPU, GPU, etc) frequency to DDR/bus BW votes. While the existing governor uses IRQ to get early notification of traffic increase, even a 4x early notification for a 50ms polling interval still takes 12.5ms. This kind of reaction time is still too slow for some bus masters like CPU. To take care of these limitations, rewrite the governor algorithm to take multiple short samples of BW within a decision window (polling interval) and use that higher resolution picture to make much better and faster decisions. Doing so allows the governor to have the following features: - Very low reaction time - Over voting to stay ahead of increasing traffic - Historic peak tracking to limit over voting - Being power aware when doing over voting - Pattern detection and intelligent hysteresis - Detection low traffic modes and being less aggressive about BW votes. Change-Id: I69886b7fbeea0b64d10b5a1fb23fcb5f3918f0ce Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions, made to_mbps_zone() static and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:33:34 +09:00
static inline int update_bw_hwmon(struct bw_hwmon *hwmon)
{
return 0;
}
static inline int bw_hwmon_sample_end(struct bw_hwmon *hwmon)
devfreq: Add CPUBW HW monitor governor The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to determine the bandwidth needed by the Krait CPU subsystem. This governor can be used in conjunction with the CPUBW devfreq device to dynamically scale the DDR frequency based on the demand/actual usage from the Krait CPU subsystem. Since this governor uses the Krait L2 PM counters it can conflict with certain profiling tools. The Krait L2 performance monitor counters have the capability to count the no. of read/write transactions going out the master ports. They also have the capability to raise interrupts when they overflow. This driver uses those counters to determine the true usage of DDR from the Krait processor subsystem and then recommends CPU DDR BW votes 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: - io_percent: The percentage of the CPU time that can be spent waiting on memory I/O. Lower value is better performance and worse power. - sample_ms: The sampling period in milliseconds. This only affects the sampling period when DDR use is ramping down or is increasing very slowly (See tolerance_percent). - tolerance_percent: The minimum increase in DDR use, compared to previous sample, that will trigger an IRQ to immediately bump up the bandwidth vote. It's expressed as a percentage of the previous sampled DDR use. - 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% mean never forget the historical max. The default 90% means forget 90% of history each time. - guard_band_mbps: This is a margin that's added to the measured BW (and hence also the Bus BW votes) that's present to account for the time it takes to ramp up the DDR BW while the CPU continues to use the DDR. - bw_step: All BW votes are rounded up to multiples of bw_step. The default value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A smaller value would mean more frequent bus BW changes. A higher value would mean less frequent BW vote updates, but also means at times an unnecessarily higher BW vote (due to the rounding up). Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [aparnam@codeaurora.org: Replaced snprintf with scnprintf] Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org> [avajid@codeaurora.org: updated attr definitions and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org>
2019-01-17 11:03:28 +09:00
{
return 0;
}
#endif
#endif /* _GOVERNOR_BW_HWMON_H */
Reference in New Issue Copy Permalink