Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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;
}

  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