At Mon, 12 May 2014 09:46:07 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, May 12, 2014 4:31 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; Pierre-Louis Bossart Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Mon, 12 May 2014 08:22:13 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, May 09, 2014 6:20 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; Pierre-Louis Bossart Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Fri, 9 May 2014 10:08:19 +0000, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi Date: Tue Apr 8 12:36:42 2014 +0300 ALSA: hda - Do not assign streams in reverse order
We'll further check the root cause. Since this patch seems only affect the stream ID. Actually Intel GPU tool only
find the stream ID is changed by this patch.
In addition, Haswell HDMI audio is not affected and works well. It seems
there is HW behavior difference between HSW and BDW.
Thanks for spotting out!
This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the
chip.
In the display HD-A controller of HSW/BDW, there are 3 sets of stream
descriptors registers which controls the DMA engines to transfer audio data over HD-A link:
set #0: 0x80 ~ 0x9c SD0CTL ~ SD0BDPU set #1: 0xa0 ~ 0xbc SD1CTL ~ SD1BDPU set #2: 0xc0 ~ 0xdc SD2CTL ~ SD2BDPU
Test shows that On HSW, DMA update on all 3 sets of registers are okay. On BDW, DMA update on set #1 and #2 are okay, but is buggy on set #0.
Since the three sets of registers have the same definition according to spec and driver behavior is also same, it seems to be a HW issue.
Maybe we'll have to use the original reverse lookup order for BDW HDMI/DP
audio.
I wonder what if you run three streams. Is the set#0 always broken, or broken only when used alone? In the former case, the fix would to mask the first slot. In the latter case, back to reverse assignment would work around it.
The set#0 is always broken, when I run single or two streams at the same time. And when running two streams, there is no difference if the audio driver choose set#0 or #1 at first.
Is it okay to introduce a flag "disabled" to struct azx_dev? If this flag is set, the azx_dev slot is masked.
You can just keep azx_dev->opened flag set at initialization time.
Takashi