On 06/13/2012 04:14 PM, Takashi Iwai wrote:
At Wed, 13 Jun 2012 16:05:12 +0800, Wang Xingchao wrote:
Hi Takashi,
2012/6/13 Takashi Iwaitiwai@suse.de:
At Wed, 13 Jun 2012 10:23:51 +0800, Wang Xingchao wrote:
this patch add proper id for Haswell HDA Controller.
Signed-off-by: Wang Xingchaoxingchao.wang@intel.com
Oh, now ID number decreases to 0xxx? :)
Id 0c0c is readout from "lspci" like below: [amanda@amanda-fedora-16 ~]$ lspci
00:03.0 Audio device: Intel Corporation Device 0c0c (rev 01)
00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 01)
So, this machine has two controllers, one for Haswell and another for Lynx Point? I guess the former is dedicated to HDMI/DP?
Yeah, that's true, it has TWO controllers.
While we are on this: could you verify whether position_fix=4 (combo) options works for Haswell? In this mode, LPIB is used for playback positioning while POS buffer is used for capture.
Seth (Cc'ed) figured out that this mode works better than the default (usually POS buf both for playback and capture) on the recent Intel controller chips, so I guess it'd be applied to Haswell, too.
I'm afraid no better result to provide now. This patch is to fix codec probe error at initialization. you can get details at this bug page: Bug 829405 - [Intel 6.4 Bug] Shark Bay: sound related warnings/errors in dmesg https://bugzilla.redhat.com/show_bug.cgi?id=829405
The page is unaccessible.
Oh, seems this bug needs special access right, sorry for trouble.
I wonder, though, how your patch fixes the "probing" problem. There is already an entry like: /* Generic Intel */ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID), .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO<< 8, .class_mask = 0xffffff, .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_BUFSIZE },
thus basically all Intel controllers are probed. Your patch will add a flag AZX_DCAPS_SCH_SNOOP, which shouldn't influence on the probing but only about streaming results.
So let me give some brief description here. As you said in "Documentation/sound/alsa/HD-Audio.txt", the error message like:
hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 hda-intel: No response from codec, disabling MSI: last cmd=0x000f0000 hda-intel: Codec #0 probe error; disabling it... hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0001
So an empty codec will be created. But i could gather useful information from /proc/asound/card0/codec*.
The error message means it's unable to probe the codec at HASWELL HDA Controller in CORB/RIRB mode, after switching to single-command mode, seems the codec could be setup[1]. That's why i could see codec infomation showing it's HDMI[2]. Please find details in below two part log:
[1] switch to single command sending/receiving mode
[ 16.775889] ALSA sound/pci/hda/hda_intel.c:827 azx_get_response timeout, switching to polling mod e: last cmd=0x000f0000 [ 17.776531] ALSA sound/pci/hda/hda_intel.c:835 No response from codec, disabling MSI: last cmd=0x 000f0000 [ 18.777163] ALSA sound/pci/hda/hda_intel.c:1556 Codec #0 probe error; disabling it... [ 19.781801] ALSA sound/pci/hda/hda_intel.c:866 hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0001
[2] alsa-info output with "--no-upload" from one sharkbay machine. i could see somd "HDMI" words in Pin fields.
Node 0x07 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI
The Error message disappear if configure snd-hda-intel option: single-cmd=1.
Append below lines to /etc/modprobe.d/alsa-base.conf: options snd-hda-intel single_cmd=1 options snd-hda-intel enable_msi=0
Then there's no "probe error" for codec#0 at card0. Here's the dmesg output:
[ 18.529908] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [ 18.529968] snd_hda_intel 0000:00:1b.0: setting latency timer to 64 [ 18.588384] hda_codec: ALC889: BIOS auto-probing. [ 18.588388] hda_codec: ALC889: SKU not ready 0x598301f0
The patch also remove the probe error.
Btw, i am not sure whether it's a BUG. After probe_codec() with error returned and switch to single-command mode, the codec has correct response then, should we probe_codec() again to get correct information instead of creating one empty codec?
thanks --xingchao
The other patch about HDMI device id could get correct device list by "aplay -l", but there's still some problem to detect HDMI monitor, so i cannot test audio on Haswell HDA now. But once the HDMI monitor detection works, i will provide the test result of Seth's patch.
Another patch is irrelevant with the position-buffer usage, so it's safe to apply.
I think if someone has Haswell HDA plus normal ALC* codec, it could help much to test the patch easily.
So Takashi you could reject this patch until i send out the updated one with test result then.
OK, I'll wait for a while.
thanks,
Takashi
thanks --xingchao
thanks,
Takashi
sound/pci/hda/hda_intel.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 2b6392b..f530c40 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -151,6 +151,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6}," "{Intel, CPT}," "{Intel, PPT}," "{Intel, LPT},"
"{Intel, HPT}," "{Intel, PBG}," "{Intel, SCH}," "{ATI, SB450},"@@ -3253,6 +3254,10 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { { PCI_DEVICE(0x8086, 0x8c20), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE},
/* Haswell */{ PCI_DEVICE(0x8086, 0x0c0c),.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |AZX_DCAPS_BUFSIZE}, /* SCH */ { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP |-- 1.7.9.5
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel