ASoC: wm_adsp: Dump DSP_SCRATCH1 on DSP shutdown
Subsystems (3)
PATCH 1/1 ASoC: wm_adsp: Dump DSP_SCRATCH1 on DSP shutdown
The DSP_SCRATCH1 register is used by firmwares to hold diagnostic information. Include this in the shutdown message - it can be useful for debugging.
--- sound/soc/codecs/wm_adsp.c | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-)
sound/soc/codecs/wm_adsp.c +13 -1
@@ -121,6 +121,11 @@#define ADSP2_WDMA_CONFIG_2 0x31#define ADSP2_RDMA_CONFIG_1 0x34 +#define ADSP2_SCRATCH0 0x40 +#define ADSP2_SCRATCH1 0x41 +#define ADSP2_SCRATCH2 0x42 +#define ADSP2_SCRATCH3 0x43 +/* * ADSP2 Control */
@@ -1880,6 +1885,7 @@ int wm_adsp2_event(struct snd_soc_dapm_widget *w,struct wm_adsp *dsp = &dsps[w->shift];struct wm_adsp_alg_region *alg_region;struct wm_coeff_ctl *ctl; +unsigned int scratch1 =0xFFFFFFFF ;int ret;switch (event) {
@@ -1898,6 +1904,12 @@ int wm_adsp2_event(struct snd_soc_dapm_widget *w,break ;case SND_SOC_DAPM_PRE_PMD : +/* Capture DSP_SCRATCH1, it can be useful for analysis */ + ret =regmap_read (dsp->regmap, dsp->base +ADSP2_SCRATCH1 , + &scratch1); +if (ret) +adsp_err (dsp,"Failed to read SCRATCH1 %d\n" , ret); + dsp->running = false; regmap_update_bits(dsp->regmap, dsp->base + ADSP2_CONTROL,
@@ -1935,7 +1947,7 @@ int wm_adsp2_event(struct snd_soc_dapm_widget *w,kfree (alg_region); } -adsp_dbg (dsp,"Shutdown complete\n" ); +adsp_info (dsp,"Shutdown complete (SCRATCH1:0x%x)\n" , scratch1);break ;default :
Signature · 1 line
1.7.2.5
Mark Brown
maintainersound/soc/codecs/wm_adsp.c line 127
Quoted 4 lines · Richard Fitzgerald
sound/soc/codecs/wm_adsp.c +4
-0+#define ADSP2_SCRATCH0 0x40 +#define ADSP2_SCRATCH1 0x41 +#define ADSP2_SCRATCH2 0x42 +#define ADSP2_SCRATCH3 0x43
May as well dump the other scratches while you're at it?
sound/soc/codecs/wm_adsp.c int wm_adsp2_event(struct snd_soc_dapm_widget *w, · line 1888
Quoted 1 line
sound/soc/codecs/wm_adsp.c +1
-0+unsigned int scratch1 =0xFFFFFFFF ;
Why is this being initialized?
sound/soc/codecs/wm_adsp.c int wm_adsp2_event(struct snd_soc_dapm_widget *w, · line 1950
Quoted 2 lines
sound/soc/codecs/wm_adsp.c +1
-1-adsp_dbg (dsp,"Shutdown complete\n" ); +adsp_info (dsp,"Shutdown complete (SCRATCH1:0x%x)\n" , scratch1);
That seems a bit loud for a diagnostic message, why raise the severity?
Quoted 9 lines · Mark Brown
sound/soc/codecs/wm_adsp.c line 127
Quoted 4 lines · Richard Fitzgerald
sound/soc/codecs/wm_adsp.c +4
-0+#define ADSP2_SCRATCH0 0x40 +#define ADSP2_SCRATCH1 0x41 +#define ADSP2_SCRATCH2 0x42 +#define ADSP2_SCRATCH3 0x43May as well dump the other scratches while you're at it?
Fair enough
Quoted 4 lines
sound/soc/codecs/wm_adsp.c int wm_adsp2_event(struct snd_soc_dapm_widget *w, · line 1888
Quoted 1 line
sound/soc/codecs/wm_adsp.c +1
-0+unsigned int scratch1 =0xFFFFFFFF ;Why is this being initialized?
It was done a way to avoid having two shutdown messages to cover the rare case that we somehow failed to read the register value, since the firmware could never write this value (it as 31 bits set).
Quoted 4 lines
sound/soc/codecs/wm_adsp.c int wm_adsp2_event(struct snd_soc_dapm_widget *w, · line 1950
Quoted 2 lines
sound/soc/codecs/wm_adsp.c +1
-1-adsp_dbg (dsp,"Shutdown complete\n" ); +adsp_info (dsp,"Shutdown complete (SCRATCH1:0x%x)\n" , scratch1);That seems a bit loud for a diagnostic message, why raise the severity?
It's a diagnostic of the firmware, not the driver, and we can't assume that people trying to use a firmware have the ability to build and flash a kernel with a debug version of the driver
Mark Brown
maintainerQuoted 10 lines · Richard Fitzgerald
Quoted 4 lines · Mark Brown
sound/soc/codecs/wm_adsp.c int wm_adsp2_event(struct snd_soc_dapm_widget *w, · line 1950
Quoted 2 lines
sound/soc/codecs/wm_adsp.c +1
-1-adsp_dbg (dsp,"Shutdown complete\n" ); +adsp_info (dsp,"Shutdown complete (SCRATCH1:0x%x)\n" , scratch1);That seems a bit loud for a diagnostic message, why raise the severity?
It's a diagnostic of the firmware, not the driver, and we can't assume that people trying to use a firmware have the ability to build and flash a kernel with a debug version of the driver
The default is that dev_dbg() is available in dmesg but not on the console which usually seems like a reasonable balance for this sort of thing - it's there if people want it but not included in the default logging.
Quoted 8 lines · Mark Brown
Quoted 6 lines · Richard Fitzgerald
Quoted 4 lines · Mark Brown
sound/soc/codecs/wm_adsp.c int wm_adsp2_event(struct snd_soc_dapm_widget *w, · line 1950
Quoted 2 lines
sound/soc/codecs/wm_adsp.c +1
-1-adsp_dbg (dsp,"Shutdown complete\n" ); +adsp_info (dsp,"Shutdown complete (SCRATCH1:0x%x)\n" , scratch1);That seems a bit loud for a diagnostic message, why raise the severity?
Quoted 8 lines
Quoted 3 lines
It's a diagnostic of the firmware, not the driver, and we can't assume that people trying to use a firmware have the ability to build and flash a kernel with a debug version of the driver
The default is that
dev_dbg()is available in dmesg but not on the console which usually seems like a reasonable balance for this sort of thing - it's there if people want it but not included in the default logging.
What you're describing seems to be the default for dev_info(). For me I don't get any dev_dbg() output in the dmesg log unless the source file has a #define DEBUG at the top.
Mark Brown
maintainerQuoted 10 lines · Richard Fitzgerald
Quoted 4 lines · Mark Brown
The default is that
dev_dbg()is available in dmesg but not on the console which usually seems like a reasonable balance for this sort of thing - it's there if people want it but not included in the default logging.What you're describing seems to be the default for
dev_info(). For me I don't get anydev_dbg()output in the dmesg log unless the source file has a #define DEBUG at the top.
Interesting... the dev_dbg default appears to have been changed at some point, possibly with the addition of dynamic debug (which I tend to have on in my configurations and is common for distros and so on). The info default is overridden by a lot of distros. In any case, it's still the way we generally do debug - doing this on every DSP stop does seem quite chatty from a system point of view (and yes, some of the existing logging in the driver does seem a bit enthusiastic here too in retrospect, IIRC at the time request_firmware() was chatty too but that has been fixed).
Users will typically have the option to get this via ftrace as well (we have trace points for register read), and you might also want to consider the option of exporting the value via a sysfs file so people can grab the latest value whenever they like.