[PATCH 1/2] dt-bindings: rockchip-thermal: Support the RK3562 SoC compatible

[PATCH 1/2] dt-bindings: rockchip-thermal: Support the RK3562 SoC compatible

[Kever Yang]

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

[PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

[Kever Yang]

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

Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

[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>
> ---
> 
>   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

Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

[Heiko Stübner]

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

Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

[Daniel Lezcano]

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

Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

[Kever Yang]

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 ...
>
>

Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

[Dragan Simic]

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.