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.

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.

[Gupta, Suresh]

Modem receive unwanted data on stream 0 even stream is not open by any device.
Stream 0 was acquired by IDC 7605 and this codec keep sending something even after closing the stream.

On further investigation I found ALSA ver 1.0.24 have new fix "Make converter setups sticky" which changes the semantics of snd_hda_codec_cleanup_stream() not to clean up the stream at that moment but delay the action. This is the reason why Modem getting some unwanted data and stop working.

To resolve this issue we need to enable "no_sticky_stream" for these IDT codec. The fix is like putting one line of code "codec->no_sticky_stream =1;" at the end of function "patch_stac92hd83xxx" in file "/sound/pci/hda/patch_sigmatel.c".

As I am not much aware of the fix "Make converter setups sticky" and also not know the side effects of above mention fix, please analyze and fix the issue properly.

Thanks
SuresH

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]

At Thu, 29 Sep 2011 10:51:28 +0530,
Gupta, Suresh wrote:
> 
> Modem receive unwanted data on stream 0 even stream is not open by any device.
> Stream 0 was acquired by IDC 7605 and this codec keep sending something even after closing the stream.

Why does the LSI modem device receive from the stream of IDT codec at
all?  In other words, how does LSI modem driver manage the allocation
of streams?


Takashi

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.

[Gupta, Suresh]

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".  

Thanks
SuresH

void __snd_hda_codec_cleanup_stream(struct hda_codec *codec, hda_nid_t nid,
				    int do_now)
{
	struct hda_cvt_setup *p;
	if (!nid)
		return;

	if (codec->no_sticky_stream)
		do_now = 1;

	snd_printdd("hda_codec_cleanup_stream: NID=0x%x\n", nid);
	p = get_hda_cvt_setup(codec, nid);
	if (p) {
		/* here we just clear the active flag when do_now isn't set;
		 * actual clean-ups will be done later in
		 * purify_inactive_streams() called from snd_hda_codec_prpapre()
		 */
		if (do_now)
			really_cleanup_stream(codec, p);
		else
			p->active = 0;
	}
}

-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de] 
Sent: Thursday, September 29, 2011 11:51 AM
To: Gupta, Suresh
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] 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.

At Thu, 29 Sep 2011 10:51:28 +0530,
Gupta, Suresh wrote:
> 
> Modem receive unwanted data on stream 0 even stream is not open by any device.
> Stream 0 was acquired by IDC 7605 and this codec keep sending something even after closing the stream.

Why does the LSI modem device receive from the stream of IDT codec at
all?  In other words, how does LSI modem driver manage the allocation
of streams?


Takashi

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.

[suresh gupta]

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".



Thanks

SuresH



void __snd_hda_codec_cleanup_stream(struct hda_codec *codec, hda_nid_t nid,

                            int do_now)

{

      struct hda_cvt_setup *p;

      if (!nid)

            return;



      if (codec->no_sticky_stream)

            do_now = 1;



      snd_printdd("hda_codec_cleanup_stream: NID=0x%x\n", nid);

      p = get_hda_cvt_setup(codec, nid);

      if (p) {

            /* here we just clear the active flag when do_now isn't set;

             * actual clean-ups will be done later in

             * purify_inactive_streams() called from snd_hda_codec_prpapre()

             */

            if (do_now)

                  really_cleanup_stream(codec, p);

            else

                  p->active = 0;

      }

}


On Thu, Sep 29, 2011 at 11:50 AM, Takashi Iwai <tiwai@suse.de> wrote:

> At Thu, 29 Sep 2011 10:51:28 +0530,
> Gupta, Suresh wrote:
> >
> > Modem receive unwanted data on stream 0 even stream is not open by any
> device.
> > Stream 0 was acquired by IDC 7605 and this codec keep sending something
> even after closing the stream.
>
> Why does the LSI modem device receive from the stream of IDT codec at
> all?  In other words, how does LSI modem driver manage the allocation
> of streams?
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

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]

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.


