* [PATCH 1/2] dt-bindings: rockchip-thermal: Support the RK3562 SoC compatible
@ 2024-12-24 9:40 Kever Yang
2024-12-24 9:40 ` [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver Kever Yang
0 siblings, 1 reply; 7+ messages in thread
From: Kever Yang @ 2024-12-24 9:40 UTC (permalink / raw)
To: heiko
Cc: linux-rockchip, Kever Yang, devicetree, Conor Dooley, Rob Herring,
Lukasz Luba, linux-pm, linux-kernel, Krzysztof Kozlowski,
Zhang Rui, Rafael J. Wysocki, linux-arm-kernel, Daniel Lezcano
Add a new compatible for tsadc on RK3562 SoCs.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---
Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
index b717ea8261ca..f55f2045fc84 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
@@ -20,6 +20,7 @@ properties:
- rockchip,rk3328-tsadc
- rockchip,rk3368-tsadc
- rockchip,rk3399-tsadc
+ - rockchip,rk3562-tsadc
- rockchip,rk3568-tsadc
- rockchip,rk3588-tsadc
- rockchip,rv1108-tsadc
--
2.25.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver
2024-12-24 9:40 [PATCH 1/2] dt-bindings: rockchip-thermal: Support the RK3562 SoC compatible Kever Yang
@ 2024-12-24 9:40 ` Kever Yang
2025-02-11 9:36 ` Daniel Lezcano
0 siblings, 1 reply; 7+ messages in thread
From: Kever Yang @ 2024-12-24 9:40 UTC (permalink / raw)
To: heiko
Cc: linux-rockchip, Shaohan Yao, Kever Yang, linux-pm, Lukasz Luba,
linux-kernel, Zhang Rui, Rafael J. Wysocki, linux-arm-kernel,
Daniel Lezcano
From: Shaohan Yao <shaohan.yao@rock-chips.com>
There are one Temperature Sensor on rk3562, channel 0 is for chip.
Signed-off-by: Shaohan Yao <shaohan.yao@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---
drivers/thermal/rockchip_thermal.c | 112 ++++++++++++++++++++++++++++-
1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index f551df48eef9..aec0e634bd1f 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2014-2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2014-2021, Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2021-2024, Rockchip Electronics Co., Ltd.
* Caesar Wang <wxt@rock-chips.com>
*/
@@ -185,6 +186,8 @@ struct rockchip_thermal_data {
#define TSADCV2_AUTO_PERIOD_HT 0x6c
#define TSADCV3_AUTO_PERIOD 0x154
#define TSADCV3_AUTO_PERIOD_HT 0x158
+#define TSADCV9_Q_MAX 0x210
+#define TSADCV9_FLOW_CON 0x218
#define TSADCV2_AUTO_EN BIT(0)
#define TSADCV2_AUTO_EN_MASK BIT(16)
@@ -195,6 +198,7 @@ struct rockchip_thermal_data {
#define TSADCV2_AUTO_TSHUT_POLARITY_MASK BIT(24)
#define TSADCV3_AUTO_Q_SEL_EN BIT(1)
+#define TSADCV3_AUTO_Q_SEL_EN_MASK BIT(17)
#define TSADCV2_INT_SRC_EN(chn) BIT(chn)
#define TSADCV2_INT_SRC_EN_MASK(chn) BIT(16 + (chn))
@@ -220,6 +224,12 @@ struct rockchip_thermal_data {
#define TSADCV5_AUTO_PERIOD_HT_TIME 1622 /* 2.5ms */
#define TSADCV6_AUTO_PERIOD_TIME 5000 /* 2.5ms */
#define TSADCV6_AUTO_PERIOD_HT_TIME 5000 /* 2.5ms */
+#define TSADCV7_AUTO_PERIOD_TIME 3000 /* 2.5ms */
+#define TSADCV7_AUTO_PERIOD_HT_TIME 3000 /* 2.5ms */
+#define TSADCV12_AUTO_PERIOD_TIME 3000 /* 2.5ms */
+#define TSADCV12_AUTO_PERIOD_HT_TIME 3000 /* 2.5ms */
+#define TSADCV3_Q_MAX_VAL 0x7ff /* 11bit 2047 */
+#define TSADCV12_Q_MAX_VAL 0xfff /* 12bit 4095 */
#define TSADCV2_USER_INTER_PD_SOC 0x340 /* 13 clocks */
#define TSADCV5_USER_INTER_PD_SOC 0xfc0 /* 97us, at least 90us */
@@ -230,6 +240,8 @@ struct rockchip_thermal_data {
#define PX30_GRF_SOC_CON2 0x0408
+#define RK3562_GRF_TSADC_CON 0x0580
+
#define RK3568_GRF_TSADC_CON 0x0600
#define RK3568_GRF_TSADC_ANA_REG0 (0x10001 << 0)
#define RK3568_GRF_TSADC_ANA_REG1 (0x10001 << 1)
@@ -497,6 +509,45 @@ static const struct tsadc_table rk3399_code_table[] = {
{TSADCV3_DATA_MASK, 125000},
};
+static const struct tsadc_table rk3562_code_table[] = {
+ {0, -40000},
+ {1419, -40000},
+ {1428, -35000},
+ {1436, -30000},
+ {1445, -25000},
+ {1453, -20000},
+ {1462, -15000},
+ {1470, -10000},
+ {1479, -5000},
+ {1487, 0},
+ {1496, 5000},
+ {1504, 10000},
+ {1512, 15000},
+ {1521, 20000},
+ {1529, 25000},
+ {1538, 30000},
+ {1546, 35000},
+ {1555, 40000},
+ {1563, 45000},
+ {1572, 50000},
+ {1580, 55000},
+ {1589, 60000},
+ {1598, 65000},
+ {1606, 70000},
+ {1615, 75000},
+ {1623, 80000},
+ {1632, 85000},
+ {1640, 90000},
+ {1648, 95000},
+ {1657, 100000},
+ {1666, 105000},
+ {1674, 110000},
+ {1682, 115000},
+ {1691, 120000},
+ {1699, 125000},
+ {TSADCV2_DATA_MASK, 125000},
+};
+
static const struct tsadc_table rk3568_code_table[] = {
{0, -40000},
{1584, -40000},
@@ -834,6 +885,37 @@ static void rk_tsadcv8_initialize(struct regmap *grf, void __iomem *regs,
regs + TSADCV2_AUTO_CON);
}
+static void rk_tsadcv12_initialize(struct regmap *grf, void __iomem *regs,
+ enum tshut_polarity tshut_polarity)
+{
+ writel_relaxed(TSADCV12_AUTO_PERIOD_TIME, regs + TSADCV3_AUTO_PERIOD);
+ writel_relaxed(TSADCV12_AUTO_PERIOD_HT_TIME,
+ regs + TSADCV3_AUTO_PERIOD_HT);
+ writel_relaxed(TSADCV2_HIGHT_INT_DEBOUNCE_COUNT,
+ regs + TSADCV3_HIGHT_INT_DEBOUNCE);
+ writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
+ regs + TSADCV3_HIGHT_TSHUT_DEBOUNCE);
+ writel_relaxed(TSADCV12_Q_MAX_VAL, regs + TSADCV9_Q_MAX);
+ writel_relaxed(TSADCV3_AUTO_Q_SEL_EN | TSADCV3_AUTO_Q_SEL_EN_MASK,
+ regs + TSADCV2_AUTO_CON);
+ if (tshut_polarity == TSHUT_HIGH_ACTIVE)
+ writel_relaxed(TSADCV2_AUTO_TSHUT_POLARITY_HIGH |
+ TSADCV2_AUTO_TSHUT_POLARITY_MASK,
+ regs + TSADCV2_AUTO_CON);
+ else
+ writel_relaxed(TSADCV2_AUTO_TSHUT_POLARITY_MASK,
+ regs + TSADCV2_AUTO_CON);
+
+ if (!IS_ERR(grf)) {
+ regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_TSEN);
+ udelay(15);
+ regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_ANA_REG0);
+ regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_ANA_REG1);
+ regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_ANA_REG2);
+ usleep_range(100, 200);
+ }
+}
+
static void rk_tsadcv2_irq_ack(void __iomem *regs)
{
u32 val;
@@ -1258,6 +1340,30 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
},
};
+static const struct rockchip_tsadc_chip rk3562_tsadc_data = {
+ .chn_offset = 0,
+ .chn_num = 1, /* one channels for tsadc */
+
+ .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
+ .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+ .tshut_temp = 95000,
+
+ .initialize = rk_tsadcv12_initialize,
+ .irq_ack = rk_tsadcv4_irq_ack,
+ .control = rk_tsadcv4_control,
+ .get_temp = rk_tsadcv4_get_temp,
+ .set_alarm_temp = rk_tsadcv3_alarm_temp,
+ .set_tshut_temp = rk_tsadcv3_tshut_temp,
+ .set_tshut_mode = rk_tsadcv3_tshut_mode,
+
+ .table = {
+ .id = rk3562_code_table,
+ .length = ARRAY_SIZE(rk3562_code_table),
+ .data_mask = TSADCV2_DATA_MASK,
+ .mode = ADC_INCREMENT,
+ },
+};
+
static const struct rockchip_tsadc_chip rk3568_tsadc_data = {
/* cpu, gpu */
.chn_offset = 0,
@@ -1337,6 +1443,10 @@ static const struct of_device_id of_rockchip_thermal_match[] = {
.compatible = "rockchip,rk3399-tsadc",
.data = (void *)&rk3399_tsadc_data,
},
+ {
+ .compatible = "rockchip,rk3562-tsadc",
+ .data = (void *)&rk3562_tsadc_data,
+ },
{
.compatible = "rockchip,rk3568-tsadc",
.data = (void *)&rk3568_tsadc_data,
--
2.25.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver
2024-12-24 9:40 ` [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver Kever Yang
@ 2025-02-11 9:36 ` Daniel Lezcano
2025-02-11 10:19 ` Heiko Stübner
2025-02-20 5:28 ` Dragan Simic
0 siblings, 2 replies; 7+ messages in thread
From: Daniel Lezcano @ 2025-02-11 9:36 UTC (permalink / raw)
To: Kever Yang, heiko
Cc: linux-rockchip, Shaohan Yao, linux-pm, Lukasz Luba, linux-kernel,
Zhang Rui, Rafael J. Wysocki, linux-arm-kernel
On 24/12/2024 10:40, Kever Yang wrote:
> From: Shaohan Yao <shaohan.yao@rock-chips.com>
>
> There are one Temperature Sensor on rk3562, channel 0 is for chip.
A bit stingy in terms of description, no ?
> Signed-off-by: Shaohan Yao <shaohan.yao@rock-chips.com>
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
>
> drivers/thermal/rockchip_thermal.c | 112 ++++++++++++++++++++++++++++-
> 1 file changed, 111 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
> index f551df48eef9..aec0e634bd1f 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Copyright (c) 2014-2016, Fuzhou Rockchip Electronics Co., Ltd
> + * Copyright (c) 2014-2021, Fuzhou Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2021-2024, Rockchip Electronics Co., Ltd.
> * Caesar Wang <wxt@rock-chips.com>
> */
>
> @@ -185,6 +186,8 @@ struct rockchip_thermal_data {
> #define TSADCV2_AUTO_PERIOD_HT 0x6c
> #define TSADCV3_AUTO_PERIOD 0x154
> #define TSADCV3_AUTO_PERIOD_HT 0x158
> +#define TSADCV9_Q_MAX 0x210
> +#define TSADCV9_FLOW_CON 0x218
>
> #define TSADCV2_AUTO_EN BIT(0)
> #define TSADCV2_AUTO_EN_MASK BIT(16)
> @@ -195,6 +198,7 @@ struct rockchip_thermal_data {
> #define TSADCV2_AUTO_TSHUT_POLARITY_MASK BIT(24)
>
> #define TSADCV3_AUTO_Q_SEL_EN BIT(1)
> +#define TSADCV3_AUTO_Q_SEL_EN_MASK BIT(17)
>
> #define TSADCV2_INT_SRC_EN(chn) BIT(chn)
> #define TSADCV2_INT_SRC_EN_MASK(chn) BIT(16 + (chn))
> @@ -220,6 +224,12 @@ struct rockchip_thermal_data {
> #define TSADCV5_AUTO_PERIOD_HT_TIME 1622 /* 2.5ms */
> #define TSADCV6_AUTO_PERIOD_TIME 5000 /* 2.5ms */
> #define TSADCV6_AUTO_PERIOD_HT_TIME 5000 /* 2.5ms */
> +#define TSADCV7_AUTO_PERIOD_TIME 3000 /* 2.5ms */
> +#define TSADCV7_AUTO_PERIOD_HT_TIME 3000 /* 2.5ms */
> +#define TSADCV12_AUTO_PERIOD_TIME 3000 /* 2.5ms */
> +#define TSADCV12_AUTO_PERIOD_HT_TIME 3000 /* 2.5ms */
> +#define TSADCV3_Q_MAX_VAL 0x7ff /* 11bit 2047 */
> +#define TSADCV12_Q_MAX_VAL 0xfff /* 12bit 4095 */
>
> #define TSADCV2_USER_INTER_PD_SOC 0x340 /* 13 clocks */
> #define TSADCV5_USER_INTER_PD_SOC 0xfc0 /* 97us, at least 90us */
> @@ -230,6 +240,8 @@ struct rockchip_thermal_data {
>
> #define PX30_GRF_SOC_CON2 0x0408
>
> +#define RK3562_GRF_TSADC_CON 0x0580
> +
> #define RK3568_GRF_TSADC_CON 0x0600
> #define RK3568_GRF_TSADC_ANA_REG0 (0x10001 << 0)
> #define RK3568_GRF_TSADC_ANA_REG1 (0x10001 << 1)
> @@ -497,6 +509,45 @@ static const struct tsadc_table rk3399_code_table[] = {
> {TSADCV3_DATA_MASK, 125000},
> };
>
> +static const struct tsadc_table rk3562_code_table[] = {
> + {0, -40000},
> + {1419, -40000},
> + {1428, -35000},
> + {1436, -30000},
> + {1445, -25000},
> + {1453, -20000},
> + {1462, -15000},
> + {1470, -10000},
> + {1479, -5000},
> + {1487, 0},
> + {1496, 5000},
> + {1504, 10000},
> + {1512, 15000},
> + {1521, 20000},
> + {1529, 25000},
> + {1538, 30000},
> + {1546, 35000},
> + {1555, 40000},
> + {1563, 45000},
> + {1572, 50000},
> + {1580, 55000},
> + {1589, 60000},
> + {1598, 65000},
> + {1606, 70000},
> + {1615, 75000},
> + {1623, 80000},
> + {1632, 85000},
> + {1640, 90000},
> + {1648, 95000},
> + {1657, 100000},
> + {1666, 105000},
> + {1674, 110000},
> + {1682, 115000},
> + {1691, 120000},
> + {1699, 125000},
> + {TSADCV2_DATA_MASK, 125000},
> +};
May be it is time to optimize all these tables out of the memory driver?
It is the 9th table introduced.
> static const struct tsadc_table rk3568_code_table[] = {
> {0, -40000},
> {1584, -40000},
> @@ -834,6 +885,37 @@ static void rk_tsadcv8_initialize(struct regmap *grf, void __iomem *regs,
> regs + TSADCV2_AUTO_CON);
> }
>
> +static void rk_tsadcv12_initialize(struct regmap *grf, void __iomem *regs,
> + enum tshut_polarity tshut_polarity)
> +{
> + writel_relaxed(TSADCV12_AUTO_PERIOD_TIME, regs + TSADCV3_AUTO_PERIOD);
> + writel_relaxed(TSADCV12_AUTO_PERIOD_HT_TIME,
> + regs + TSADCV3_AUTO_PERIOD_HT);
> + writel_relaxed(TSADCV2_HIGHT_INT_DEBOUNCE_COUNT,
> + regs + TSADCV3_HIGHT_INT_DEBOUNCE);
> + writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
> + regs + TSADCV3_HIGHT_TSHUT_DEBOUNCE);
> + writel_relaxed(TSADCV12_Q_MAX_VAL, regs + TSADCV9_Q_MAX);
> + writel_relaxed(TSADCV3_AUTO_Q_SEL_EN | TSADCV3_AUTO_Q_SEL_EN_MASK,
> + regs + TSADCV2_AUTO_CON);
> + if (tshut_polarity == TSHUT_HIGH_ACTIVE)
> + writel_relaxed(TSADCV2_AUTO_TSHUT_POLARITY_HIGH |
> + TSADCV2_AUTO_TSHUT_POLARITY_MASK,
> + regs + TSADCV2_AUTO_CON);
> + else
> + writel_relaxed(TSADCV2_AUTO_TSHUT_POLARITY_MASK,
> + regs + TSADCV2_AUTO_CON);
> +
> + if (!IS_ERR(grf)) {
> + regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_TSEN);
> + udelay(15);
> + regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_ANA_REG0);
> + regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_ANA_REG1);
> + regmap_write(grf, RK3562_GRF_TSADC_CON, RK3568_GRF_TSADC_ANA_REG2);
> + usleep_range(100, 200);
> + }
> +}
> +
> static void rk_tsadcv2_irq_ack(void __iomem *regs)
> {
> u32 val;
> @@ -1258,6 +1340,30 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
> },
> };
>
> +static const struct rockchip_tsadc_chip rk3562_tsadc_data = {
> + .chn_offset = 0,
> + .chn_num = 1, /* one channels for tsadc */
> +
> + .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
> + .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
> + .tshut_temp = 95000,
> +
> + .initialize = rk_tsadcv12_initialize,
> + .irq_ack = rk_tsadcv4_irq_ack,
> + .control = rk_tsadcv4_control,
> + .get_temp = rk_tsadcv4_get_temp,
> + .set_alarm_temp = rk_tsadcv3_alarm_temp,
> + .set_tshut_temp = rk_tsadcv3_tshut_temp,
> + .set_tshut_mode = rk_tsadcv3_tshut_mode,
> +
> + .table = {
> + .id = rk3562_code_table,
> + .length = ARRAY_SIZE(rk3562_code_table),
> + .data_mask = TSADCV2_DATA_MASK,
> + .mode = ADC_INCREMENT,
> + },
> +};
> +
> static const struct rockchip_tsadc_chip rk3568_tsadc_data = {
> /* cpu, gpu */
> .chn_offset = 0,
> @@ -1337,6 +1443,10 @@ static const struct of_device_id of_rockchip_thermal_match[] = {
> .compatible = "rockchip,rk3399-tsadc",
> .data = (void *)&rk3399_tsadc_data,
> },
> + {
> + .compatible = "rockchip,rk3562-tsadc",
> + .data = (void *)&rk3562_tsadc_data,
> + },
> {
> .compatible = "rockchip,rk3568-tsadc",
> .data = (void *)&rk3568_tsadc_data,
--
<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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver
2025-02-11 9:36 ` Daniel Lezcano
@ 2025-02-11 10:19 ` Heiko Stübner
2025-02-18 19:43 ` Daniel Lezcano
2025-02-20 5:28 ` Dragan Simic
1 sibling, 1 reply; 7+ messages in thread
From: Heiko Stübner @ 2025-02-11 10:19 UTC (permalink / raw)
To: Kever Yang, Daniel Lezcano
Cc: linux-rockchip, Shaohan Yao, linux-pm, Lukasz Luba, linux-kernel,
Zhang Rui, Rafael J. Wysocki, linux-arm-kernel
Hey Daniel,
Am Dienstag, 11. Februar 2025, 10:36:09 MEZ schrieb Daniel Lezcano:
> On 24/12/2024 10:40, Kever Yang wrote:
> > From: Shaohan Yao <shaohan.yao@rock-chips.com>
> >
> > There are one Temperature Sensor on rk3562, channel 0 is for chip.
>
> A bit stingy in terms of description, no ?
>
>
> > Signed-off-by: Shaohan Yao <shaohan.yao@rock-chips.com>
> > Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
[...]
> > +static const struct tsadc_table rk3562_code_table[] = {
> > + {0, -40000},
> > + {1419, -40000},
> > + {1428, -35000},
> > + {1436, -30000},
> > + {1445, -25000},
> > + {1453, -20000},
> > + {1462, -15000},
> > + {1470, -10000},
> > + {1479, -5000},
> > + {1487, 0},
> > + {1496, 5000},
> > + {1504, 10000},
> > + {1512, 15000},
> > + {1521, 20000},
> > + {1529, 25000},
> > + {1538, 30000},
> > + {1546, 35000},
> > + {1555, 40000},
> > + {1563, 45000},
> > + {1572, 50000},
> > + {1580, 55000},
> > + {1589, 60000},
> > + {1598, 65000},
> > + {1606, 70000},
> > + {1615, 75000},
> > + {1623, 80000},
> > + {1632, 85000},
> > + {1640, 90000},
> > + {1648, 95000},
> > + {1657, 100000},
> > + {1666, 105000},
> > + {1674, 110000},
> > + {1682, 115000},
> > + {1691, 120000},
> > + {1699, 125000},
> > + {TSADCV2_DATA_MASK, 125000},
> > +};
>
> May be it is time to optimize all these tables out of the memory driver?
>
> It is the 9th table introduced.
just to see if we think differently, what do you have in mind?
For me the adc-to-temperature conversion _is_ part of the hw-block itself,
so should likely not spill into the devicetree, but you're right, defining
a big table for each soc also isn't really great.
For the rk3562 in question, the stepping seems to be 8,9,8,9,....
where for the rk3568 the value stepping seems to be 32,36,32,36,...
and it looks similar for the other socs too, with the driver is already
interpolating between values it seems.
So even just halving (or more) all the big tables (dropping every second
entry for example) should not really loose us real granularity.
Heiko
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver
2025-02-11 10:19 ` Heiko Stübner
@ 2025-02-18 19:43 ` Daniel Lezcano
2025-02-27 11:26 ` Kever Yang
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Lezcano @ 2025-02-18 19:43 UTC (permalink / raw)
To: Heiko Stübner, Kever Yang
Cc: linux-rockchip, Shaohan Yao, linux-pm, Lukasz Luba, linux-kernel,
Zhang Rui, Rafael J. Wysocki, linux-arm-kernel
On 11/02/2025 11:19, Heiko Stübner wrote:
> Hey Daniel,
>
> Am Dienstag, 11. Februar 2025, 10:36:09 MEZ schrieb Daniel Lezcano:
>> On 24/12/2024 10:40, Kever Yang wrote:
>>> From: Shaohan Yao <shaohan.yao@rock-chips.com>
>>>
>>> There are one Temperature Sensor on rk3562, channel 0 is for chip.
>>
>> A bit stingy in terms of description, no ?
>>
>>
>>> Signed-off-by: Shaohan Yao <shaohan.yao@rock-chips.com>
>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> [...]
>>> +static const struct tsadc_table rk3562_code_table[] = {
>>> + {0, -40000},
>>> + {1419, -40000},
>>> + {1428, -35000},
>>> + {1436, -30000},
>>> + {1445, -25000},
>>> + {1453, -20000},
>>> + {1462, -15000},
>>> + {1470, -10000},
>>> + {1479, -5000},
>>> + {1487, 0},
>>> + {1496, 5000},
>>> + {1504, 10000},
>>> + {1512, 15000},
>>> + {1521, 20000},
>>> + {1529, 25000},
>>> + {1538, 30000},
>>> + {1546, 35000},
>>> + {1555, 40000},
>>> + {1563, 45000},
>>> + {1572, 50000},
>>> + {1580, 55000},
>>> + {1589, 60000},
>>> + {1598, 65000},
>>> + {1606, 70000},
>>> + {1615, 75000},
>>> + {1623, 80000},
>>> + {1632, 85000},
>>> + {1640, 90000},
>>> + {1648, 95000},
>>> + {1657, 100000},
>>> + {1666, 105000},
>>> + {1674, 110000},
>>> + {1682, 115000},
>>> + {1691, 120000},
>>> + {1699, 125000},
>>> + {TSADCV2_DATA_MASK, 125000},
>>> +};
>>
>> May be it is time to optimize all these tables out of the memory driver?
>>
>> It is the 9th table introduced.
>
> just to see if we think differently, what do you have in mind?
>
> For me the adc-to-temperature conversion _is_ part of the hw-block itself,
> so should likely not spill into the devicetree, but you're right, defining
> a big table for each soc also isn't really great.
>
> For the rk3562 in question, the stepping seems to be 8,9,8,9,....
> where for the rk3568 the value stepping seems to be 32,36,32,36,...
> and it looks similar for the other socs too, with the driver is already
> interpolating between values it seems.
>
> So even just halving (or more) all the big tables (dropping every second
> entry for example) should not really loose us real granularity.
It can be just a formula to be reused in the adc_to_temp, temp_to_adc or
precompute the table from the formula:
For instance the following formulas:
rk3588_code_table:
y = ((x^2 + 23315x - 5949300) * 100) / 2457
rk3568_code_table:
y = ((x^2 - 2660x + 1547712) * 625) / 2448
etc ...
--
<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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver
2025-02-11 9:36 ` Daniel Lezcano
2025-02-11 10:19 ` Heiko Stübner
@ 2025-02-20 5:28 ` Dragan Simic
1 sibling, 0 replies; 7+ messages in thread
From: Dragan Simic @ 2025-02-20 5:28 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Kever Yang, heiko, linux-rockchip, Shaohan Yao, linux-pm,
Lukasz Luba, linux-kernel, Zhang Rui, Rafael J. Wysocki,
linux-arm-kernel
Hello Daniel,
On 2025-02-11 10:36, Daniel Lezcano wrote:
> On 24/12/2024 10:40, Kever Yang wrote:
>> From: Shaohan Yao <shaohan.yao@rock-chips.com>
>>
>> There are one Temperature Sensor on rk3562, channel 0 is for chip.
>
> A bit stingy in terms of description, no ?
[snip]
>> @@ -497,6 +509,45 @@ static const struct tsadc_table
>> rk3399_code_table[] = {
>> {TSADCV3_DATA_MASK, 125000},
>> };
>> +static const struct tsadc_table rk3562_code_table[] = {
>> + {0, -40000},
>> + {1419, -40000},
>> + {1428, -35000},
>> + {1436, -30000},
>> + {1445, -25000},
>> + {1453, -20000},
>> + {1462, -15000},
>> + {1470, -10000},
>> + {1479, -5000},
>> + {1487, 0},
>> + {1496, 5000},
>> + {1504, 10000},
>> + {1512, 15000},
>> + {1521, 20000},
>> + {1529, 25000},
>> + {1538, 30000},
>> + {1546, 35000},
>> + {1555, 40000},
>> + {1563, 45000},
>> + {1572, 50000},
>> + {1580, 55000},
>> + {1589, 60000},
>> + {1598, 65000},
>> + {1606, 70000},
>> + {1615, 75000},
>> + {1623, 80000},
>> + {1632, 85000},
>> + {1640, 90000},
>> + {1648, 95000},
>> + {1657, 100000},
>> + {1666, 105000},
>> + {1674, 110000},
>> + {1682, 115000},
>> + {1691, 120000},
>> + {1699, 125000},
>> + {TSADCV2_DATA_MASK, 125000},
>> +};
>
> May be it is time to optimize all these tables out of the memory
> driver?
>
> It is the 9th table introduced.
FWIW, I'm also not a big fan of these tables, and I always feel like
"meh" when I see them. However, I'm also not a big fan of substituting
them with some kind of formulas, because the SoC TRMs specify exactly
these tables, with some additional notes that the values may change in
future SoC revisions. In other words, these values may even change at
some point, at least in theory.
With all that in mind, FWIW, I'd rather see these conversion tables
included verbatim in the driver code, because such an approach reduces
the possibilities for some hard-to-spot errors, allows easy, direct
correlation with the TRMs, and should make possible changes to them
in the future easier.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver
2025-02-18 19:43 ` Daniel Lezcano
@ 2025-02-27 11:26 ` Kever Yang
0 siblings, 0 replies; 7+ messages in thread
From: Kever Yang @ 2025-02-27 11:26 UTC (permalink / raw)
To: Daniel Lezcano, Heiko Stübner
Cc: linux-rockchip, Shaohan Yao, linux-pm, Lukasz Luba, linux-kernel,
Zhang Rui, Rafael J. Wysocki, linux-arm-kernel
Hi Daniel,
On 2025/2/19 03:43, Daniel Lezcano wrote:
> On 11/02/2025 11:19, Heiko Stübner wrote:
>> Hey Daniel,
>>
>> Am Dienstag, 11. Februar 2025, 10:36:09 MEZ schrieb Daniel Lezcano:
>>> On 24/12/2024 10:40, Kever Yang wrote:
>>>> From: Shaohan Yao <shaohan.yao@rock-chips.com>
>>>>
>>>> There are one Temperature Sensor on rk3562, channel 0 is for chip.
>>>
>>> A bit stingy in terms of description, no ?
>>>
>>>
>>>> Signed-off-by: Shaohan Yao <shaohan.yao@rock-chips.com>
>>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>> [...]
>>>> +static const struct tsadc_table rk3562_code_table[] = {
>>>> + {0, -40000},
>>>> + {1419, -40000},
>>>> + {1428, -35000},
>>>> + {1436, -30000},
>>>> + {1445, -25000},
>>>> + {1453, -20000},
>>>> + {1462, -15000},
>>>> + {1470, -10000},
>>>> + {1479, -5000},
>>>> + {1487, 0},
>>>> + {1496, 5000},
>>>> + {1504, 10000},
>>>> + {1512, 15000},
>>>> + {1521, 20000},
>>>> + {1529, 25000},
>>>> + {1538, 30000},
>>>> + {1546, 35000},
>>>> + {1555, 40000},
>>>> + {1563, 45000},
>>>> + {1572, 50000},
>>>> + {1580, 55000},
>>>> + {1589, 60000},
>>>> + {1598, 65000},
>>>> + {1606, 70000},
>>>> + {1615, 75000},
>>>> + {1623, 80000},
>>>> + {1632, 85000},
>>>> + {1640, 90000},
>>>> + {1648, 95000},
>>>> + {1657, 100000},
>>>> + {1666, 105000},
>>>> + {1674, 110000},
>>>> + {1682, 115000},
>>>> + {1691, 120000},
>>>> + {1699, 125000},
>>>> + {TSADCV2_DATA_MASK, 125000},
>>>> +};
>>>
>>> May be it is time to optimize all these tables out of the memory
>>> driver?
>>>
>>> It is the 9th table introduced.
>>
>> just to see if we think differently, what do you have in mind?
>>
>> For me the adc-to-temperature conversion _is_ part of the hw-block
>> itself,
>> so should likely not spill into the devicetree, but you're right,
>> defining
>> a big table for each soc also isn't really great.
>>
>> For the rk3562 in question, the stepping seems to be 8,9,8,9,....
>> where for the rk3568 the value stepping seems to be 32,36,32,36,...
>> and it looks similar for the other socs too, with the driver is already
>> interpolating between values it seems.
>>
>> So even just halving (or more) all the big tables (dropping every second
>> entry for example) should not really loose us real granularity.
>
> It can be just a formula to be reused in the adc_to_temp, temp_to_adc
> or precompute the table from the formula:
>
> For instance the following formulas:
>
> rk3588_code_table:
>
> y = ((x^2 + 23315x - 5949300) * 100) / 2457
>
> rk3568_code_table:
>
> y = ((x^2 - 2660x + 1547712) * 625) / 2448
I can understand, it looks much better if we can use the formula instead
of the table.
We got all these data from different vendor/foundry , some of vendor do
provide the formula while others not.
And I think there is a key issue is that the formula may not fit for all
the situation, sometimes need to calibrate
after chips are out, only the table is available in this case.
And in this case, we send the table as-is from the vendor.
Thanks,
- Kever
>
> etc ...
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-02-27 12:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-24 9:40 [PATCH 1/2] dt-bindings: rockchip-thermal: Support the RK3562 SoC compatible Kever Yang
2024-12-24 9:40 ` [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver Kever Yang
2025-02-11 9:36 ` Daniel Lezcano
2025-02-11 10:19 ` Heiko Stübner
2025-02-18 19:43 ` Daniel Lezcano
2025-02-27 11:26 ` Kever Yang
2025-02-20 5:28 ` Dragan Simic
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox