Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c7772dd5-f081-426a-5443-5ebf32b7c7c0@samsung.com>
Date:   Thu, 6 Oct 2022 18:25:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0)
        Gecko/20100101 Thunderbird/102.3.1
Subject: Re: [PATCH v8 00/29] Rework the trip points creation
To:     Daniel Lezcano <daniel.lezcano@linaro.org>
Cc:     linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        rui.zhang@intel.com,
        Broadcom Kernel Team <bcm-kernel-feedback-list@broadcom.com>,
        Support Opensource <support.opensource@diasemi.com>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        NXP Linux Team <linux-imx@nxp.com>,
        Andy Gross <agross@kernel.org>,
        Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Alim Akhtar <alim.akhtar@samsung.com>, netdev@vger.kernel.org,
        platform-driver-x86@vger.kernel.org,
        linux-rpi-kernel@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org,
        linux-arm-msm@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
        linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
        linux-omap@vger.kernel.org, rafael@kernel.org
Content-Language: en-US
From:   Marek Szyprowski <m.szyprowski@samsung.com>
In-Reply-To: <97201878-3bb8-eac5-7fac-a690322ac43a@linaro.org>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <CGME20221003092704eucas1p2875c1f996dfd60a58f06cf986e02e8eb@eucas1p2.samsung.com>
        <20221003092602.1323944-1-daniel.lezcano@linaro.org>
        <8cdd1927-da38-c23e-fa75-384694724b1c@samsung.com>
        <c3258cb2-9a56-d048-5738-1132331a157d@linaro.org>
        <851008bf-145d-224c-87a8-cb6ec1e9addb@linaro.org>
        <207c1979-0da2-b05d-fead-6880ad956b90@samsung.com>
        <97201878-3bb8-eac5-7fac-a690322ac43a@linaro.org>
Precedence: bulk

Hi Daniel,

On 06.10.2022 08:55, Daniel Lezcano wrote:
>
> On 05/10/2022 15:05, Marek Szyprowski wrote:
>>
>> On 05.10.2022 14:37, Daniel Lezcano wrote:
>>>
>>> On 03/10/2022 23:18, Daniel Lezcano wrote:
>>>
>>> [ ... ]
>>>
>>>>> I've tested this v8 patchset after fixing the issue with Exynos TMU
>>>>> with
>>>>> https://lore.kernel.org/all/20221003132943.1383065-1-daniel.lezcano@linaro.org/ 
>>>>>
>>>>>
>>>>> patch and I got the following lockdep warning on all Exynos-based
>>>>> boards:
>>>>>
>>>>>
>>>>> ======================================================
>>>>> WARNING: possible circular locking dependency detected
>>>>> 6.0.0-rc1-00083-ge5c9d117223e #12945 Not tainted
>>>>> ------------------------------------------------------
>>>>> swapper/0/1 is trying to acquire lock:
>>>>> c1ce66b0 (&data->lock#2){+.+.}-{3:3}, at: exynos_get_temp+0x3c/0xc8
>>>>>
>>>>> but task is already holding lock:
>>>>> c2979b94 (&tz->lock){+.+.}-{3:3}, at:
>>>>> thermal_zone_device_update.part.0+0x3c/0x528
>>>>>
>>>>> which lock already depends on the new lock.
>>>>
>>>> I'm wondering if the problem is not already there and related to
>>>> data->lock ...
>>>>
>>>> Doesn't the thermal zone lock already prevent racy access to the data
>>>> structure?
>>>>
>>>> Another question: if the sensor clock is disabled after reading it,
>>>> how does the hardware update the temperature and detect the programed
>>>> threshold is crossed?
>>>
>>> just a gentle ping, as the fix will depend on your answer ;)
>>>
>> Sorry, I've been busy with other stuff. I thought I will fix this once I
>> find a bit of spare time.
>
> Ok, that is great if you can find time to fix it up because I've other 
> drivers to convert to the generic thermal trips.
>
>
>> IMHO the clock management is a bit over-engineered, as there is little
>> (if any) benefit from such fine grade clock management. That clock is
>> needed only for the AHB related part of the TMU (reading/writing the
>> registers). The IRQ generation and temperature measurement is clocked
>> from so called 'sclk' (special clock).
>>
>> I also briefly looked at the code and the internal lock doesn't look to
>> be really necessary assuming that the thermal core already serializes
>> all the calls.
>
> I looked at the code and I think the driver can be simplified (fixed?) 
> even more.
>
> IIUC, the sensor has multiple trip point interrupts, so if the device 
> tree is describing more trip points than the sensor supports, there is 
> a warning and the number of trip point is capped.
>
> IMO that can be simplified by using two trip point interrupt because 
> the thermal_zone_device_update() will call the set_trips callback with 
> the new boundaries. IOW, the thermal framework sets a new trip point 
> interrupt when one is crossed.
>
> That should result in the simplification of the tmu_control as well as 
> the tmu_probe function. As well as removing the limitation of the 
> number of trip points.
>
> In order to have that correctly working, the 'set_trips' ops must be 
> used to call the tmu_control callback instead of calling it in tmu_probe.
>
> The intialization workflow should be:
>
> probe->...
>  ->thermal_zone_device_register()
>   ->thermal_zone_device_update()
>    ->update_trip_points()
>     ->ops->set_trips()
>       ->tmu_control()
>
> Also, replace the workqueue by a threaded interrupt.
>
> Does it make sense?

Yes, definitely. Frankly speaking I've never looked into that code, so I 
was not aware that it needs some cleanup.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland