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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e36a5771-d277-41d3-af9c-c5841c4060a2@linaro.org>
Date: Tue, 18 Feb 2025 20:43:42 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Heiko Stübner <heiko@...ech.de>,
 Kever Yang <kever.yang@...k-chips.com>
Cc: linux-rockchip@...ts.infradead.org,
 Shaohan Yao <shaohan.yao@...k-chips.com>, linux-pm@...r.kernel.org,
 Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org,
 Zhang Rui <rui.zhang@...el.com>, "Rafael J. Wysocki" <rafael@...nel.org>,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal
 driver

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@...k-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@...k-chips.com>
>>> Signed-off-by: Kever Yang <kever.yang@...k-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