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] [day] [month] [year] [list]

Message-ID: <d77bfb17-d875-4bd2-abb4-e9ff012d7bfc@rock-chips.com>
Date: Thu, 27 Feb 2025 19:26:21 +0800
From: Kever Yang <kever.yang@...k-chips.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>,
 Heiko Stübner <heiko@...ech.de>
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

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