All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Arnaud Mouiche <arnaud.mouiche@invoxia.com>
Cc: alsa-devel@alsa-project.org, timur@tabi.org, lgirdwood@gmail.com,
	tiwai@suse.com, linux-kernel@vger.kernel.org, caleb@crome.org,
	mpa@pengutronix.de, broonie@kernel.org,
	max.krummenacher@toradex.com, lukma@denx.de,
	fabio.estevam@nxp.com, mail@maciej.szmigiero.name,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number
Date: Tue, 12 Sep 2017 14:32:34 -0700	[thread overview]
Message-ID: <20170912213233.GA11419@Asurada-Nvidia> (raw)
In-Reply-To: <2020d72a-4517-55d0-59a1-171c71f91c7b@invoxia.com>

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.

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

> Is it really needed ? It is true that, up to now, we are using
> fsl_ssi_set_dai_sysclk() in addition to snd_soc_dai_set_tdm_slot()
> only because this was the only way to deal with correct mclk
> setting. And if now, snd_soc_dai_set_tdm_slot() do its job
> correctly, fsl_ssi_set_dai_sysclk() will become useless (except for
> obscure TDM users of course)

The idea here is to drop the set_sysclk() for all user cases
including TDM cases. So we need a solid patch to calculate the
bit clock rate in hw_params() for TDM user cases..

WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Arnaud Mouiche <arnaud.mouiche@invoxia.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: Tue, 12 Sep 2017 14:32:34 -0700	[thread overview]
Message-ID: <20170912213233.GA11419@Asurada-Nvidia> (raw)
In-Reply-To: <2020d72a-4517-55d0-59a1-171c71f91c7b@invoxia.com>

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.

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

> Is it really needed ? It is true that, up to now, we are using
> fsl_ssi_set_dai_sysclk() in addition to snd_soc_dai_set_tdm_slot()
> only because this was the only way to deal with correct mclk
> setting. And if now, snd_soc_dai_set_tdm_slot() do its job
> correctly, fsl_ssi_set_dai_sysclk() will become useless (except for
> obscure TDM users of course)

The idea here is to drop the set_sysclk() for all user cases
including TDM cases. So we need a solid patch to calculate the
bit clock rate in hw_params() for TDM user cases..

  reply	other threads:[~2017-09-12 21:32 UTC|newest]

Thread overview: 18+ 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:23 ` Nicolin Chen
2017-09-08  5:42 ` 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 [this message]
2017-09-12 21:32     ` Nicolin Chen
2017-09-13  8:02     ` Arnaud Mouiche
2017-09-13  8:02       ` Arnaud Mouiche
2017-09-13 23:01       ` Nicolin Chen
2017-11-25 22:29         ` Lukasz Majewski
2017-11-25 22:29           ` Lukasz Majewski
2017-11-26  0:36           ` Nicolin Chen
2017-11-26  0:36             ` Nicolin Chen
2017-11-26 20:22             ` Lukasz Majewski
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=20170912213233.GA11419@Asurada-Nvidia \
    --to=nicoleotsuka@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnaud.mouiche@invoxia.com \
    --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=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 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.