Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: RongJun Ying <rjying@gmail.com>
Cc: alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	workgroup.linux@csr.com, Rongjun Ying <rongjun.ying@csr.com>
Subject: Re: [PATCH v4-resend 1/7] ASoC: sirf: Add SiRF internal audio codec driver
Date: Thu, 27 Feb 2014 14:33:39 +0900	[thread overview]
Message-ID: <20140227053339.GU9383@sirena.org.uk> (raw)
In-Reply-To: <1393399342-31177-2-git-send-email-rongjun.ying@csr.com>


[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]

On Wed, Feb 26, 2014 at 03:22:16PM +0800, RongJun Ying wrote:

Overall looks fairly good, a few issues below but they're quite small.

> +static struct sirf_audio_codec_reg_bits sirf_audio_codec_reg_bits_prima2 = {
> +	.dig_mic_en_bits = 20,
> +	.dig_mic_freq_bits = 21,
> +	.adc14b_12_bits = 22,
> +	.firdac_hsl_en_bits = 23,
> +	.firdac_hsr_en_bits = 24,
> +	.firdac_lout_en_bits = 25,
> +	.por_bits = 26,
> +	.codec_clk_en_bits = 27,
> +};

This looks like the sort of thing that the regmap_field layer was
supposed to hide?

> +static int adc_event(struct snd_soc_dapm_widget *w,
> +		struct snd_kcontrol *kcontrol, int event)
> +{
> +	struct snd_soc_codec *codec = w->codec;
> +	struct sirf_audio_codec *sirf_audio_codec = dev_get_drvdata(codec->dev);
> +	u32 val;
> +
> +	val = sirfsoc_rtc_iobrg_readl(sirf_audio_codec->sys_pwrc_reg_base +
> +			PWRC_PDN_CTRL_OFFSET);
> +	switch (event) {
> +	case SND_SOC_DAPM_POST_PMU:
> +		/* Enable capture power of codec*/
> +		val |= (1 << AUDIO_POWER_EN_BIT);
> +		break;

Looking at this code (and many of the other controls) I can't help but
feel that there's some room for more abstraction here.  The controls are
all setting two bits rather than just one but for example...

> +	case SND_SOC_DAPM_PRE_PMU:
> +		val = (1 << sirf_audio_codec->reg_bits->firdac_hsl_en_bits);
> +		break;

...this looks like a supply widget could be used to manage the bits
controlled by the pre and post PMU events?  The same is true for most of
the events.

> +	dn = of_find_compatible_node(dn, NULL, "sirf,prima2-pwrc");
> +	if (!dn) {
> +		dev_err(&pdev->dev, "Failed to get sirf,prima2-pwrc  node!\n");
> +		return -ENODEV;
> +	}
> +
> +	ret = of_property_read_u32(dn, "reg", &sirf_audio_codec->sys_pwrc_reg_base);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed tp get pwrc register base address\n");
> +		return -EINVAL;
> +	}

Should prima2-pwrc be a syscon?  Not a blocker for merging this.

> +#ifdef CONFIG_PM_RUNTIME
> +static int sirf_audio_codec_runtime_suspend(struct device *dev)
> +{
> +	struct sirf_audio_codec *sirf_audio_codec = dev_get_drvdata(dev);
> +	regmap_update_bits(sirf_audio_codec->regmap, AUDIO_IC_CODEC_CTRL1,
> +		(1 << sirf_audio_codec->reg_bits->codec_clk_en_bits),
> +		0);
> +	return 0;
> +}

Can you disable the clock in the clock API as well?  This might allow
further supply clocks to be disabled and is genarally good practice.

> +static int sirf_audio_codec_suspend(struct device *dev)
> +{
> +	struct sirf_audio_codec *sirf_audio_codec = dev_get_drvdata(dev);
> +
> +	regmap_read(sirf_audio_codec->regmap, AUDIO_IC_CODEC_CTRL0,
> +		&sirf_audio_codec->reg_ctrl0);
> +	regmap_read(sirf_audio_codec->regmap, AUDIO_IC_CODEC_CTRL1,
> +		&sirf_audio_codec->reg_ctrl1);
> +	sirf_audio_codec_runtime_suspend(dev);

Have you seen the series Ulf has been posting regarding the integration
of runtime PM and system suspend?  There's all sorts of nasty cases with
this stuff unfortunately.  Not sure it should be a blocker for merging
though since we haven't really figured out how this stuff is supposed to
work.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2014-02-27  7:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26  7:22 [PATCH v4-resend 0/7] ASoC: add CSR SiRFSoC sound drivers RongJun Ying
2014-02-26  7:22 ` [PATCH v4-resend 1/7] ASoC: sirf: Add SiRF internal audio codec driver RongJun Ying
2014-02-27  5:33   ` Mark Brown [this message]
2014-02-28  1:52     ` Rongjun Ying
2014-03-01  3:16       ` Mark Brown
2014-03-03  2:15         ` Rongjun Ying
2014-03-03  5:07           ` Mark Brown
2014-03-03  7:48             ` Barry Song
2014-03-04  4:58               ` Mark Brown
2014-03-04  5:11                 ` RongJun Ying
2014-03-05  3:34                   ` Mark Brown
2014-03-05  5:34                     ` RongJun Ying
2014-02-26  7:22 ` [PATCH v4-resend 2/7] ASoC: sirf: Add SiRF audio port driver is used by SiRF internal audio codec RongJun Ying
2014-03-01  4:49   ` Mark Brown
2014-02-26  7:22 ` [PATCH v4-resend 3/7] ASoC: sirf: Add SiRF audio card RongJun Ying
2014-02-26  7:22 ` [PATCH v4-resend 4/7] ASoC: sirf: Add SiRF I2S driver RongJun Ying
2014-02-26  7:22 ` [PATCH v4-resend 5/7] ASoC: sirf: Add hdmi card RongJun Ying
2014-02-26  7:22 ` [PATCH v4-resend 6/7] ASoC: sirf: Add usp driver which is used by dsp mode RongJun Ying
2014-02-26  7:22 ` [PATCH v4-resend 7/7] ASoC: sirf: Add bt-sco card RongJun Ying

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=20140227053339.GU9383@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=lgirdwood@gmail.com \
    --cc=rjying@gmail.com \
    --cc=rongjun.ying@csr.com \
    --cc=tiwai@suse.de \
    --cc=workgroup.linux@csr.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