[alsa-devel] [PATCH v2] ASoC: bf5xx-ssm2602: Setup sysclock in init callback
The sysclock is fixed, so just set it up once in the init callback instead of setting it repeatably in the hw_params callback.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de --- Since v1: * Fix duplicate use of bf5xx_ssm2602_init function name. Sorry, I amended the wrong commit before sending out v1...
--- sound/soc/blackfin/bf5xx-ssm2602.c | 37 ++++-------------------------------- 1 file changed, 4 insertions(+), 33 deletions(-)
diff --git a/sound/soc/blackfin/bf5xx-ssm2602.c b/sound/soc/blackfin/bf5xx-ssm2602.c index b39ad35..7dbeef1 100644 --- a/sound/soc/blackfin/bf5xx-ssm2602.c +++ b/sound/soc/blackfin/bf5xx-ssm2602.c @@ -44,16 +44,8 @@
static struct snd_soc_card bf5xx_ssm2602;
-static int bf5xx_ssm2602_hw_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params) +static int bf5xx_ssm2602_dai_init(struct snd_soc_pcm_runtime *rtd) { - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct snd_soc_dai *codec_dai = rtd->codec_dai; - unsigned int clk = 0; - int ret = 0; - - pr_debug("%s rate %d format %x\n", __func__, params_rate(params), - params_format(params)); /* * If you are using a crystal source which frequency is not 12MHz * then modify the below case statement with frequency of the crystal. @@ -61,31 +53,10 @@ static int bf5xx_ssm2602_hw_params(struct snd_pcm_substream *substream, * If you are using the SPORT to generate clocking then this is * where to do it. */ - - switch (params_rate(params)) { - case 8000: - case 16000: - case 48000: - case 96000: - case 11025: - case 22050: - case 44100: - clk = 12000000; - break; - } - - ret = snd_soc_dai_set_sysclk(codec_dai, SSM2602_SYSCLK, clk, + return snd_soc_dai_set_sysclk(rtd->codec_dai, SSM2602_SYSCLK, 12000000, SND_SOC_CLOCK_IN); - if (ret < 0) - return ret; - - return 0; }
-static struct snd_soc_ops bf5xx_ssm2602_ops = { - .hw_params = bf5xx_ssm2602_hw_params, -}; - /* CODEC is master for BCLK and LRC in this configuration. */ #define BF5XX_SSM2602_DAIFMT (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | \ SND_SOC_DAIFMT_CBM_CFM) @@ -98,7 +69,7 @@ static struct snd_soc_dai_link bf5xx_ssm2602_dai[] = { .codec_dai_name = "ssm2602-hifi", .platform_name = "bfin-i2s-pcm-audio", .codec_name = "ssm2602.0-001b", - .ops = &bf5xx_ssm2602_ops, + .init = bf5xx_ssm2602_dai_init, .dai_fmt = BF5XX_SSM2602_DAIFMT, }, { @@ -108,7 +79,7 @@ static struct snd_soc_dai_link bf5xx_ssm2602_dai[] = { .codec_dai_name = "ssm2602-hifi", .platform_name = "bfin-i2s-pcm-audio", .codec_name = "ssm2602.0-001b", - .ops = &bf5xx_ssm2602_ops, + .init = bf5xx_ssm2602_dai_init, .dai_fmt = BF5XX_SSM2602_DAIFMT, }, };
On Wed, Apr 25, 2012 at 11:34:54AM +0200, Lars-Peter Clausen wrote:
The sysclock is fixed, so just set it up once in the init callback instead of setting it repeatably in the hw_params callback.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de
Applied, thanks. I had to do a bit of fixup to apply for 3.5 as it depends on your previous 3.4 only patch but the conflicts are trivial so it should all work out fine. I'll merge things up when the DAI format patch has propagated into an -rc.
This feels like it should be a framework feature, though we might want to punt on that for a while in the hope that we'll be able to start using the clock framework for more and more of this stuff.
participants (2)
-
Lars-Peter Clausen
-
Mark Brown