Re: [alsa-devel] [Fwd: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux]]
Dear list,
My original mail on this topic was posted to the alsa-user list, while I was informed that this alsa-devel list would be the right place to post.
The problem I had encountered is that the Adi 1986 codec chip on my device with Poulsbo(SCH) chipset could not be recognized by the snd_hda_intel driver module.
Tobin has kindly given me an advice on trying an ALSA driver that is later than 1.0.16.final. For a cross-test pupose, I have tried both the following 1.0.16 and the latest 1.0.17-rc2.
[1.0.16] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2
[1.0.17-rc2] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.17rc2.tar.bz2
By following the guide described in the INSTALL text file in both the above two packages, I have done make and make install without a problem.
Unfortunately, both these two version of ALSA driver does not recognized the Adi 1986 codec and in the dmesg output claiming that "no codecs found!".
<dmesg> -- snip -- ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.16/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1887: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled -- snip --
I have also tried applying some module parameters like probe_mask and position_fix but with no luck.
Actually, we have two machines with Poulsbo(SCH) chipset inside. The ALSA driver works fine in one(with a chipset's revision of "04") while it does not work on the other (with a chipset's revision of "06").
Here I attach the "lspci -nnvvvxxxx" result from both two machines.
Any comment would be greatly appericiated. If anyone needs more information, please let me know.
---------- Forwarded message ----------
2008/6/24 stan ghjeold_i_mwee@cox.net:
This is a response from the alsa-devel list. I forwarded your message there as that was the more appropriate list.
Not sure what version of alsa driver you are using, but the driver for that chipset was added prior to 1.0.16 final. Anything after that should work.
Tobin
On Mon, 2008-06-23 at 06:20 -0700, stan wrote:
Sent to wrong list.
email message attachment ([Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux.eml)
-------- Forwarded Message -------- From: Kan-I Jyo cecilhsujp@gmail.com To: alsa-user@lists.sourceforge.net Subject: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux Date: Mon, 23 Jun 2008 20:53:42 +0900
Dear list,
I have recently got a device with Intel's Poulsbo chipset and Adi 1986 codec attatched.
The Adi 1986 codec along with the Poulsbo chipset could been recognized by installing the SoundMAX driver under Windows XP.
While switching to Linux, the snd_intel_hda is loaded but the Adi 1986 codec could not been seen and there is no "codec#0" entry under /proc/asound/card0.
From what I can see from dmesg, the hda_intel module had complained
about "no codecs found!".
<dmesg.txt> -- snip -- [ 93.463277] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 93.463286] Do fixup for Poulsbo <6>D0 or newer stepping [ 93.463439] HDA snoop disabled, try to enable ... OK [ 93.491624] hda-intel: no codecs found! -- snip --
I have attached both output of dmesg command the "lspci -nnvvvxxx" result along with this mail. Any comment would be greatly appreciated.
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
_______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Tobin Davis
The only copy of Norton Utilities was on THAT disk???
--Top 100 things you don't want the sysadmin to say
If the system you are referring to is a development platform, then it is possible that the jumper settings on your sound board are not configured correctly. One simple test is to swap sound boards. Another thing to look at is the bios settings. The mainstream alsa driver should not care about the chipset revision. But if the audio hardware is misconfigured, that would cause it not to work.
Tobin
On Wed, 2008-06-25 at 10:40 +0900, Kan-I Jyo wrote:
Dear list,
My original mail on this topic was posted to the alsa-user list, while I was informed that this alsa-devel list would be the right place to post.
The problem I had encountered is that the Adi 1986 codec chip on my device with Poulsbo(SCH) chipset could not be recognized by the snd_hda_intel driver module.
Tobin has kindly given me an advice on trying an ALSA driver that is later than 1.0.16.final. For a cross-test pupose, I have tried both the following 1.0.16 and the latest 1.0.17-rc2.
[1.0.16] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2
[1.0.17-rc2] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.17rc2.tar.bz2
By following the guide described in the INSTALL text file in both the above two packages, I have done make and make install without a problem.
Unfortunately, both these two version of ALSA driver does not recognized the Adi 1986 codec and in the dmesg output claiming that "no codecs found!".
<dmesg> -- snip -- ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.16/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1887: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled -- snip --
I have also tried applying some module parameters like probe_mask and position_fix but with no luck.
Actually, we have two machines with Poulsbo(SCH) chipset inside. The ALSA driver works fine in one(with a chipset's revision of "04") while it does not work on the other (with a chipset's revision of "06").
Here I attach the "lspci -nnvvvxxxx" result from both two machines.
Any comment would be greatly appericiated. If anyone needs more information, please let me know.
---------- Forwarded message ----------
2008/6/24 stan ghjeold_i_mwee@cox.net:
This is a response from the alsa-devel list. I forwarded your message there as that was the more appropriate list.
Not sure what version of alsa driver you are using, but the driver for that chipset was added prior to 1.0.16 final. Anything after that should work.
Tobin
On Mon, 2008-06-23 at 06:20 -0700, stan wrote:
Sent to wrong list.
email message attachment ([Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux.eml)
-------- Forwarded Message -------- From: Kan-I Jyo cecilhsujp@gmail.com To: alsa-user@lists.sourceforge.net Subject: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux Date: Mon, 23 Jun 2008 20:53:42 +0900
Dear list,
I have recently got a device with Intel's Poulsbo chipset and Adi 1986 codec attatched.
The Adi 1986 codec along with the Poulsbo chipset could been recognized by installing the SoundMAX driver under Windows XP.
While switching to Linux, the snd_intel_hda is loaded but the Adi 1986 codec could not been seen and there is no "codec#0" entry under /proc/asound/card0.
From what I can see from dmesg, the hda_intel module had complained
about "no codecs found!".
<dmesg.txt> -- snip -- [ 93.463277] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 93.463286] Do fixup for Poulsbo <6>D0 or newer stepping [ 93.463439] HDA snoop disabled, try to enable ... OK [ 93.491624] hda-intel: no codecs found! -- snip --
I have attached both output of dmesg command the "lspci -nnvvvxxx" result along with this mail. Any comment would be greatly appreciated.
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
_______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Tobin Davis
The only copy of Norton Utilities was on THAT disk???
--Top 100 things you don't want the sysadmin to say
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Dear Tobin,
Thank you for your response.
2008/6/25 Tobin Davis tdavis@dsl-only.net:
If the system you are referring to is a development platform, then it is possible that the jumper settings on your sound board are not configured correctly.
This was the first thing that came to my mind as well. To make sure that the hardware is correctly configured, we had installed a retail version of Windows XP to this device along with SoundMAX driver as well. And the misterious thing is that sound output was working on this revision 06 device with Windows XP but not Linux.
One simple test is to swap sound boards.
This is a good idea and worth trying. However, as all chips including the sound codec are hard-wired on this board, there is no extra slots like pci or isa available for me to make such a test.
Another thing to look at is the bios settings.
Another good point that inspires me. I have digged around the BIOS menu. There did be some difference between the working machine and the not-working one. Frustratingly, the sound codec chip remains unrecognized even they have exact settings along with each other after adjustments.
The mainstream alsa driver should not care about the chipset revision. But if the audio hardware is misconfigured, that would cause it not to work.
I can't not agree with you more. Though it seems that there is less possibility as the device works under Windows, I wil try to see if there were any other hardware jumper that I can adjust.
On the other hand, is there any other thing/info that I can do to help solve phenomenon?
At Wed, 25 Jun 2008 10:40:41 +0900, Kan-I Jyo wrote:
Dear list,
My original mail on this topic was posted to the alsa-user list, while I was informed that this alsa-devel list would be the right place to post.
The problem I had encountered is that the Adi 1986 codec chip on my device with Poulsbo(SCH) chipset could not be recognized by the snd_hda_intel driver module.
Tobin has kindly given me an advice on trying an ALSA driver that is later than 1.0.16.final. For a cross-test pupose, I have tried both the following 1.0.16 and the latest 1.0.17-rc2.
[1.0.16] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2
[1.0.17-rc2] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.17rc2.tar.bz2
By following the guide described in the INSTALL text file in both the above two packages, I have done make and make install without a problem.
Unfortunately, both these two version of ALSA driver does not recognized the Adi 1986 codec and in the dmesg output claiming that "no codecs found!".
<dmesg> -- snip -- ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.16/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1887: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled
The driver was properly loaded, so the problem is in the codec communication...
On which slot is assigned the codec chip? As now, SCH is set up to probe up to 3rd slots. The driver had a problem regarding the probe on the 4th slot on some hardwares, so it limited the probe to 3 slots as default. SCH support was just copied from ICH, and this workaround was likely inherited, too.
The patch below enables the probe on 4th slot on SCH.
thanks,
Takashi
--- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 16715a6..2e9d9c9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1157,7 +1157,7 @@ static int azx_setup_controller(struct azx *chip, struct azx_dev *azx_dev)
static unsigned int azx_max_codecs[] __devinitdata = { [AZX_DRIVER_ICH] = 4, /* Some ICH9 boards use SD3 */ - [AZX_DRIVER_SCH] = 3, + [AZX_DRIVER_SCH] = 4, [AZX_DRIVER_ATI] = 4, [AZX_DRIVER_ATIHDMI] = 4, [AZX_DRIVER_VIA] = 3, /* FIXME: correct? */
Dear Takashi,
Thank you for your reply.
2008/6/25 Takashi Iwai tiwai@suse.de:
The patch below enables the probe on 4th slot on SCH.
Thank you for your patch. I have applied your patch and recompiled the snd-hda-intel kernel module. A reload of the newly compiled driver stiil gives me the "no codec found!" output in dmesg.
After inserting some snd_printk() into the hda_intel.c, it seems that this "azx_readw()" macro in azx_reset() function returns a "0" to chip->codec_mask on our not-working device. It is returns a "1" on the other working device though.
<hda_intel.c> -- snip -- 751 /* detect codecs */ 752 if (!chip->codec_mask) { 753 chip->codec_mask = azx_readw(chip, STATESTS); 754 snd_printk("codec_mask = 0x%x\n", chip->codec_mask); -- snip --
<dmesg> -- snip -- PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2069: chipset global capabilities = 0x2200 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:912: HDA snoop disabled, enabling ... OK ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:754: codec_mask = 0x0 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled
For I am not an expert in sound driver development, the above are provided for reference. But would this be some kind of hint?
At Wed, 25 Jun 2008 21:00:46 +0900, Kan-I Jyo wrote:
Dear Takashi,
Thank you for your reply.
2008/6/25 Takashi Iwai tiwai@suse.de:
The patch below enables the probe on 4th slot on SCH.
Thank you for your patch. I have applied your patch and recompiled the snd-hda-intel kernel module. A reload of the newly compiled driver stiil gives me the "no codec found!" output in dmesg.
After inserting some snd_printk() into the hda_intel.c, it seems that this "azx_readw()" macro in azx_reset() function returns a "0" to chip->codec_mask on our not-working device. It is returns a "1" on the other working device though.
<hda_intel.c> -- snip -- 751 /* detect codecs */ 752 if (!chip->codec_mask) { 753 chip->codec_mask = azx_readw(chip, STATESTS); 754 snd_printk("codec_mask = 0x%x\n", chip->codec_mask); -- snip --
<dmesg> -- snip -- PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2069: chipset global capabilities = 0x2200 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:912: HDA snoop disabled, enabling ... OK ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:754: codec_mask = 0x0 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled
For I am not an expert in sound driver development, the above are provided for reference. But would this be some kind of hint?
The hardware sets the corresponding bits to this register when the codec is found on the slot. So, this seems really like a hardware problem.
Or, if it's a timing issue, you can try to add some delays in azx_reset()...
Takashi
Dear Takashi,
Thank you for your kind help all the time.
2008/6/25 Takashi Iwai tiwai@suse.de:
The hardware sets the corresponding bits to this register when the codec is found on the slot. So, this seems really like a hardware problem.
For all my try these days have all led to a non-working audio device, I can not help thinking the high possibility of a hardware problem. Just want to make sure that I have made good efforts before blaming on hardware side.
Or, if it's a timing issue, you can try to add some delays in azx_reset()...
Considering this kind of issue, I have increased the "msleep" in azx_reset() from 1 to 1000. With no luck, stiil there the "no codecs found" message.
Moreover, I have changed the "msleep" to "ssleep" with a even larger value. As you may have expected, no recognization of the ADi 1986A codec at all.
Though there might be no much left for trying, I just want to make sure that I did not miss any import part. And I would like say thank you as well for your timely advetise.
2008/6/30 Kan-I Jyo cecilhsujp@gmail.com:
And I would like say thank you as well for your timely advetise.
^^^^^^^^ it is "advise", I mean. sorry about this.
At Mon, 30 Jun 2008 22:20:17 +0900, Kan-I Jyo wrote:
Dear Takashi,
Thank you for your kind help all the time.
2008/6/25 Takashi Iwai tiwai@suse.de:
The hardware sets the corresponding bits to this register when the codec is found on the slot. So, this seems really like a hardware problem.
For all my try these days have all led to a non-working audio device, I can not help thinking the high possibility of a hardware problem. Just want to make sure that I have made good efforts before blaming on hardware side.
Or, if it's a timing issue, you can try to add some delays in azx_reset()...
Considering this kind of issue, I have increased the "msleep" in azx_reset() from 1 to 1000. With no luck, stiil there the "no codecs found" message.
Moreover, I have changed the "msleep" to "ssleep" with a even larger value. As you may have expected, no recognization of the ADi 1986A codec at all.
Then it implies that the hardware doesn't set this bit. It's supposed to be mandatory, and this probing mechanism works well for other hundreds of devices. Thus I think something still wrong in your device setup.
If you know the slot number of the codec beforehand, you can modify to force to set chip->codec_mask in azx_reset(). Then the driver will continue to probe the codec.
Takashi
Dear Takashi,
Thank you for your reply.
2008/7/1 Takashi Iwai tiwai@suse.de:
If you know the slot number of the codec beforehand, you can modify to force to set chip->codec_mask in azx_reset(). Then the driver will continue to probe the codec.
By changing the "chip->codec_mask", amazingly the codec chip is now recognized.
<hda_intel.c.diff> --- hda_intel.c.orig 2008-07-02 13:27:14.699908463 +0900 +++ hda_intel.c 2008-07-02 13:27:48.303899618 +0900 @@ -750,7 +750,8 @@ static int azx_reset(struct azx *chip)
/* detect codecs */ if (!chip->codec_mask) { - chip->codec_mask = azx_readw(chip, STATESTS); + /* chip->codec_mask = azx_readw(chip, STATESTS); */ + chip->codec_mask = 1; snd_printdd("codec_mask = 0x%x\n", chip->codec_mask); }
<ends here>
I do not consider this as a good way to solve this issue, this is quite a progress to me. Thank you for your advise, Takashi.
Regardless of being recognized and been configurable by alsamixer, there is no sound output from the speaker. I have tried all the model option listed in Documentation/sound/alsa/ALSA-Configuration.txt for AD1986A and none provides a sound output.
By switching to different models, it results some similar log output in both dmesg and /var/log/messages have some info like this:
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:601: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:608: hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000 ALSA /root/alsa-driver-1.0.17rc3/pci/hda/hda_codec.c:2334: hda_codec: model '6stack' is selected ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1196: snd_hda_codec_new() results is 0
<ends here>
When trying to apply the "position_fix" module option to values other than the default "0", I got following ouput from dmesg.
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/acore/../alsa-kernel/core/pcm_lib.c:1540: playback write error (DMA or IRQ trouble?)
<ends here>
And in /var/log/messages, I have following messages complaining that the position buffer is invalid.
</var/log/messages>
--snip-- Jan 2 18:34:03 localhost kernel: hda-intel: Invalid position buffer, using LPIB read method instead. Jan 2 18:34:03 localhost kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
<ends here>
As you have metioned in your previous update, there is high possibility that this is not a software(driver) issue but a hardware misconfiguration. Though I think there might some kind of workaround to solve this issue, I will try contacting the hardware vendor about this situation.
And still, any commet would be greatly appreciated.
At Thu, 3 Jul 2008 14:42:16 +0900, Kan-I Jyo wrote:
Dear Takashi,
Thank you for your reply.
2008/7/1 Takashi Iwai tiwai@suse.de:
If you know the slot number of the codec beforehand, you can modify to force to set chip->codec_mask in azx_reset(). Then the driver will continue to probe the codec.
By changing the "chip->codec_mask", amazingly the codec chip is now recognized.
<hda_intel.c.diff> --- hda_intel.c.orig 2008-07-02 13:27:14.699908463 +0900 +++ hda_intel.c 2008-07-02 13:27:48.303899618 +0900 @@ -750,7 +750,8 @@ static int azx_reset(struct azx *chip)
/* detect codecs */ if (!chip->codec_mask) {
chip->codec_mask = azx_readw(chip, STATESTS);
/* chip->codec_mask = azx_readw(chip, STATESTS); */chip->codec_mask = 1;<ends here>
I do not consider this as a good way to solve this issue, this is quite a progress to me. Thank you for your advise, Takashi.
Regardless of being recognized and been configurable by alsamixer, there is no sound output from the speaker. I have tried all the model option listed in Documentation/sound/alsa/ALSA-Configuration.txt for AD1986A and none provides a sound output.
By switching to different models, it results some similar log output in both dmesg and /var/log/messages have some info like this:
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:601: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:608: hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000
If this happens, usually it means that the device access is pretty ragged. Does /proc/asound/card0/codec#* show the correct values?
ALSA /root/alsa-driver-1.0.17rc3/pci/hda/hda_codec.c:2334: hda_codec: model '6stack' is selected ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1196: snd_hda_codec_new() results is 0
<ends here>
When trying to apply the "position_fix" module option to values other than the default "0", I got following ouput from dmesg.
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/acore/../alsa-kernel/core/pcm_lib.c:1540: playback write error (DMA or IRQ trouble?)
This error is fatal, and implies that the IRQ isn't triggered properly. Doesn't this happen if you set position_fix=0? Still weird...
<ends here>
And in /var/log/messages, I have following messages complaining that the position buffer is invalid.
</var/log/messages>
--snip-- Jan 2 18:34:03 localhost kernel: hda-intel: Invalid position buffer, using LPIB read method instead. Jan 2 18:34:03 localhost kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
On Intel devices, we choose the 1 sample position fix while 32 samples for other controller chips. This might be a wrong assumption, but I'd like to check all other cases first.
And, this basically is no fatal error. This may lead to higher CPU load (for busy wait) but the playback should still work.
Takashi
Dear Takhashi,
After having some discussions with the hardware vender and reviewing some technical specifiction documents on Intel's website, this issue has now been fixed by a rework of the hardware.
I would like to say thank you for all your kind support on this issue.
2008/7/4 Takashi Iwai tiwai@suse.de:
At Thu, 3 Jul 2008 14:42:16 +0900, Kan-I Jyo wrote:
Dear Takashi,
Thank you for your reply.
2008/7/1 Takashi Iwai tiwai@suse.de:
If you know the slot number of the codec beforehand, you can modify to force to set chip->codec_mask in azx_reset(). Then the driver will continue to probe the codec.
By changing the "chip->codec_mask", amazingly the codec chip is now recognized.
<hda_intel.c.diff> --- hda_intel.c.orig 2008-07-02 13:27:14.699908463 +0900 +++ hda_intel.c 2008-07-02 13:27:48.303899618 +0900 @@ -750,7 +750,8 @@ static int azx_reset(struct azx *chip)
/* detect codecs */ if (!chip->codec_mask) {
chip->codec_mask = azx_readw(chip, STATESTS);
/* chip->codec_mask = azx_readw(chip, STATESTS); */chip->codec_mask = 1; snd_printdd("codec_mask = 0x%x\n", chip->codec_mask); }<ends here>
I do not consider this as a good way to solve this issue, this is quite a progress to me. Thank you for your advise, Takashi.
Regardless of being recognized and been configurable by alsamixer, there is no sound output from the speaker. I have tried all the model option listed in Documentation/sound/alsa/ALSA-Configuration.txt for AD1986A and none provides a sound output.
By switching to different models, it results some similar log output in both dmesg and /var/log/messages have some info like this:
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:601: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:608: hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000
If this happens, usually it means that the device access is pretty ragged. Does /proc/asound/card0/codec#* show the correct values?
ALSA /root/alsa-driver-1.0.17rc3/pci/hda/hda_codec.c:2334: hda_codec: model '6stack' is selected ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1196: snd_hda_codec_new() results is 0
<ends here>
When trying to apply the "position_fix" module option to values other than the default "0", I got following ouput from dmesg.
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/acore/../alsa-kernel/core/pcm_lib.c:1540: playback write error (DMA or IRQ trouble?)
This error is fatal, and implies that the IRQ isn't triggered properly. Doesn't this happen if you set position_fix=0? Still weird...
<ends here>
And in /var/log/messages, I have following messages complaining that the position buffer is invalid.
</var/log/messages>
--snip-- Jan 2 18:34:03 localhost kernel: hda-intel: Invalid position buffer, using LPIB read method instead. Jan 2 18:34:03 localhost kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
On Intel devices, we choose the 1 sample position fix while 32 samples for other controller chips. This might be a wrong assumption, but I'd like to check all other cases first.
And, this basically is no fatal error. This may lead to higher CPU load (for busy wait) but the playback should still work.
Takashi
participants (3)
-
Kan-I Jyo -
Takashi Iwai -
Tobin Davis