From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux PM <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [PATCH v2 2/8] thermal/debugfs: Do not extend mitigation episodes beyond system resume
Date: Mon, 10 Jun 2024 15:39:26 +0200 [thread overview]
Message-ID: <1ca6f4db-a7cc-4f47-b626-51daf7175885@linaro.org> (raw)
In-Reply-To: <CAJZ5v0jku1tptD3O=x-rptgUWGQFOQT-U3rsxk9k4XXsyeq3Kw@mail.gmail.com>
On 10/06/2024 13:29, Rafael J. Wysocki wrote:
> On Mon, Jun 10, 2024 at 10:28 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>
>> On 28/05/2024 16:53, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>
>>> Because thermal zone handling by the thermal core is started from
>>> scratch during resume from system-wide suspend, prevent the debug
>>> code from extending mitigation episodes beyond that point by ending
>>> the mitigation episode currently in progress, if any, for each thermal
>>> zone.
>>
>> Why it is done at resume time and not at suspend time ?
>
> Because it is related to thermal_zone_device_init() which also runs at
> the resume time, so IMV it's better to keep these two pieces together.
>
> Why would it be better to run this during suspend?
From a logical point of view, it makes more sense to cancel something
at suspend time rather than resume. That prevents future readers to be
puzzled by an action done in an unexpected place.
Technically speaking there is no difference if it is done during suspend
or resume. Well... we want to prevent actions to be done at resume time
in order to not increase the resume duration but I'm not sure this code
is doing a big difference.
If you want to keep it as is, feel free to add my:
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2024-06-10 13:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 14:51 [PATCH v2 0/8] thermal/debugfs: Assorted improvements for the 6.11 cycle Rafael J. Wysocki
2024-05-28 14:52 ` [PATCH v2 1/8] thermal/debugfs: Use helper to update trip point overstepping duration Rafael J. Wysocki
2024-06-10 7:52 ` Daniel Lezcano
2024-05-28 14:53 ` [PATCH v2 2/8] thermal/debugfs: Do not extend mitigation episodes beyond system resume Rafael J. Wysocki
2024-06-10 8:28 ` Daniel Lezcano
2024-06-10 11:29 ` Rafael J. Wysocki
2024-06-10 13:39 ` Daniel Lezcano [this message]
2024-06-11 18:35 ` Rafael J. Wysocki
2024-05-28 14:55 ` [PATCH v2 3/8] thermal/debugfs: Print mitigation timestamp value in milliseconds Rafael J. Wysocki
2024-06-10 8:29 ` Daniel Lezcano
2024-05-28 14:55 ` [PATCH v2 4/8] thermal/debugfs: Fix up units in "mitigations" files Rafael J. Wysocki
2024-06-10 8:30 ` Daniel Lezcano
2024-05-28 14:57 ` [PATCH v2 5/8] thermal/debugfs: Adjust check for trips without statistics in tze_seq_show() Rafael J. Wysocki
2024-06-10 8:59 ` Daniel Lezcano
2024-05-28 14:58 ` [PATCH v2 6/8] thermal/debugfs: Compute maximum temperature for mitigation episode as a whole Rafael J. Wysocki
2024-06-10 10:33 ` Daniel Lezcano
2024-05-28 14:59 ` [PATCH v2 7/8] thermal/debugfs: Move some statements from under thermal_dbg->lock Rafael J. Wysocki
2024-06-10 13:27 ` Daniel Lezcano
2024-05-28 15:00 ` [PATCH v2 8/8] thermal: trip: Use common set of trip type names Rafael J. Wysocki
2024-06-10 13:28 ` Daniel Lezcano
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=1ca6f4db-a7cc-4f47-b626-51daf7175885@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
/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).