Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.

  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