From: Vinod Koul Date: Mon, 20 Oct 2014 15:24:33 +0000 (+0530) Subject: ASoC: intel: explain why block not found isn't error always X-Git-Tag: v3.19-rc1~119^2~20^2~16^3~49 X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=commitdiff_plain;h=33c1256f1ce30a94f4b590bb30baf787e17f64aa;p=linux.git ASoC: intel: explain why block not found isn't error always The IPC blocking can be error when we don't find block or a short message, explain that by adding a comment about this scenario Signed-off-by: Vinod Koul Signed-off-by: Mark Brown --- diff --git a/sound/soc/intel/sst/sst_ipc.c b/sound/soc/intel/sst/sst_ipc.c index 41a2b41b232b..2126f5bb2813 100644 --- a/sound/soc/intel/sst/sst_ipc.c +++ b/sound/soc/intel/sst/sst_ipc.c @@ -54,6 +54,21 @@ struct sst_block *sst_create_block(struct intel_sst_drv *ctx, return msg; } +/* + * while handling the interrupts, we need to check for message status and + * then if we are blocking for a message + * + * here we are unblocking the blocked ones, this is based on id we have + * passed and search that for block threads. + * We will not find block in two cases + * a) when its small message and block in not there, so silently ignore + * them + * b) when we are actually not able to find the block (bug perhaps) + * + * Since we have bit of small messages we can spam kernel log with err + * print on above so need to keep as debug prints which should be enabled + * via dynamic debug while debugging IPC issues + */ int sst_wake_up_block(struct intel_sst_drv *ctx, int result, u32 drv_id, u32 ipc, void *data, u32 size) {