From: Marek Szyprowski <m.szyprowski@samsung.com>
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
Subject: Re: [PATCH v8 00/29] Rework the trip points creation
Date: Thu, 6 Oct 2022 18:25:35 +0200 [thread overview]
Message-ID: <c7772dd5-f081-426a-5443-5ebf32b7c7c0@samsung.com> (raw)
In-Reply-To: <97201878-3bb8-eac5-7fac-a690322ac43a@linaro.org>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2022-10-06 16:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20221003092704eucas1p2875c1f996dfd60a58f06cf986e02e8eb@eucas1p2.samsung.com>
[not found] ` <20221003092602.1323944-1-daniel.lezcano@linaro.org>
[not found] ` <CGME20221003093207eucas1p1d456288f35eadbc6fcda0bf24b58e678@eucas1p1.samsung.com>
[not found] ` <20221003092602.1323944-20-daniel.lezcano@linaro.org>
2022-10-03 12:50 ` [PATCH v8 19/29] thermal/of: Remove of_thermal_get_crit_temp() Marek Szyprowski
2022-10-03 13:29 ` [PATCH] thermal/drivers/exynos: Fix NULL pointer dereference when getting the critical temp Daniel Lezcano
2022-10-03 13:40 ` Krzysztof Kozlowski
2022-10-03 13:50 ` Marek Szyprowski
2022-10-17 13:48 ` Marek Szyprowski
2022-10-17 14:14 ` Daniel Lezcano
2022-10-03 13:31 ` [PATCH v8 19/29] thermal/of: Remove of_thermal_get_crit_temp() Daniel Lezcano
2022-10-03 14:10 ` [PATCH v8 00/29] Rework the trip points creation Marek Szyprowski
2022-10-03 15:36 ` Daniel Lezcano
2022-10-03 21:18 ` Daniel Lezcano
2022-10-05 12:37 ` Daniel Lezcano
2022-10-05 13:05 ` Marek Szyprowski
2022-10-06 6:55 ` Daniel Lezcano
2022-10-06 16:25 ` Marek Szyprowski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7772dd5-f081-426a-5443-5ebf32b7c7c0@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=agross@kernel.org \
--cc=alim.akhtar@samsung.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bzolnier@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=support.opensource@diasemi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).