diff mbox

[v2,3/3] ASoC: Intel: Skylake: Increase loglevel of debug messages.

Message ID 1461711790-7277-4-git-send-email-vedang.patel@intel.com (mailing list archive)
State Accepted
Commit 91c1832579700891747820862633f9a8d0d81fa4
Headers show

Commit Message

Vedang Patel April 26, 2016, 11:03 p.m. UTC 
From: Vedang Patel <vedang.patel@intel.com>

There is log spam while doing playback, record or reloading the
audio firmware.

print_hex_dump uses printk(KERN_DEBUG,... which is different from
dev_dbg used elsewhere in the driver: it's always enabled at
compile-time. Change it to print_hex_dump_debug for logging consistency.

For consistency with other log statements, change dev_info to dev_dbg
for a kernel print which is frequently printed by the driver.

Change-Id: Ib3f29a02e79eabbd7a4452279841514277a471c4
Signed-off-by: Vedang Patel <vedang.patel@intel.com>
---
 sound/soc/intel/skylake/skl-messages.c | 2 +-
 sound/soc/intel/skylake/skl-sst-ipc.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Comments

Vedang Patel June 1, 2016, 1:14 a.m. UTC | #1 
From: Vedang Patel <vedang.patel@intel.com>

There have been complaints regarding audio related kernel messages flooding
dmesg. This series tries to address those complaints.

Also, I have created 3 different patches for this because they touch different
drivers. But, I can combine those to reduce the number of patches.

v2 Changes:
- Use print_hex_dump_debug instead of #ifdef DEBUG

v3 Changes:
- Remove Change-Id from all the patches.

Vedang Patel (3):
  ASoC: hdac_hdmi: Increase loglevel of hex dump printed
  ASoC: Intel: common: increase the loglevel of "FW Poll Status".
  ASoC: Intel: Skylake: Increase loglevel of debug messages.

 sound/soc/codecs/hdac_hdmi.c           |    6 ++++--
 sound/soc/intel/common/sst-dsp.c       |    2 +-
 sound/soc/intel/skylake/skl-messages.c |    2 +-
 sound/soc/intel/skylake/skl-sst-ipc.c  |    4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)
Vinod Koul June 1, 2016, 5:56 a.m. UTC | #2 
On Tue, May 31, 2016 at 06:14:58PM -0700, vedang.patel@intel.com wrote:
> From: Vedang Patel <vedang.patel@intel.com>
> 
> There have been complaints regarding audio related kernel messages flooding
> dmesg. This series tries to address those complaints.
> 
> Also, I have created 3 different patches for this because they touch different
> drivers. But, I can combine those to reduce the number of patches.
Split sound fine to me

Acked-by: Vinod Koul <vinod.koul@intel.com>
Vedang Patel June 25, 2016, 12:37 a.m. UTC | #3 
From: Vedang Patel <vedang.patel@intel.com>

There have been complaints regarding audio related kernel messages flooding
dmesg. This series tries to address those complaints.

Also, I have created 3 different patches for this because they touch different
drivers. But, I can combine those to reduce the number of patches.

v2 Changes:
- Use print_hex_dump_debug instead of #ifdef DEBUG

v3 Changes:
- Remove Change-Id from all the patches.

Vedang Patel (3):
  ASoC: hdac_hdmi: Increase loglevel of hex dump printed
  ASoC: Intel: common: increase the loglevel of "FW Poll Status".
  ASoC: Intel: Skylake: Increase loglevel of debug messages.

 sound/soc/codecs/hdac_hdmi.c           |    6 ++++--
 sound/soc/intel/common/sst-dsp.c       |    2 +-
 sound/soc/intel/skylake/skl-messages.c |    2 +-
 sound/soc/intel/skylake/skl-sst-ipc.c  |    4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)
Mark Brown June 27, 2016, 2:50 p.m. UTC | #4 
On Fri, Jun 24, 2016 at 05:37:08PM -0700, vedang.patel@intel.com wrote:
> From: Vedang Patel <vedang.patel@intel.com>
> 
> There have been complaints regarding audio related kernel messages flooding
> dmesg. This series tries to address those complaints.

Please don't include noise like REPOST in the subject line, especially
not at the start of the subject line where it makes it look less like a
patch e-mail and so harder to spot in an inbox.  I also note that this
appears to be the first time you've sent me these patches...
Vedang Patel June 29, 2016, 11:39 p.m. UTC | #5 
Thanks Mark for merging the patches. I apologize for any unwanted noise
in your inbox.

I did post the patches a few weeks back (http://www.spinics.net/lists/a
lsa-devel/msg50782.html). The only difference this time was I cc'ed you
in the patches. Moving forward, what is the preferred method for
submitting patches for the first time or reposting them so that you are
less likely to miss them?

Thanks,
Vedang

On Mon, 2016-06-27 at 15:50 +0100, Mark Brown wrote:
> On Fri, Jun 24, 2016 at 05:37:08PM -0700, vedang.patel@intel.com

