linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Arnaud Mouiche <arnaud.mouiche@invoxia.com>
To: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: broonie@kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, alsa-devel@alsa-project.org,
	tiwai@suse.com, perex@perex.cz, lgirdwood@gmail.com,
	fabio.estevam@nxp.com, timur@tabi.org, lukma@denx.de,
	caleb@crome.org, max.krummenacher@toradex.com,
	mpa@pengutronix.de, mail@maciej.szmigiero.name
Subject: Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number
Date: Wed, 13 Sep 2017 10:02:20 +0200	[thread overview]
Message-ID: <fdb71350-0b89-8c5a-9ed0-c744bb6f2118@invoxia.com> (raw)
In-Reply-To: <20170912213233.GA11419@Asurada-Nvidia>



On 12/09/2017 23:32, Nicolin Chen wrote:
> On Tue, Sep 12, 2017 at 04:35:13PM +0200, Arnaud Mouiche wrote:
>
>>> - * freq: Output BCLK frequency = samplerate * 32 (fixed) * channels
>>> - * dir: SND_SOC_CLOCK_OUT -> TxBCLK, SND_SOC_CLOCK_IN -> RxBCLK.
>>> + * freq: Output BCLK frequency = samplerate * 32 (fixed) * slots (or channels)
>> Slots are not necessarily 32 bits width.
>> Indeed, a simple grep of snd_soc_dai_set_tdm_slot shows 16, 24, 32
>> and 0 bits usage. (don't know the real meaning of 0 BTW...)
>> So, it should be good to also remember the slots width given in
>> snd_soc_dai_set_tdm_slot() call.
> RM says that the word length is fixed to 32 in I2S Master mode.
> So I used it here. But I think using it with the slots could be
> wrong here as you stated. What kind of clock rates (bit and lr)
> does a TDM case have?
>
> The problem of slot width here is handled in the set_tdm_slot()
> at all. So I tried to ignored that. But we probably do need it
> when calculating things with the slot number.
>
> Could you please give me a few set of examples of how you set
> set_sysclk(), set_tdm_slot() with the current driver? The idea
> here is to figure out a way to calculate the bclk in hw_params
> without getting set_sysclk() involved any more.

Here is one, where a bclk = 4*16*fs is expected

    static int imx_hifi_hw_params(struct snd_pcm_substream *substream,
                          struct snd_pcm_hw_params *params)
    {
         struct snd_soc_pcm_runtime *rtd = substream->private_data;
         struct imx_priv *priv = &card_priv;
         struct device *dev = &priv->pdev->dev;

         int ret = 0;
         struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
         unsigned int freq;
         int ch;

         /* configuring cpu_dai
          * - bitclk  (fclk is computed automatically)
          *      16bit * 4 (max) channels * sampling rate
          * - tdm maskto select the active channels
          */

         freq = 4 * 16 * params_rate(params);
         if (freq != priv->current_freq) {
             /* clk_id and direction are not taken in count by fsl_ssi
    driver */
             ret = snd_soc_dai_set_sysclk( cpu_dai, 0, freq, 0 );
             if (ret) {
                 dev_err(dev, "failed to set cpu dai bitclk: %u\n", freq);
                 return ret;
             }
             priv->current_freq = freq;
         }
         ch = params_channels(params);
         if (ch != priv->current_ch) {
             ret = snd_soc_dai_set_tdm_slot( cpu_dai, (1 << ch)-1, (1 <<
    ch)-1, 4, 16 );
             if (ret) {
                 dev_err(dev, "failed to set cpu dai tdm slots:
    ch=%d\n", ch);
                 return ret;
             }
             priv->current_ch = ch;
         }
         return 0;
    }

In another setup, there are 8 x 16 bits slots, whatever the number of 
active channels is.
In this case bclk = 128 * fs
The number of slots is completely arbitrary. Some slots can even be 
reserved for communication between codecs that don't communicate with linux.

>
>> Anyway, there is something wrong in the snd_soc_codec_set_sysclk
>> usage by fsl_ssi
>> Let's get a look again at the description:
>>
>>     /**
>>       * snd_soc_dai_set_sysclk - configure DAI system or master clock.
>>       * @dai: DAI
>>       * @clk_id: DAI specific clock ID
>>       * @freq: new clock frequency in Hz
>>       * @dir: new clock direction - input/output.
>>       *
>>       * Configures the DAI master (MCLK) or system (SYSCLK) clocking.
>>       */
>>     int snd_soc_dai_set_sysclk(struct snd_soc_dai *dai, int clk_id,
>>          unsigned int freq, int dir)
>>
>> So, it can be used to configure 2 different clocks (and more) with
>> different usages.
>>
>> Lukasz complains that simple-card is configuring MCLK incorrectly.
>> but simple-card, only want to configure the SYSCLK, whereas fsl_ssi
>> understand "configure the MCLK..." (fsl_ssi doesn't check the clk_id
>> at all)
> It's more than a clock_id in my opinion. The driver now sets
> the bit clock rate via set_sysclk() other than the MCLK rate
> actually.
>
>> I think the problem is here.
>> I would propose a new clk_id
>>
>>      #define FSL_SSI_SYSCLK_MCLK 1
>>
>> And leave fsl_ssi_set_dai_sysclk(xxx, FSL_SSI_SYSCLK_MCLK, ...)
>> override the computed mlck.
>> This will leave a way for obscure TDM users to specify a specific a
>> random mclk frequency for obscure reasons...
>> Unfortunately, such generic clock_id (sysclk, mclk) were never
>> defined widely.
> Unfortunately, it looks like a work around to me. I understand
> the idea of leaving set_sysclk() out there to override the bit
> clock is convenient, but it is not a standard ALSA design and
> may eventually introduce new problems like today.

I agree. I'm not conservative at all concerning this question.
I don't see a way to remove set_sysclk without breaking current TDM 
users anyway, at least for those who don't have their code upstreamed.


All information provided through snd_soc_dai_set_tdm_slot( cpu_dai, 
mask, mask, slots, width ) should be enough
In this case, for TDM users

    bclk = slots * width * fs   (where slots is != channels)



will manage 99 % of the cases.
And the remaining 1% will concern people who need to hack the kernel so 
widely they don't care about the set_sysclk removal.

Now, looking at the code currently in linus/master:sound/soc/fsl 
concerning TDM
- imx-mc13783.c : the codec is master => OK
- fsl-asoc-card.c : *something will break since snd_soc_dai_set_sysclk 
returned code is checked*
- eukrea-tlv320.c : based on imx-ssi.c, so not affected by changes in 
fsl_ssi.c.  Use set_sysclk() only to setup the clock direction
- wm1133-ev1.c : bclk generated by the codec. set_sysclk() not called 
for cpu_dai

Consequently, we can say that few things is broken in linux upstream if 
set_sysclk is removed, and this can be fixed easily for fsl-asoc-card.c


Arnaud

  reply	other threads:[~2017-09-13  8:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08  5:23 [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number Nicolin Chen
2017-09-08  5:42 ` Nicolin Chen
2017-09-08  6:14   ` Arnaud Mouiche
2017-09-08  8:41   ` Łukasz Majewski
2017-09-12 14:35 ` Arnaud Mouiche
2017-09-12 21:32   ` Nicolin Chen
2017-09-13  8:02     ` Arnaud Mouiche [this message]
2017-09-13 23:01       ` Nicolin Chen
2017-11-25 22:29         ` Lukasz Majewski
2017-11-26  0:36           ` Nicolin Chen
2017-11-26 20:22             ` Lukasz Majewski

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=fdb71350-0b89-8c5a-9ed0-c744bb6f2118@invoxia.com \
    --to=arnaud.mouiche@invoxia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=caleb@crome.org \
    --cc=fabio.estevam@nxp.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukma@denx.de \
    --cc=mail@maciej.szmigiero.name \
    --cc=max.krummenacher@toradex.com \
    --cc=mpa@pengutronix.de \
    --cc=nicoleotsuka@gmail.com \
    --cc=perex@perex.cz \
    --cc=timur@tabi.org \
    --cc=tiwai@suse.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;
as well as URLs for NNTP newsgroup(s).