From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio Date: Mon, 12 May 2014 11:51:32 +0200 Message-ID: References: <1399485804-75028-1-git-send-email-libin.yang@intel.com> <96A12704CE18D347B625EE2D4A099D195232A6@SHSMSX103.ccr.corp.intel.com> <96A12704CE18D347B625EE2D4A099D19523313@SHSMSX103.ccr.corp.intel.com> <96A12704CE18D347B625EE2D4A099D1952333A@SHSMSX103.ccr.corp.intel.com> <96A12704CE18D347B625EE2D4A099D195233B1@SHSMSX103.ccr.corp.intel.com> <536BAB70.3010905@canonical.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 13ADD26162E for ; Mon, 12 May 2014 11:51:33 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Lin, Mengdong" Cc: "Yang, Libin" , "anssi.hannula@iki.fi" , "alsa-devel@alsa-project.org" , Pierre-Louis Bossart , David Henningsson List-Id: alsa-devel@alsa-project.org 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 > > > > > 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