summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/tegra194-cpufreq.c
AgeCommit message (Collapse)AuthorFilesLines
2024-07-09cpufreq: Make cpufreq_driver->exit() return voidLizhe1-3/+1
The cpufreq core doesn't check the return type of the exit() callback and there is not much the core can do on failures at that point. Just drop the returned value and make it return void. Signed-off-by: Lizhe <sensor1010@163.com> [ Viresh: Reworked the patches to fix all missing changes together. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> # Mediatek Acked-by: Sudeep Holla <sudeep.holla@arm.com> # scpi, scmi, vexpress Acked-by: Mario Limonciello <mario.limonciello@amd.com> # amd Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # bmips Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Kevin Hilman <khilman@baylibre.com> # omap
2023-10-10cpufreq: tegra194: remove redundant AND with cpu_online_maskSumit Gupta1-1/+1
Remove redundant 'AND' with cpu_online_mask as the policy->cpus always contains only the currently online CPUs. Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/lkml/20231003050019.a6mcchw2o2z2wkrh@vireshk-i7/ Signed-off-by: Sumit Gupta <sumitg@nvidia.com> [ Viresh: Fix rebase conflict ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-10cpufreq: tegra194: use refclk delta based loop instead of udelaySumit Gupta1-17/+55
Use reference clock count based loop instead of "udelay()" for sampling of counters to improve the accuracy of re-generated CPU frequency. "udelay()" internally calls "WFE" which stops the counters and results in bigger delta between the last set freq and the re-generated value from counters. The counter sampling window used in loop is the minimum number of reference clock cycles which is known to give a stable value of CPU frequency. The change also helps to reduce the sampling window from "500us" to "<50us". Suggested-by: Antti Miettinen <amiettinen@nvidia.com> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-10cpufreq: tegra194: save CPU data to avoid repeated SMP callsSumit Gupta1-28/+51
Currently, we make SMP call on every frequency set request to get the physical 'CPU ID' and 'CLUSTER ID' for the target CPU. This change optimizes the repeated calls by storing the physical IDs and the per core frequency register offset for all CPUs during boot. Later this info is used directly when required to set the frequency or read it from ACTMON counters. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-09-27cpufreq: tegra194: fix warning due to missing opp_putSumit Gupta1-0/+2
Fix the warning due to missing dev_pm_opp_put() call and hence wrong refcount value. This causes below warning message when trying to remove the module. Call trace: dev_pm_opp_put_opp_table+0x154/0x15c dev_pm_opp_remove_table+0x34/0xa0 _dev_pm_opp_cpumask_remove_table+0x7c/0xbc dev_pm_opp_of_cpumask_remove_table+0x10/0x18 tegra194_cpufreq_exit+0x24/0x34 [tegra194_cpufreq] cpufreq_remove_dev+0xa8/0xf8 subsys_interface_unregister+0x90/0xe8 cpufreq_unregister_driver+0x54/0x9c tegra194_cpufreq_remove+0x18/0x2c [tegra194_cpufreq] platform_remove+0x24/0x74 device_remove+0x48/0x78 device_release_driver_internal+0xc8/0x160 driver_detach+0x4c/0x90 bus_remove_driver+0x68/0xb8 driver_unregister+0x2c/0x58 platform_driver_unregister+0x10/0x18 tegra194_ccplex_driver_exit+0x14/0x1e0 [tegra194_cpufreq] __arm64_sys_delete_module+0x184/0x270 Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Signed-off-by: Sumit Gupta <sumitg@nvidia.com> [ Viresh: Add a blank line ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-08-28cpufreq: tegra194: remove opp table in exit hookSumit Gupta1-0/+12
Add exit hook and remove OPP table when the device gets unregistered. This will fix the error messages when the CPU FREQ driver module is removed and then re-inserted. It also fixes these messages while onlining the first CPU from a policy whose all CPU's were previously offlined. debugfs: File 'cpu5' in directory 'opp' already present! debugfs: File 'cpu6' in directory 'opp' already present! debugfs: File 'cpu7' in directory 'opp' already present! Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Signed-off-by: Sumit Gupta <sumitg@nvidia.com> [ Viresh: Dropped irrelevant change from it ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-08-28cpufreq: tegra194: add online/offline hooksSumit Gupta1-0/+17
Implement the light-weight tear down and bring up helpers to reduce the amount of work to do on CPU offline/online operation. This change helps to make the hotplugging paths much faster. Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Link: https://lore.kernel.org/lkml/20230816033402.3abmugb5goypvllm@vireshk-i7/ [ Viresh: Fixed rebase conflict ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-07-20cpufreq: tegra194: Convert to platform remove callback returning voidYangtao Li1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-05-11cpufreq: tegra194: Fix an error handling path in tegra194_cpufreq_probe()Christophe JAILLET1-2/+4
If the probe needs to be deferred, some resources still need to be released. So branch to the error handling path instead of returning directly. Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-04-18cpufreq: tegra194: add OPP support and set bandwidthSumit Gupta1-13/+143
Add support to use OPP table from DT in Tegra194 cpufreq driver. Tegra SoC's receive the frequency lookup table (LUT) from BPMP-FW. Cross check the OPP's present in DT against the LUT from BPMP-FW and enable only those DT OPP's which are present in LUT also. The OPP table in DT has CPU Frequency to bandwidth mapping where the bandwidth value is per MC channel. DRAM bandwidth depends on the number of MC channels which can vary as per the boot configuration. This per channel bandwidth from OPP table will be later converted by MC driver to final bandwidth value by multiplying with number of channels before sending the request to BPMP-FW. If OPP table is not present in DT, then use the LUT from BPMP-FW directy as the CPU frequency table and not do the DRAM frequency scaling which is same as the current behavior. Now, as the CPU Frequency table is being controlling through OPP table in DT. Keeping fewer entries in the table will create less frequency steps and can help to scale fast to high frequencies when required. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-02-06cpufreq: tegra194: Enable CPUFREQ thermal coolingYi-Wei Wang1-1/+2
Populate the flag CPUFREQ_IS_COOLING_DEV for the Tegra194 CPUFREQ driver to register it as a cooling device. This enables CPU frequency throttling for CPUs when the passive trip points are crossed. Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: tegra194: Fix module loadingJon Hunter1-0/+1
When the Tegra194 CPUFREQ driver is built as a module it is not automatically loaded as expected on Tegra194 devices. Populate the MODULE_DEVICE_TABLE to fix this. Cc: v5.9+ <stable@vger.kernel.org> # v5.9+ Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-09-26cpufreq: tegra194: change tegra239_cpufreq_soc to staticYang Yingliang1-1/+1
tegra239_cpufreq_soc is only used in tegra194-cpufreq.c now, change it to static. Fixes: 676886010707 ("cpufreq: tegra194: Add support for Tegra239") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-09-21cpufreq: tegra194: Add support for Tegra239Sumit Gupta1-14/+15
Adding support for Tegra239 SoC which has eight cores in a single cluster. Also, moving num_clusters to SoC data to avoid over allocating memory for four clusters always. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-09-01cpufreq: tegra194: Remove the unneeded result variableye xingchen1-5/+1
Return the value returned by smp_call_function_single() directly instead of storing it in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> [ Viresh: Minor update to commit log ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-18cpufreq: tegra194: Staticize struct tegra_cpufreq_soc instancesViresh Kumar1-2/+2
Fix sparse warnings by marking these structures static. Fixes: 273bc890a2a8 ("cpufreq: tegra194: Add support for Tegra234") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: tegra194: Add support for Tegra234Sumit Gupta1-0/+104
This patch adds driver support for Tegra234 cpufreq. Tegra234 has per core MMIO registers instead of system registers for cpu frequency requests and to read the counters for re-constructing the cpu frequency. Also, MPIDR affinity info in Tegra234 is different from Tegra194. Added ops hooks and soc data for Tegra234. This will help to easily add variants of Tegra234 and future SoC's which use similar logic to {get|set} the cpu frequency. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: tegra194: add soc data to support multiple socSumit Gupta1-37/+105
Adding SoC data and ops to support multiple SoC's in same driver. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-10-04cpufreq: tegra186/tegra194: Handle errors in BPMP responseMikko Perttunen1-1/+7
The return value from tegra_bpmp_transfer indicates the success or failure of the IPC transaction with BPMP. If the transaction succeeded, we also need to check the actual command's result code. Add code to do this. While at it, explicitly handle missing CPU clusters, which can occur on floorswept chips. This worked before as well, but possibly only by accident. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-02-04cpufreq: Remove CPUFREQ_STICKY flagViresh Kumar1-2/+1
During cpufreq driver's registration, if the ->init() callback for all the CPUs fail then there is not much point in keeping the driver around as it will only account for more of unnecessary noise, for example cpufreq core will try to suspend/resume the driver which never got registered properly. The removal of such a driver is avoided if the driver carries the CPUFREQ_STICKY flag. This was added way back [1] in 2004 and perhaps no one should ever need it now. A lot of drivers do set this flag, probably because they just copied it from other drivers. This was added earlier for some platforms [2] because their cpufreq drivers were getting registered before the CPUs were registered with subsys framework. And hence they used to fail. The same isn't true anymore though. The current code flow in the kernel is: start_kernel() -> kernel_init() -> kernel_init_freeable() -> do_basic_setup() -> driver_init() -> cpu_dev_init() -> subsys_system_register() //For CPUs -> do_initcalls() -> cpufreq_register_driver() Clearly, the CPUs will always get registered with subsys framework before any cpufreq driver can get probed. Remove the flag and update the relevant drivers. Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/include/linux/cpufreq.h?id=7cc9f0d9a1ab04cedc60d64fd8dcf7df224a3b4d # [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/arm/mach-sa1100/cpu-sa1100.c?id=f59d3bbe35f6268d729f51be82af8325d62f20f5 # [2] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-07cpufreq: tegra194: Rename tegra194_get_speed_common functionJon Hunter1-2/+2
The function tegra194_get_speed_common() uses hardware timers to calculate the current CPUFREQ and so rename this function to be tegra194_calculate_speed() to reflect what it does. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-12-07cpufreq: tegra194: Remove unnecessary frequency calculationJon Hunter1-9/+3
The Tegra194 CPUFREQ driver sets the CPUFREQ_NEED_INITIAL_FREQ_CHECK flag which means that the CPUFREQ framework will call the 'get' callback on boot to determine the current frequency of the CPUs. Therefore, it is not necessary for the Tegra194 CPUFREQ driver to internally call the tegra194_get_speed_common() during initialisation to query the current frequency as well. Fix this by removing the call to the tegra194_get_speed_common() during initialisation and simplify the code. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-12-07cpufreq: tegra194: get consistent cpuinfo_cur_freqSumit Gupta1-9/+53
Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed and keeps changing slightly. This change returns a consistent value from freq_table. If the reconstructed frequency has acceptable delta from the last written value, then return the frequency corresponding to the last written ndiv value from freq_table. Otherwise, print a warning and return the reconstructed freq. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-21cpufreq: replace cpu_logical_map() with read_cpuid_mpir()Sumit Gupta1-3/+7
Commit eaecca9e7710 ("arm64: Fix __cpu_logical_map undefined issue") fixes the issue with building tegra194 cpufreq driver as module. But the fix might cause problem while supporting physical CPU hotplug[1]. This patch fixes the original problem by avoiding use of cpu_logical_map(). Instead calling read_cpuid_mpidr() to get MPIDR on target CPU. [1] https://lore.kernel.org/linux-arm-kernel/20200724131059.GB6521@bogus/ Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver") Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject & changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-30cpufreq: Add Tegra194 cpufreq driverSumit Gupta1-0/+390
Add support for CPU frequency scaling on Tegra194. The frequency of each core can be adjusted by writing a clock divisor value to a MSR on the core. The range of valid divisors is queried from the BPMP. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-18 00:58:18 +0300