[PATCH] ASoC: fsl_asrc: Set ASR76K and ASR56K based on processing clock
The processing clock is different for platforms, so it is better to set ASR76K and ASR56K based on processing clock, rather than hard coding the value for them.
Signed-off-by: Shengjiu Wang shengjiu.wang@nxp.com Signed-off-by: Mihai Serban mihai.serban@nxp.com --- sound/soc/fsl/fsl_asrc.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 067a54ab554f..ca926915068f 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -858,6 +858,8 @@ static const struct regmap_config fsl_asrc_regmap_config = { */ static int fsl_asrc_init(struct fsl_asrc *asrc) { + unsigned long ipg_rate; + /* Halt ASRC internal FP when input FIFO needs data for pair A, B, C */ regmap_write(asrc->regmap, REG_ASRCTR, ASRCTR_ASRCEN);
@@ -875,11 +877,14 @@ static int fsl_asrc_init(struct fsl_asrc *asrc) regmap_update_bits(asrc->regmap, REG_ASRTFR1, ASRTFR1_TF_BASE_MASK, ASRTFR1_TF_BASE(0xfc));
- /* Set the processing clock for 76KHz to 133M */ - regmap_write(asrc->regmap, REG_ASR76K, 0x06D6); - - /* Set the processing clock for 56KHz to 133M */ - return regmap_write(asrc->regmap, REG_ASR56K, 0x0947); + /* + * Set the period of the 76KHz and 56KHz sampling clocks based on + * the ASRC processing clock. + * On iMX6, ipg_clk = 133MHz, REG_ASR76K = 0x06D6, REG_ASR56K = 0x0947 + */ + ipg_rate = clk_get_rate(asrc->ipg_clk); + regmap_write(asrc->regmap, REG_ASR76K, ipg_rate / 76000); + return regmap_write(asrc->regmap, REG_ASR56K, ipg_rate / 56000); }
/**
On Tue, 12 May 2020 18:22:59 +0800, Shengjiu Wang wrote:
The processing clock is different for platforms, so it is better to set ASR76K and ASR56K based on processing clock, rather than hard coding the value for them.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/1] ASoC: fsl_asrc: Set ASR76K and ASR56K based on processing clock commit: f8953043e6e24f9425249464605a541d00950709
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (2)
-
Mark Brown
-
Shengjiu Wang