The linux-next integration testing tree https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=akpm 2022-06-28T00:59:28+00:00 2022-06-28T00:59:28+00:00 Stephen Rothwell sfr@canb.auug.org.au 2022-06-28T00:59:28+00:00 urn:sha1:92ca5327741fb8d315b14bb26ef8e6db674a4eaf 2022-06-15T05:23:01+00:00 Viresh Kumar viresh.kumar@linaro.org 2022-05-25T11:30:51+00:00 urn:sha1:74d850aa40a2423036ec51bc0a671c45fdc0f924 The OPP core now provides a unified API for setting all configuration types, i.e. dev_pm_opp_set_config(). Lets start using it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> 2022-06-15T05:23:01+00:00 Viresh Kumar viresh.kumar@linaro.org 2022-05-25T11:30:51+00:00 urn:sha1:2d862cc21bfe3bd0a28217541fa1628c9773b809 The OPP core now provides a unified API for setting all configuration types, i.e. dev_pm_opp_set_config(). Lets start using it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> 2022-06-15T05:23:01+00:00 Viresh Kumar viresh.kumar@linaro.org 2022-05-25T11:30:51+00:00 urn:sha1:95b9dcf95d91f0cbc35137d019fae2cb7313edc7 The OPP core now provides a unified API for setting all configuration types, i.e. dev_pm_opp_set_config(). Lets start using it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> 2022-06-09T01:05:05+00:00 Johnson Wang johnson.wang@mediatek.com 2022-06-07T14:05:56+00:00 urn:sha1:9f3ec0f65421e4c334a2ab36a506bf181957e060 We introduce a devfreq driver for the MediaTek Cache Coherent Interconnect (CCI) used by some MediaTek SoCs. In this driver, we use the passive devfreq driver to get target frequencies and adjust voltages accordingly. In MT8183 and MT8186, the MediaTek CCI is supplied by the same regulators with the little core CPUs. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Johnson Wang <johnson.wang@mediatek.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> 2022-05-19T17:32:19+00:00 Chanwoo Choi cw00.choi@samsung.com 2022-05-19T01:07:53+00:00 urn:sha1:42d2607d91c4ec37ea1970899c2d614824f3014b Each devfreq governor specifies the supported governor event such as GOV_START and GOV_STOP. When not-supported event is required, just return non-error. But, commit ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") returned the error value. So that return non-error value when not-supported event is required. Fixes: ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2022-05-17T09:24:39+00:00 Chanwoo Choi cw00.choi@samsung.com 2022-04-26T18:49:19+00:00 urn:sha1:26984d9d581e5049bd75091d2e789b9cc3ea12e0 The passive governor requires the cpu data to get the next target frequency of devfreq device if depending on cpu. In order to reduce the unnecessary memory data, keep cpufreq_policy data for possible cpus instead of NR_CPU. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> 2022-05-17T09:24:39+00:00 Chanwoo Choi cw00.choi@samsung.com 2021-03-02T08:22:50+00:00 urn:sha1:05723e71234b60a1a47313ea1a889797ec648f1c In order to keep the consistent coding style between passive_devfreq and passive_cpufreq, use common code for handling required opp property. Also remove the unneed conditional statement and unify the comment of both passive_devfreq and passive_cpufreq when getting the target frequency. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> 2022-05-17T09:24:39+00:00 Saravana Kannan skannan@codeaurora.org 2021-03-02T06:58:21+00:00 urn:sha1:a03dacb0316f74400846aaf144d6c73f4217ca08 Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure that the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for RAM/DDR. To achieve this, this patch adds support for cpu based scaling to the passive governor. This is accomplished by taking the current frequency of each CPU frequency domain and then adjust the frequency of the cache (or any devfreq device) based on the frequency of the CPUs. It listens to CPU frequency transition notifiers to keep itself up to date on the current CPU frequency. To decide the frequency of the device, the governor does one of the following: * Derives the optimal devfreq device opp from required-opps property of the parent cpu opp_table. * Scales the device frequency in proportion to the CPU frequency. So, if the CPUs are running at their max frequency, the device runs at its max frequency. If the CPUs are running at their min frequency, the device runs at its min frequency. It is interpolated for frequencies in between. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [Sibi: Integrated cpu-freqmap governor into passive_governor] Signed-off-by: Sibi Sankar <sibis@codeaurora.org> [Chanwoo: Fix conflict with latest code and cleanup code] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> 2022-05-17T09:24:39+00:00 Chanwoo Choi cw00.choi@samsung.com 2021-02-28T17:07:29+00:00 urn:sha1:713472e53e6e53c985e283782b0fd76b8ecfd47e In order to get frequency range within devfreq governors, export devfreq_get_freq_range symbol within devfreq. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>