Takashi

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]

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

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.

[suresh gupta]

Sorry for delay, I was out for Lunch.

I believe we are in sink now, I seen the purity_inactive_streams part of
code and found this is totally new logic in 1.0.24 ver. Can you please
answer some question for my proper understanding?

1. Why this marking stream dirty come into picture and why ALSA code do not
directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?

2. Why Analog devices codec (patch_analog.c) clear
AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
   really_cleanup_stream(codec, p);
)


On Thu, Sep 29, 2011 at 1:27 PM, Takashi Iwai <tiwai@suse.de> wrote:

> 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
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

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]

At Thu, 29 Sep 2011 14:01:40 +0530,
suresh gupta wrote:
> 
> Sorry for delay, I was out for Lunch.
> 
> I believe we are in sink now, I seen the purity_inactive_streams part of
> code and found this is totally new logic in 1.0.24 ver. Can you please
> answer some question for my proper understanding?
> 
> 1. Why this marking stream dirty come into picture and why ALSA code do not
> directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?

For keeping the same stream tag for the same device.
A device is often shortly closed and reopened.  It'd be better to keep
the same stream tag for such a case.

> 2. Why Analog devices codec (patch_analog.c) clear
> AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
>    really_cleanup_stream(codec, p);

It's because AD codecs (according to bug reports) don't like the
sticky-tag feature by some reason.  It'll be removed, once when the
real culprit is found.


Takashi

> )
> 
> 
> On Thu, Sep 29, 2011 at 1:27 PM, Takashi Iwai <tiwai@suse.de> wrote:
> 
> > 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
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> [2  <text/html; ISO-8859-1 (quoted-printable)>]
> 

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.

[suresh gupta]

Thanks for answers,

 I will explore more our code to understand the issue and will come back.

Again thanks for help…..
SuresH

On Thu, Sep 29, 2011 at 2:16 PM, Takashi Iwai <tiwai@suse.de> wrote:

> At Thu, 29 Sep 2011 14:01:40 +0530,
> suresh gupta wrote:
> >
> > Sorry for delay, I was out for Lunch.
> >
> > I believe we are in sink now, I seen the purity_inactive_streams part of
> > code and found this is totally new logic in 1.0.24 ver. Can you please
> > answer some question for my proper understanding?
> >
> > 1. Why this marking stream dirty come into picture and why ALSA code do
> not
> > directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?
>
> For keeping the same stream tag for the same device.
> A device is often shortly closed and reopened.  It'd be better to keep
> the same stream tag for such a case.
>
> > 2. Why Analog devices codec (patch_analog.c) clear
> > AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
> >    really_cleanup_stream(codec, p);
>
> It's because AD codecs (according to bug reports) don't like the
> sticky-tag feature by some reason.  It'll be removed, once when the
> real culprit is found.
>
>
> Takashi
>
> > )
>  >
> >
> > On Thu, Sep 29, 2011 at 1:27 PM, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > > 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
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > >
> > [2  <text/html; ISO-8859-1 (quoted-printable)>]
> >
>

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.

[Raymond Yau]

2011/9/29 Takashi Iwai <tiwai@suse.de>:
> At Thu, 29 Sep 2011 14:01:40 +0530,
> suresh gupta wrote:
>>
>> Sorry for delay, I was out for Lunch.
>>
>> I believe we are in sink now, I seen the purity_inactive_streams part of
>> code and found this is totally new logic in 1.0.24 ver. Can you please
>> answer some question for my proper understanding?
>>
>> 1. Why this marking stream dirty come into picture and why ALSA code do not
>> directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?
>
> For keeping the same stream tag for the same device.
> A device is often shortly closed and reopened.  It'd be better to keep
> the same stream tag for such a case.

I have doubt about this since hw_free() can also cleanup the stream tag too

http://thread.gmane.org/gmane.linux.alsa.devel/89420

