[Sound-open-firmware] Introduce a module parameter to configure SOF driver debug output?

Liam Girdwood liam.r.girdwood at intel.com
Mon Apr 30 17:55:39 CEST 2018


On Fri, 2018-04-27 at 08:33 -0500, Pierre-Louis Bossart wrote:
> > MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
> > category.\n"
> > "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
> > "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
> > "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
> > "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
> > "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
> > "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
> > "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)");
> 
> not a bad idea for developers. when folks debug topology or IPC stuff, 
> they don't necessarily care about PCM or page tables, so it's a good way 
> to filter. we could have one bit per module (core, pcm, ipc, topology, 
> acpi, pci, etc).
> 
> I don't see how this improves CI work though?

btw, there already is a snd_debug() or snd_printk() iirc that was meant to do
something like this ? Can you check this and if it's similar it's probably worth
asking on alsa-devel so we dont duplicate.

Liam
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


More information about the Sound-open-firmware mailing list