[PATCH] ASoC: Add a debug log to track DAPM widget power up/down

[PATCH] ASoC: Add a debug log to track DAPM widget power up/down

[bgoswami]

From: Banajit Goswami <bgoswami@codeaurora.org>

Add a debug log to help track widgets being powered-up and powered-down
by DAPM.

Signed-off-by: Banajit Goswami <bgoswami@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 29cdfbf4c888..9bab90410de5 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1665,6 +1665,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);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] ASoC: Add a debug log to track DAPM widget power up/down

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 489 bytes --]

On Fri, May 24, 2019 at 12:54:27AM -0700, bgoswami@codeaurora.org wrote:
> From: Banajit Goswami <bgoswami@codeaurora.org>
> 
> Add a debug log to help track widgets being powered-up and powered-down
> by DAPM.

We already have huge amounts of trace available via tracepoints and
having something on by default in the debug logs seems like it's going
to get very verbose for people who aren't specifically working on audio.
What's the advantage of adding dev_dbg() logs as well?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] ASoC: Add a debug log to track DAPM widget power up/down

[Banajit Goswami]

Thanks Mark for the review!

On 5/24/2019 4:29 AM, Mark Brown wrote:
> On Fri, May 24, 2019 at 12:54:27AM -0700, bgoswami@codeaurora.org wrote:
>> From: Banajit Goswami <bgoswami@codeaurora.org>
>>
>> Add a debug log to help track widgets being powered-up and powered-down
>> by DAPM.
> We already have huge amounts of trace available via tracepoints and
> having something on by default in the debug logs seems like it's going
> to get very verbose for people who aren't specifically working on audio.
> What's the advantage of adding dev_dbg() logs as well?

Having this debug statement helps collecting logs about DAPM widget power

Up/Down sequence, which helps significantly during debugging. The 
advantage of

having the dev_dbg here are-

1. Do not need to enable trace, which helps collecting logs, without 
much know-how

about audio or kernel

2. Dynamic debug (using /sys/kernel/debug/dynamic_debug) can be enabled for

either just this line of code, or, for the function containing this 
debug statement.

This way, logs can be collected just for the DAPM widget enable/disable, 
and thereby

avoid having the output logs filled with unwanted logs.

3. Though I agree with you about the additional DAPM debug logs being 
present for

someone who may not be specifically working on Audio, based on the number of

widgets in the audio path used, the number of prints should be limited 
to only widget

power on/off.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] ASoC: Add a debug log to track DAPM widget power up/down

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

On Mon, May 27, 2019 at 06:15:20PM -0700, Banajit Goswami wrote:

> having the dev_dbg here are-

> 1. Do not need to enable trace, which helps collecting logs, without much
> know-how

> about audio or kernel

That approach results in kernel logs that are really hard to use and
wrap round far too fast - if everything starts spamming the logs it does
nothing for readability.

> 2. Dynamic debug (using /sys/kernel/debug/dynamic_debug) can be enabled for

> either just this line of code, or, for the function containing this debug
> statement.

> This way, logs can be collected just for the DAPM widget enable/disable, and
> thereby

> avoid having the output logs filled with unwanted logs.

That's into needing to learn about the kernel at which point there's no
real advantage of this approach.

> 3. Though I agree with you about the additional DAPM debug logs being
> present for

> someone who may not be specifically working on Audio, based on the number of

> widgets in the audio path used, the number of prints should be limited to
> only widget

> power on/off.

Some devices are *much* bigger than others, and some systems will start
and stop audio much more frequently than others (things like noises for
taps for example) both of which will massively amplify the noise.  Even
when actively working on audio with those systems logging everything
gets old really fast.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]