All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Péter Ujfalusi" <peter.ujfalusi@ti.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: Re: [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
Date: Wed, 23 Nov 2011 14:30:50 +0000	[thread overview]
Message-ID: <20111123143049.GC20272@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <3755917.L7uBQxiu6F@barack>

On Wed, Nov 23, 2011 at 04:00:23PM +0200, Péter Ujfalusi wrote:
> On Wednesday 23 November 2011 10:58:07 Mark Brown wrote:

> > > 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.

> > That sounds like the enable is happening too early, then.

> This only enables the clock for the DMIC block, the clock for the external 
> DMIC will start at trigger time (and stop as well).
> In order to access to DMIC registers we need clocks, and the clocks are 
> enabled for the duration we have capture stream open.
> I would think this is acceptable.

Meh, I guess.  It's hard to love code-wise.

> > If that's what you're doing then it seems like the machine drivers
> > should be use set_sysclk() (or perhaps even the clk API) to set up the
> > rate they're looking for from the visible clock rather than fiddling
> > about with magic divider values.  That way they can say exactly what
> > they want directly in terms of the result they're looking for.

> In OMAP4 DMIC the divider can not be chosen freely.
> The clock provided to the external microphones will depend on the selected 
> DMIC_FCLK, and the divider.
> If I ask the machine driver to ask for specific speed for the external mic, 
> the writer of the machine driver anyways have to look up the table from the 
> TRM for the possible frequencies. So instead of providing magic divider it has 
> to provide magic speed.

Sure, but on the other hand it means that someone reading the machine
driver can tell what's going on without going back to the magic table
either.  Having the rates in the code makes the code more legible and
means that people can at least refer to the DMIC driver for a list of
supported rates rather than having to find the TRM.

I'd also guess that it's much more likely that people will remember
clock rates they can set than divider tables but perhaps that's just me.
--
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 14:30 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
2011-11-23 10:58       ` Mark Brown
2011-11-23 14:00         ` Péter Ujfalusi
2011-11-23 14:30           ` Mark Brown [this message]
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=20111123143049.GC20272@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=peter.ujfalusi@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.