[PATCH V1] Add debug print in soc-dapm
Add debug print useful for issue analysis in soc-dapm. This print for dapm widgets useful for debugging to find widgets powering up and down.
Signed-off-by: Laxminath Kasam lkasam@codeaurora.org --- sound/soc/soc-dapm.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index b005f9e..09d35df 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1717,6 +1717,13 @@ static void dapm_seq_run(struct snd_soc_card *card, break; }
+ /* + * Add this debug log to keep track of widgets being + * powered-up and powered-down. + */ + dev_dbg(w->dapm->dev, "dapm: powering %s widget %s\n", + power_up ? "up" : "down", w->name); + if (ret < 0) dev_err(w->dapm->dev, "ASoC: Failed to apply widget power: %d\n", ret);
On Fri, Mar 05, 2021 at 12:24:02PM +0530, Laxminath Kasam wrote:
Add debug print useful for issue analysis in soc-dapm. This print for dapm widgets useful for debugging to find widgets powering up and down.
There's already fairly extensive tracepoints for DAPM - this seems to correspond to snd_soc_dapm_widget_power, though it's at the application time rather than the queue time so we could add another tracepoint for this if you like? I can see that the separate tracepoint would be useful, I mostly use the regmap tracepoints for that purpose but not every widget has register I/O. Tracepoints are less noisy for the system as a whole than tracing every DAPM operation in dmesg, that tends to irritate other users if it's left in as standard.
On 2021-03-05 15:29, Mark Brown wrote:
On Fri, Mar 05, 2021 at 12:24:02PM +0530, Laxminath Kasam wrote:
Add debug print useful for issue analysis in soc-dapm. This print for dapm widgets useful for debugging to find widgets powering up and down.
There's already fairly extensive tracepoints for DAPM - this seems to correspond to snd_soc_dapm_widget_power, though it's at the application time rather than the queue time so we could add another tracepoint for this if you like? I can see that the separate tracepoint would be useful, I mostly use the regmap tracepoints for that purpose but not every widget has register I/O. Tracepoints are less noisy for the system as a whole than tracing every DAPM operation in dmesg, that tends to irritate other users if it's left in as standard.
Thanks Mark for the response. But this is not default err/info print and only dynamic debug print which should not result in noise. In case of customer OEMs/final product versions where less options of debugging, dynamic dmesg logging is preferable provided faster and this print is used to identify issues debug fastly sometimes.
-- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
On Fri, Mar 05, 2021 at 08:07:19PM +0530, b_lkasam@codeaurora.org wrote:
On 2021-03-05 15:29, Mark Brown wrote:
this if you like? I can see that the separate tracepoint would be useful, I mostly use the regmap tracepoints for that purpose but not every widget has register I/O. Tracepoints are less noisy for the system as a whole than tracing every DAPM operation in dmesg, that tends to irritate other users if it's left in as standard.
Thanks Mark for the response. But this is not default err/info print and only dynamic debug print which should not result in noise. In case of customer OEMs/final product versions where less options of debugging, dynamic dmesg logging is preferable provided faster and this print is used to identify issues debug fastly sometimes.
This is precisely the use case tracepoints were added for and I know that they are being succesfully used in the development of major mobile handsets. They are very low overhead, you can even leave them recording in production usage without getting in anyone's way, and they're also simple to flip on and off at runtime.
participants (3)
-
b_lkasam＠codeaurora.org -
Laxminath Kasam -
Mark Brown