Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ola Lilja <ola.o.lilja@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Liam Girdwood <lrg@ti.com>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 4/5] ASoC: codecs: Add AB8500 codec-driver
Date: Wed, 30 May 2012 15:49:51 +0200	[thread overview]
Message-ID: <4FC6257F.4080905@stericsson.com> (raw)
In-Reply-To: <20120530131421.GK9947@opensource.wolfsonmicro.com>

On 05/30/2012 03:14 PM, Mark Brown wrote:

> On Thu, May 24, 2012 at 03:26:38PM +0200, Ola Lilja wrote:
> 
>> +static void show_regulator_status(struct device *dev)
>> +{
>> +	struct ab8500_codec_drvdata *drvdata = dev_get_drvdata(dev);
>> +	struct ab8500_codec_drvdata_dbg *dbg = &drvdata->dbg;
>> +
>> +	dev_dbg(dev, "%s: Regulator-status:\n", __func__);
>> +	dev_dbg(dev, "%s:     V-AUD: %s\n", __func__,
>> +		(regulator_is_enabled(dbg->vaud) > 0) ?
>> +			"On" : "Off");
>> +	dev_dbg(dev, "%s:     V-AMIC1: %s\n", __func__,
>> +		(regulator_is_enabled(dbg->vamic1) > 0) ?
>> +			"On" : "Off");
>> +	dev_dbg(dev, "%s:     V-AMIC2: %s\n", __func__,
>> +		(regulator_is_enabled(dbg->vamic2) > 0) ?
>> +			"On" : "Off");
>> +	dev_dbg(dev, "%s:     V-DMIC: %s\n", __func__,
>> +		(regulator_is_enabled(dbg->vdmic) > 0) ?
>> +			"On" : "Off");
> 
> What problems are you finding when you try to use the debug
> infrastructure in both the regulator API and DAPM to discover the state
> of the regulators?


My vision here is that in a simple way, in one place, activate all
debug-information we need in our driver, prefixed with our dev_xxx. This is very
valuable for us when debugging, especially when a customer is told to activate
debug-information that we can use to debug.
I removed the menuconfig flag on your request, and then we lost the information
for regulators and clocks when I implemented the clock/regulator-widgets. I'm
just trying to keep some aspects of what we want to have but still conforming
what you want to see on mainline.

> 
>> +	/* Clocks */
>> +	SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"),
>> +	SND_SOC_DAPM_CLOCK_SUPPLY("gpio.1"),
> 
> This looks wrong - audioclk looks reasonable but gpio.1 looks like a
> board-specific name which shouldn't be encoded into the driver.
> 
>> +	if (ucontrol->value.integer.value[0] != SID_APPLY_FIR) {
>> +		dev_err(codec->dev,
>> +			"%s: ERROR: This control supports '%s' only!\n",
>> +			__func__, enum_sid_state[SID_APPLY_FIR]);
>> +		return 0;
>> +	}
> 
> I'd expect this to return an error...


Yes.

> 
>> +	status = snd_soc_dapm_force_enable_pin(&codec->dapm,
>> +					"ANC Configure Input");
>> +	if (status < 0) {
>> +		dev_err(dev,
>> +			"%s: ERROR: Failed to enable power (status = %d)!\n",
>> +			__func__, status);
>> +		goto cleanup;
>> +	}
>> +	snd_soc_dapm_sync(&codec->dapm);
>> +
>> +	mutex_lock(&codec->mutex);
> 
> Your locking looks bad here.  Nothing ensures that something doesn't
> come along and undo the force enable.  Looking at the code this is the
> only function that fiddles with the input but there's still a race where
> one writer might exit the mutex section and disable the pin while a
> second enters the mutex section.


Will fix.

> 
>> +static int filter_control_get(struct snd_kcontrol *kcontrol,
>> +			struct snd_ctl_elem_value *ucontrol)
>> +{
>> +	struct filter_control *fc =
>> +			(struct filter_control *)kcontrol->private_value;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < fc->count; i++)
>> +		ucontrol->value.integer.value[i] = fc->value[i];
>> +
>> +	return 0;
>> +}
>> +
>> +static int filter_control_put(struct snd_kcontrol *kcontrol,
>> +		struct snd_ctl_elem_value *ucontrol)
>> +{
>> +	struct filter_control *fc =
>> +			(struct filter_control *)kcontrol->private_value;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < fc->count; i++)
>> +		fc->value[i] = ucontrol->value.integer.value[i];
> 
> These don't seem to be locked?


Will look into it.

> 
>> +int ab8500_audio_init_audioblock(struct snd_soc_codec *codec)
> 
> static.  Lots of other functions in the rest of the driver have the same
> issue.


This one should be static, yes. Cannot find any other non-static functions in
the codec-driver that is missing static.

> 
>> +static int ab8500_codec_pcm_hw_params(struct snd_pcm_substream *substream,
>> +		struct snd_pcm_hw_params *hw_params, struct snd_soc_dai *dai)
>> +{
>> +	dev_dbg(dai->codec->dev, "%s Enter.\n", __func__);
>> +
>> +	return 0;
>> +}
> 
> Remove empty functions.


OK.

> 
>> +	default:
>> +		dev_err(dai->codec->dev,
>> +			"%s: ERROR: Unsupported INV mask 0x%x\n",
>> +			__func__, fmt & SND_SOC_DAIFMT_INV_MASK);
>> +		return -EINVAL;
>> +		break;
> 
> The break is redundant.


Yes.

> 
>> +	/* Only 16 bit slot width is supported at the moment in TDM mode */
>> +	if (slot_width != 16) {
>> +		dev_err(dai->codec->dev,
>> +			"%s: ERROR: Unsupported slot_width %d.\n",
>> +			__func__, slot_width);
>> +		return -EINVAL;
>> +	}
> 
> You've got code which supports other widths...


Will look into it.

> 
>> +static struct snd_soc_codec_driver ab8500_codec_driver = {
>> +	.probe =		ab8500_codec_probe,
>> +	.read =			ab8500_codec_read_reg,
>> +	.write =		ab8500_codec_write_reg,
>> +	.reg_cache_size =	0,
> 
> no need to init things to zero or NULL in static structs.


Yes, was just for clarity. Will remove it.

> 
>> +#define PRE_PMU_POST_PMD			(SND_SOC_DAPM_PRE_PMU | \
>> +						SND_SOC_DAPM_POST_PMD)
> 
> You shouldn't define stuff like this in your driver!


This was mainly to avoid impossible situations trying to comply with the
80-char-width.

  reply	other threads:[~2012-05-30 13:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1337865998-26150-1-git-send-email-ola.o.lilja@stericsson.com>
2012-05-30 13:14 ` [PATCH 4/5] ASoC: codecs: Add AB8500 codec-driver Mark Brown
2012-05-30 13:49   ` Ola Lilja [this message]
2012-05-30 15:09     ` Mark Brown
2012-05-30 15:14       ` Ola Lilja

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=4FC6257F.4080905@stericsson.com \
    --to=ola.o.lilja@stericsson.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linus.walleij@linaro.org \
    --cc=lrg@ti.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