[alsa-devel] ASUS Phoebus (CMI8888) HDA Support

Vincent Lejeune vljn at ovi.com
Mon Aug 4 20:35:21 CEST 2014


By the way the sound volume is correct with spif output. The issue only occur with analog outputs (either speakrs or headphone)



Le Lundi 4 août 2014 20h30, Vincent Lejeune <vljn at ovi.com> a écrit :
 

>
>
>Thanks, it almost works now !
>
>
>Actually it requires the AZX_DCAPS_NO_MSI (otherwise dma doesnt work) and AZX_DCAPS_POSFIX_LPIB (otherwise sound is stuttered) and no snoop.
>There is still an issue with the sound volume : it's very low, I have to put my speakers to 100% of their power to actually hear something. Otherwise sound is ok, no more crakling as with single_cmd mode.
>
>
>Dmesg also complains about a db Mismatch, I suspect it's related to the issue. If I remove the patching ops in snd_hda_codec_build_controls the error goes away but there is no more sound and the digital output control disappear too. I dont know which patch is applied (cmedia ?).
>
>
>
>[    2.483128] snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002)
>[    2.483238] snd_hda_intel 0000:01:00.1: Handle VGA-switcheroo audio client
>[    2.483282] snd_hda_intel
 0000:01:00.1: irq 50 for MSI/MSI-X
>[    2.483454] snd_hda_intel 0000:02:00.0: enabling device (0000 -> 0002)
>[    2.483494] snd_hda_intel 0000:02:00.0: Disabling MSI
>[    2.489701] snd_hda_intel 0000:01:00.1: no codecs initialized
>[    2.511016] sound hdaudioC1D1: autoconfig: line_outs=4 (0xc/0xe/0xd/0xf/0x0) type:line
>[    2.511018] sound hdaudioC1D1:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
>[    2.511019] sound hdaudioC1D1:    hp_outs=1 (0x10/0x0/0x0/0x0/0x0)
>[    2.511020] sound hdaudioC1D1:    mono: mono_out=0x0
>[    2.511021] sound hdaudioC1D1:    dig-out=0x14/0x0
>[   
 2.511021] sound hdaudioC1D1:    inputs:
>[    2.511022] sound hdaudioC1D1:      Mic=0x12
>[    2.511023] sound hdaudioC1D1:      Line=0x15
>[    2.511024] sound hdaudioC1D1:      Aux=0x13
>[    2.523844] ALSA sound/pci/hda/hda_codec.c:2792 hda_codec: Mismatching dB step for vmaster slave (-100!=1000)
>
>
>Regards,
>Vincent
>
>
>
>
>Le Lundi 4 août 2014 13h28, Takashi Iwai <tiwai at suse.de> a écrit :
> 
>
>>
>>
>>At Sun, 3 Aug 2014 14:05:44 -0700,
>>Vincent Lejeune wrote:
>>> 
>>> Hi,
>>> 
>>> I just found this thread http://thread.gmane.org/gmane.linux.alsa.devel/116096 
>>> I'm trying to find what can make the CMI8888 not work in non single_cmd mode and it looks more and more like a DMA issue.
>>> I don't have an "iommu mode" option in my bios like Geoffrey McRae, it looks like an AMD only option, and using bigger page size/alignement constraint didnt solve the issue.
>>> However I added some code to dump the content of the rirb buffer in the update_rirb() function and I copied it
 below.
>>> 
>>> The first command seems to be correctly handled the second time it is send to the hardware. As the AZX_DCAPS_*DELAY_RIRB doesnt change anything, I'm starting to think
>>> that the corb engine may require some delay to be processed.
>>> Is there a way to spy the dma transfer request from the device point of view ? I'd like to know when the cmi8888 request a dma read from the corb buffer and when it requests a dma write to the rirb buffer
>>> to determine if it parses the corb buffer correctly or not.
>>
>>Well, if the CORB RP is updated, it essentially means that the CORB
>>has been updated.  Did you already try snoop=false option?
>>Also,  AZX_DCAPS_RIRB_PRE_DELAY might be worth to try.
>>
>>> In addition
 the first value returned is very odd : 13f68888. The pci id of the phoebus is 13f6:5011.
>>> What does the 100f0001 cmd mean ? hda-decode-verb tells me the verb is "0x0"...
>>
>>This is the codec IDs, which is often different from the PCI IDs.
>>
>>
>>thanks,
>>
>>Takashi
>>_______________________________________________
>>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