Re: [PATCH] snd-hda-intel: don't print using snd_printdd on device open

[Takashi Iwai]

At Sun, 17 Feb 2008 11:31:09 +0100,
Adel Gadllah wrote:
> 
> Hi,
> 
> When CONFIG_SND_DEBUG_DETECT is set the hda-intel driver prints verbose 
> info like this:
> 
> ALSA sound/pci/hda/hda_intel.c:1259: azx_pcm_prepare: bufsize=0x4400,
> fragsize=0x1100, format=0x11
> ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x7,
> stream=0x5, channel=0, format=0x11
> ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x3,
> stream=0x5, channel=0, format=0x11
> ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x3,
> stream=0x0, channel=0, format=0x0
> ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x7,
> stream=0x0, channel=0, format=0x0
> ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x3,
> stream=0x0, channel=0, format=0x0
> 
> Every time when an app opens the sound device.
> This makes it impossible for distribution to enable this config option 
> (to get more debug information for bug reports),

Grr... why distrubionts need to set this option blindly at all?


> because its way too noisy.
> SND_DEBUG_DETECT should only print stuff once when loading the driver.
> 
> There are some options to fix this:
> 
> 1) don't print anything in functions that gets called when the device gets
> opened/prepared for output.
> 
> 2) use snd_printd instead of snd_printdd and make 
> CONFIG_SND_DEBUG_DETECT not depend on CONFIG_SND_DEBUG (this should be 
> done anyway)
> 
> 3) introduce a CONFIG_SND_DEBUG_DETECT_VERBOSE and snd_printddv and use 
> it in this places (this one should be disabled by distributions then)

CONFIG_SND_DEBUG_DETECT is just a verbose debug option and thus
wrongly named.  snd_printdd() there is the exactly intended behavior.

The real fix is to rename CONFIG_SND_DEBUG_DETECT to
CONFIG_SND_DEBUG_VERBOSE or so.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/