[alsa-devel] [PATCH] ALSA: hda - Add DeviceID for Haswell HDA
this patch add proper id for Haswell HDA Controller.
Signed-off-by: Wang Xingchao xingchao.wang@intel.com --- 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 |
0x80862807 is HDMI id for Haswell HDA.
Signed-off-by: Wang Xingchao xingchao.wang@intel.com --- sound/pci/hda/patch_hdmi.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index ad319d4..1e94086 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1911,6 +1911,7 @@ static const struct hda_codec_preset snd_hda_preset_hdmi[] = { { .id = 0x80862804, .name = "IbexPeak HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862805, .name = "CougarPoint HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862806, .name = "PantherPoint HDMI", .patch = patch_generic_hdmi }, +{ .id = 0x80862807, .name = "Haswell HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862880, .name = "CedarTrail HDMI", .patch = patch_generic_hdmi }, { .id = 0x808629fb, .name = "Crestline HDMI", .patch = patch_generic_hdmi }, {} /* terminator */ @@ -1958,6 +1959,7 @@ MODULE_ALIAS("snd-hda-codec-id:80862803"); MODULE_ALIAS("snd-hda-codec-id:80862804"); MODULE_ALIAS("snd-hda-codec-id:80862805"); MODULE_ALIAS("snd-hda-codec-id:80862806"); +MODULE_ALIAS("snd-hda-codec-id:80862807"); MODULE_ALIAS("snd-hda-codec-id:80862880"); MODULE_ALIAS("snd-hda-codec-id:808629fb");
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 Xingchao xingchao.wang@intel.com
Oh, now ID number decreases to 0xxx? :)
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.
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},-- 1.7.9.5
Hi Takashi,
2012/6/13 Takashi Iwai tiwai@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 Xingchao xingchao.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)
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 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.
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.
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
At Wed, 13 Jun 2012 16:05:12 +0800, Wang Xingchao wrote:
Hi Takashi,
2012/6/13 Takashi Iwai tiwai@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 Xingchao xingchao.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?
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.
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.
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
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
At Wed, 13 Jun 2012 16:31:26 +0800, Wang Xingchao wrote:
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
OK, that explains. It's about the coherency in CORB/RIRB buffers. This could be avoided by snoop=0 option, too.
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?
Yes, it's a bug. The chipset requires some proper snooping setup, or requires the non-cached pages for non-snooping behavior. The single-command mode doesn't require CORB/RIRB, thus it still works no matter which snooping mode is used. But it means that you have no way for unsolicited events, of course.
Takashi
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
Date 13.6.2012 08:46, Takashi Iwai wrote:
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 Xingchao xingchao.wang@intel.com
Oh, now ID number decreases to 0xxx? :)
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.
The combo works OK for the Haswell. I think that the patch should be applied with the HDMI ID patch "[PATCH] ALSA: hda - add Haswell HDMI pci id".
Acked-by: Jaroslav Kysela perex@perex.cz
But it seems that the HDA bridge (8086:0c0c) with the HDMI codecs is detected as first in the PCI probe in this system, which is not ideal. So the card0 is HDMI only and card1 is analog:
!Soundcards recognised by ALSA !!-----------------------------
0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc2820000 irq 11 1 [PCH_1 ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc2824000 irq 11
!!PCI Soundcards installed in the system !!--------------------------------------
00:03.0 Audio device: Intel Corporation Device 0c0c (rev 01) 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 01)
!!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
Jaroslav
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},-- 1.7.9.5
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
2012/7/14 Jaroslav Kysela perex@perex.cz:
Date 13.6.2012 08:46, Takashi Iwai wrote:
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 Xingchao xingchao.wang@intel.com
Oh, now ID number decreases to 0xxx? :)
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.
The combo works OK for the Haswell. I think that the patch should be applied with the HDMI ID patch "[PATCH] ALSA: hda - add Haswell HDMI pci id".
Acked-by: Jaroslav Kysela perex@perex.cz
But it seems that the HDA bridge (8086:0c0c) with the HDMI codecs is detected as first in the PCI probe in this system, which is not ideal. So the card0 is HDMI only and card1 is analog:
that's right. In the board named Sharkbay there're two HDA controllers, one is Lynxpoint HDA with ALC* codec and the other one is Haswell HDA which only connected with HDMI audio. There's also drm patches to enable HDMI audio on haswell, i will send them out after some cleanup.
also please wait a moment before apply this patch, it's not the final right version after some work on HDMI audio enabling. At least the driver type is "SCH" not "PCH". i will resend the patch in second version.
Before that i will also verify whether Haswell could work well with test Seth's patch.
thanks --xingchao
On 07/13/2012 07:48 PM, Jaroslav Kysela wrote:
!!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
While this wouldn't hurt, I don't see much gain from it either. Are there really that many applications that hard-code "plughw:0", or what is the main reason that you want to switch the order of these two?
At Mon, 16 Jul 2012 10:20:37 +0200, David Henningsson wrote:
On 07/13/2012 07:48 PM, Jaroslav Kysela wrote:
!!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
While this wouldn't hurt, I don't see much gain from it either. Are there really that many applications that hard-code "plughw:0", or what is the main reason that you want to switch the order of these two?
I guess it's about the system without PA or such. alsa-lib takes the index 0 for the system-default card unless specified by user. And user wants the analog I/O normally as the primary I/O.
Takashi
Date 16.7.2012 10:42, Takashi Iwai wrote:
At Mon, 16 Jul 2012 10:20:37 +0200, David Henningsson wrote:
On 07/13/2012 07:48 PM, Jaroslav Kysela wrote:
!!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
While this wouldn't hurt, I don't see much gain from it either. Are there really that many applications that hard-code "plughw:0", or what is the main reason that you want to switch the order of these two?
I guess it's about the system without PA or such. alsa-lib takes the index 0 for the system-default card unless specified by user. And user wants the analog I/O normally as the primary I/O.
Exactly.
Jaroslav
At Fri, 13 Jul 2012 19:48:22 +0200, Jaroslav Kysela wrote:
Date 13.6.2012 08:46, Takashi Iwai wrote:
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 Xingchao xingchao.wang@intel.com
Oh, now ID number decreases to 0xxx? :)
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.
The combo works OK for the Haswell. I think that the patch should be applied with the HDMI ID patch "[PATCH] ALSA: hda - add Haswell HDMI pci id".
Acked-by: Jaroslav Kysela perex@perex.cz
But it seems that the HDA bridge (8086:0c0c) with the HDMI codecs is detected as first in the PCI probe in this system, which is not ideal. So the card0 is HDMI only and card1 is analog:
!Soundcards recognised by ALSA !!-----------------------------
0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc2820000 irq 11 1 [PCH_1 ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc2824000 irq 11
!!PCI Soundcards installed in the system !!--------------------------------------
00:03.0 Audio device: Intel Corporation Device 0c0c (rev 01) 00:1b.0 Audio device: Intel Corporation Device 8c20 (rev 01)
!!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
Having index=0 for analog would be nice in general, but I'm afraid that it isn't always safe in the case of HD-audio (depending on the implementation, though, of course):
- BIOS may disable the analog PCI part, e.g. if a device has only HDMI/DP, or vice versa.
- There are already devices showing the same problem, e.g. AMD on-board with AMD D-GPU, and users may have already added index option for such.
IMO, we should provide a mechanism to advertise the preferred configuration from the driver side without fiddling the index. For example, exposing an info bit that this is digital-I/O only card, and let alsa-lib choose another one as default (unless explicitly specified).
thanks,
Takashi
Jaroslavthanks,
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},-- 1.7.9.5
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
Date 16.7.2012 10:40, Takashi Iwai wrote:
At Fri, 13 Jul 2012 19:48:22 +0200, Jaroslav Kysela wrote:
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
Having index=0 for analog would be nice in general, but I'm afraid that it isn't always safe in the case of HD-audio (depending on the implementation, though, of course):
BIOS may disable the analog PCI part, e.g. if a device has only HDMI/DP, or vice versa.
There are already devices showing the same problem, e.g. AMD on-board with AMD D-GPU, and users may have already added index option for such.
IMO, we should provide a mechanism to advertise the preferred configuration from the driver side without fiddling the index. For example, exposing an info bit that this is digital-I/O only card, and let alsa-lib choose another one as default (unless explicitly specified).
It's not a bad idea, but it would be good to have also "standard" plughw:0 and hw:0 devices available in the system.
Do you think that the PCI ID / PCI subsystem ID check is not sufficient to determine the hw type before the codec probe?
Jaroslav
At Mon, 16 Jul 2012 10:53:15 +0200, Jaroslav Kysela wrote:
Date 16.7.2012 10:40, Takashi Iwai wrote:
At Fri, 13 Jul 2012 19:48:22 +0200, Jaroslav Kysela wrote:
00:03.0 0403: 8086:0c0c (rev 01) Subsystem: 8086:2010 -- 00:1b.0 0403: 8086:8c20 (rev 01) Subsystem: 8086:7270
Perhaps, we may add also some code to penalize the HDMI only HDA bridges and allocate these cards on indexes 1+ by default (implement AZX_DCAPS_INDEX1) . Comments? I'll prepare a patch upon an agreement.
Having index=0 for analog would be nice in general, but I'm afraid that it isn't always safe in the case of HD-audio (depending on the implementation, though, of course):
BIOS may disable the analog PCI part, e.g. if a device has only HDMI/DP, or vice versa.
There are already devices showing the same problem, e.g. AMD on-board with AMD D-GPU, and users may have already added index option for such.
IMO, we should provide a mechanism to advertise the preferred configuration from the driver side without fiddling the index. For example, exposing an info bit that this is digital-I/O only card, and let alsa-lib choose another one as default (unless explicitly specified).
It's not a bad idea, but it would be good to have also "standard" plughw:0 and hw:0 devices available in the system.
You can omit ":0" part. Then alsa-lib should choose the right device.
Do you think that the PCI ID / PCI subsystem ID check is not sufficient to determine the hw type before the codec probe?
Not really, because the controller ID doesn't always tell you whether it's analog or digital.
Also, as mentioned, BIOS may enable/disable the PCI entries as it wishes, thus you may get a system suddenly without index=0 in the end if you forcibly set index=1 to HDMI/DP controller.
Takashi
At Fri, 13 Jul 2012 19:48:22 +0200, Jaroslav Kysela wrote:
Date 13.6.2012 08:46, Takashi Iwai wrote:
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 Xingchao xingchao.wang@intel.com
Oh, now ID number decreases to 0xxx? :)
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.
The combo works OK for the Haswell. I think that the patch should be applied with the HDMI ID patch "[PATCH] ALSA: hda - add Haswell HDMI pci id".
Acked-by: Jaroslav Kysela perex@perex.cz
OK, applied patches with the combo fix now. Thanks!
Takashi
participants (5)
-
David Henningsson -
Jaroslav Kysela -
Takashi Iwai -
Wang Xingchao -
Wang Xingchao