Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752491AbbFNRRM (ORCPT ); Sun, 14 Jun 2015 13:17:12 -0400 Received: from hofr.at ([212.69.189.236]:46859 "EHLO mail.hofr.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861AbbFNRRC (ORCPT ); Sun, 14 Jun 2015 13:17:02 -0400 Date: Sun, 14 Jun 2015 19:16:59 +0200 From: Nicholas Mc Guire To: Takashi Iwai Cc: Nicholas Mc Guire , Jaroslav Kysela , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mips/ad1843: convert time to jiffies HZ independent Message-ID: <20150614171659.GA15401@opentech.at> References: <1434270059-20472-1-git-send-email-hofrat@osadl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3439 Lines: 91 On Sun, 14 Jun 2015, Takashi Iwai wrote: > At Sun, 14 Jun 2015 10:20:59 +0200, > Nicholas Mc Guire wrote: > > > > PI compliance scanning with coccinelle flagged: > > ./sound/mips/ad1843.c:503:2-32: WARNING: > > timeout (5) seems HZ dependent > > > > This was introduced in 'commit 862c2c0a61c5 ("ALSA: ALSA driver for SGI O2 > > audio board")'. schedule_timeout_interruptible() expects a timeout in > > jiffies so the numeric constant makes the effective timeout HZ dependent. > > Simply put it through msecs_to_jiffies() to make it HZ independent. > > > > Signed-off-by: Nicholas Mc Guire > > --- > > > > The loop here is bounded by 500 jiffies and it does not seem reasonable that > > it would loop 10 times faster on HZ=1000 configs over HZ=100 configs. The > > conversion via msecs_to_jiffies(5) ensures that it will loop at most 100 > > times for all configs of HZ which seems reasonable (to me) but needs to be > > checked by someone that knows the details of this driver. > > Using 5ms looks reasonable for this case. However, > schedule_timeout_interruptible() isn't. This is a loop that won't > break. So, the best would be to replace it with msleep() or its > friends. > > > Note that the CONFIG_SND_PCM_OSS dependency was not listed in the > > Depends on: in Kconfig (which it probably should) > > Why at all? It has nothing to do with OSS. > the procedure to see the problem I used was (linux-next 20150612) make ip32_defconfig ARCH=mips make menuconfig ARCH=mips Device Drivers ... Sound card support ---> Advanced Linux Sound Architecture ---> [*] MIPS sound devices ---> SGI O2 Audio compiling fails with: MODPOST 95 modules ERROR: "snd_pcm_period_elapsed" [sound/mips/snd-sgi-o2.ko] undefined! ERROR: "snd_pcm_set_ops" [sound/mips/snd-sgi-o2.ko] undefined! ERROR: "snd_pcm_lib_get_vmalloc_page" [sound/mips/snd-sgi-o2.ko] undefined! ERROR: "snd_pcm_lib_ioctl" [sound/mips/snd-sgi-o2.ko] undefined! ERROR: "_snd_pcm_lib_alloc_vmalloc_buffer" [sound/mips/snd-sgi-o2.ko] undefined! ERROR: "snd_pcm_new" [sound/mips/snd-sgi-o2.ko] undefined! ERROR: "snd_pcm_lib_free_vmalloc_buffer" [sound/mips/snd-sgi-o2.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 as the pcm_lib functions depend on SND_PCM I added that - So if I add the below patch the problem goes away and the module build correclty - not saying that this is the right fix though (did not look into it in more detail yet) >From d9cb7d166613e6129f021a913f66f377f5ac56c0 Mon Sep 17 00:00:00 2001 From: Nicholas Mc Guire Date: Sun, 14 Jun 2015 19:06:19 +0200 Subject: [PATCH] ALSA: let SND_SGI_O2 select SND_PCM Signed-off-by: Nicholas Mc Guire --- sound/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/mips/Kconfig b/sound/mips/Kconfig index d2f615a..7875af0 100644 --- a/sound/mips/Kconfig +++ b/sound/mips/Kconfig @@ -12,6 +12,7 @@ if SND_MIPS config SND_SGI_O2 tristate "SGI O2 Audio" depends on SGI_IP32 + select SND_PCM help Sound support for the SGI O2 Workstation. -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/