summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/qcom-cpufreq-hw.c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-06Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki1-46/+89
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for 5.10-rc1 from Viresh Kumar: "- STI cpufreq driver updates to allow new hardware (Alain Volmat). - Minor tegra driver fixes around initial frequency mismatch warnings (Jon Hunter). - dev_err simplification for s5pv210 driver (Krzysztof Kozlowski). - Qcom driver updates to allow new hardware and minor cleanup (Manivannan Sadhasivam and Matthias Kaehlcke). - Add missing MODULE_DEVICE_TABLE for armada driver (Pali Rohár). - Improved defer-probe handling in cpufreq-dt driver (Stephan Gerhold). - Call dev_pm_opp_of_remove_table() unconditionally for imx driver (Viresh Kumar)." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom: Don't add frequencies without an OPP cpufreq: qcom-hw: Add cpufreq support for SM8250 SoC cpufreq: qcom-hw: Use of_device_get_match_data for offsets and row size cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify code dt-bindings: cpufreq: cpufreq-qcom-hw: Document Qcom EPSS compatible cpufreq: qcom-hw: Make use of cpufreq driver_data for passing pdev cpufreq: armada-37xx: Add missing MODULE_DEVICE_TABLE cpufreq: arm: Kconfig: add CPUFREQ_DT depend for STI CPUFREQ cpufreq: dt-platdev: Blacklist st,stih418 SoC cpufreq: sti-cpufreq: add stih418 support cpufreq: s5pv210: Use dev_err instead of pr_err in probe cpufreq: s5pv210: Simplify with dev_err_probe() cpufreq: tegra186: Fix initial frequency cpufreq: dt: Refactor initialization to handle probe deferral properly opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1() cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table() opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
2020-09-18cpufreq: move invariance setter calls in cpufreq coreIonela Voinescu1-8/+1
To properly scale its per-entity load-tracking signals, the task scheduler needs to be given a frequency scale factor, i.e. some image of the current frequency the CPU is running at. Currently, this scale can be computed either by using counters (APERF/MPERF on x86, AMU on arm64), or by piggy-backing on the frequency selection done by cpufreq. For the latter, drivers have to explicitly set the scale factor themselves, despite it being purely boiler-plate code: the required information depends entirely on the kind of frequency switch callback implemented by the driver, i.e. either of: target_index(), target(), fast_switch() and setpolicy(). The fitness of those callbacks with regard to driving the Frequency Invariance Engine (FIE) is studied below: target_index() ============== Documentation states that the chosen frequency "must be determined by freq_table[index].frequency". It isn't clear if it *has* to be that frequency, or if it can use that frequency value to do some computation that ultimately leads to a different frequency selection. All drivers go for the former, while the vexpress-spc-cpufreq has an atypical implementation which is handled separately. Therefore, the hook works on the assumption the core can use freq_table[index].frequency. target() ======= This has been flagged as deprecated since: commit 9c0ebcf78fde ("cpufreq: Implement light weight ->target_index() routine") It also doesn't have that many users: gx-suspmod.c:439: .target = cpufreq_gx_target, s3c24xx-cpufreq.c:428: .target = s3c_cpufreq_target, intel_pstate.c:2528: .target = intel_cpufreq_target, cppc_cpufreq.c:401: .target = cppc_cpufreq_set_target, cpufreq-nforce2.c:371: .target = nforce2_target, sh-cpufreq.c:163: .target = sh_cpufreq_target, pcc-cpufreq.c:573: .target = pcc_cpufreq_target, Similarly to the path taken for target_index() calls in the cpufreq core during a frequency change, all of the drivers above will mark the end of a frequency change by a call to cpufreq_freq_transition_end(). Therefore, cpufreq_freq_transition_end() can be used as the location for the arch_set_freq_scale() call to potentially inform the scheduler of the frequency change. This change maintains the previous functionality for the drivers that implement the target_index() callback, while also adding support for the few drivers that implement the deprecated target() callback. fast_switch() ============= This callback *has* to return the frequency that was selected. setpolicy() =========== This callback does not have any designated way of informing what was the end choice. But there are only two drivers using setpolicy(), and none of them have current FIE support: drivers/cpufreq/longrun.c:281: .setpolicy = longrun_set_policy, drivers/cpufreq/intel_pstate.c:2215: .setpolicy = intel_pstate_set_policy, The intel_pstate is known to use counter-driven frequency invariance. Conclusion ========== Given that the significant majority of current FIE enabled drivers use callbacks that lend themselves to triggering the setting of the FIE scale factor in a generic way, move the invariance setter calls to cpufreq core. As a result of setting the frequency scale factor in cpufreq core, after callbacks that lend themselves to trigger it, remove this functionality from the driver side. To be noted that despite marking a successful frequency change, many cpufreq drivers will consider the new frequency as the requested frequency, although this is might not be the one granted by the hardware. Therefore, the call to arch_set_freq_scale() is a "best effort" one, and it is up to the architecture if the new frequency is used in the new frequency scale factor setting (determined by the implementation of arch_set_freq_scale()) or eventually used by the scheduler (determined by the implementation of arch_scale_freq_capacity()). The architecture is in a better position to decide if it has better methods to obtain more accurate information regarding the current frequency and use that information instead (for example, the use of counters). Also, the implementation to arch_set_freq_scale() will now have to handle error conditions (current frequency == 0) in order to prevent the overhead in cpufreq core when the default arch_set_freq_scale() implementation is used. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Suggested-by: Valentin Schneider <valentin.schneider@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-16cpufreq: qcom: Don't add frequencies without an OPPMatthias Kaehlcke1-6/+15
The driver currently adds all frequencies from the hardware LUT to the cpufreq table, regardless of whether the corresponding OPP exists. This prevents devices from disabling certain OPPs through the device tree and can result in CPU frequencies for which the interconnect bandwidth can't be adjusted. Only add frequencies with an OPP entry. Fixes: 55538fbc79e9 ("cpufreq: qcom: Read voltage LUT and populate OPP") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Add cpufreq support for SM8250 SoCManivannan Sadhasivam1-0/+9
SM8250 SoC uses EPSS block for carrying out the cpufreq duties. Hence, add support for it in the driver with relevant dev data. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Amit Kucheria <amitk@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Use of_device_get_match_data for offsets and row sizeManivannan Sadhasivam1-30/+59
For preparing the driver to handle further SoC revisions, let's use the of_device_get_match_data() API for getting the device specific offsets and row size instead of defining them globally. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify codeManivannan Sadhasivam1-8/+3
devm_platform_ioremap_resource() is the combination of platform_get_resource() and devm_ioremap_resource(). Hence, use it to simplify the code a bit. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Amit Kucheria <amitk@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Make use of cpufreq driver_data for passing pdevManivannan Sadhasivam1-5/+6
Get rid of global_pdev pointer and make use of cpufreq driver_data for passing the reference of pdev. This aligns with what other cpufreq drivers are doing. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-04Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki1-8/+83
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq driver changes for v5.9-rc1 from Viresh Kumar: "Here are the details: - Adaptive voltage scaling (AVS) support and minor cleanups for brcmstb driver (Florian Fainelli and Markus Mayer). - A new tegra driver and cleanup for the existing one (Sumit Gupta and Jon Hunter). - Bandwidth level support for Qcom driver along with OPP changes (Sibi Sankar). - Cleanups to sti, cpufreq-dt, ap806, CPPC drivers (Viresh Kumar, Lee Jones, Ivan Kokshaysky, Sven Auhagen, and Xin Hao). - Make schedutil default governor for ARM (Valentin Schneider). - Fix dependency issues for imx (Walter Lozano). - Cleanup around cached_resolved_idx in cpufreq core (Viresh Kumar)." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: make schedutil the default for arm and arm64 cpufreq: cached_resolved_idx can not be negative cpufreq: Add Tegra194 cpufreq driver dt-bindings: arm: Add NVIDIA Tegra194 CPU Complex binding cpufreq: imx: Select NVMEM_IMX_OCOTP cpufreq: sti-cpufreq: Fix some formatting and misspelling issues cpufreq: tegra186: Simplify probe return path cpufreq: CPPC: Reuse caps variable in few routines cpufreq: ap806: fix cpufreq driver needs ap cpu clk cpufreq: cppc: Reorder code and remove apply_hisi_workaround variable cpufreq: dt: fix oops on armada37xx cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS cpufreq: brcmstb-avs-cpufreq: Support polling AVS firmware cpufreq: brcmstb-avs-cpufreq: more flexible interface for __issue_avs_command() cpufreq: qcom: Disable fast switch when scaling DDR/L3 cpufreq: qcom: Update the bandwidth levels on frequency change OPP: Add and export helper to set bandwidth cpufreq: blacklist SC7180 in cpufreq-dt-platdev cpufreq: blacklist SDM845 in cpufreq-dt-platdev
2020-07-30cpufreq: cached_resolved_idx can not be negativeViresh Kumar1-4/+1
It is not possible for cached_resolved_idx to be invalid here as the cpufreq core always sets index to a positive value. Change its type to unsigned int and fix qcom usage a bit. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-07-30cpufreq: qcom: Disable fast switch when scaling DDR/L3Sibi Sankar1-2/+1
Disable fast switch when the opp-tables required for scaling DDR/L3 are populated. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-07-30cpufreq: qcom: Update the bandwidth levels on frequency changeSibi Sankar1-2/+81
Add support to parse optional OPP table attached to the cpu node when the OPP bandwidth values are populated. This allows for scaling of DDR/L3 bandwidth levels with frequency change. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-06-24OPP: refactor dev_pm_opp_of_register_em() and update related driversLukasz Luba1-1/+1
The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-11-07cpufreq: qcom-hw: Move driver initialization earlierAmit Kucheria1-1/+1
Allow qcom-hw driver to initialize right after the cpufreq and thermal subsystems are initialised in core_initcall so we get earlier access to thermal mitigation. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Taniya Das <tdas@codeaurora.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/eacce8d08388b0bdfc908d2701fe7c2b78d90441.1571656015.git.amit.kucheria@linaro.org
2019-08-22cpufreq: qcom-hw: invoke frequency-invariance setter functionDouglas RAILLARD1-1/+9
Add calls to arch_set_freq_scale() in qcom-cpufreq-hw driver to enable frequency invariance. Signed-off-by: Douglas RAILLARD <douglas.raillard@arm.com> Reviewed-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-08-22cpufreq: qcom-hw: Update logic to detect turbo frequencySibi Sankar1-7/+6
The core count read back from the each domain's look up table serves as an indicator for the onset of the turbo frequency and not accurate representation of number of cores in a paticular domain. Update turbo detection logic accordingly to add support for SM8150 SoCs. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-13Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki1-10/+40
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm into pm-cpufreq Pull ARM cpufreq driver updates for v5.1 from Viresh Kumar: "This pull request contains following changes: - New Armada 8k cpufreq driver (Gregory CLEMENT). - qcom driver cleanups (Amit Kucheria, Taniya Das, Yangtao Li). - s5pv210 driver cleanup (Paweł Chmiel). - tegra driver cleanup (Yangtao Li). - Minor update to MAINTAINERS file (Baruch Siach)." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom-hw: Register an Energy Model cpufreq: qcom: Read voltage LUT and populate OPP cpufreq: qcom-hw: Move to device_initcall cpufreq: tegra124: add missing of_node_put() cpufreq: qcom-kryo: make some variables static MAINTAINERS: Update the active pm tree for ARM cpufreq: ap806: add cpufreq driver for Armada 8K MAINTAINERS: add new entries for Armada 8K cpufreq driver cpufreq: s5pv210: Defer probe if getting regulators fail MAINTAINERS: use common indentation PM / OPP: Introduce a power estimation helper PM / OPP: Remove unused parameter of _generic_set_opp_clk_only()
2019-02-08cpufreq: qcom-hw: Register an Energy ModelMatthias Kaehlcke1-0/+2
Try and register an Energy Model from qcom-cpufreq-hw to allow interested sub-systems like the task scheduler to use the provided information. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Rebased over cpufreq related changes ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-08cpufreq: qcom: Read voltage LUT and populate OPPTaniya Das1-9/+37
Add support to read the voltage look up table and populate OPP for all corresponding CPUS for consumers like the energy model could use the frequency and voltage from the OPP tables. Also update the logic to not add duplicate OPPs. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Taniya Das <tdas@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-08cpufreq: qcom-hw: Move to device_initcallAmit Kucheria1-1/+1
subsys_initcall causes problems registering the driver as a thermal cooling device. If "faster boot" is the main reason for doing subsys_initcall, this should be handled in the bootloader or another boot constraint framework. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-01-31cpufreq: qcom-hw: Register as a cpufreq cooling deviceAmit Kucheria1-1/+2
Add the CPUFREQ_IS_COOLING_DEV flag to allow the cpufreq core to auto-register the driver as a cooling device. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-19cpufreq: qcom-hw: Add support for QCOM cpufreq HW driverTaniya Das1-0/+308
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this hardware engine. Signed-off-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Taniya Das <tdas@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>