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

["Heiko Stübner" <heiko@sntech.de>]

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