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

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

 




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 | 22 +++++++++++++
  drivers/acpi/internal.h              |  9 +++++
  drivers/acpi/processor_thermal.c     | 49 +++++++++++++++++++++++-----
  4 files changed, 72 insertions(+), 9 deletions(-)
  create mode 100644 drivers/acpi/arm64/thermal_cpufreq.c

diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
index 143debc1ba4a..726944648c9b 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-y                                += thermal_cpufreq.o
diff --git a/drivers/acpi/arm64/thermal_cpufreq.c b/drivers/acpi/arm64/thermal_cpufreq.c
new file mode 100644
index 000000000000..40d5806ed528
--- /dev/null
+++ b/drivers/acpi/arm64/thermal_cpufreq.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/acpi.h>
+
+#include "../internal.h"
+
+#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
+#define SMCCC_SOC_ID_T241      0x036b0241

Sorry for missing this earlier. Not sure if the above define needs to be
conditional. Even if it has to be, CONFIG_ARM_SMCCC_SOC_ID is more
appropriate.


Will remove the ifdef.

+
+int acpi_arch_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
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 866c7c4ed233..ee213a8cddc5 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -85,6 +85,15 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent);
  acpi_status acpi_sysfs_table_handler(u32 event, void *table, void *context);
  void acpi_scan_table_notify(void);

+#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY

It looks weird to add a such specific ARM config option in generic ACPI
code/header.

Does it make sense to add some new config this new feature you are adding
or just use ARM64 and have CONFIG_HAVE_ARM_SMCCC_DISCOVERY check internally
in the arch specific call.

--
Regards,
Sudeep

Ok, will use CONFIG_ARM64 instead.
I think we don't need to check for CONFIG_HAVE_ARM_SMCCC_DISCOVERY inside the arch call as it returns zero if the soc_id value is different from Tegra241.

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