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.

[Takashi Iwai <tiwai@suse.de>]

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