From: Lukasz Luba <lukasz.luba@arm.com>
To: Mateusz Majewski <m.majewski2@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Amit Kucheria <amitk@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
Alim Akhtar <alim.akhtar@samsung.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 7/8] thermal: exynos: split initialization of TMU and the thermal zone
Date: Mon, 23 Oct 2023 13:59:07 +0100 [thread overview]
Message-ID: <91b3ff5a-cfdf-4bba-806e-093a90746d86@arm.com> (raw)
In-Reply-To: <20231003111638.241542-8-m.majewski2@samsung.com>
Hi Mateusz,
On 10/3/23 12:16, Mateusz Majewski wrote:
> This will be needed in the future, as the thermal zone subsystem might
> call our callbacks right after devm_thermal_of_zone_register. Currently
> we just make get_temp return EAGAIN in such case, but this will not be
> possible with state-modifying callbacks, for instance set_trips.
>
> Signed-off-by: Mateusz Majewski <m.majewski2@samsung.com>
> ---
> v1 -> v2: We take clocks into account; exynos_tmu_initialize needs both
> clocks, as tmu_initialize might use the base_second registers. However,
> exynos_thermal_zone_configure only needs clk.
>
> drivers/thermal/samsung/exynos_tmu.c | 104 +++++++++++++++------------
> 1 file changed, 60 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
> index 7138e001fa5a..343e27c61528 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -251,25 +251,8 @@ static void sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
> static int exynos_tmu_initialize(struct platform_device *pdev)
> {
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> - struct thermal_zone_device *tzd = data->tzd;
> - int num_trips = thermal_zone_get_num_trips(tzd);
> unsigned int status;
> - int ret = 0, temp;
> -
> - ret = thermal_zone_get_crit_temp(tzd, &temp);
> - if (ret && data->soc != SOC_ARCH_EXYNOS5433) { /* FIXME */
> - dev_err(&pdev->dev,
> - "No CRITICAL trip point defined in device tree!\n");
> - goto out;
> - }
> -
> - if (num_trips > data->ntrip) {
> - dev_info(&pdev->dev,
> - "More trip points than supported by this TMU.\n");
> - dev_info(&pdev->dev,
> - "%d trip points should be configured in polling mode.\n",
> - num_trips - data->ntrip);
> - }
> + int ret = 0;
>
> mutex_lock(&data->lock);
> clk_enable(data->clk);
> @@ -280,32 +263,63 @@ static int exynos_tmu_initialize(struct platform_device *pdev)
> if (!status) {
> ret = -EBUSY;
> } else {
> - int i, ntrips =
> - min_t(int, num_trips, data->ntrip);
> -
> data->tmu_initialize(pdev);
> -
> - /* Write temperature code for rising and falling threshold */
> - for (i = 0; i < ntrips; i++) {
> -
> - struct thermal_trip trip;
> -
> - ret = thermal_zone_get_trip(tzd, i, &trip);
> - if (ret)
> - goto err;
> -
> - data->tmu_set_trip_temp(data, i, trip.temperature / MCELSIUS);
> - data->tmu_set_trip_hyst(data, i, trip.temperature / MCELSIUS,
> - trip.hysteresis / MCELSIUS);
> - }
> -
> data->tmu_clear_irqs(data);
> }
> +
> + mutex_unlock(&data->lock);
> + clk_disable(data->clk);
> + if (!IS_ERR(data->clk_sec))
> + clk_disable(data->clk_sec);
In all other places the clock is strictly protected inside the critical
section, but not here. In this code in theory on SMP (especially with
big.LITTLE system with different speeds of CPUs) this could lead to
disabling the clocks just after other CPU acquired the mutex and enabled
them (in order to use the HW regs).
Please put those two clocks before the mutex_unlock() and in the
reverse order.
Regards,
Lukasz
next prev parent reply other threads:[~2023-10-23 12:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20231003111703eucas1p271e5b007be186b73639f3b958e2544f8@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 0/8] Improve Exynos thermal driver Mateusz Majewski
[not found] ` <CGME20231003111705eucas1p2f47a85d9c53d608654c5957cae88cf60@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 1/8] thermal: exynos: remove an unnecessary field description Mateusz Majewski
[not found] ` <CGME20231003111707eucas1p2ec2e5eacf68ecb0610f74ca1105c9da4@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 2/8] thermal: exynos: drop id field Mateusz Majewski
[not found] ` <CGME20231003111708eucas1p29eebdad45a2eae16148c9a5dbbcd47eb@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 3/8] thermal: exynos: switch from workqueue-driven interrupt handling to threaded interrupts Mateusz Majewski
[not found] ` <CGME20231003111709eucas1p21f2d28615faab2f4aa4d9a264cf7f54f@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 4/8] thermal: exynos: handle devm_regulator_get_optional return value correctly Mateusz Majewski
2023-10-06 13:15 ` Krzysztof Kozlowski
[not found] ` <CGME20231003111711eucas1p2646dcfd2d7d473b78b012153bca06cc7@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 5/8] thermal: exynos: simplify regulator (de)initialization Mateusz Majewski
2023-10-06 13:15 ` Krzysztof Kozlowski
[not found] ` <CGME20231003111712eucas1p1a089b3aa7e10ae84d8963f89b6bbecd6@eucas1p1.samsung.com>
2023-10-03 11:16 ` [PATCH v3 6/8] thermal: exynos: stop using the threshold mechanism on Exynos 4210 Mateusz Majewski
[not found] ` <CGME20231003111713eucas1p27fcc64df0091b6097461f28b05bf772a@eucas1p2.samsung.com>
2023-10-03 11:16 ` [PATCH v3 7/8] thermal: exynos: split initialization of TMU and the thermal zone Mateusz Majewski
2023-10-06 13:41 ` Krzysztof Kozlowski
2023-10-23 12:59 ` Lukasz Luba [this message]
2023-10-23 13:33 ` Marek Szyprowski
2023-10-23 13:44 ` Lukasz Luba
[not found] ` <CGME20231003111714eucas1p19c2351845d47b4ed1da8bc1b866e3353@eucas1p1.samsung.com>
2023-10-03 11:16 ` [PATCH v3 8/8] thermal: exynos: use set_trips Mateusz Majewski
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=91b3ff5a-cfdf-4bba-806e-093a90746d86@arm.com \
--to=lukasz.luba@arm.com \
--cc=alim.akhtar@samsung.com \
--cc=amitk@kernel.org \
--cc=broonie@kernel.org \
--cc=bzolnier@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.majewski2@samsung.com \
--cc=m.szyprowski@samsung.com \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.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
all inboxes | Powered by JetHome®