[alsa-devel] [PATCH] ALSA: hda - Add DeviceID for Haswell HDA

Takashi Iwai tiwai at suse.de
Wed Jun 13 10:43:26 CEST 2012


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 Iwai<tiwai at 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 at intel.com>
> >>> Oh, now ID number decreases to 0xxx? :)
> >> Id 0c0c is readout from "lspci" like below:
> >> [amanda at 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 at alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 


More information about the Alsa-devel mailing list