Repository navigation
Reduce dmesg verbosity - #1980
Conversation
Using a Canon Lake machine with the SOF driver causes dmesg to fill up with a ton of these messages: [ 275.902194] sof-audio-pci 0000:00:1f.3: firmware boot complete [ 351.529358] sof-audio-pci 0000:00:1f.3: firmware boot complete [ 560.049047] sof-audio-pci 0000:00:1f.3: firmware boot complete etc. Since the DSP is powered down when not in used this happens everytime e.g. a notification plays, polluting dmesg. Turn this messages into a debug message, matching what the code already does for the ""booting DSP firmware" message. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
No need to repeat the same info log on all enumerations (essentially each power-up), keep it as debug information. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This reverts commit 1549754. if you need dynamic debug, it's easy enough to add a /etc/modprobe.d/sof-dyndgb.conf with the following content options snd_sof_intel_byt dyndbg=+p options snd_sof_intel_bdw dyndbg=+p options snd_sof_intel_ipc dyndbg=+p options snd_sof_intel_hda_common dyndbg=+p options snd_sof_intel_hda dyndbg=+p options snd_sof dyndbg=+p options snd_sof_pci dyndbg=+p options snd_sof_acpi dyndbg=+p options snd_sof_of dyndbg=+p options snd_sof_nocodec dyndbg=+p options soundwire_bus dyndbg=+p options soundwire_generic_allocation dyndbg=+p options soundwire_cadence dyndbg=+p options soundwire_intel_init dyndbg=+p options soundwire_intel dyndbg=+p <add more files as needed> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
These messages are generated at each enumeration, this is overkill. Move to dev_dbg [ 86.481709] rt1308 sdw:1:25d:1308:0: rt1308_io_init m_btl_l=0xffee, m_btl_r=0xffff [ 86.481714] rt1308 sdw:1:25d:1308:0: rt1308_io_init c_btl_l=0x28c, c_btl_r=0x113 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
lyakh
left a comment
lyakh
left a comment
There was a problem hiding this comment.
In general this is a good PR, I like the changes, but the last commit doesn't seem to belong here?
| u8 val; | ||
|
|
||
| dev_err(slave->bus->dev, | ||
| "programming SDW_SCP_INTMASK1\n"); |
There was a problem hiding this comment.
I'm a bit confused: first this doesn't seem to belong to this PR. And as a side note for this commit: this error message would confuse me, if I saw it in my kernel log. And it's supposed to appear every time SDW is used?
There was a problem hiding this comment.
This is to expose a problem with the other log, that shows whether we program the parity or not. It's not final of course, I just want to root-cause why we see parity errors for no good reason.
paulstelian97
left a comment
paulstelian97
left a comment
There was a problem hiding this comment.
Waiting for the commit that @lyakh complained about to go away (it's for testing right?). Everything else looks good.
kv2019i
left a comment
kv2019i
left a comment
There was a problem hiding this comment.
I guess it's time to let the debugs go. Looks good except for the 3rd patch, please clarify do you want it in sof-dev as well
a15b339 to
d39cbb5
Compare
|
removed last commit and moved it to PR #1984 |
|
SOFCI TEST |
|
One chekcpatch warning for spelling, but that's an upstream patch, so let's ignore that. Device test shows some errors triggered by lack of traces (test case expectes verbose traces to be enabled). Sent a mail to CI folks separately about this. Let's give a bit of time for discussing and then merge. Seems good to go otherwise. |
@xiulipan @wenqingfu please provide a PR for sof-test that shows when the CI/QA devices add dynamic debug on their own instead of assuming the kernel enables it.This will help btw test other kernel branches that don't enable dynamic debug with Makefile changes |
|
@plbossart I think a kmod reload w/o |
RanderWang
left a comment
RanderWang
left a comment
There was a problem hiding this comment.
yes, it works on cml for all components
|
Ok, thanks, all, merging. |
We have too many logs, so start reducing the verbosity.
This work also exposes a problem with SoundWire interrupts. For some reason, even when PARITY interrupts are not enabled, codecs still report them on startup. By default all masks should be disabled on a hardware reset, not sure what's going on here but this adds too many false positives.
@shumingfan @bardliao @RanderWang can you look into this?