Linux on ARM based TI OMAP SoCs
 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: Re: Re: [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
Date: Wed, 23 Nov 2011 17:24:41 +0200	[thread overview]
Message-ID: <2903628.kUHW0DbjnM@barack> (raw)
In-Reply-To: <20111123143049.GC20272@opensource.wolfsonmicro.com>

On Wednesday 23 November 2011 14:30:50 Mark Brown wrote:
> Meh, I guess.  It's hard to love code-wise.

So you would prefer me to enable the OMAP DMIC's clocks at pcm_trigger:start 
time, and disable them on pcm_trigger:stop?
I have seen cases when the driver did not received the pcm_trigger:stop prior 
to pcm_close call, so in that case a safety check in dai_shutdown is needed to 
be sure the dmic clocks are really disabled.
I would still prefer to keep the dmic clocks enabled for the duration the 
stream is open. On the other hand if I had it in pcm_trigger, I don't need to 
play with the clocks when reparenting...

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

Sure, I will change the driver accordingly.

--
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 15:24 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
2011-11-23 15:24             ` Péter Ujfalusi [this message]
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=2903628.kUHW0DbjnM@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox