[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20131218115703.GL28455@sirena.org.uk>
Date: Wed, 18 Dec 2013 11:57:03 +0000
From: Mark Brown <broonie@...nel.org>
To: Nicolin Chen <Guangyu.Chen@...escale.com>
Cc: lgirdwood@...il.com, alsa-devel@...a-project.org, tiwai@...e.de,
perex@...ex.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ASoC: fsl: imx-wm8962: Grant hw_params/free()
permission to control FLL
On Wed, Dec 18, 2013 at 01:13:36PM +0800, Nicolin Chen wrote:
> On Tue, Dec 17, 2013 at 10:50:02PM +0000, Mark Brown wrote:
> > I do think refcounting from both here and the bias level changes is
> > going to be the most robust thing, that'd also avoid the need to peer
> > into the CODEC register map.
> I've tried count reference way to handle FLL enabler/disabler here before
> I sent this version. But the result shows the FLL would be never disabled
> in hw_free() because the refcount is accumulated to 2, one from hw_params()
> and the other from set_bias_level(PREPARE), which just made this patch
> meaningless to me.
Well, it gets the clocking configured early which was part of the goal I
thought to ensure smoother startup.
> So the reclocking with bypass checking seems to be the last resort I can
> figure out right here as the playback flow for 'aplay -Dhw:0 44k16bit.wav
> 48k24bit.wav' does need to reprogram the FLL during CODEC active.
That's the other bit. It should be possible for the machine driver to
disable all outputs prior to reprogramming the FLL, though this will
obviously glitch bypass paths. One way of doing it would be to have
something that does the reprogramming but only if there is actually a
change - that way the common case is unaffected.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists