From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Yang Shen <shenyang39@huawei.com>,
rui.zhang@intel.com, amit.kucheria@verdurent.com
Cc: linux-pm@vger.kernel.org, linuxarm@huawei.com, wangzhou1@hisilicon.com
Subject: Re: [PATCH V3 2/2] thermal: Add HiSilicon Kunpeng thermal driver
Date: Mon, 27 Apr 2020 14:13:31 +0200 [thread overview]
Message-ID: <53ca3883-9155-c023-7916-10ec8cccf977@linaro.org> (raw)
In-Reply-To: <1587455093-33876-3-git-send-email-shenyang39@huawei.com>
On 21/04/2020 09:44, Yang Shen wrote:
> Support HiSilicon Kunpeng tsensor. the driver will report the max
> temperature for each core.
As this is a new driver, can you give a bit more details of the hardware
in this description.
A subsidiary question, why do you want to aggregate the temperatures in
this driver ?
> Signed-off-by: Yang Shen <shenyang39@huawei.com>
> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
> Signed-off-by: Kunshan Tang <tangkunshan@huawei.com>
> ---
> drivers/thermal/Kconfig | 8 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/kunpeng_thermal.c | 216 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 225 insertions(+)
> create mode 100644 drivers/thermal/kunpeng_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5a05db5..7611b5d 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -239,6 +239,14 @@ config HISI_THERMAL
> thermal framework. cpufreq is used as the cooling device to throttle
> CPUs when the passive trip is crossed.
>
> +config KUNPENG_THERMAL
> + tristate "HiSilicon kunpeng thermal driver"
> + depends on ARM64 || COMPILE_TEST
> + help
> + Enable this to plug HiSilicon kunpeng's thermal sensors driver into
> + the Linux thermal framework, which supports to get the highest
> + temperature of one Kunpeng SoC.
> +
> config IMX_THERMAL
> tristate "Temperature sensor driver for Freescale i.MX SoCs"
> depends on ARCH_MXC || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 9fb88e2..88ffca5 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -57,3 +57,4 @@ obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
> +obj-$(CONFIG_KUNPENG_THERMAL) += kunpeng_thermal.o
> diff --git a/drivers/thermal/kunpeng_thermal.c b/drivers/thermal/kunpeng_thermal.c
> new file mode 100644
> index 0000000..d22e875
> --- /dev/null
> +++ b/drivers/thermal/kunpeng_thermal.c
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2020 HiSilicon Limited. */
> +
> +#include <linux/acpi.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define KUNPENG_TSENSOR_CONTROL 0x20D0
> +#define KUNPENG_TSENSOR_ST 0x60D0
> +#define KUNPENG_TSENSOR_SAMPLE 0x60D4
> +#define KUNPENG_TSENSOR_CONTROL_EN BIT(0)
> +
> +#define KUNPENG_TSENSOR_IS_READY(reg) (((reg) >> 12) & 0x1)
> +#define KUNPENG_TSENSOR_IS_VALID(reg) (((reg) >> 31) & 0x1)
> +#define KUNPENG_TSENSOR_TRIM_HIGH(reg) (((reg) >> 15) & 0x7FF)
> +#define KUNPENG_TSENSOR_TRIM_LOW(reg) ((reg) & 0x7FF)
> +#define KUNPENG_TSENSOR_TEMP_VAL(reg) ((reg) & 0x3FF)
> +#define KUNPENG_TSENSOR_BASE_NUM(num) (2 * (num))
> +#define KUNPENG_TSENSOR_TRIM_NUM(num) (2 * (num) + 1)
> +
> +#define KUNPENG_TSENSOR_RD_INTVRL_US 5
> +#define KUNPENG_TSENSOR_RD_TMOUT_US 5000
> +#define KUNPENG_TSENSOR_BASIC_TMP 25000
> +#define KUNPENG_TSENSOR_BASIC_TRIM_RANGE 80000
> +
> +struct kunpeng_tsensor {
> + void __iomem *base;
> + void __iomem *trim_register;
> +};
> +
> +struct kunpeng_thermal_dev {
> + u32 num_tsensors;
> + struct kunpeng_tsensor tsensor[];
> +};
> +
> +static int kunpeng_thermal_temp_correct(u32 tmp, u32 trim)
> +{
> + int trim_high = KUNPENG_TSENSOR_TRIM_HIGH(trim);
> + int trim_low = KUNPENG_TSENSOR_TRIM_LOW(trim);
> + int val = KUNPENG_TSENSOR_TEMP_VAL(tmp);
> +
> + if (trim_high == trim_low)
> + return INT_MIN;
> +
> + /* temperature of tsensor needs to be calibrated */
> + return KUNPENG_TSENSOR_BASIC_TRIM_RANGE * (val - trim_low) /
> + (trim_high - trim_low) + KUNPENG_TSENSOR_BASIC_TMP;
Is it possible to give some details about why this is done?
> +}
> +
> +static int kunpeng_thermal_get_temp(struct thermal_zone_device *thermal,
> + int *temp)
> +{
> + struct kunpeng_thermal_dev *tdev = thermal->devdata;
> + int tempmax = INT_MIN;
> + u32 i, reg, tmp, trim;
> + int ret;
> +
> + for (i = 0; i < tdev->num_tsensors; i++) {
> + /* Waiting for tsensor ready */
> + ret = readl_relaxed_poll_timeout(tdev->tsensor[i].base +
> + KUNPENG_TSENSOR_ST, reg,
> + KUNPENG_TSENSOR_IS_READY(reg),
> + KUNPENG_TSENSOR_RD_INTVRL_US,
> + KUNPENG_TSENSOR_RD_TMOUT_US);
> + if (ret) {
> + dev_err(&thermal->device,
> + "Tsensor%u isn't ready!\n", i);
> + continue;
> + }
> +
> + /* checking if temperatures are valid */
> + tmp = readl_relaxed(tdev->tsensor[i].base +
> + KUNPENG_TSENSOR_SAMPLE);
> + if (!KUNPENG_TSENSOR_IS_VALID(tmp)) {
> + dev_err(&thermal->device,
> + "Tsensor%u temperature is invalid!\n", i);
> + continue;
> + }
> +
> + trim = readl_relaxed(tdev->tsensor[i].trim_register);
> +
> + ret = kunpeng_thermal_temp_correct(tmp, trim);
> + if (ret == INT_MIN) {
> + dev_err(&thermal->device,
> + "Tsensor%u trim value is invalid!\n", i);
> + continue;
> + }
> +
> + tempmax = max(ret, tempmax);
> + }
> +
> + if (tempmax == INT_MIN)
> + return -EINVAL;
> +
> + *temp = tempmax;
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_device_ops ops = {
> + .get_temp = kunpeng_thermal_get_temp,
> +};
> +
> +static int kunpeng_thermal_get_iobase(struct platform_device *pdev,
> + struct kunpeng_tsensor *tsensor,
> + u32 resource_num)
> +{
> + struct resource *res;
> + void __iomem *base;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, resource_num);
> + if (!res)
> + return -EINVAL;
> +
> + base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (IS_ERR(base))
> + return -EINVAL;
> +
> + if (resource_num & 1)
> + tsensor->trim_register = base;
> + else
> + tsensor->base = base;
> +
> + return 0;
> +}
> +
> +static int kunpeng_thermal_probe(struct platform_device *pdev)
> +{
> + u32 num_tsensors = pdev->num_resources >> 1;
> + struct thermal_zone_device *thermal_zone;
> + struct kunpeng_thermal_dev *tdev;
> + u32 i, reg;
> + int ret;
> +
> + tdev = devm_kzalloc(&pdev->dev, sizeof(*tdev) + sizeof(*tdev->tsensor) *
> + num_tsensors, GFP_KERNEL);
> + if (!tdev)
> + return -ENOMEM;
> +
> + tdev->num_tsensors = num_tsensors;
> +
> + for (i = 0; i < num_tsensors; i++) {
> + ret = kunpeng_thermal_get_iobase(pdev, &tdev->tsensor[i],
> + KUNPENG_TSENSOR_BASE_NUM(i));
> + if (ret) {
> + dev_err(&pdev->dev, "Fail to ioremap base!\n");
> + return ret;
> + }
> +
> + ret = kunpeng_thermal_get_iobase(pdev, &tdev->tsensor[i],
> + KUNPENG_TSENSOR_TRIM_NUM(i));
> + if (ret) {
> + dev_err(&pdev->dev, "Fail to ioremap trim register!\n");
> + return ret;
> + }
I initially thought there was a bug because the function is called with
the &tsensor[i] twice, then noticed the spin in the underlying function.
It is probably better to make the code a bit more self-explicit. May be
increment 'i' by a step of 2?
> + reg = readl_relaxed(tdev->tsensor[i].base +
> + KUNPENG_TSENSOR_CONTROL);
> + writel_relaxed(reg | KUNPENG_TSENSOR_CONTROL_EN,
> + tdev->tsensor[i].base +
> + KUNPENG_TSENSOR_CONTROL);
Please add helpers with explicit function name for understanding.
> + }
> +
> + thermal_zone = thermal_zone_device_register("kunpeng_thermal", 0, 0,
> + tdev, &ops, NULL, 0, 0);
> + if (IS_ERR(thermal_zone)) {
> + dev_err(&pdev->dev, "Fail to register to thermal subsystem\n");
> + return PTR_ERR(thermal_zone);
> + }
> +
> + platform_set_drvdata(pdev, thermal_zone);
> +
> + return 0;
> +}
> +
> +/**
> + * kunpeng_thermal_remove() - Unregister device from thermal.
> + *
> + * This driver and IMU share tsensor devices. This function only unregister
> + * devices from thermal but never disable tsensors.
What is the IMU ?
I don't see in this driver anything related to the sensors being shared
with something else.
> + */
> +static int kunpeng_thermal_remove(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *thermal_zone = platform_get_drvdata(pdev);
> +
> + thermal_zone_device_unregister(thermal_zone);
Why not add a devm_thermal_zone_device_register() ? and get rid of this
function ?
> + return 0;
> +}
> +
> +static const struct acpi_device_id kunpeng_thermal_acpi_match[] = {
> + { "HISI0371", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, kunpeng_thermal_acpi_match);
> +
> +static struct platform_driver kunpeng_thermal_driver = {
> + .probe = kunpeng_thermal_probe,
> + .remove = kunpeng_thermal_remove,
> + .driver = {
> + .name = "kunpeng_thermal",
> + .acpi_match_table = ACPI_PTR(kunpeng_thermal_acpi_match),
> + },
> +};
> +
> +module_platform_driver(kunpeng_thermal_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Yang Shen <shenyang39@huawei.com>");
> +MODULE_DESCRIPTION("HiSilicon Kunpeng thermal driver");
> --
> 2.7.4
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2020-04-27 12:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 7:44 [PATCH V3 0/2] thermal:Add HiSilicon Kunpeng thermal driver and Maintainers Yang Shen
2020-04-21 7:44 ` [PATCH V3 1/2] MAINTAINERS: Add maintainers for kunpeng thermal Yang Shen
2020-04-21 7:44 ` [PATCH V3 2/2] thermal: Add HiSilicon Kunpeng thermal driver Yang Shen
2020-04-27 12:13 ` Daniel Lezcano [this message]
2020-04-28 11:58 ` shenyang (M)
2020-04-28 14:02 ` Daniel Lezcano
2020-05-09 7:35 ` Zhou Wang
2020-05-10 5:04 ` Daniel Lezcano
2020-05-11 1:26 ` Zhou Wang
2020-05-11 8:14 ` Daniel Lezcano
2020-05-13 8:12 ` Zhou Wang
2020-05-13 12:45 ` Amit Kucheria
2020-05-14 13:08 ` Zhou Wang
2020-05-15 18:29 ` Daniel Lezcano
2020-04-27 8:36 ` [PATCH V3 0/2] thermal:Add HiSilicon Kunpeng thermal driver and Maintainers shenyang (M)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53ca3883-9155-c023-7916-10ec8cccf977@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=amit.kucheria@verdurent.com \
--cc=linux-pm@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=rui.zhang@intel.com \
--cc=shenyang39@huawei.com \
--cc=wangzhou1@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).