[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5f1791b4-78d8-9895-e639-238411b60f00@linaro.org>
Date: Mon, 11 Sep 2023 18:05:35 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>,
Mateusz Majewski <m.majewski2@...sung.com>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Amit Kucheria <amitk@...nel.org>,
Zhang Rui <rui.zhang@...el.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH 04/11] thermal: exynos: remove fine-grained clk management
On 01/09/2023 10:40, Marek Szyprowski wrote:
> On 29.08.2023 11:56, Krzysztof Kozlowski wrote:
>> On 29/08/2023 11:18, Mateusz Majewski wrote:
>>> This clock only controls the register operations. The gain in power
>>> efficiency is therefore quite dubious, while there is price of added
>>> complexity that is important to get right (as a register operation might
>>> outright hang the CPU if the clock is not enabled).
>> So once it is done right, this stops being argument. The benefit is to
>> keep this clock disabled most of the time, which now we lost.
>>
>> I don't find this patch correct approach.
>
> I've suggested this change while playing with this driver.
>
> For me turning AHB clock on/off during normal driver operation seems to
> be over-engineering and really gives no real power saving benefits,
> especially if thermal driver is the only one that does such fine-grained
> clock management (none of the Exynos supported in mainline does that).
> Removing it simplifies code and makes it easier to understand or read,
> as the current code already was somehow problematic to understand and
> unintuitive:
>
> https://lore.kernel.org/all/c3258cb2-9a56-d048-5738-1132331a157d@linaro.org/
>
> Taking into account that the driver is not really maintained, making it
> simpler without noticeable feature loss counts as a benefit for me.
Hm, ok, let it be, although I bet once someone will come and start
adding runtime PM for clock handling...
Best regards,
Krzysztof
Powered by blists - more mailing lists