From: Arnaud Pouliquen <arnaud.pouliquen@st.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com
Subject: Re: [PATCH 7/7] ASoc: Codec: add sti platform codec
Date: Mon, 20 Apr 2015 11:13:27 +0200 [thread overview]
Message-ID: <5534C337.9080009@st.com> (raw)
In-Reply-To: <20150418130914.GT26185@sirena.org.uk>
On 04/18/2015 03:09 PM, Mark Brown wrote:
> On Tue, Apr 14, 2015 at 03:35:31PM +0200, Arnaud Pouliquen wrote:
>
>> +struct codec_regfield {
>> + struct regmap_field *field;
>> + const struct reg_field regfield;
>> +};
> The fact that you're defining this structure should be settinng off
> alarm bells. You shouldn't be storing the per device dynamically
> allocated regmap_feild in global static data, you should be storing it
> in the driver data for your device.
Not clear for me.
Register definitions are already part of the driver data structure
(stih407_data or stih416_data) .
Your point is that i should delete this structure?
And then use separate regmap_field tables (dynamically allocated) for
for register map
and declare registers struct like this
static struct reg_field sti_sas_dac_stih416[STIH416_DAC_MAX_RF] = {
/*STIH416_DAC_MODE*/
{REG_FIELD(STIH416_AUDIO_DAC_CTRL, 1, 2)},
...
}
>
>> +/* specify ops depends on codec version */
>> +struct sti_codec_ops {
>> + int (*dai_dac_probe)(struct snd_soc_dai *dai);
>> + int (*mute)(struct snd_soc_dai *dai, int mute);
>> + int (*startup)(struct snd_soc_dai *);
>> + void (*shutdown)(struct snd_soc_dai *);
>> +};
> Don't define an abstraction layer within your driver wrapping the core
> abstraction layer, this is just making things harder to follow. Just
> register different ops with the core if you need to.
>
>> + /* init DAC configuration */
>> + if (data->chipid == CHIPID_STIH407) {
>> + /* init configuration */
>> + ret = regmap_field_write(
>> + dac->regfield[STIH407_DAC_STANDBY].field, 1);
>> + ret |= regmap_field_write(
>> + dac->regfield[STIH407_DAC_STANDBY_ANA].field, 1);
>> + ret |= regmap_field_write(
>> + dac->regfield[STIH407_DAC_SOFTMUTE].field, 1);
> Don't or multiple return values together, check and return errors
> properly. That way the error value isn't corrupted if you get different
> errors.
>
>> + } else if (data->chipid == CHIPID_STIH416) {
> Use switch statements to select among multiple values.
>
>> + dac->rst = devm_reset_control_get(codec->dev, "dac_rst");
>> + if (IS_ERR(dac->rst)) {
>> + dev_err(dai->codec->dev,
>> + "%s: ERROR: DAC reset not declared in DT (%d)!\n",
>> + __func__, (int)dac->rst);
> That error message might be wrong, it could be some other error.
>
>> + return -EFAULT;
> Don't ignore the error that was returned, use PTR_ERR() - this is broken
> for probe deferral.
>
>> +int stih407_sas_dac_startup(struct snd_soc_dai *dai)
>> +{
>> + struct snd_soc_codec *codec = dai->codec;
>> + struct sti_sas_codec_data *drvdata = dev_get_drvdata(codec->dev);
>> + struct sti_dac_audio *dac = &drvdata->dac;
>> + int ret;
>> +
>> + /* mute */
>> + ret = regmap_field_write(
>> + dac->regfield[STIH407_DAC_SOFTMUTE].field, 1);
>> +
>> + /* Enable analog */
>> + ret |= regmap_field_write(
>> + dac->regfield[STIH407_DAC_STANDBY_ANA].field, 0);
>> +
>> + /* Disable standby */
>> + ret |= regmap_field_write(
>> + dac->regfield[STIH407_DAC_STANDBY].field, 0);
> This looks like at least standby and analogue should be moved to DAPM,
> I'm not clear why the mute is being controlled here...
>
>> +static int sti_sas_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params,
>> + struct snd_soc_dai *dai)
>> +{
>> + struct snd_soc_codec *codec = dai->codec;
>> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
>> + int ret, div;
>> +
>> + div = sti_sas_dai_clk_div[dai->id];
>> + ret = snd_soc_dai_set_clkdiv(cpu_dai, SND_SOC_CLOCK_OUT, div);
>> + if (ret)
> set_clkdiv() is an external API, you shouldn't be calling it within the
> driver - probably you should just not implement it and inline the
> functionality here.
how to do it properly?
My point is that cpu codecs have a constraint on MCLK_FS division.
So i need to provide it to the CPU_DAI that generates MCLK.
I checked simple driver
priv->mclk_fs exists but is only used to set codec dai not CPU dai...
should i add call in simple card?
>> +static int sti_sas_codec_suspend(struct snd_soc_codec *codec)
>> +{
>> + /* Nothing done but need to be declared for PM management*/
>> + return 0;
>> +}
> Remove empty functions, the comment is not accurate.
>
>> + /* Allocate device structure */
>> + drvdata = devm_kzalloc(&pdev->dev, sizeof(struct sti_sas_codec_data),
>> + GFP_KERNEL);
>> +
>> + if (!drvdata) {
>> + dev_err(&pdev->dev, "Failed to allocate device structure");
> The memory allocators are already very noisy if they fail.
next prev parent reply other threads:[~2015-04-20 9:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-14 13:35 [PATCH 0/7] asoc: Add audio for sti platforms Arnaud Pouliquen
2015-04-14 13:35 ` [PATCH 1/7] ASoC: sti: add binding for ASoc driver Arnaud Pouliquen
2015-04-18 13:12 ` Mark Brown
2015-04-14 13:35 ` [PATCH 2/7] Asoc: sti: add uniperipheral header file Arnaud Pouliquen
2015-07-10 18:08 ` Applied "ASoC: sti: Add uniperipheral header file" to the asoc tree Mark Brown
2015-04-14 13:35 ` [PATCH 3/7] Asoc: sti: add CPU DAI driver for playback Arnaud Pouliquen
2015-04-24 18:15 ` Mark Brown
2015-04-27 13:58 ` Arnaud Pouliquen
2015-04-27 19:46 ` Mark Brown
2015-04-14 13:35 ` [PATCH 4/7] Asoc: sti: add CPU DAI driver for capture Arnaud Pouliquen
2015-04-24 18:20 ` Mark Brown
2015-04-27 14:53 ` Arnaud Pouliquen
2015-04-27 20:00 ` Mark Brown
2015-04-14 13:35 ` [PATCH 5/7] Asoc: sti: Add platform driver Arnaud Pouliquen
2015-04-14 13:35 ` [PATCH 6/7] ASoc: Add ability to build sti drivers Arnaud Pouliquen
2015-04-14 13:35 ` [PATCH 7/7] ASoc: Codec: add sti platform codec Arnaud Pouliquen
2015-04-18 13:09 ` Mark Brown
2015-04-20 9:13 ` Arnaud Pouliquen [this message]
2015-04-20 20:33 ` Mark Brown
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=5534C337.9080009@st.com \
--to=arnaud.pouliquen@st.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.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