>
>> 2. Why Analog devices codec (patch_analog.c) clear
>> AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
>>    really_cleanup_stream(codec, p);
>
> It's because AD codecs (according to bug reports) don't like the
> sticky-tag feature by some reason.  It'll be removed, once when the
> real culprit is found.
>
>

http://thread.gmane.org/gmane.linux.alsa.devel/78379

Can the converters can retrain the stream tag after suspend/resume ?

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]

At Sat, 1 Oct 2011 10:56:55 +0800,
Raymond Yau wrote:
> 
> 2011/9/29 Takashi Iwai <tiwai@suse.de>:
> > At Thu, 29 Sep 2011 14:01:40 +0530,
> > suresh gupta wrote:
> >>
> >> Sorry for delay, I was out for Lunch.
> >>
> >> I believe we are in sink now, I seen the purity_inactive_streams part of
> >> code and found this is totally new logic in 1.0.24 ver. Can you please
> >> answer some question for my proper understanding?
> >>
> >> 1. Why this marking stream dirty come into picture and why ALSA code do not
> >> directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?
> >
> > For keeping the same stream tag for the same device.
> > A device is often shortly closed and reopened.  It'd be better to keep
> > the same stream tag for such a case.
> 
> I have doubt about this since hw_free() can also cleanup the stream tag too
> 
> http://thread.gmane.org/gmane.linux.alsa.devel/89420

It's only in the case of no_sticky.  It doesn't happen in the normal
case.

> >
> >> 2. Why Analog devices codec (patch_analog.c) clear
> >> AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
> >>    really_cleanup_stream(codec, p);
> >
> > It's because AD codecs (according to bug reports) don't like the
> > sticky-tag feature by some reason.  It'll be removed, once when the
> > real culprit is found.
> >
> >
> 
> http://thread.gmane.org/gmane.linux.alsa.devel/78379
> 
> Can the converters can retrain the stream tag after suspend/resume ?

No.  The flag is cleared in the suspend.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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.

[Raymond Yau]

2011/10/1 Takashi Iwai <tiwai@suse.de>:
>> >
>> >> 2. Why Analog devices codec (patch_analog.c) clear
>> >> AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
>> >>    really_cleanup_stream(codec, p);
>> >
>> > It's because AD codecs (according to bug reports) don't like the
>> > sticky-tag feature by some reason.  It'll be removed, once when the
>> > real culprit is found.
>> >
>> >
>>
>> http://thread.gmane.org/gmane.linux.alsa.devel/78379
>>
>> Can the converters can retrain the stream tag after suspend/resume ?
>
> No.  The flag is cleared in the suspend.
>

The main difference is only AD codecs have Power widget but driver
does not has init verbs for this [Power widget]

e.g. ad1988 has 9 widets support power states ,

Table 13 Widet Parameters (Power states 0f)
Five [Audio Output] , three [Audio Input] and [Power widget] have 00000009


Table 10
widget
No. Name                    Description
19 Mixer Power Down   Power widget Powers down the analog mixer and
associated amps
23 VREF Power Down Vendor defined Powers down the internal and
external VREF circularity
2f BIAS Power Down Vendor defined Powers down the internal
MIC_BIAS_FILT and all MIC_BIAS pins


Node 0x19 [Power Widget] wcaps 0x500500: Mono
  Power states:  D0 D3
  Power: setting=D0, actual=D0
  Connection: 2
     0x20 0x21

There are two vendor defined widgets (VREF power down and BIAS power pown)

Node 0x23 [Vendor Defined Widget] wcaps 0xf00100: Mono
  Connection: 18
     0x11* 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x24 0x25 0x38 0x39 0x3a
0x3b 0x3c

Node 0x2f [Vendor Defined Widget] wcaps 0xf00100: Mono
  Connection: 6
     0x11* 0x12 0x14 0x15 0x16 0x17

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]

