Piteball
/
android_kernel_samsung_msm8976
mirror of https://github.com/team-infusion-developers/android_kernel_samsung_msm8976.git
1
1
Fork 0
Code Issues Projects Releases Wiki Activity
android_kernel_samsung_msm8976/drivers/devfreq/Makefile

27 lines
1.3 KiB
Makefile
Raw Normal View History

msm: kgsl: fix build issue with devfreq_trace.h When building the kernel in tree we get: In file included from drivers/devfreq/devfreq_trace.h:43:0, from drivers/devfreq/devfreq_trace.c:20: include/trace/define_trace.h:79:43: fatal error: ./devfreq_trace.h: No such file or directory #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) The recommend solution is to add the include path to CFLAGS for the file. Change-Id: I0389abcdcec29b35fa4da997b4ee3fd71c8a6c04 Signed-off-by: Kumar Gala <galak@codeaurora.org>
2014-08-27 14:13:08 +00:00
CFLAGS_devfreq_trace.o := -I$(src)
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs With OPPs, a device may have multiple operable frequency and voltage sets. However, there can be multiple possible operable sets and a system will need to choose one from them. In order to reduce the power consumption (by reducing frequency and voltage) without affecting the performance too much, a Dynamic Voltage and Frequency Scaling (DVFS) scheme may be used. This patch introduces the DVFS capability to non-CPU devices with OPPs. DVFS is a techique whereby the frequency and supplied voltage of a device is adjusted on-the-fly. DVFS usually sets the frequency as low as possible with given conditions (such as QoS assurance) and adjusts voltage according to the chosen frequency in order to reduce power consumption and heat dissipation. The generic DVFS for devices, devfreq, may appear quite similar with /drivers/cpufreq. However, cpufreq does not allow to have multiple devices registered and is not suitable to have multiple heterogenous devices with different (but simple) governors. Normally, DVFS mechanism controls frequency based on the demand for the device, and then, chooses voltage based on the chosen frequency. devfreq also controls the frequency based on the governor's frequency recommendation and let OPP pick up the pair of frequency and voltage based on the recommended frequency. Then, the chosen OPP is passed to device driver's "target" callback. When PM QoS is going to be used with the devfreq device, the device driver should enable OPPs that are appropriate with the current PM QoS requests. In order to do so, the device driver may call opp_enable and opp_disable at the notifier callback of PM QoS so that PM QoS's update_target() call enables the appropriate OPPs. Note that at least one of OPPs should be enabled at any time; be careful when there is a transition. Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Mike Turquette <mturquette@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-01 22:19:15 +00:00
obj-$(CONFIG_PM_DEVFREQ) += devfreq.o
msm: kgsl: Split BMC code to a separate devfreq governor The existing devfreq governor_msm_adreno_tz supports both GPU DCVS and BMC (Bus Modification Calculation) at the same time. This change splits BMC code into a new governor_gpubw_mon. Change-Id: Ie7162985e994aa5bed0fb41eb2741a811cf8bd56 Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
2014-05-22 17:44:25 +00:00
obj-$(CONFIG_PM_DEVFREQ) += devfreq_trace.o
PM / devfreq: Add basic governors Four cpufreq-like governors are provided as examples. powersave: use the lowest frequency possible. The user (device) should set the polling_ms as 0 because polling is useless for this governor. performance: use the highest freqeuncy possible. The user (device) should set the polling_ms as 0 because polling is useless for this governor. userspace: use the user specified frequency stored at devfreq.user_set_freq. With sysfs support in the following patch, a user may set the value with the sysfs interface. simple_ondemand: simplified version of cpufreq's ondemand governor. When a user updates OPP entries (enable/disable/add), OPP framework automatically notifies devfreq to update operating frequency accordingly. Thus, devfreq users (device drivers) do not need to update devfreq manually with OPP entry updates or set polling_ms for powersave , performance, userspace, or any other "static" governors. Note that these are given only as basic examples for governors and any devices with devfreq may implement their own governors with the drivers and use them. Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Mike Turquette <mturquette@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-01 22:19:34 +00:00
obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) += governor_simpleondemand.o
obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o
obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
PM / devfreq: Generic cpufreq governor This devfreq governor is a generic implementation that can scale any devfreq device based on the current CPU frequency of all ONLINE CPUs. It allows for specifying CPU freq to devfreq mapping for specific devices. When such a mapping is not present, it defaults to scaling the device frequency in proportion to the CPU frequency. Change-Id: I8d3b1fea26572defbad2ce8b6cf87930caa25ca6 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
2014-04-12 01:48:38 +00:00
obj-$(CONFIG_DEVFREQ_GOV_CPUFREQ) += governor_cpufreq.o
PM / devfreq: add msm-adreno-tz governor This governor can be used to control adreno GPUs. It is unlikely to be useful for other devices. Change-Id: Icf481322454b814d2f41019f2f01286062409952 Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org> Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
2013-03-13 19:54:15 +00:00
obj-$(CONFIG_DEVFREQ_GOV_MSM_ADRENO_TZ) += governor_msm_adreno_tz.o
devfreq: Add MSM CPUfreq governor The MSM CPUfreq devfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. This functionality used to be a part of the MSM CPUfreq driver that directly voted for the CPU to DDR bandwidth using MSM bus scaling APIs. This refactor decouples CPU to DDR BW scaling from CPU frequency and allows switch between various CPU BW governors. The bandwidth values in the msm-cpufreq table have to be updated since the new CPU BW driver does the MBps to Bps conversion correctly. The MSM CPUfreq driver used to do * 1000 * 1000 to convert from MBps to Bps instead of doing * 1024 * 1024. Change-Id: I184f09d628a1b27d52506d2f760d65831f1a1110 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
2013-11-24 11:45:00 +00:00
obj-$(CONFIG_DEVFREQ_GOV_MSM_CPUFREQ) += governor_msm_cpufreq.o
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>
2014-01-23 09:04:30 +00:00
obj-$(CONFIG_ARCH_MSM_KRAIT) += krait-l2pm.o
PM / devfreq: Add MSM BIMC bwmon support for bw_hwmon governor The BIMC bwmon device supports monitoring read/write traffic from each BIMC master port. It also has the capability to raise an IRQ when the traffic count exceeds a programmable threshold. This allows for it to be used with the bw_hwmon governor to scale the BW requests from each BIMC master. Change-Id: Ie8a1471226411e23954ed556292186a5a864ddc1 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
2014-05-29 01:59:54 +00:00
obj-$(CONFIG_MSM_BIMC_BWMON) += bimc-bwmon.o
PM / devfreq: Add ARM PMU support for bw_hwmon governor The ARM PMU supports monitoring bus access from each CPU. It also has the ability to raise an IRQ when the counters overflow. This allows for it to be used with the bw_hwmon governor to scale the CPU BW requests by monitoring on the actual bus access traffic. Change-Id: I0594a6acb846acdc11a18744033636951f22e387 Signed-off-by: Jacob Stevens <jstevens@codeaurora.org>
2014-07-14 23:50:58 +00:00
obj-$(CONFIG_ARMBW_HWMON) += armbw-pm.o
PM / devfreq: Introduce MSM CCI HWmon device CCI400 on MSM has additional PMU counters that can be used to monitor cache requests. MSM CCI hardware monitor device configures these registers to monitor cache and inform governor. It can also set an IRQ when count exceeds a programmable limit. Change-Id: I1d80f57749b91c3972e60e54c75226c4d49d2ec6 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
2014-10-31 23:18:02 +00:00
obj-$(CONFIG_MSMCCI_HWMON) += msmcci-hwmon.o
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>
2014-05-15 21:42:21 +00:00
obj-$(CONFIG_DEVFREQ_GOV_MSM_BW_HWMON) += governor_bw_hwmon.o
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>
2014-01-22 08:15:33 +00:00
obj-$(CONFIG_DEVFREQ_GOV_MSM_CACHE_HWMON) += governor_cache_hwmon.o
msm: kgsl: Split BMC code to a separate devfreq governor The existing devfreq governor_msm_adreno_tz supports both GPU DCVS and BMC (Bus Modification Calculation) at the same time. This change splits BMC code into a new governor_gpubw_mon. Change-Id: Ie7162985e994aa5bed0fb41eb2741a811cf8bd56 Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
2014-05-22 17:44:25 +00:00
obj-$(CONFIG_DEVFREQ_GOV_MSM_GPUBW_MON) += governor_gpubw_mon.o
PM/devfreq: Add bw_vbif governor This governor should be used by KGSL driver to vote for msm bus bandwidth using devbw devices. KGSL driver needs to register a callback function that returns required IB value, and call devfreq_vbif_update_bw() function any time it want to vote for bus bandwidth. Change-Id: I6c7c08b7c3255b3793f1868d9cde604175093145 Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
2014-08-31 23:49:43 +00:00
obj-$(CONFIG_DEVFREQ_GOV_MSM_GPUBW_MON) += governor_bw_vbif.o
devfreq: devfreq_spdm: Introduce devfreq_spdm driver. The devfreq_spdm driver implements support for bandwidth voting based on input from the SPDM device on MSM SoC's. The SPDM governor registers for the SPDM interrupt and then calls the hypervisor to determine the correct bandwidth to vote for. The devfreq framework poll timer is used to perdiocially ask the hypervisor for the new bandwidth to request from the MSM bus scaling code. Change-Id: I851457e40d49b5929f01c510249d3e6bb4ff2f1d Signed-off-by: Dan Sneddon <dsneddon@codeaurora.org>
2014-09-22 18:49:26 +00:00
obj-$(CONFIG_DEVFREQ_GOV_SPDM_HYP) += governor_spdm_bw_hyp.o
PM/Devfreq: Add Exynos4-bus device DVFS driver for Exynos4210/4212/4412. Exynos4-bus device devfreq driver add DVFS capability for Exynos4210/4212/4412-Bus (memory). The driver monitors PPMU counters of memory controllers and adjusts operating frequencies and voltages with OPP. For Exynos4210, vdd_int is controlled. For exynos4412/4212, vdd_mif and vdd_int are controlled. Dependency (CONFIG_EXYNOS_ASV): Exynos4 ASV driver has been posted in the mailing list; however, it si not yet upstreamed. Although the current revision of Exynos4 ASV patch does not contain "CONFIG_EXYNOS_ASV", we have added the symbol to hide the dependent from compilers for now. As soon as Exynos4 ASV drivers are merged, the #ifdef statement will be removed or the name will be changed. However, enabling ASV is essential in most Exynos4 chips to reduce the power consumption of Exynos4210 because without ASV, this Devfreq driver assumes the worst case scenario, which consumes more power. Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> --- Changes from v1 - Support 4212 and 4412 as well as 4210.
2011-07-14 01:33:55 +00:00
# DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos4_bus.o
PM / devfreq: Make the CPUBW voting device driver to be more generic Making the driver more generic would allow it to be reused for voting for BW requirements of other devices like GPU, etc. Instead of cpubw and qcom,cpubw, the driver and the device are now called devbw and qcom,devbw respectively. Change-Id: I49e5a5ba6d46517da19d013413abd471a730af29 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
2014-05-17 02:59:22 +00:00
obj-$(CONFIG_MSM_DEVFREQ_DEVBW) += devfreq_devbw.o
PM / devfreq: Add devfreq driver for simple device This driver registers a devfreq device that allows devfreq governors to scale the frequency of a device clock. This single driver can be used to support multiple devices as long as those devices don't have a need or mechanism to monitor their load and use clock APIs to control their device/core clock. If devices need to support device specific status monitoring, they could extend this driver to allow registering device specific status monitoring funtions or write their own specific devfreq device driver. Change-Id: Ie1797acf7b35cac6dc49428e270c23082634eb1e Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
2014-01-22 02:49:37 +00:00
obj-$(CONFIG_DEVFREQ_SIMPLE_DEV) += devfreq_simple_dev.o
devfreq: devfreq spdm: Add debugfs support Add debugfs support for the devfreq spdm driver. The parameters used for determing the SPDM port threshold value can be updated via debugfs and sent to the hypervisor to support fine tuning SPDM performance. Change-Id: I6f85deacd7d463d90f512f5de18b7e2140c9f492 Signed-off-by: Dan Sneddon <dsneddon@codeaurora.org>
2014-10-02 19:11:09 +00:00
obj-$(CONFIG_DEVFREQ_SPDM) += devfreq_spdm.o devfreq_spdm_debugfs.o