> wrote:

> > 

> > From: Vedang Patel <vedang.patel@intel.com>

> > 

> > There have been complaints regarding audio related kernel messages

> > flooding

> > dmesg. This series tries to address those complaints.

> Please don't include noise like REPOST in the subject line,

> especially

> not at the start of the subject line where it makes it look less like

> a

> patch e-mail and so harder to spot in an inbox.  I also note that

> this

> appears to be the first time you've sent me these patches...
Vinod Koul June 30, 2016, 2:27 a.m. UTC | #6 
On Thu, Jun 30, 2016 at 05:09:09AM +0530, Patel, Vedang wrote:
> Thanks Mark for merging the patches. I apologize for any unwanted noise
> in your inbox.

Please never *top post*

> 
> I did post the patches a few weeks back (http://www.spinics.net/lists/a
> lsa-devel/msg50782.html). The only difference this time was I cc'ed you
> in the patches. Moving forward, what is the preferred method for
> submitting patches for the first time or reposting them so that you are
> less likely to miss them?

Ah not CCing maintainers is not correct. That is why checkpatch gives you
names to cc.

Your patch got ignored for this reason then!

> 
> Thanks,
> Vedang
> 
> On Mon, 2016-06-27 at 15:50 +0100, Mark Brown wrote:
> > On Fri, Jun 24, 2016 at 05:37:08PM -0700, vedang.patel@intel.com
> > wrote:
> > > 
> > > From: Vedang Patel <vedang.patel@intel.com>
> > > 
> > > There have been complaints regarding audio related kernel messages
> > > flooding
> > > dmesg. This series tries to address those complaints.
> > Please don't include noise like REPOST in the subject line,
> > especially
> > not at the start of the subject line where it makes it look less like
> > a
> > patch e-mail and so harder to spot in an inbox.  I also note that
> > this
> > appears to be the first time you've sent me these patches...
Mark Brown July 1, 2016, 7:50 a.m. UTC | #7 
On Thu, Jun 30, 2016 at 07:57:47AM +0530, Vinod Koul wrote:
> On Thu, Jun 30, 2016 at 05:09:09AM +0530, Patel, Vedang wrote:

> > I did post the patches a few weeks back (http://www.spinics.net/lists/a
> > lsa-devel/msg50782.html). The only difference this time was I cc'ed you
> > in the patches. Moving forward, what is the preferred method for
> > submitting patches for the first time or reposting them so that you are
> > less likely to miss them?

> Ah not CCing maintainers is not correct. That is why checkpatch gives you
> names to cc.

> Your patch got ignored for this reason then!

The process for submitting patches is covered in
Documentation/SubmittingPatches
diff mbox

Patch

diff --git a/sound/soc/intel/skylake/skl-messages.c b/sound/soc/intel/skylake/skl-messages.c
index e3d149c..b208f56 100644
--- a/sound/soc/intel/skylake/skl-messages.c
+++ b/sound/soc/intel/skylake/skl-messages.c
@@ -730,7 +730,7 @@  static int skl_set_module_format(struct skl_sst *ctx,
 
 	dev_dbg(ctx->dev, "Module type=%d config size: %d bytes\n",
 			module_config->id.module_id, param_size);
-	print_hex_dump(KERN_DEBUG, "Module params:", DUMP_PREFIX_OFFSET, 8, 4,
+	print_hex_dump_debug("Module params:", DUMP_PREFIX_OFFSET, 8, 4,
 			*param_data, param_size, false);
 	return 0;
 }
diff --git a/sound/soc/intel/skylake/skl-sst-ipc.c b/sound/soc/intel/skylake/skl-sst-ipc.c
index 5434602..c141f24 100644
--- a/sound/soc/intel/skylake/skl-sst-ipc.c
+++ b/sound/soc/intel/skylake/skl-sst-ipc.c
@@ -363,7 +363,7 @@  static void skl_ipc_process_reply(struct sst_generic_ipc *ipc,
 	/* first process the header */
 	switch (reply) {
 	case IPC_GLB_REPLY_SUCCESS:
-		dev_info(ipc->dev, "ipc FW reply %x: success\n", header.primary);
+		dev_dbg(ipc->dev, "ipc FW reply %x: success\n", header.primary);
 		/* copy the rx data from the mailbox */
 		sst_dsp_inbox_read(ipc->dsp, msg->rx_data, msg->rx_size);
 		break;
@@ -692,7 +692,7 @@  int skl_ipc_init_instance(struct sst_generic_ipc *ipc,
 	 /* param_block_size must be in dwords */
 	u16 param_block_size = msg->param_data_size / sizeof(u32);
 
-	print_hex_dump(KERN_DEBUG, NULL, DUMP_PREFIX_NONE,
+	print_hex_dump_debug(NULL, DUMP_PREFIX_NONE,
 		16, 4, buffer, param_block_size, false);
 
 	header.primary = IPC_MSG_TARGET(IPC_MOD_MSG);