At Mon, 3 Oct 2011 09:35:59 +0800,
Raymond Yau wrote:
> 
> 2011/10/1 Takashi Iwai <tiwai@suse.de>:
> >> >
> >> >> 2. Why Analog devices codec (patch_analog.c) clear
> >> >> AC_VERB_SET_CHANNEL_STREAMID on close? (if (do_now)
> >> >>    really_cleanup_stream(codec, p);
> >> >
> >> > It's because AD codecs (according to bug reports) don't like the
> >> > sticky-tag feature by some reason.  It'll be removed, once when the
> >> > real culprit is found.
> >> >
> >> >
> >>
> >> http://thread.gmane.org/gmane.linux.alsa.devel/78379
> >>
> >> Can the converters can retrain the stream tag after suspend/resume ?
> >
> > No.  The flag is cleared in the suspend.
> >
> 
> The main difference is only AD codecs have Power widget but driver
> does not has init verbs for this [Power widget]

Yeah, but this has nothing to do with the sticky assignment.
Actually the widget isn't touched, so it means all widgets are fully
powered up or all powered down at suspend.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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]

At Thu, 29 Sep 2011 10:46:02 +0200,
Takashi Iwai wrote:
> 
> At Thu, 29 Sep 2011 14:01:40 +0530,
> suresh gupta wrote:
> > 
> > Sorry for delay, I was out for Lunch.
> > 
> > I believe we are in sink now, I seen the purity_inactive_streams part of
> > code and found this is totally new logic in 1.0.24 ver. Can you please
> > answer some question for my proper understanding?
> > 
> > 1. Why this marking stream dirty come into picture and why ALSA code do not
> > directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?
> 
> For keeping the same stream tag for the same device.
> A device is often shortly closed and reopened.  It'd be better to keep
> the same stream tag for such a case.

While reading the code again, it seems that the code in hda_intel.c
doesn't do perfectly for some stream setups.  For example, it blindly
relies on pcm->device number, so playback and capture streams won't be
distinguished, and the first taker will win always.

I fixed it now with the patch below.


Takashi

===
From: Takashi Iwai <tiwai@suse.de>
Subject: ALSA: hda - Distinguish each substream for better sticky assignment

The commit ef18beded8ddbaafdf4914bab209f77e60ae3a18 introduced a
mechanism to assign the previously used slot for the next reopen of a
PCM stream.  But the PCM device number isn't always unique (it may
have multiple substreams), and also the code doesn't check the stream
direction, thus both playback and capture streams share the same
device number.

