All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@ti.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@ti.com>, Tony Lindgren <tony@atomide.com>,
	alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
	Benoit Cousson <b-cousson@ti.com>
Subject: Re: Re: [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
Date: Wed, 23 Nov 2011 10:48:24 +0200	[thread overview]
Message-ID: <1619032.uInsqOQfdX@barack> (raw)
In-Reply-To: <20111122160105.GC30583@opensource.wolfsonmicro.com>

On Tuesday 22 November 2011 16:01:05 Mark Brown wrote:
> On Tue, Nov 22, 2011 at 04:01:57PM +0200, Peter Ujfalusi wrote:
> > +	switch (params_rate(params)) {
> > +	case 96000:
> > +	case 192000:
> > +		break;
> 
> Why doesn't the driver need to tell the hardware what sample rate to run
> at?

Because the OMAP4 DMIC can only support on 96KHz...
Will be fixed.

> 
> > +	dmic_clk = clk_get(dmic->dev, "dmic_fck");
> > +	if (IS_ERR(dmic_clk)) {
> > +		dev_err(dmic->dev, "cant get dmic_fck\n");
> > +		return -ENODEV;
> > +	}
> 
> Why aren't we getting and holding a reference to the clock over the
> entire lifetime of the driver?

We only need the reference for the dmic_fclk for reparenting which will happen 
only once in most cases (or not at all, if pad_clks_ck is going to be used). I 
don't think we should hold the reference for the dmic_fclk.
The clock handling is done via pm_runtime_get/put_sync().

> > +	/* disable clock while reparenting */
> > +	pm_runtime_put_sync(dmic->dev);
> > +	ret = clk_set_parent(dmic_clk, parent_clk);
> > +	pm_runtime_get_sync(dmic->dev);
> 
> Since we're only allowing reclocking while idle shouldn't the clock
> already be disabled?  Seems like it ought to be good for power if
> nothing else...

We enable the clocks at dai_startup for the DMIC (and disable them on 
dai_shutdown). We can not reparent while the clocks are enabled.
This is the reason for this part.
 
> > +static int omap_dmic_set_clkdiv(struct snd_soc_dai *dai,
> > +				int div_id, int div)
> > +{
> 
> DMIC clocking is usually fairly simple so it seems surprising that the
> driver isn't able to figure this out for itself.

The clock towards the external digital mics are based on the DMIC_FCLK rate.
In case of DMIC_FCLK = 19.2MHz, 24.576MHz we can select between two dividers 
which will result different clocks for the external microphones.
I would rather leave this decision to the machine driver which knows the 
external components, and can pick the best divider for them.

--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-11-23  8:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22 14:01 [PATCH 0/5] Support for OMAP4 Digital Microphone interface Peter Ujfalusi
2011-11-22 14:01 ` [PATCH 1/5] OMAP4: hwmod: Add names for DMIC memory address space Peter Ujfalusi
2011-11-22 14:01 ` [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC Peter Ujfalusi
2011-11-22 16:01   ` Mark Brown
2011-11-23  8:48     ` Péter Ujfalusi [this message]
2011-11-23 10:58       ` Mark Brown
2011-11-23 14:00         ` Péter Ujfalusi
2011-11-23 14:30           ` Mark Brown
2011-11-23 15:24             ` Péter Ujfalusi
2011-11-23 15:28               ` Mark Brown
2011-11-22 14:01 ` [PATCH 3/5] OMAP4: devices: Register OMAP4 DMIC platform device Peter Ujfalusi
2011-11-22 14:01 ` [PATCH 4/5] OMAP4: board-4430sdp: Register platform device for digimic codec Peter Ujfalusi
2011-11-22 14:02 ` [PATCH 5/5] ASoC: sdp4430: Add support for digital microphones Peter Ujfalusi

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=1619032.uInsqOQfdX@barack \
    --to=peter.ujfalusi@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=b-cousson@ti.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=tony@atomide.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.