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