For avoiding this conflict, make a unique key for each substream and
store/check this value at reopening.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_intel.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 8a5dc57..90713f0 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -381,7 +381,7 @@ struct azx_dev {
 					 */
 	unsigned char stream_tag;	/* assigned stream */
 	unsigned char index;		/* stream index */
-	int device;			/* last device number assigned to */
+	int assigned_key;		/* last device# key assigned to */
 
 	unsigned int opened :1;
 	unsigned int running :1;
@@ -1613,6 +1613,9 @@ azx_assign_device(struct azx *chip, struct snd_pcm_substream *substream)
 {
 	int dev, i, nums;
 	struct azx_dev *res = NULL;
+	/* make a non-zero unique key for the substream */
+	int key = (substream->pcm->device << 16) | (substream->number << 2) |
+		(substream->stream + 1);
 
 	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
 		dev = chip->playback_index_offset;
@@ -1624,12 +1627,12 @@ azx_assign_device(struct azx *chip, struct snd_pcm_substream *substream)
 	for (i = 0; i < nums; i++, dev++)
 		if (!chip->azx_dev[dev].opened) {
 			res = &chip->azx_dev[dev];
-			if (res->device == substream->pcm->device)
+			if (res->assigned_key == key)
 				break;
 		}
 	if (res) {
 		res->opened = 1;
-		res->device = substream->pcm->device;
+		res->assigned_key = key;
 	}
 	return res;
 }
-- 
1.7.7

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.

[suresh gupta]

Our modem works with this fix, so I try to understand it and found that, the
only difference is now "azx_assign_device" function assign stream from last
position and assign last one.  This is the reason why our modem works with
this fix as our modem try to get stream from first position and get first
one.

Do you really want this to do and what the significance of acquiring stream
from last position?

However from your previous explanation about new logic, I fixed the issue by
making change in our modem code.
Thanks for your support and help.
SuresH

On Thu, Oct 6, 2011 at 1:54 PM, Takashi Iwai <tiwai@suse.de> wrote:

> At Thu, 29 Sep 2011 10:46:02 +0200,
> Takashi Iwai wrote:
> >
> > At Thu, 29 Sep 2011 14:01:40 +0530,
> > suresh gupta wrote:
> > >
> > > Sorry for delay, I was out for Lunch.
> > >
> > > I believe we are in sink now, I seen the purity_inactive_streams part
> of
> > > code and found this is totally new logic in 1.0.24 ver. Can you please
> > > answer some question for my proper understanding?
> > >
> > > 1. Why this marking stream dirty come into picture and why ALSA code do
> not
> > > directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?
> >
> > For keeping the same stream tag for the same device.
> > A device is often shortly closed and reopened.  It'd be better to keep
> > the same stream tag for such a case.
>
> While reading the code again, it seems that the code in hda_intel.c
> doesn't do perfectly for some stream setups.  For example, it blindly
> relies on pcm->device number, so playback and capture streams won't be
> distinguished, and the first taker will win always.
>
> I fixed it now with the patch below.
>
>
> Takashi
>
> ===
> From: Takashi Iwai <tiwai@suse.de>
> Subject: ALSA: hda - Distinguish each substream for better sticky
> assignment
>
> The commit ef18beded8ddbaafdf4914bab209f77e60ae3a18 introduced a
> mechanism to assign the previously used slot for the next reopen of a
> PCM stream.  But the PCM device number isn't always unique (it may
> have multiple substreams), and also the code doesn't check the stream
> direction, thus both playback and capture streams share the same
> device number.
>
> For avoiding this conflict, make a unique key for each substream and
> store/check this value at reopening.
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/pci/hda/hda_intel.c |    9 ++++++---
>  1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 8a5dc57..90713f0 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -381,7 +381,7 @@ struct azx_dev {
>                                         */
>        unsigned char stream_tag;       /* assigned stream */
>        unsigned char index;            /* stream index */
> -       int device;                     /* last device number assigned to
> */
> +       int assigned_key;               /* last device# key assigned to */
>
>        unsigned int opened :1;
>        unsigned int running :1;
> @@ -1613,6 +1613,9 @@ azx_assign_device(struct azx *chip, struct
> snd_pcm_substream *substream)
>  {
>        int dev, i, nums;
>        struct azx_dev *res = NULL;
> +       /* make a non-zero unique key for the substream */
> +       int key = (substream->pcm->device << 16) | (substream->number << 2)
> |
> +               (substream->stream + 1);
>
>        if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>                dev = chip->playback_index_offset;
> @@ -1624,12 +1627,12 @@ azx_assign_device(struct azx *chip, struct
> snd_pcm_substream *substream)
>        for (i = 0; i < nums; i++, dev++)
>                if (!chip->azx_dev[dev].opened) {
>                        res = &chip->azx_dev[dev];
> -                       if (res->device == substream->pcm->device)
> +                       if (res->assigned_key == key)
>                                break;
>                }
>        if (res) {
>                res->opened = 1;
> -               res->device = substream->pcm->device;
> +               res->assigned_key = key;
>        }
>        return res;
>  }
> --
> 1.7.7
>
>

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]

At Tue, 11 Oct 2011 14:49:00 +0530,
suresh gupta wrote:
> 
> Our modem works with this fix, so I try to understand it and found that, the
> only difference is now "azx_assign_device" function assign stream from last
> position and assign last one.  This is the reason why our modem works with
> this fix as our modem try to get stream from first position and get first
> one.
> 
> Do you really want this to do and what the significance of acquiring stream
> from last position?

