Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio

[Takashi Iwai <tiwai@suse.de>]

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