Hi
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/fsl/Kconfig | 10 +
> > sound/soc/fsl/Makefile |2 +
> > sound/soc/fsl/fsl_asrc_common.h |1 +
> > sound/soc/fsl/fsl_easrc.c | 2265 +++
> > sound/soc/fsl/fsl_easrc.h
Hi Rob, Nicolin
>
> Hi Rob
> >
> > On Wed, Oct 30, 2019 at 07:41:26PM +0800, Shengjiu Wang wrote:
> > > In order to support the two asrc modules in imx8qm, we need to add
> > > compatible string "fsl,imx8qm-asrc0" and "fsl,imx8qm-asrc1"
> >
> > Are the blocks different in some way?
> >
> > If not
Hi Rob
>
> On Wed, Oct 30, 2019 at 07:41:26PM +0800, Shengjiu Wang wrote:
> > In order to support the two asrc modules in imx8qm, we need to add
> > compatible string "fsl,imx8qm-asrc0" and "fsl,imx8qm-asrc1"
>
> Are the blocks different in some way?
>
> If not, why do you need to distinguish th
Hi
>
> Hi Shengjiu,
>
> Comments inline.
>
> On Wed, Nov 6, 2019 at 9:30 AM Shengjiu Wang
> wrote:
> >
> > Audmix support two substream, When two substream start to run, the
> > trigger function may be called by two substream in same time, that the
> > priv->tdms may be updated wrongly.
> >
> >
Hi Rob
>
> Hi
> >
> > On Wed, Oct 30, 2019 at 07:41:26PM +0800, Shengjiu Wang wrote:
> > > In order to support the two asrc modules in imx8qm, we need to add
> > > compatible string "fsl,imx8qm-asrc0" and "fsl,imx8qm-asrc1"
> >
> > Are the blocks different in some way?
> >
> > If not, why do you n
Hi
>
> On Wed, Oct 30, 2019 at 07:41:26PM +0800, Shengjiu Wang wrote:
> > In order to support the two asrc modules in imx8qm, we need to add
> > compatible string "fsl,imx8qm-asrc0" and "fsl,imx8qm-asrc1"
>
> Are the blocks different in some way?
>
> If not, why do you need to distinguish them?
Hi
>
> On Tue, Oct 29, 2019 at 05:17:09PM +0800, Shengjiu Wang wrote:
> > There are two asrc module in imx8qm, each module has different clock
> > configuration, and the DMA type is EDMA.
> >
> > So in this patch, we define the new clocks, refine the clock map, and
> > include struct fsl_asrc_soc
Hi
>
> On Fri, Oct 25, 2019 at 03:13:53PM +0800, Shengjiu Wang wrote:
> > xrun may happen at the end of stream, the
> > trigger->fsl_esai_trigger_stop maybe called in the middle of
> > fsl_esai_hw_reset, this may cause esai in wrong state after stop, and
> > there may be endless xrun interrupt.
>
Hi
>
> On Wed, Oct 23, 2019 at 03:29:49PM +0800, Shengjiu Wang wrote:
> > xrun may happen at the end of stream, the
> > trigger->fsl_esai_trigger_stop maybe called in the middle of
> > fsl_esai_hw_reset, this may cause esai in wrong state after stop, and
> > there may be endless xrun interrupt.
Hi
>
> On Wed, Oct 23, 2019 at 06:25:20AM +0000, S.j. Wang wrote:
> > > On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote:
> > > > For P2P output, the output divider should align with the output
> > > > sample
> > >
> > >
Hi
>
> On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote:
> > For P2P output, the output divider should align with the output sample
>
> I think we should avoid "P2P" (or "M2M") keyword in the mainline code as
> we know M2M will never get merged while somebody working with the
> mainl
Hi
> Just a small concern...
>
> On Thu, Sep 26, 2019 at 09:29:51AM +0800, Shengjiu Wang wrote:
> > static int fsl_asrc_dma_startup(struct snd_pcm_substream *substream)
> > {
> > +
> > + release_pair = false;
> > + ret = snd_soc_set_runtime_hwparams(substream,
> > + &snd_imx_hardware);
>
Hi
> On Tue, Sep 24, 2019 at 06:52:35PM +0800, Shengjiu Wang wrote:
> > There is error "aplay: pcm_write:2023: write error: Input/output error"
> > on i.MX8QM/i.MX8QXP platform for S24_3LE format.
> >
> > In i.MX8QM/i.MX8QXP, the DMA is EDMA, which don't support 24bit
> > sample, but we didn't add
Hi
>
> One issue for error-out and some nit-pickings inline. Thanks.
>
> On Thu, Sep 19, 2019 at 08:11:42PM +0800, Shengjiu Wang wrote:
> > There is error "aplay: pcm_write:2023: write error: Input/output error"
> > on i.MX8QM/i.MX8QXP platform for S24_3LE format.
> >
> > In i.MX8QM/i.MX8QXP, the
Hi
>
> When set the runtime hardware parameters, we may need to query the
> capability of DMA to complete the parameters.
>
> This patch is to Extract this operation from
> dmaengine_pcm_set_runtime_hwparams function to a separate function
> snd_dmaengine_pcm_set_runtime_hwparams, that other com
Hi
>
> On Fri, Sep 13, 2019 at 05:48:40AM +0000, S.j. Wang wrote:
> > Hi
> >
> > >
> > > On Tue, Sep 10, 2019 at 02:07:25AM +, S.j. Wang wrote:
> > > > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote:
> > > >
Hi
>
> On Tue, Sep 10, 2019 at 02:07:25AM +0000, S.j. Wang wrote:
> > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote:
> > > > The ASRC support 24bit/16bit/8bit input width, so S20_3LE format
> > > > should not be supported, it is word wi
Hi
>
> On Mon, Sep 09, 2019 at 06:33:21PM -0400, Shengjiu Wang wrote:
> > There is error "aplay: pcm_write:2023: write error: Input/output error"
> > on i.MX8QM/i.MX8QXP platform for S24_3LE format.
> >
> > In i.MX8QM/i.MX8QXP, the DMA is EDMA, which don't support 24bit
> > sample, but we didn'
Hi
>
> On Mon, Sep 09, 2019 at 06:33:19PM -0400, Shengjiu Wang wrote:
> > snd_pcm_format_t is more formal than enum asrc_word_width, which
> has
> > two property, width and physical width, which is more accurate than
> > enum asrc_word_width. So it is better to use in(out)put_format instead
> > o
Hi
>
> On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote:
> > The ASRC support 24bit/16bit/8bit input width, so S20_3LE format
> > should not be supported, it is word width is 20bit.
>
> I thought 3LE used 24-bit physical width. And the driver assigns
> ASRC_WIDTH_24_BIT to "width" f
Hi Mark
>
> On Fri, Aug 16, 2019 at 01:03:14AM -0400, Shengjiu Wang wrote:
>
> > + for (i = 0; i < reg_max; i++)
> > + regcache[i] = readl(audmux_base + i * 4);
>
> If only there were some framework which provided a register cache! 😝
Yes, next step I can refine this driver to use
>
> Hi Shengjiu,
>
> Mostly looks good to me, just some small comments.
>
> On Mon, Jul 08, 2019 at 02:38:52PM +0800, shengjiu.w...@nxp.com wrote:
>
> > +static void fsl_esai_hw_reset(unsigned long arg) {
> > + struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
> > + u32 saisr, tfcr
> > > > +
> > > > + /* restore registers by regcache_sync */
> > > > + fsl_esai_register_restore(esai_priv);
> > > > +
> > > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > > > +ESAI_xCR_xPR_MASK, 0);
> > > > + regmap_update_bits(esai_priv->regm
>
> > +
> > + /* restore registers by regcache_sync */
> > + fsl_esai_register_restore(esai_priv);
> > +
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > +ESAI_xCR_xPR_MASK, 0);
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
> > +
Hi
>
> Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are non
> volatile") removed TX data registers from the volatile_reg list and appended
> default values for them. However, being data registers of TX, they should
> not have been removed from the list because they should not be
Hi
> > > > > Sounds like a bug to me...should fix it first by marking the
> > > > > data registers as volatile.
> > > > >
> > > > The ETDR is a writable register, it is not volatile. Even we
> > > > change it to Volatile, I don't think we can't avoid this issue.
> > > > for the regcache_sync Just t
Hi
> On Thu, May 23, 2019 at 09:53:42AM +0000, S.j. Wang wrote:
> > > > + /*
> > > > + * Add fifo reset here, because the regcache_sync will
> > > > + * write one more data to ETDR.
> > > > + * Which will cause channel shift.
Hi
> > + /*
> > + * Add fifo reset here, because the regcache_sync will
> > + * write one more data to ETDR.
> > + * Which will cause channel shift.
>
> Sounds like a bug to me...should fix it first by marking the data registers as
> volatile.
>
The ETDR is a writable registe
There is chip errata ERR008000, the reference doc is
(https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),
The issue is "While using ESAI transmit or receive and
an underrun/overrun happens, channel swap may occur.
The only recovery mechanism is to reset the ESAI."
In this commit add a tasklet to ha
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asr
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is [1/24, 8]. In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support f
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in RESEND V6
- change the Content-Transfer-Encoding to "q
Hi
> Hi Mark,
> On Fri, May 03, 2019 at 01:27:31PM +0900, Mark Brown wrote:
> > On Thu, May 02, 2019 at 09:13:58AM +0000, S.j. Wang wrote:
> >
> > > I am checking, but I don't know why this patch failed in your side.
> > > I Tried to apply this patch on fo
Hi Mark
> On Sun, Apr 28, 2019 at 02:24:54AM +0000, S.j. Wang wrote:
> > Add pm runtime support and move clock handling there.
> > Close the clocks at suspend to reduce the power consumption.
> >
> > fsl_esai_suspend is replaced by pm_runtime_force_suspend.
> &g
Add pm runtime support and move clock handling there.
Close the clocks at suspend to reduce the power consumption.
fsl_esai_suspend is replaced by pm_runtime_force_suspend.
fsl_esai_resume is replaced by pm_runtime_force_resume.
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
Changes in
Hi Mark
> On Fri, Apr 26, 2019 at 10:51:15AM +0000, S.j. Wang wrote:
> > > On Mon, Apr 22, 2019 at 02:31:55AM +0000, S.j. Wang wrote:
> > > > Add pm runtime support and move clock handling there.
> > > > Close the clocks at suspend to reduce the power consump
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
independent of each other, so replace fall-through with break.
Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
Cc:
---
Changes in V6
- resend base one for-5.2
Changes in
Hi Mark
>
> On Mon, Apr 22, 2019 at 02:31:55AM +0000, S.j. Wang wrote:
> > Add pm runtime support and move clock handling there.
> > Close the clocks at suspend to reduce the power consumption.
> >
> > fsl_esai_suspend is replaced by pm_runtime_force_suspend.
>
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asr
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is [1/24, 8]. In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support f
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v6
- add acked-by
- fixed minor issue according to com
Hi
>
>
> On Mon, Apr 22, 2019 at 03:15:34AM +0000, S.j. Wang wrote:
> > Hi
> >
> > >
> > >
> > > On Mon, Apr 22, 2019 at 02:32:35AM +, S.j. Wang wrote:
> > > > When we want to support more sample rate, for example
> 12kHz/24k
Hi
>
>
> On Mon, Apr 22, 2019 at 02:32:35AM +0000, S.j. Wang wrote:
> > When we want to support more sample rate, for example 12kHz/24kHz
> we
> > need update the process_option table, if we want to support more
> > sample rate next time, the table need to be u
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is (1/24, 8). In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support f
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v5
- fix the [1/24, 8]
- move fsl_asrc_sel_proc before
Add pm runtime support and move clock handling there.
Close the clocks at suspend to reduce the power consumption.
fsl_esai_suspend is replaced by pm_runtime_force_suspend.
fsl_esai_resume is replaced by pm_runtime_force_resume.
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
Changes in
Hi.
>
> On Fri, Apr 19, 2019 at 10:23:56AM +0000, S.j. Wang wrote:
> > Unify the supported input and output rate, add the 12kHz/24kHz/128kHz
> > to the support list
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/fsl/fsl_asrc.c | 32 ++
Hi
>
>
> On Fri, Apr 19, 2019 at 10:23:53AM +0000, S.j. Wang wrote:
>
> > @@ -289,6 +318,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair
> *pair)
> > return -EINVAL;
> > }
> >
> > + ret = fsl_asrc_sel_proc(inrate
Hi
>
>
> On Fri, Apr 19, 2019 at 10:23:50AM +0000, S.j. Wang wrote:
> > When the output sample rate is [8kHz, 30kHz], the limitation of the
> > supported ratio range is (1/24, 8). In the driver we use (8kHz, 30kHz)
> > instead of [8kHz, 30kHz].
> > So this p
Hi
>
>
> Add pm runtime support and move clock handling there.
> fsl_esai_suspend is replaced by pm_runtime_force_suspend.
> fsl_esai_resume is replaced by pm_runtime_force_resume.
>
> Signed-off-by: Shengjiu Wang
> ---
> Changes in v2
> -refine the commit comments.
> -move regcache_mark_dir
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is (1/24, 8). In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support f
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v4
- add patch to Fix the [8kHz, 30kHz] open set issue
Hi
>
>
> On Thu, Apr 18, 2019 at 09:37:06AM +0000, S.j. Wang wrote:
> > > > > And this is according to IMX6DQRM:
> > > > > Limited support for the case when output sampling rates is
> > > > > between 8kHz and 30kHz. The limitation i
Add pm runtime support and move clock handling there.
fsl_esai_suspend is replaced by pm_runtime_force_suspend.
fsl_esai_resume is replaced by pm_runtime_force_resume.
Signed-off-by: Shengjiu Wang
---
Changes in v2
-refine the commit comments.
-move regcache_mark_dirty to runtime suspend.
sound
Hi
> On Thu, Apr 18, 2019 at 10:15:24AM +0000, S.j. Wang wrote:
> > > On Thu, Apr 18, 2019 at 02:00:12AM -0700, Nicolin Chen wrote:
> > > > On Thu, Apr 18, 2019 at 03:29:09AM +, S.j. Wang wrote:
>
> > > > Just for curiosity, we had similar situation
Hi
>
>
> On Thu, Apr 18, 2019 at 03:29:09AM +0000, S.j. Wang wrote:
> > In imx8 when systerm enter suspend state, the power of subsystem will
> > be off, the clock enable state will be lost and register configuration
>
> Just for curiosity, we had similar situa
Hi
>
> On Thu, Apr 18, 2019 at 02:00:12AM -0700, Nicolin Chen wrote:
> > On Thu, Apr 18, 2019 at 03:29:09AM +0000, S.j. Wang wrote:
>
> > > In imx8 when systerm enter suspend state, the power of subsystem
> > > will be off, the clock enable state will be lost
Hi
>
> On Thu, Apr 18, 2019 at 08:50:48AM +0000, S.j. Wang wrote:
> > > And this is according to IMX6DQRM:
> > > Limited support for the case when output sampling rates is
> > > between 8kHz and 30kHz. The limitation is the supported ratio
> > >
Hi
>
>
> On Thu, Apr 18, 2019 at 02:37:03AM +0000, S.j. Wang wrote:
> > > Here:
> > > > + /* Does not support cases: Tsout > 8.125 * Tsin */
> > > > + if (inrate * 8 > 65 * outrate)
>
> Though it might not matter any more (see my la
In imx8 when systerm enter suspend state, the power of subsystem will
be off, the clock enable state will be lost and register configuration
will be lost. So the driver need to enter runtime suspend state in
suspend.
With this implementation the suspend function almost same as runtime
suspend func
Hi
>
> Hi Shengjiu,
>
> This looks better. Just a couple of more small comments inline.
>
> On Wed, Apr 17, 2019 at 09:06:18AM +, S.j. Wang wrote:
>
> > +static int fsl_asrc_sel_proc(int inrate, int outrate, int *pre_proc,
> > + in
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_as
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
Support more sample rate in asrc
Shengjiu Wang (2):
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v3
- remove FSL_ASRC_RATES
- refine fsl_asrc_sel_proc according to comments
Changes in v2
- add more comment
Hi
>
>
> On Thu, Apr 11, 2019 at 09:39:06AM +0000, S.j. Wang wrote:
>
> > +/*
> > + * Select the pre-processing and post-processing options
>
> By aligning with other function comments:
> /**
> * Select the pre-processing and post-processing options
>
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asr
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
Support more sample rate in asrc
Shengjiu Wang (2):
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v2
- add more comments in code
- add commit "Unify the supported input and output rate"
sound/soc/fsl/fsl_a
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
independent of each other, so replace fall-through with break.
Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
Cc:
---
Changes in v5
- remove new line after Fixes
Changes
Hi Mark
>
> On Wed, Apr 10, 2019 at 02:42:45AM +0000, S.j. Wang wrote:
> > case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent
> of
> > each other, so replace fall-through with break.
>
> This doesn't apply against current code, please check and r
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
independent of each other, so replace fall-through with break.
Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
Cc:
---
Change in v4
- Add Acked-by and cc stable
- change
Hi
>
>
> case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent
> of each other, so replace fall-through with break.
>
> Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
>
> Signed-off-by: Shengjiu Wang
> Cc:
Forget to add Acked-by: Nicolin Chen , will send v4,
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
independent of each other, so replace fall-through with break.
Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Signed-off-by: Shengjiu Wang
Cc:
---
changes in v3
- add cc stable
- change the subject
sound/soc/fsl/fsl_esai
Hi
>
>
> On 4/9/19 9:42 PM, S.j. Wang wrote:
> > case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent
> of
> > each other, so replace fall-through with break.
> >
> I think you should change the subject line to:
>
> fix missing break in s
Hi
>
>
> On Wed, Apr 10, 2019 at 08:26:59AM +0000, S.j. Wang wrote:
> > > Is it possible to update the table? It'd be way quicker to use
> > > lookup table than real-time calculation all the time. I believe you
> > > can simply calculate all the value
> -Original Message-
> From: Nicolin Chen
> Sent: Wednesday, April 10, 2019 4:01 PM
> To: S.j. Wang
> Cc: ti...@kernel.org; xiubo@gmail.com; feste...@gmail.com;
> broo...@kernel.org; alsa-de...@alsa-project.org; linuxppc-
> d...@lists.ozlabs.org
> Subje
Hi
>
> On Wed, Apr 10, 2019 at 03:15:26AM +0000, S.j. Wang wrote:
> > The table is not flexible if supported sample rate is not in the
> > table, so use a function to replace it.
>
> Could you please elaborate a bit the special use case here?
>
> The tabl
The table is not flexible if supported sample rate is not in the
table, so use a function to replace it.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 73 +++-
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/sound/soc/fsl/
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of
each other, so replace fall-through with break.
Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Signed-off-by: Shengjiu Wang
---
Changes in v2
- fix the fixes tag.
sound/soc/fsl/fsl_esai.c | 2 +-
1 file cha
Hi
>
> Hi Gustavo,
>
> On Mon, Apr 08, 2019 at 10:20:25PM -0500, Gustavo A. R. Silva wrote:
> > >>> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> > >>> index
> > >>> c7410bbfd2af..bad0dfed6b68 100644
> > >>> --- a/sound/soc/fsl/fsl_esai.c
> > >>> +++ b/sound/soc/fsl/fsl_esai
Hi Gustavo
>
>
> On 4/8/19 4:28 AM, S.j. Wang wrote:
> > case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
> independent of
> > each other, so replace fall-through with break.
> >
> If this is correct, then you should use the following "Fixes
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of
each other, so replace fall-through with break.
Fixes: 16bbeb2b43c3 ("ASoC: fsl_esai: Mark expected switch fall-through")
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 2 +-
1 file changed, 1 insertion(+), 1 de
In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
Changes in v3
- fix the indentati
Hi
>
> This looks better :)
>
> On Wed, Apr 03, 2019 at 10:07:40AM +0000, S.j. Wang wrote:
> > @@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct
> > snd_soc_dai *dai, int clk_id, {
> > struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(da
In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.
Signed-off-by: Shengjiu Wang
---
changes in v2
- refine the patch according Nicolin's comm
Hi
>
> > > On Mon, Apr 01, 2019 at 11:39:10AM +0000, S.j. Wang wrote:
> > > > In ESAI synchronous mode, the clock is generated by Tx, So we
> > > > should always set registers of Tx which relate with the bit clock
> > > > and frame clock gener
Hi
>
> Shengjiu,
>
> On Mon, Apr 01, 2019 at 11:39:10AM +0000, S.j. Wang wrote:
> > In ESAI synchronous mode, the clock is generated by Tx, So we should
> > always set registers of Tx which relate with the bit clock and frame
> > clock generation (TCCR, TCR,
In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 28 ++
Hi Mark
Can this patch be accepted? Or need I do any update?
Best regards
Wang shengjiu
>
> There is very low possibility ( < 0.1% ) that channel swap happened in
> beginning when multi output/input pin is enabled. The issue is that
> hardware can't send data to correct pin in the beginning
There is a constraint for the channel number setting on the
asrc of older version (e.g. imx35), the channel number should
be even, odd number isn't valid.
So add this constraint when the asrc of older version is used.
Acked-by: Nicolin Chen
Signed-off-by: Shengjiu Wang
---
Changes in v3
- fix c
Hi
> On Fri, Mar 01, 2019 at 08:37:08AM +0000, S.j. Wang wrote:
> > There is constraint for the channel number setting on the
>
> nit: "a constraint"
>
> > asrc of older version (e.g. imx35), the channel number should be even,
> > odd number isn't v
Hi
> On 3/1/19 12:32 AM, S.j. Wang wrote:
> > This case is covered by S24_LE I think. The S32_LE means the data is
> > 32bit and slot width Is 32bit, this is not in data sheet.
>
> The problem is that if you have 32-bit samples in your audio file, and you
> want to play
There is constraint for the channel number setting on the
asrc of older version (e.g. imx35), the channel number should
be even, odd number isn't valid.
So add this constraint when the asrc of older version is used.
Signed-off-by: Shengjiu Wang
---
changes in v2
- switch to add constraint in sta
Hi
>
> On Fri, Mar 01, 2019 at 06:55:25AM +0000, S.j. Wang wrote:
>
> > > Alternatively, I feel instead of error-out at here, should we add a
> > > HW constraint or at least fence it off at the beginning of the
> > > hw_params()? This is actually
1 - 100 of 117 matches
Mail list logo