Not really much.  The only goal is to re-use the last used stream
at the next open.


Takashi

> However from your previous explanation about new logic, I fixed the issue by
> making change in our modem code.
> Thanks for your support and help.
> SuresH
> 
> On Thu, Oct 6, 2011 at 1:54 PM, Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Thu, 29 Sep 2011 10:46:02 +0200,
> > Takashi Iwai wrote:
> > >
> > > At Thu, 29 Sep 2011 14:01:40 +0530,
> > > suresh gupta wrote:
> > > >
> > > > Sorry for delay, I was out for Lunch.
> > > >
> > > > I believe we are in sink now, I seen the purity_inactive_streams part
> > of
> > > > code and found this is totally new logic in 1.0.24 ver. Can you please
> > > > answer some question for my proper understanding?
> > > >
> > > > 1. Why this marking stream dirty come into picture and why ALSA code do
> > not
> > > > directly clear the AC_VERB_SET_CHANNEL_STREAMID while closing?
> > >
> > > For keeping the same stream tag for the same device.
> > > A device is often shortly closed and reopened.  It'd be better to keep
> > > the same stream tag for such a case.
> >
> > While reading the code again, it seems that the code in hda_intel.c
> > doesn't do perfectly for some stream setups.  For example, it blindly
> > relies on pcm->device number, so playback and capture streams won't be
> > distinguished, and the first taker will win always.
> >
> > I fixed it now with the patch below.
> >
> >
> > Takashi
> >
> > ===
> > From: Takashi Iwai <tiwai@suse.de>
> > Subject: ALSA: hda - Distinguish each substream for better sticky
> > assignment
> >
> > The commit ef18beded8ddbaafdf4914bab209f77e60ae3a18 introduced a
> > mechanism to assign the previously used slot for the next reopen of a
> > PCM stream.  But the PCM device number isn't always unique (it may
> > have multiple substreams), and also the code doesn't check the stream
> > direction, thus both playback and capture streams share the same
> > device number.
> >
> > For avoiding this conflict, make a unique key for each substream and
> > store/check this value at reopening.
> >
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> >  sound/pci/hda/hda_intel.c |    9 ++++++---
> >  1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > index 8a5dc57..90713f0 100644
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -381,7 +381,7 @@ struct azx_dev {
> >                                         */
> >        unsigned char stream_tag;       /* assigned stream */
> >        unsigned char index;            /* stream index */
> > -       int device;                     /* last device number assigned to
> > */
> > +       int assigned_key;               /* last device# key assigned to */
> >
> >        unsigned int opened :1;
> >        unsigned int running :1;
> > @@ -1613,6 +1613,9 @@ azx_assign_device(struct azx *chip, struct
> > snd_pcm_substream *substream)
> >  {
> >        int dev, i, nums;
> >        struct azx_dev *res = NULL;
> > +       /* make a non-zero unique key for the substream */
> > +       int key = (substream->pcm->device << 16) | (substream->number << 2)
> > |
> > +               (substream->stream + 1);
> >
> >        if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> >                dev = chip->playback_index_offset;
> > @@ -1624,12 +1627,12 @@ azx_assign_device(struct azx *chip, struct
> > snd_pcm_substream *substream)
> >        for (i = 0; i < nums; i++, dev++)
> >                if (!chip->azx_dev[dev].opened) {
> >                        res = &chip->azx_dev[dev];
> > -                       if (res->device == substream->pcm->device)
> > +                       if (res->assigned_key == key)
> >                                break;
> >                }
> >        if (res) {
> >                res->opened = 1;
> > -               res->device = substream->pcm->device;
> > +               res->assigned_key = key;
> >        }
> >        return res;
> >  }
> > --
> > 1.7.7
> >
> >