Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752440AbYAML0X (ORCPT ); Sun, 13 Jan 2008 06:26:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751323AbYAML0O (ORCPT ); Sun, 13 Jan 2008 06:26:14 -0500 Received: from mx1.suse.de ([195.135.220.2]:41151 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751307AbYAML0N (ORCPT ); Sun, 13 Jan 2008 06:26:13 -0500 Date: Sun, 13 Jan 2008 12:26:12 +0100 Message-ID: From: Takashi Iwai To: Harald Dunkel Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep In-Reply-To: <47888B41.70803@t-online.de> References: <4782833D.3010600@t-online.de> <4783AC7C.50900@t-online.de> <478463A6.2070106@t-online.de> <47852A41.9020903@t-online.de> <4786960D.2040500@t-online.de> <47888B41.70803@t-online.de> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2090 Lines: 60 At Sat, 12 Jan 2008 10:41:21 +0100, Harald Dunkel wrote: > > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >>> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > > > There is no udelay() in the reverted patch. Hm? Ingo's patch replaces msleep(1) with udelay(10) + cond_resched(). This is the patch we're arguing. This was already reverted (based on your report) on git. > If I replace "udelay(10)" > by "udelay(500)" in the original rc7, then there is still no sound. Interesting... What about udelay(1000)? Then it'll be closer to msleep(1). > This is like fishing in the dark. We've got a working version. Why not > keep it? Yes, we are shooting in the dark now indeed. Honestly, I have no concrete idea why the patch breaks the sound initialization. It seems that Dell machines (or STAC codecs) have problems with the initialization timing. I don't think that all commands but only certain some command sequences that are so sensitive to the access timing. We need to identify this. Ingo's patch is basically a really nice fix. It reduces the unnecessary delay, especially improves resume speed much. I'd love to have it. And above all, I need to understand what is the real problem. Unfortunately, I have no this hardware and the precise h/w data, so must rely on testers and a guess work. thanks, Takashi -- 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/