From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
alsa-devel@alsa-project.org
Cc: tiwai@suse.de, liam.r.girdwood@linux.intel.com,
broonie@kernel.org, vinod.koul@intel.com
Subject: Re: [PATCH 3/5] ASoC: Intel: bytcr_rt5651: add MCLK support and fix quirks
Date: Mon, 18 Sep 2017 10:10:45 +0300 [thread overview]
Message-ID: <1505718645.25945.265.camel@linux.intel.com> (raw)
In-Reply-To: <20170908174356.23788-4-pierre-louis.bossart@linux.intel.com>
On Fri, 2017-09-08 at 12:43 -0500, Pierre-Louis Bossart wrote:
> Same as for other codecs, enable MCLK by default. When it is not
> present, e.g. on MinnowBoard B3 since it's not routed on the LSE
> connector, we fall back to blck-based clocking.
>
> The DMIC quirks are also fixed, there is a single DMIC input of the
> codec
> #include <linux/device.h>
> #include <linux/dmi.h>
> #include <linux/slab.h>
> +#include <asm/cpu_device_id.h>
> +#include <asm/platform_sst_audio.h>
> +#include <linux/clk.h>
Just a nit: I would rather squeeze this to somewhere above device
(alphabetical ordering)
> #include <sound/pcm.h>
> #include <sound/pcm_params.h>
> #include <sound/soc.h>
> +#define BYT_RT5651_MAP(quirk) ((quirk) & 0xff)
GENMASK(7, 0) ?
> +#define BYT_RT5651_DMIC_EN BIT(16)
> +#define BYT_RT5651_MCLK_EN BIT(17)
> +#define BYT_RT5651_MCLK_25MHZ BIT(18)
> +static void log_quirks(struct device *dev)
> +{
> + if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_DMIC_MAP)
> + dev_info(dev, "quirk DMIC_MAP enabled");
> + if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN1_MAP)
> + dev_info(dev, "quirk IN1_MAP enabled");
> + if (byt_rt5651_quirk & BYT_RT5651_DMIC_EN)
> + dev_info(dev, "quirk DMIC enabled");
> + if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN)
> + dev_info(dev, "quirk MCLK_EN enabled");
> + if (byt_rt5651_quirk & BYT_RT5651_MCLK_25MHZ)
> + dev_info(dev, "quirk MCLK_25MHZ enabled");
> +}
> +
> +#define BYT_CODEC_DAI1 "rt5651-aif1"
> +
> +static inline struct snd_soc_dai *byt_get_codec_dai(struct
> snd_soc_card *card)
> +{
> + struct snd_soc_pcm_runtime *rtd;
> +
> + list_for_each_entry(rtd, &card->rtd_list, list) {
> + if (!strncmp(rtd->codec_dai->name, BYT_CODEC_DAI1,
> + strlen(BYT_CODEC_DAI1)))
Still same comment about str_n_cmp vs. strcmp() in this case.
(strlen() also can be calculated once size_t dai1_len = strlen(...); )
> + return rtd->codec_dai;
> + }
> + return NULL;
> + if (SND_SOC_DAPM_EVENT_ON(event)) {
> + if (priv->mclk) {
Do we need this check?
I'm not sure I have read a comment why this is left as in initial
series.
> SND_SOC_CLOCK_IN);
> + if (!ret)
> + if (priv->mclk)
Ditto ?
> + clk_disable_unprepare(priv->mclk);
> + }
>
> static const struct dmi_system_id byt_rt5651_quirk_table[] = {
> + {
> + .callback = byt_rt5651_quirk_cb,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Circuitco"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Minnowboard Max
> B3 PLATFORM"),
> + },
> + .driver_data = (unsigned long *)(BYT_RT5651_DMIC_MAP
> |
Shouldn't be just (void *) [and maybe fit one line]?
> + BYT_RT5651_DMIC_EN),
>
> + if (priv->mclk) {
Same question as above.
> + /*
> + * The firmware might enable the clock at
> + * boot (this information may or may not
> + * be reflected in the enable clock register).
> + * To change the rate we must disable the clock
> + * first to cover these cases. Due to common
> + * clock framework restrictions that do not allow
> + * to disable a clock that has not been enabled,
> + * we need to enable the clock first.
> + */
> + ret = clk_prepare_enable(priv->mclk);
> + if (!ret)
> + clk_disable_unprepare(priv->mclk);
> +
> + if (byt_rt5651_quirk & BYT_RT5651_MCLK_25MHZ)
> + ret = clk_set_rate(priv->mclk, 25000000);
> + else
> + ret = clk_set_rate(priv->mclk, 19200000);
> +
> + if (ret)
> + dev_err(card->dev, "unable to set MCLK
> rate\n");
> + }
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-09-18 7:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 17:43 [PATCH 0/5] BYT/CHT-Realtek remaining fixes Pierre-Louis Bossart
2017-09-08 17:43 ` [PATCH 1/5] ASoC: Intel: boards: use devm_clk_get() unconditionally Pierre-Louis Bossart
2017-09-19 13:46 ` Applied "ASoC: Intel: boards: use devm_clk_get() unconditionally" to the asoc tree Mark Brown
2017-09-08 17:43 ` [PATCH 2/5] ASoC: Intel: bytcr-rt5651: fix capture routes Pierre-Louis Bossart
2017-09-08 17:43 ` [PATCH 3/5] ASoC: Intel: bytcr_rt5651: add MCLK support and fix quirks Pierre-Louis Bossart
2017-09-18 7:10 ` Andy Shevchenko [this message]
2017-09-18 17:20 ` Pierre-Louis Bossart
2017-09-08 17:43 ` [PATCH 4/5] ASoC: Intel: bytcr_rt5651: filter codec name Pierre-Louis Bossart
2017-09-18 7:13 ` Andy Shevchenko
2017-09-18 17:24 ` Pierre-Louis Bossart
2017-09-08 17:43 ` [PATCH 5/5] ASoC: Intel: bytcr_rt5640: simplify MCLK quirk tests Pierre-Louis Bossart
2017-09-18 3:34 ` [PATCH 0/5] BYT/CHT-Realtek remaining fixes Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1505718645.25945.265.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.de \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).