From: Troy Kisky <troy.kisky@boundarydevices.com>
To: "Ambrose, Martin" <martin@ti.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [PATCH V1 09/11] ASoC: DaVinci: i2s, add davinci_i2s_prepare and shutdown
Date: Fri, 24 Sep 2010 16:13:50 -0700 [thread overview]
Message-ID: <4C9D30AE.6080103@boundarydevices.com> (raw)
In-Reply-To: <A24693684029E5489D1D202277BE89447289CF40@dlee02.ent.ti.com>
>> I don't see the problem because my codec waits until trigger to activate its interface.
>
> Thanks for the feedback. I'm using the tlv320aic3x codec driver. Which codec are you using?
A modified tlv320aic23. I wrote it before it was available in the kernel, and never finished
a merge.
>
>> So the question is, who should be responsible for the final turn on?
>>
>> My thought was that the device (master) which starts the external wires to wiggling should be last.
>
> Fair enough. I suppose that is the reasoning for the addition of the prepare function.
> The assumption being that a cpu_dai callback to the prepare function will always proceed
> a call to the codec_dai trigger function. In this way the serial port can be configured and enabled.
> Then the codec can turn on the bit/frame clocks which will start the flow of data.
> Although it would seem the codec is unmuted a bit prematurely in this scenario since it happens
> before the clocks are enabled in the core prepare function -- at least I think this is the case.
>
> However there would still seem to be spurious, or at least superfluous, calls
> to mcbsp_stop/start when just requesting the device to enter the pause state.
>
> I guess the call tree is then different in the case where the cpu, or machine, is the
> clock master. This has pros/cons obviously.
>
>> If the codec is master, and starts the clocks before the mcbsp is ready that could also cause a pop
>> or noise.
>
> I still a newbie when it comes to the ALSA architecture.
> Is the proper signal indicating everything is ready, including valid data, a trigger call with cmd=START?
>
That is my understanding.
I think the main problem with using trigger to start the codec wiggling wires
is the need to use schedule_work to do i2c writes. That's probably why the mainline
aic23 driver doesn't use trigger. Sample below.
static void codec_trigger_deferred(struct work_struct *work)
{
struct aic23 *aic23 = container_of(work, struct aic23,
deferred_trigger_work);
struct snd_soc_codec *codec = &aic23->codec;
int playback = aic23->active_mask & ACTIVE_PLAYBACK;
u16 dia = (aic23->active_mask) ? 1 : 0;
if (playback) {
tlv320aic23_set(codec, TLV320AIC23_ACTIVE, 1);
tlv320aic23_modify(codec, TLV320AIC23_ANLG, 0, TLV320AIC23_DAC_SELECTED);
tlv320aic23_mute_volume(codec, 0);
} else {
tlv320aic23_mute_volume(codec, 1);
if (dia)
tlv320aic23_set(codec, TLV320AIC23_ACTIVE, dia);
tlv320aic23_modify(codec, TLV320AIC23_ANLG, TLV320AIC23_DAC_SELECTED, 0);
if (!dia)
tlv320aic23_set(codec, TLV320AIC23_ACTIVE, dia);
}
}
static int tlv320aic23_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_device *socdev = rtd->socdev;
struct snd_soc_codec *codec = socdev->card->codec;
struct aic23 *aic23 = container_of(codec, struct aic23, codec);
int ret = 0;
int playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
unsigned char mask = (playback)? ACTIVE_PLAYBACK : ACTIVE_CAPTURE;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
aic23->active_mask |= mask;
schedule_work(&aic23->deferred_trigger_work);
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
aic23->active_mask &= ~mask;
schedule_work(&aic23->deferred_trigger_work);
/* don't stop driving data lines
* until digital_mute done
*/
break;
default:
return ret;
}
next prev parent reply other threads:[~2010-09-24 23:13 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-05 2:29 davinci-i2c,pcm updates Troy Kisky
2009-07-05 2:29 ` [PATCH V1 01/11] ASoC: DaVinci: i2s, remove MOD_REG_BIT macro Troy Kisky
2009-07-05 2:29 ` [PATCH V1 02/11] ASoC: DaVinci: i2s toggle clock to complete reset Troy Kisky
2009-07-05 2:29 ` [PATCH V1 03/11] ASoc: DaVinci: i2s, minor cleanup Troy Kisky
2009-07-05 2:29 ` [PATCH V1 04/11] ASoC: DaVinci: i2s cleanup Troy Kisky
2009-07-05 2:29 ` [PATCH V1 05/11] ASoC: DaVinci: i2s, only start sample generator if needed Troy Kisky
2009-07-05 2:29 ` [PATCH V1 06/11] ASoC: DaVinci: i2s, minor cleanup of davinci_i2s_startup Troy Kisky
2009-07-05 2:29 ` [PATCH V1 07/11] ASoC: DaVinci: i2s, fix mcbsp_word_length update Troy Kisky
2009-07-05 2:29 ` [PATCH V1 08/11] ASoc: DaVinci: i2s, Improve underrun, support mono Troy Kisky
2009-07-05 2:29 ` [PATCH V1 09/11] ASoC: DaVinci: i2s, add davinci_i2s_prepare and shutdown Troy Kisky
[not found] ` <1246761001-21982-10-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2009-07-05 2:30 ` [PATCH V1 10/11] ASoC: DaVinci: i2s don't limit rates Troy Kisky
2009-07-05 2:30 ` [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram Troy Kisky
2009-07-05 13:03 ` Mark Brown
2009-07-07 1:10 ` Troy Kisky
2009-07-07 9:31 ` Mark Brown
2009-07-07 19:07 ` Troy Kisky
2009-07-07 19:14 ` Troy Kisky
2009-07-07 19:21 ` Troy Kisky
2009-07-05 11:57 ` [PATCH V1 10/11] ASoC: DaVinci: i2s don't limit rates Mark Brown
2009-07-06 22:01 ` Troy Kisky
2009-07-06 22:19 ` Mark Brown
2009-07-06 22:27 ` Troy Kisky
2009-07-05 12:17 ` [PATCH V1 09/11] ASoC: DaVinci: i2s, add davinci_i2s_prepare and shutdown Mark Brown
2010-09-24 16:48 ` Ambrose, Martin
2010-09-24 19:14 ` Troy Kisky
2010-09-24 19:43 ` Ambrose, Martin
2010-09-24 23:13 ` Troy Kisky [this message]
2010-09-27 0:56 ` Mark Brown
2010-09-27 18:50 ` Troy Kisky
2010-09-27 20:35 ` Mark Brown
2010-09-27 0:27 ` Mark Brown
2009-07-05 12:12 ` [PATCH V1 08/11] ASoc: DaVinci: i2s, Improve underrun, support mono Mark Brown
[not found] ` <1246761001-21982-9-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2009-07-06 11:09 ` Steve Chen
2009-07-06 11:54 ` Mark Brown
[not found] ` <20090706115442.GA8925-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2009-07-06 12:45 ` Steve Chen
2009-07-06 13:26 ` snd_pcm_format_set_silence parameter Guilherme Longo
2009-07-06 13:52 ` Clemens Ladisch
2009-07-05 11:41 ` davinci-i2c,pcm updates Mark Brown
2009-07-05 12:03 ` performance between access mothods! Guilherme Longo
2009-07-07 11:26 ` Takashi Iwai
2009-07-06 21:30 ` davinci-i2c,pcm updates Troy Kisky
2009-07-06 21:41 ` Mark Brown
2009-07-06 22:51 ` Kevin Hilman
2009-07-07 9:20 ` Mark Brown
2009-07-06 21:47 ` Kevin Hilman
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=4C9D30AE.6080103@boundarydevices.com \
--to=troy.kisky@boundarydevices.com \
--cc=alsa-devel@alsa-project.org \
--cc=martin@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 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.