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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox