Re: [Patch v5 2/2] ACPI: processor: reduce CPUFREQ thermal reduction pctg for Tegra241

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 23/10/23 14:23, Sudeep Holla wrote:
External email: Use caution opening links or attachments


On Sat, Oct 14, 2023 at 04:24:26PM +0530, Sumit Gupta wrote:
From: Srikar Srimath Tirumala <srikars@xxxxxxxxxx>

Current implementation of processor_thermal performs software throttling
in fixed steps of "20%" which can be too coarse for some platforms.
We observed some performance gain after reducing the throttle percentage.
Change the CPUFREQ thermal reduction percentage and maximum thermal steps
to be configurable. Also, update the default values of both for Nvidia
Tegra241 (Grace) SoC. The thermal reduction percentage is reduced to "5%"
and accordingly the maximum number of thermal steps are increased as they
are derived from the reduction percentage.

Signed-off-by: Srikar Srimath Tirumala <srikars@xxxxxxxxxx>
Co-developed-by: Sumit Gupta <sumitg@xxxxxxxxxx>
Signed-off-by: Sumit Gupta <sumitg@xxxxxxxxxx>
---
  drivers/acpi/arm64/Makefile          |  1 +
  drivers/acpi/arm64/thermal_cpufreq.c | 20 ++++++++++++++++
  drivers/acpi/processor_thermal.c     | 35 +++++++++++++++++++++++++---
  include/linux/acpi.h                 |  9 +++++++
  4 files changed, 62 insertions(+), 3 deletions(-)
  create mode 100644 drivers/acpi/arm64/thermal_cpufreq.c

diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
index 143debc1ba4a..3f181d8156cc 100644
--- a/drivers/acpi/arm64/Makefile
+++ b/drivers/acpi/arm64/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_ACPI_GTDT)       += gtdt.o
  obj-$(CONFIG_ACPI_APMT)      += apmt.o
  obj-$(CONFIG_ARM_AMBA)               += amba.o
  obj-y                                += dma.o init.o
+obj-$(CONFIG_ACPI)           += thermal_cpufreq.o

Do we really need CONFIG_ACPI here ? We won't be building this if it
is not enabled.


I think we can remove the CONFIG_ACPI macro here and enable it by default.

If this is for some module building, then does it make sense to have
more specific config ? May be CONFIG_ACPI_THERMAL ?

diff --git a/drivers/acpi/arm64/thermal_cpufreq.c b/drivers/acpi/arm64/thermal_cpufreq.c
new file mode 100644
index 000000000000..de834fb013e7
--- /dev/null
+++ b/drivers/acpi/arm64/thermal_cpufreq.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/acpi.h>
+
+#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
+#define SMCCC_SOC_ID_T241      0x036b0241
+
+int acpi_thermal_cpufreq_pctg(void)
+{
+     s32 soc_id = arm_smccc_get_soc_id_version();
+
+     /*
+      * Check JEP106 code for NVIDIA Tegra241 chip (036b:0241) and
+      * reduce the CPUFREQ Thermal reduction percentage to 5%.
+      */
+     if (soc_id == SMCCC_SOC_ID_T241)
+             return 5;
+
+     return 0;
+}
+#endif

Since this looks like arch specific hook/callback, not sure if it is good
idea to have "arch_" in the function name. But if Rafael is OK with the name
I am fine with this as well.

--
Regards,
Sudeep

Will change the name from acpi_thermal_cpufreq_* to acpi_arch_thermal_cpufreq_* if this suits more.

Best Regards,
Sumit Gupta




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux