From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: LSI HDA Modem is not working on HP new Laptop which has IDT 7605 HDA codec and REDHAT installed on it with ALSA ver 1.0.24. Date: Thu, 29 Sep 2011 09:57:47 +0200 Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 68D8E103843 for ; Thu, 29 Sep 2011 09:57:50 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: "Gupta, Suresh" Cc: "alsa-devel@alsa-project.org" List-Id: alsa-devel@alsa-project.org At Thu, 29 Sep 2011 09:34:17 +0200, Takashi Iwai wrote: > > At Thu, 29 Sep 2011 12:42:41 +0530, > Gupta, Suresh wrote: > > > > LSI Modem always checks the "opened" bit of "azx_dev" before opening the stream. Modem sets "opened" bit and > > use stream if and only if that "opened" bit was not set otherwise move to next stream "azx_dev". > > > > I found that the ALSA unset this "opened" bit on close but do not reset AC_VERB_SET_CHANNEL_STREAMID of IDC codec. > > Due to which IDC Codec always get active and always sending data to stream 0. Now when LSI modem check the "opened" > > bit of stream 0, it found it is not set and open the stream 0 and start reading data from stream 0. As IDC codec > > still sending data on stream 0 the LSI Modem get this unexpected data and stop working. > > > > I believe the Code (below) which checks "no_sticky_stream" is the culprit due to which "really_cleanup_stream" > > function is not called. I found the Analog devices codec set "no_sticky_stream" while probing their codec. > > This is the reason, our modem works on HP laptop with Analog device codec. > > > > According to me the IDC codec should stop sending data after closing the stream or otherwise they should always acquire the stream which is not right. > > > > I don't know why "no_sticky_stream" come into new code and what's it significance. Why only Analog devices use this "no_sticky_stream". > > The problem is that your driver steals the stream silently. > The stream is still assigned to the IDT codec driver even after the > PCM is closed. It's just not used. When the PCM is opened, the very > same stream is used again without reassigning the stream tag. > > Now the modem driver grabs the stream and use the stream tag. Of > course, the data will be fed. > > The stream must be allocated via azx_assign_device(). If you don't, > it's not guaranteed what happens. Looking back at the code, I think my previous analysis was incorrect. The problem is likely that your driver doesn't set up the stream via snd_hda_codec_setup_stream() or snd_hda_codec_prepare() isn't called properly by any reason. The logic is: - the inactive old streams conflicting with the newly prepared stream are marked as dirty in snd_hda_codec_setup_stream(); this is supposed to be called from the codec driver's prepare callback, - then the codecs with dirty streams are cleaned up in purity_inactive_streams() called from snd_hda_codec_prepare(). Takashi