[alsa-devel] [PATCH v2] ALSA: hda - restore BCLK M/N values when resuming HSW/BDW display controller

[Lin, Mengdong]

Hi Takashi,

I submitted patches, using the private API to query CDCLK from i915 and restore BCLK. Could you have a review?
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-July/078489.html

The 1st patch by Jani is actually for i915 to provide the interface for audio driver to query CDCLK. 

Thanks
Mengdong

> -----Original Message-----
> From: alsa-devel-bounces at alsa-project.org
> [mailto:alsa-devel-bounces at alsa-project.org] On Behalf Of Lin, Mengdong
> Sent: Wednesday, July 02, 2014 6:58 PM
> To: Takashi Iwai
> Cc: Nikula, Jani; Yang, Libin; alsa-devel at alsa-project.org; Li, Jocelyn
> Subject: Re: [alsa-devel] [PATCH v2] ALSA: hda - restore BCLK M/N values
> when resuming HSW/BDW display controller
> 
> Add Jani from Gfx driver team and audio team.
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Friday, June 27, 2014 6:28 PM
> >
> > At Fri, 27 Jun 2014 06:38:47 +0000,
> > Lin, Mengdong wrote:
> > >
> > > Hi Takashi,
> > >
> > > Sorry. This patch cannot handle the following case:
> > > If only embedded DP is connected on boot, the gfx driver will turn
> > > off
> > the display power well on boot case before the audio driver probes and
> > request this power.
> > > So the M/V values programmed by BIOS in EM4/5 registers will be lost
> > > at
> > the very beginning. And so the audio driver will save invalid M/N
> > values on suspend and restore these invalid values on resume.
> > > One phenomenon is: if HDMI or DP monitor is connected after boot,
> > audio playback rate is ~20% faster than normal.
> > > And I guess it's the patch cannot fix the Haswell issue
> > > https://bugzilla.kernel.org/show_bug.cgi?id=74861
> > >
> > > There are two possible solutions:
> > > (1) Follows Windows model: Windows, gfx driver notifies BIOS on LPSP
> > (when only eDP is connected) exit and BIOS reprograms those EM4/5
> > registers.
> > >    There is no such implementation in Linux gfx driver now. We need
> > time to check the effort.
> > >
> > > (2) Gfx driver notify audio driver on exiting LPSP and CDCLK value
> > > (by
> > reading GPU registers), so audio driver can reprograms EM4/5 registers.
> > >   The open source interface between audio/gfx driver is still not
> ready.
> > Would an private API to get CDCLK from gfx driver will be a possible
> > workaround atm?
> > >
> > > Could you share your opinion on this issue?
> >
> > To me, the former sounds like an easier solution.  In the latter case,
> > it can be still an issue of module loading order.
> 
> Can we introduce a private i915 interface for the audio driver to get the
> CDCLK as a quick fix?  Then the audio driver can reprogram the EM4/5
> M/N values as per the CDCLK.
> 
> The interface can be like 'int i915_get_cdclk_freq(void)' and the audio
> driver will use symbol_request() to get this private API and avoid the issue
> of module loading order.
> We can put the relevant code in sound/pci/hda/ hda_i915.c
> 
> For Broadwell Jani has implemented a notification to BIOS, so BIOS can
> reprogram the EM4/5 value after restoring the power.
> http://patchwork.freedesktop.org/patch/28866/
> http://patchwork.freedesktop.org/patch/28868/
> 
> But for Haswell, BIOS does not support the above notification and provide
> another heavy-weight notification which will enable/disable the HD-A
> controller at runtime and so need OS to re-enumerate the device stack.
> That causes system hang. And test on Haswell shows that reprogramming
> the EM4/5 as per the CDCLK is also enough to give good BCLK and audio
> rate. So we hope to avoid further dependency on the black-box BIOS.
> 
> Libin is working on the generic interface between audio and gfx now and
> we can clean up code in the future.
> But before the interface is ready, a private API to query CDCLK seems to be
> a quick and reliable fix for Haswell and Broadwell.
> 
> Thanks
> Mengdong
> 
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel