Home
last modified time | relevance | path

Searched hist:b8a3ee820f7b0802c9b90a9f3426dbda54e93d09 (Results 1 – 2 of 2) sorted by relevance

/linux/sound/soc/codecs/
H A Dmax98090.hdiff b8a3ee820f7b0802c9b90a9f3426dbda54e93d09 Wed Sep 03 14:42:48 CEST 2014 Jarkko Nikula <jarkko.nikula@linux.intel.com> ASoC: max98090: Add recovery for PLL lock failure

All MAX98090 input clocks MCLK, LRCLK and BCLK must be running and stable
before powering on the codec in slave mode. Otherwise the PLL may not lock
to LRCLK causing silence in playback and capture. How often that happens is
somewhat hardware and clock configuration specific.

Now if wanting to follow strictly this clocks must be active before
powering the codec on requirement we should have a notification from DAI
driver to codec driver when clocks are activated and take codec out of
shutdown only after that. Plus take care of possible active bypass paths.

However, when PLL unlock occurs, MAX98090 asserts the PLL Unlock Flag which
can be configured as an IRQ source. This allows to workaround around the
issue by toggling the codec power shortly in case of PLL lock failure.

In order to prevent needlessly toggling codec power in case of short PLL
unlocks at the beginning of stream this patch implements delayed activation
for PLL unlock interrupt. Then workaround is run only when the PLL doesn't
lock at all.

Power toggling workaround for PLL unlock comes originally from
Liam Girdwood <liam.r.girdwood@linux.intel.com> and delayed activation from
me.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
H A Dmax98090.cdiff b8a3ee820f7b0802c9b90a9f3426dbda54e93d09 Wed Sep 03 14:42:48 CEST 2014 Jarkko Nikula <jarkko.nikula@linux.intel.com> ASoC: max98090: Add recovery for PLL lock failure

All MAX98090 input clocks MCLK, LRCLK and BCLK must be running and stable
before powering on the codec in slave mode. Otherwise the PLL may not lock
to LRCLK causing silence in playback and capture. How often that happens is
somewhat hardware and clock configuration specific.

Now if wanting to follow strictly this clocks must be active before
powering the codec on requirement we should have a notification from DAI
driver to codec driver when clocks are activated and take codec out of
shutdown only after that. Plus take care of possible active bypass paths.

However, when PLL unlock occurs, MAX98090 asserts the PLL Unlock Flag which
can be configured as an IRQ source. This allows to workaround around the
issue by toggling the codec power shortly in case of PLL lock failure.

In order to prevent needlessly toggling codec power in case of short PLL
unlocks at the beginning of stream this patch implements delayed activation
for PLL unlock interrupt. Then workaround is run only when the PLL doesn't
lock at all.

Power toggling workaround for PLL unlock comes originally from
Liam Girdwood <liam.r.girdwood@linux.intel.com> and delayed activation from
me.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>