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

[Vincent Lejeune]

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
>
>
>