[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7hy0ysi4pf.fsf@baylibre.com>
Date: Thu, 30 Jan 2025 09:36:44 -0800
From: Kevin Hilman <khilman@...nel.org>
To: Keita Morisaki <keyz@...gle.com>, rostedt@...dmis.org,
mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
lpieralisi@...nel.org, sudeep.holla@....com, rafael@...nel.org,
daniel.lezcano@...aro.org, linux-pm@...r.kernel.org
Cc: aarontian@...gle.com, yimingtseng@...gle.com, Keita Morisaki
<keyz@...gle.com>
Subject: Re: [PATCH v3] cpuidle: psci: Add trace for PSCI domain idle
Keita Morisaki <keyz@...gle.com> writes:
> The trace event cpu_idle provides insufficient information for debugging
> PSCI requests due to lacking access to determined PSCI domain idle
> states. The cpu_idle usually only shows -1, 0, or 1 regardless how many
> idle states the power domain has.
>
> Add new trace events namely psci_domain_idle_enter and
> psci_domain_idle_exit to trace enter and exit events with a determined
> idle state.
>
> These new trace events will help developers debug CPUidle issues on ARM
> systems using PSCI by providing more detailed information about the
> requested idle states.
>
> Signed-off-by: Keita Morisaki <keyz@...gle.com>
> Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>
Tested-by: Kevin Hilman <khilman@...libre.com>
I've been using some local trace_printk() to do exactly this, so I fully
support having some official tracepoints here.
For my local hacks, I was trackin the state index as well as the state
value since for quick debug, I find the index to more human readable
than the state value, which I have to compare with the
arm,psci-suspend-pararm from the DT.
Anyways, thanks for submitting this!
Kevin
Powered by blists - more mailing lists