Re: [PATCH] MAINTAINERS: Add Shengjiu to reviewer list of sound/soc/fsl

2020-07-02 Thread Fabio Estevam
On Thu, Jul 2, 2020 at 4:31 PM Nicolin Chen  wrote:
>
> Add Shengjiu who's actively working on the latest fsl/nxp audio drivers.
>
> Signed-off-by: Nicolin Chen 
> Cc: Shengjiu Wang 

Reviewed-by: Fabio Estevam 


Re: [PATCH v3] ASoC: fsl_asrc: Add an option to select internal ratio mode

2020-06-30 Thread Fabio Estevam
On Tue, Jun 30, 2020 at 11:07 AM Shengjiu Wang  wrote:
>
> The ASRC not only supports ideal ratio mode, but also supports
> internal ratio mode.
>
> For internal rato mode, the rate of clock source should be divided
> with no remainder by sample rate, otherwise there is sound
> distortion.
>
> Add function fsl_asrc_select_clk() to find proper clock source for
> internal ratio mode, if the clock source is available then internal
> ratio mode will be selected.
>
> With change, the ideal ratio mode is not the only option for user.
>
> Signed-off-by: Shengjiu Wang 

Reviewed-by: Fabio Estevam 


Re: [PATCH] ASoC: fsl_asrc: Add an option to select internal ratio mode

2020-06-30 Thread Fabio Estevam
Hi Shengjiu,

On Mon, Jun 29, 2020 at 11:10 AM Shengjiu Wang  wrote:

> +/**

"/**" notation may confuse 'make htmldocs". Since this is a single
line comment you could do:

/* Select proper clock source for internal ratio mode */


> + * Select proper clock source for internal ratio mode
> + */
> +static int fsl_asrc_select_clk(struct fsl_asrc_priv *asrc_priv,
> +  struct fsl_asrc_pair *pair,
> +  int in_rate,
> +  int out_rate)
> +{
> +   struct fsl_asrc_pair_priv *pair_priv = pair->private;
> +   struct asrc_config *config = pair_priv->config;
> +   int rate[2], select_clk[2]; /* Array size 2 means IN and OUT */
> +   int clk_rate, clk_index;
> +   int i = 0, j = 0;
> +   bool clk_sel[2];
> +
> +   rate[0] = in_rate;
> +   rate[1] = out_rate;
> +
> +   /* Select proper clock source for internal ratio mode */
> +   for (j = 0; j < 2; j++) {
> +   for (i = 0; i < ASRC_CLK_MAP_LEN; i++) {
> +   clk_index = asrc_priv->clk_map[j][i];
> +   clk_rate = 
> clk_get_rate(asrc_priv->asrck_clk[clk_index]);
> +   if (clk_rate != 0 && (clk_rate / rate[j]) <= 1024 &&
> +   (clk_rate % rate[j]) == 0)
> +   break;
> +   }
> +
> +   if (i == ASRC_CLK_MAP_LEN) {
> +   select_clk[j] = OUTCLK_ASRCK1_CLK;
> +   clk_sel[j] = false;
> +   } else {
> +   select_clk[j] = i;
> +   clk_sel[j] = true;
> +   }
> +   }
> +
> +   /* Switch to ideal ratio mode if there is no proper clock source */
> +   if (!clk_sel[IN] || !clk_sel[OUT])
> +   select_clk[IN] = INCLK_NONE;
> +
> +   config->inclk = select_clk[IN];
> +   config->outclk = select_clk[OUT];
> +
> +   return 0;

This new function always returns 0. Should it be converted to 'void'
type instead?

> +   ret = fsl_asrc_select_clk(asrc_priv, pair,
> + config.input_sample_rate,
> + config.output_sample_rate);
> +   if (ret) {
> +   dev_err(dai->dev, "fail to select clock\n");

fsl_asrc_select_clk() does not return error, so you could skip the
error checking.


Re: [PATCH 2/3] ASoC: dt-bindings: fsl_easrc: Add document for EASRC

2020-02-12 Thread Fabio Estevam
On Wed, Feb 12, 2020 at 1:35 AM Shengjiu Wang  wrote:
>
> EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
> IP module found on i.MX815.

i.MX815 in an internal terminology. Please avoid it on the commit log.

>
> Signed-off-by: Shengjiu Wang 
> ---
>  .../devicetree/bindings/sound/fsl,easrc.txt   | 57 +++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/fsl,easrc.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.txt 
> b/Documentation/devicetree/bindings/sound/fsl,easrc.txt
> new file mode 100644
> index ..0e8153165e3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.txt
> @@ -0,0 +1,57 @@
> +NXP Asynchronous Sample Rate Converter (ASRC) Controller
> +
> +The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of a
> +signal associated with an input clock into a signal associated with a 
> different
> +output clock. The driver currently works as a Front End of DPCM with other 
> Back
> +Ends Audio controller such as ESAI, SSI and SAI. It has four context to 
> support
> +four substreams within totally 32 channels.
> +
> +Required properties:
> +- compatible:Contains "fsl,imx8mn-easrc".
> +
> +- reg:   Offset and length of the register set for the
> +device.
> +
> +- interrupts:Contains the asrc interrupt.
> +
> +- dmas:  Generic dma devicetree binding as described in
> +Documentation/devicetree/bindings/dma/dma.txt.
> +
> +- dma-names: Contains "ctx0_rx", "ctx0_tx",
> + "ctx1_rx", "ctx1_tx",
> + "ctx2_rx", "ctx2_tx",
> + "ctx3_rx", "ctx3_tx".
> +
> +- clocks:Contains an entry for each entry in clock-names.
> +
> +- clock-names:   "mem" - Peripheral clock to driver module.
> +
> +- fsl,easrc-ram-script-name: The coefficient table for the filters
> +
> +- fsl,asrc-rate: Defines a mutual sample rate used by DPCM Back
> +Ends.
> +
> +- fsl,asrc-width:Defines a mutual sample width used by DPCM Back
> +Ends.
> +
> +Example:
> +
> +easrc: easrc@300C {
> +   compatible = "fsl,imx8mn-easrc";
> +   reg = <0x0 0x300C 0x0 0x1>;
> +   interrupts = ;
> +   clocks = < IMX8MN_CLK_ASRC_ROOT>;
> +   clock-names = "mem";
> +   dmas = < 16 23 0> , < 17 23 0>,
> +  < 18 23 0> , < 19 23 0>,
> +  < 20 23 0> , < 21 23 0>,
> +  < 22 23 0> , < 23 23 0>;
> +   dma-names = "ctx0_rx", "ctx0_tx",
> +   "ctx1_rx", "ctx1_tx",
> +   "ctx2_rx", "ctx2_tx",
> +   "ctx3_rx", "ctx3_tx";
> +   fsl,easrc-ram-script-name = "imx/easrc/easrc-imx8mn.bin";
> +   fsl,asrc-rate  = <8000>;
> +   fsl,asrc-width = <16>;
> +   status = "disabled";
> +};
> --
> 2.21.0
>


Re: [PATCH v4 1/2] ASoC: dt-bindings: fsl_asrc: add compatible string for imx8qm & imx8qxp

2019-12-02 Thread Fabio Estevam
On Mon, Dec 2, 2019 at 8:56 AM Shengjiu Wang  wrote:

> -  - compatible : Contains "fsl,imx35-asrc" or "fsl,imx53-asrc".
> +  - compatible : Contains "fsl,imx35-asrc", "fsl,imx53-asrc",
> + "fsl,imx8qm-asrc", "fsl,imx8qxp-asrc"

You missed the word "or" as in the original binding.


Re: [PATCH] ASoC: fsl_sai: add IRQF_SHARED

2019-11-29 Thread Fabio Estevam
Hi Michael,

On Thu, Nov 28, 2019 at 7:38 PM Michael Walle  wrote:
>
> The LS1028A SoC uses the same interrupt line for adjacent SAIs. Use
> IRQF_SHARED to be able to use these SAIs simultaneously.

On i.MX8M SAI5 and SAI6 share the same interrupt number too:

Reviewed-by: Fabio Estevam 

Thanks


Re: [PATCH v2 00/21] Refine memblock API

2019-09-25 Thread Fabio Estevam
On Wed, Sep 25, 2019 at 9:17 AM Adam Ford  wrote:

> I tried cma=256M and noticed the cma dump at the beginning didn't
> change.  Do we need to setup a reserved-memory node like
> imx6ul-ccimx6ulsom.dtsi did?

I don't think so.

Were you able to identify what was the exact commit that caused such regression?


Re: [PATCH v2 00/21] Refine memblock API

2019-09-25 Thread Fabio Estevam
Hi Adam,

On Wed, Sep 25, 2019 at 6:38 AM Adam Ford  wrote:

> I know it's rather late, but this patch broke the Etnaviv 3D graphics
> in my i.MX6Q.
>
> When I try to use the 3D, it returns some errors and the dmesg log
> shows some memory allocation errors too:
> [3.682347] etnaviv etnaviv: bound 13.gpu (ops gpu_ops)
> [3.688669] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
> [3.695099] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
> [3.700800] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
> [3.723013] etnaviv-gpu 13.gpu: command buffer outside valid
> memory window
> [3.731308] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [3.752437] etnaviv-gpu 134000.gpu: command buffer outside valid
> memory window

This looks similar to what was reported at:
https://bugs.freedesktop.org/show_bug.cgi?id=111789

Does it help if you use the same suggestion and pass cma=256M in your
kernel command line?


Re: [PATCH] ASoC: fsl_ssi: Fix clock control issue in master mode

2019-08-28 Thread Fabio Estevam
Hi Shengjiu,

On Wed, Aug 28, 2019 at 2:21 AM Shengjiu Wang  wrote:
>
> The test case is
> arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav &
> aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav
>
> There will be error after end of arecord:
> aplay: pcm_write:2051: write error: Input/output error
>
> Capture and Playback work in parallel in master mode, one
> substream stops, the other substream is impacted, the
> reason is that clock is disabled wrongly.
>
> The clock's reference count is not increased when second
> substream starts, the hw_param() function returns in the
> beginning because first substream is enabled, then in end
> of first substream, the hw_free() disables the clock.
>
> This patch is to move the clock enablement to the place
> before checking of the device enablement in hw_param().
>
> Signed-off-by: Shengjiu Wang 

It would be nice if you could add a Fixes tag as well.


Re: [PATCH 1/2] ASoC: mpc5200_dma: Fix invalid license ID

2019-04-14 Thread Fabio Estevam
On Sun, Apr 14, 2019 at 4:15 PM Andra Danciu  wrote:
>
> As the file had no other license notice/reference, it falls under the
> project license and therefore the proper SPDX id is: GPL-2.0-only
>
> Cc: Daniel Baluta 
> Fixes: 1edfc2485d8dc ("ASoC: mpc5200_dma: Switch to SPDX identifier")
> Reported-by: Thomas Gleixner 
> Signed-off-by: Andra Danciu 
> ---
>  sound/soc/fsl/mpc5200_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index 4396442c2fdd..ccf9301889fe 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL
> +// SPDX-License-Identifier: GPL-2.0-only

According to Documentation/process/license-rules.rst this should be:

// SPDX-License-Identifier: GPL-2.0


Re: [PATCH v4 3/4] ASoC: imx-audmix: fix object reference leaks in probe

2019-04-10 Thread Fabio Estevam
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman  wrote:
>
> Release the reference to the underlying device taken
> by of_find_device_by_node() call.
>
> Signed-off-by: Viorel Suman 
> Reported-by: Julia Lawall 
> Acked-by: Nicolin Chen 

Please provide a Fixes tag.


Re: [PATCH v4 2/4] ASoC: fsl_audmix: remove "model" attribute from DT document

2019-04-10 Thread Fabio Estevam
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman  wrote:
>
> Remove "model" attribute from fsl_audmix DT document.

Please provide the reasoning.


Re: [PATCH 02/20] ASoC: efika-audio-fabric.c: Switch to SPDX identifier

2019-04-05 Thread Fabio Estevam
On Fri, Apr 5, 2019 at 10:24 AM Mukesh Ojha  wrote:

> you mean all lines to start with //, does not it look to noisy to eyes ?

Mark Brown's recommendation is to use // in all the initial block
lines instead of only in the SPDX one.


Re: [PATCH 02/20] ASoC: efika-audio-fabric.c: Switch to SPDX identifier

2019-04-05 Thread Fabio Estevam
On Fri, Apr 5, 2019 at 9:47 AM Mukesh Ojha  wrote:

> Don't change entire thing with //. only above line with the license is
> enough.
>
> Please apply this rule every patch of yours.

Not really. This is the style preferred in this subsystem.


Re: [PATCH] ASoC: imx-pcm: Switch to SPDX identifier

2019-04-04 Thread Fabio Estevam
On Thu, Apr 4, 2019 at 9:07 AM Andra Danciu  wrote:
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Andra Danciu 
> ---
>  sound/soc/fsl/imx-pcm.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
> index 133c4470acad..3ce2f437e645 100644
> --- a/sound/soc/fsl/imx-pcm.h
> +++ b/sound/soc/fsl/imx-pcm.h
> @@ -1,13 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

This is not correct...

>  /*
>   * Copyright 2009 Sascha Hauer 
>   *
>   * This code is based on code copyrighted by Freescale,
>   * Liam Girdwood, Javier Martin and probably others.
> - *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.

as it does not match with the original license text.

You should use:

/* SPDX-License-Identifier: GPL-2.0+ */


Re: [PATCH] ASoC: fsl_esai: fix channel swap issue when stream starts

2019-02-21 Thread Fabio Estevam
Hi Shengjiu.

On Thu, Feb 21, 2019 at 6:53 AM S.j. Wang  wrote:
>
> From: Shengjiu Wang 

Better use your nxp.com address as the freescale.com domain is gone
for a long time.

> 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 begginning with

s/begginning/beginning

> the normal enable flow.
>
> This is hardware issue, the workaround flow is that: Each time

Is there an erratum reference for this issue? If so, please add it here.

> playback/recording, firstly clear the xSMA/xSMB, then enable TE/RE,
> then enable xSMB and xSMA (xSMB must be enabled before xSMA).
> Which is to use the xSMA as the trigger start register, previously
> the xCR_TE or xCR_RE is the bit for starting

Please add a Fixes tag and Cc stable.

> Signed-off-by: Shengjiu Wang 

Reviewed-by: Fabio Estevam 

Thanks


Re: [PATCH] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode

2019-02-16 Thread Fabio Estevam
Hi Shengjiu,

On Fri, Feb 15, 2019 at 9:04 AM S.j. Wang  wrote:
>
> The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to
> wrong register, correct it.
>
> Signed-off-by: Shengjiu Wang 

Reviewed-by: Fabio Estevam 

Please add a Fixes tag and Cc stable.

Also, it seems that Mark Brown is not on Cc. Please Cc him in v2.

Thanks


Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: Change to use DEFINE_SHOW_ATTRIBUTE macro

2018-11-07 Thread Fabio Estevam
On Wed, Nov 7, 2018 at 4:57 PM Yangtao Li  wrote:
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li 

Reviewed-by: Fabio Estevam 


[PATCH] powerpc: cpm_gpio: Remove owner assignment from platform_driver

2018-05-04 Thread Fabio Estevam
From: Fabio Estevam <fabio.este...@nxp.com>

Structure platform_driver does not need to set the owner field, as this
will be populated by the driver core.

Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 arch/powerpc/sysdev/cpm_gpio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/sysdev/cpm_gpio.c b/arch/powerpc/sysdev/cpm_gpio.c
index 0badc90..0695d26 100644
--- a/arch/powerpc/sysdev/cpm_gpio.c
+++ b/arch/powerpc/sysdev/cpm_gpio.c
@@ -63,7 +63,6 @@ static struct platform_driver cpm_gpio_driver = {
.probe  = cpm_gpio_probe,
.driver = {
.name   = "cpm-gpio",
-   .owner  = THIS_MODULE,
.of_match_table = cpm_gpio_match,
},
 };
-- 
2.7.4



Re: [alsa-devel] [PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio

2018-04-10 Thread Fabio Estevam
Hi Nicolin,

On Sun, Apr 8, 2018 at 8:57 PM, Nicolin Chen <nicoleots...@gmail.com> wrote:
> When the desired ratio is less than 256, the savesub (tolerance)
> in the calculation would become 0. This will then fail the loop-
> search immediately without reporting any errors.
>
> But if the ratio is smaller enough, there is no need to calculate
> the tolerance because PM divisor alone is enough to get the ratio.
>
> So a simple fix could be just to set PM directly instead of going
> into the loop-search.
>
> Reported-by: Marek Vasut <ma...@denx.de>
> Signed-off-by: Nicolin Chen <nicoleots...@gmail.com>
> Cc: Marek Vasut <ma...@denx.de>

Thanks for the fix:

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>


Re: [alsa-devel] [PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio

2018-04-08 Thread Fabio Estevam
Hi Nicolin,

On Sun, Apr 8, 2018 at 8:57 PM, Nicolin Chen  wrote:
> When the desired ratio is less than 256, the savesub (tolerance)
> in the calculation would become 0. This will then fail the loop-
> search immediately without reporting any errors.
>
> But if the ratio is smaller enough, there is no need to calculate
> the tolerance because PM divisor alone is enough to get the ratio.
>
> So a simple fix could be just to set PM directly instead of going
> into the loop-search.
>
> Reported-by: Marek Vasut 
> Signed-off-by: Nicolin Chen 
> Cc: Marek Vasut 

If this fixes Marek's usecase then I think we should also add:

Cc: 

Thanks


Re: [alsa-devel] [PATCH] ASoC: fsl_esai: Add freq check in set_dai_sysclk()

2018-04-08 Thread Fabio Estevam
On Sun, Apr 8, 2018 at 9:33 PM, Nicolin Chen <nicoleots...@gmail.com> wrote:
> The freq parameter indicates the physical frequency of an actual
> input clock or a desired frequency of an output clock for HCKT/R.
> It should never be passed 0. This might cause Division-by-zero.
>
> So this patch adds a check to fix it.
>
> Signed-off-by: Nicolin Chen <nicoleots...@gmail.com>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>


[PATCH] soc/fsl/guts: Add a NULL check for devm_kasprintf()

2018-01-06 Thread Fabio Estevam
From: Fabio Estevam <fabio.este...@nxp.com>

devm_kasprintf() may fail, so we should better add a NULL check
and propagate an error on failure.

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 drivers/soc/fsl/guts.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index d89a6a8..82251b4 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -167,10 +167,16 @@ static int fsl_guts_probe(struct platform_device *pdev)
} else {
soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL, "QorIQ");
}
+   if (!soc_dev_attr.family)
+   return -ENOMEM;
soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
 "svr:0x%08x", svr);
+   if (!soc_dev_attr.soc_id)
+   return -ENOMEM;
soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
   (svr >>  4) & 0xf, svr & 0xf);
+   if (!soc_dev_attr.revision)
+   return -ENOMEM;
 
soc_dev = soc_device_register(_dev_attr);
if (IS_ERR(soc_dev))
-- 
2.7.4



Re: [PATCH] powerpc/40x: acadia: Fix the 'interrupt-parent' property

2017-12-04 Thread Fabio Estevam
Hi Michael,

On Mon, Dec 4, 2017 at 2:45 AM, Michael Ellerman  wrote:

> Will pick it up for 4.16.

Just realized that there is already a fix for this in linux-next:

commit 3d2d4339cc326c427638daa67e264dd455ee1899
Author: Geert Uytterhoeven 
Date:   Fri Jun 2 14:38:47 2017 +0200

powerpc: dts: acadia: DT fix s/#interrupts-parent/#interrupt-parent/

Signed-off-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
Signed-off-by: Michael Ellerman 


Re: [PATCH] powerpc/40x: acadia: Fix the 'interrupt-parent' property

2017-12-01 Thread Fabio Estevam
Hi Michael,

On Tue, Oct 17, 2017 at 11:01 AM, Fabio Estevam <fabio.este...@nxp.com> wrote:
> 'interrupts-parent' property does not exist. Fix the typo.
>
> Fixes: 00f3ca740a9c26 ("powerpc/40x: AMCC PowerPC 405EZ Acadia DTS")
> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
> ---
>  arch/powerpc/boot/dts/acadia.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/acadia.dts 
> b/arch/powerpc/boot/dts/acadia.dts
> index 57291f6..8626615 100644
> --- a/arch/powerpc/boot/dts/acadia.dts
> +++ b/arch/powerpc/boot/dts/acadia.dts
> @@ -183,7 +183,7 @@
> usb@ef603000 {
> compatible = "ohci-be";
> reg = <0xef603000 0x80>;
> -   interrupts-parent = <>;
> +   interrupt-parent = <>;

Any comments?


[PATCH] powerpc/40x: acadia: Fix the 'interrupt-parent' property

2017-10-17 Thread Fabio Estevam
'interrupts-parent' property does not exist. Fix the typo.

Fixes: 00f3ca740a9c26 ("powerpc/40x: AMCC PowerPC 405EZ Acadia DTS")
Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 arch/powerpc/boot/dts/acadia.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/acadia.dts b/arch/powerpc/boot/dts/acadia.dts
index 57291f6..8626615 100644
--- a/arch/powerpc/boot/dts/acadia.dts
+++ b/arch/powerpc/boot/dts/acadia.dts
@@ -183,7 +183,7 @@
usb@ef603000 {
compatible = "ohci-be";
reg = <0xef603000 0x80>;
-   interrupts-parent = <>;
+   interrupt-parent = <>;
interrupts = <0xd 0x4 0xe 0x4>;
};
 
-- 
2.7.4



Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

2017-09-05 Thread Fabio Estevam
On Tue, Sep 5, 2017 at 6:13 PM, Łukasz Majewski  wrote:

>  {
> clock-frequency = <40>;
> pinctrl-names = "default";
> pinctrl-0 = <_i2c1>;
> status = "okay";
>
> codec: tfa9879@6C {
> #sound-dai-cells = <0>;
> compatible = "tfa9879";

This codec seems to miss device tree support. Don't you need something
like this?

--- a/sound/soc/codecs/tfa9879.c
+++ b/sound/soc/codecs/tfa9879.c
@@ -312,9 +312,15 @@ static const struct i2c_device_id tfa9879_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tfa9879_i2c_id);

+static const struct of_device_id tfa9879_of_match[] = {
+   { .compatible = "nxp,tfa9879", },
+   { }
+};
+
 static struct i2c_driver tfa9879_i2c_driver = {
.driver = {
.name = "tfa9879",
+   .of_match_table = tfa9879_of_match,
},
.probe = tfa9879_i2c_probe,
.remove = tfa9879_i2c_remove,


Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

2017-09-05 Thread Fabio Estevam
Hi Lukasz,

On Tue, Sep 5, 2017 at 5:35 AM, Łukasz Majewski  wrote:

> Note:
> [*] - I could workaround this problem by setting:
>
> system-clock-frequency = <0> in
>
> dailink_master: cpu {
> sound-dai = <>;
> };
>

Which mx6 type are you using? Can you post the complete audio related
bindings of your dts?

Still trying to understand why we do not see this error on other imx6 boards.


Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

2017-09-03 Thread Fabio Estevam
On Sun, Sep 3, 2017 at 11:40 AM, Łukasz Majewski <lu...@denx.de> wrote:

> This is the part of fsl_ssi_set_bclk() function which is called after
> fsl_ssi_set_dai_sysclk() (which sets ssi_private->bitclk_freq = freq;).
>
> Before the aforementioned check we do have:
>
> if (ssi_private->bitclk_freq)
> freq = ssi_private->bitclk_freq;
> else
> freq = params_channels(hw_params) * 32 *
> params_rate(hw_params);
>
>
> Which assigns freq = bitclk_freq (66 MHz)
>
> And then we break on this particular check:
>
> 66MHz * 5 > 66 MHz.
>
>
>
> The culprit IMHO is the  ssi_private->bitclk_freq = freq; in the
> fsl_ssi_set_dai_sysclk(), since we _should_ set SSI's IP block clock
> (ssi_private->clk), not the bit clock (BCLK).
>
>
> This patch just quits early if it detects change, which don't need to be
> done.

Thanks for the clarification.

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>


Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

2017-09-03 Thread Fabio Estevam
[Sorry for the top-posting]


The driver currently has:


/*
* Hardware limitation: The bclk rate must be
* never greater than 1/5 IPG clock rate
*/
if (freq * 5 > clk_get_rate(ssi_private->clk)) {
dev_err(cpu_dai->dev, "bitclk > ipgclk/5\n");
return -EINVAL;
}


Isn't this properly taking care of the clock restriction?


From: Lukasz Majewski <lu...@denx.de>
Sent: Sunday, September 3, 2017 8:05:01 AM
To: Timur Tabi; Nicolin Chen; Xiubo Li; Fabio Estevam; Liam Girdwood; Mark 
Brown; Jaroslav Kysela; Takashi Iwai
Cc: alsa-de...@alsa-project.org; linuxppc-dev@lists.ozlabs.org; 
linux-ker...@vger.kernel.org; Lukasz Majewski
Subject: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to 
system freq

The problem is visible in the following setup (on the imx6q):
"simple-audio-card" -> ssi2 -> I2S + I2C -> codec

The function call log (simple-card probe -> CONFIG_SND_SIMPLE_CARD):

asoc_simple_card_init_dai() @ sound/soc/generic/simple-card-utils.c
snd_soc_dai_set_sysclk()
fsl_ssi_set_dai_sysclk() @ sound/soc/fsl/fsl_ssi.c

The last call is changing the bit clock (BCLK) frequency to SSI's IP
block clock (ipg = 66 MHz) [1].
This is wrong, since IMX SSI block requires the I2S BCLK to be less
than 1/5 of [1].

As a result the driver initialization passes without any errors, but the
speaker-test test case breaks.

This commit checks if the fsl_ssi_set_dai_sysclk() frequency passed is
not equal to [1].

Signed-off-by: Lukasz Majewski <lu...@denx.de>
---
 sound/soc/fsl/fsl_ssi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 173cb84..1186fa9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -809,6 +809,8 @@ static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai 
*cpu_dai,
 int clk_id, unsigned int freq, int dir)
 {
 struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
+   if (clk_get_rate(ssi_private->clk) == freq)
+   return 0;

 ssi_private->bitclk_freq = freq;

--
2.1.4



Re: [alsa-devel] [PATCH v3] ASoC: fsl_dma: remove dma_object path member

2017-08-29 Thread Fabio Estevam
On Tue, Aug 29, 2017 at 9:37 AM, Rob Herring <r...@kernel.org> wrote:
> dma_object.path is unused, so rather than fix it to work with DT
> full_name changes, just remove it.
>
> Signed-off-by: Rob Herring <r...@kernel.org>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>


Re: [PATCH] fsl/fman: add dependency on HAS_DMA

2017-06-26 Thread Fabio Estevam
On Mon, Jun 26, 2017 at 12:12 PM, Madalin Bucur  wrote:
> A previous commit inserted a dependency on DMA API that requires
> HAS_DMA to be added in Kconfig.

It would be nice to specify the commit that caused this.


Re: [alsa-devel] [PATCH 1/1] ASoC: fsl_asrc: use dma_transfer_direction enum when calling dmaengine_prep_dma_cyclic

2017-01-15 Thread Fabio Estevam
On Sun, Jan 15, 2017 at 10:43 AM, Nicolas Iooss
<nicolas.iooss_li...@m4x.org> wrote:
> When fsl_asrc_dma_prepare_and_submit() calls
> dmaengine_prep_dma_cyclic(), it uses either DMA_TO_DEVICE or
> DMA_FROM_DEVICE. These values are both items of dma_data_direction enum,
> not of dma_data_direction enum, which is the type expected by
> dmaengine_prep_dma_cyclic().
>
> Replace DMA_TO_DEVICE with DMA_MEM_TO_DEV and DMA_FROM_DEVICE with
> DMA_DEV_TO_MEM to fix this type mismatch issue.
>
> Signed-off-by: Nicolas Iooss <nicolas.iooss_li...@m4x.org>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>


Re: [alsa-devel] [PATCH] fsl_ssi: set fifo watermark to more reliable value

2017-01-03 Thread Fabio Estevam
On Tue, Jan 3, 2017 at 4:22 PM, Caleb Crome <ccr...@gmail.com> wrote:
> From: Caleb Crome <ca...@crome.org>
>
> The fsl_ssi fifo watermark is by default set to 2 free spaces (i.e.
> activate DMA on FIFO when only 2 spaces are left.)  This means the
> DMA must service the fifo within 2 audio samples, which is just not
> enough time  for many use cases with high data rate.  In many
> configurations the audio channel slips (causing l/r swap in stereo
> configurations, or channel slipping in multi-channel configurations).
>
> This patch gives more breathing room and allows the SSI to operate
> reliably by changing the fifio refill watermark to 8.
>
> There is no change in behavior for older chips (with an 8-deep fifo).
> Only the newer chips with a 15-deep fifo get the new behavior. I
> suspect a new fifo depth setting could be optimized on the older
> chips too, but I have not tested.
>
> Signed-off-by: Caleb Crome <ca...@crome.org>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>


Re: [alsa-devel] [PATCH] ASoC : fsl_ssi : Correct the condition to check AC97 mode

2016-12-28 Thread Fabio Estevam
On Wed, Dec 28, 2016 at 9:06 AM, Harisangam, Sharvari (S.)
 wrote:
>  Corrected the condition to check if ssi is configured for AC97
>  mode. Other modes like dsp_a also satisfy the ANDing condition.
>
> Signed-off-by: Sharvari Harisangam 

This has been fixed in 4.3 kernel by commit:

5b64c173cdea211 ("ASoC: fsl_ssi: Fix checking of dai format for AC97 mode")


Re: [alsa-devel] Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1

2016-08-31 Thread Fabio Estevam
On Wed, Aug 31, 2016 at 2:49 PM, Xavi Drudis Ferran  wrote:

> Thank you amd feel free to suggest more tests, but it is good enough
> as it is for me.

Ok, thanks for trying. So let's keep the SPDIF parent clock as is.


Re: [alsa-devel] Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1

2016-08-31 Thread Fabio Estevam
Hi Xavi,

On Wed, Aug 31, 2016 at 10:47 AM, Xavi Drudis Ferran  wrote:

> If it's easy for you to send it yourself, I would prefer so and I'm
> grateful. If not, it'll be an exercise for me, no problem.

I have just submitted the patch with you on Cc.

If you could reply to it with your Tested-by tag, that would be great.

Thanks


Re: [alsa-devel] Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1

2016-08-31 Thread Fabio Estevam
Xavi,

On Wed, Aug 31, 2016 at 10:11 AM, Fabio Estevam <feste...@gmail.com> wrote:

> Xavi,
>
> Care to send a formal patch with your change?

If you prefer, I can send this change to the ARM kernel mailing list.

Please let me know what you prefer.

Thanks


Re: [alsa-devel] Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1

2016-08-31 Thread Fabio Estevam
Hi Xavi/Nicolin,

On Wed, Aug 31, 2016 at 6:10 AM, Xavi Drudis Ferran <xdru...@tinet.cat> wrote:
> El Tue, Aug 30, 2016 at 09:21:01PM -0700, Nicolin Chen deia:
>>
>> No, the problem is not at the rate but the source -- Although the
>> MLB clock exists in the clock tree as a better rate provider, it
>> might not be correctly enabled or running at the rate it claims.
>>
>
>>
>> There are five MLB clocks sharing the same clock gate according
>> to CCM chapter in the Reference Manual of imx6q. But five clocks
>> come from three different parent clocks, and I am wondering if
>> the MLB clock that's connected to the S/PDIF module is really
>> derived from this AXI.
>>
>> Hope Fabio might be able to help on the clock tree issue here:)
>>
>
> I hope too, it's a little over my head, to be euphemistic.
>
>>
>> Another solution for you could be to change the rates of two of
>> those existing clocks to the perfect rates for 44.1KHz and 48KHz
>> respectively, 22579200Hz and 24576000Hz for example. (If you
>> only need one sample rate support, changing rxtx1 SPDIF clock
>> only then.)
>
> Thank you very much.  I'm not sure what practical problem that would
> solve for me, audio sounds quite right to my ears with the workaround
> (disabling MLB). I've looked page 121 of
> http://cache.freescale.com/files/32bit/doc/data_sheet/IMX6DQIEC.pdf
> And it seems like the the margin for the SPDIF clock would be 16 ns
> and I'm like 10 times out of spec. But I can't hear the problem.  I
> may try it one day to hear how it sounds.
>
> I'll try to remember it if I ever come across some problem with my audio.
> For now what I'd like is to stay as close to linux-libre mainline
> as possible, so the quick workaround is enough for me.
>
> Now for the general case, I'm not sure what the solution should be.
> Page 4 of the pdf above says MLB is not present in industrial "parts",
> only automotive, or consumer "parts". There are several versions of
> IMX6Q in the market.  What version must I have ? I guess consumer
> (with MLB) but I'm not sure... According to the wandboard-quad-rev-b1
> manual its consumer, MCIMX6Q5EYM10AC, so I should have MLB, I guess.
>
> $ cat /proc/cpuinfo
> processor  : 0
> model name : ARMv7 Processor rev 10 (v7l)
> BogoMIPS   : 7.54
> Features   : half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
> vfpd32
> CPU implementer: 0x41
> CPU architecture: 7
> CPU variant   : 0x2
> CPU part  : 0xc09
> CPU revision  : 10
> [...]
>
> I can't tell what CPU part : 0xc09 means.
>
> In the reference manual pg 796 I see the same gate seems to affect Media
> Local Bus (MLB) clock and Digital Transmission Content Protection
> (DTCP). I don't use DTCP but I haven't done anything to disable it.
>
> http://www.nxp.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fasp=1_TYPE=Reference%20Manuals_VENDOR=FREESCALE_FILE_FORMAT=pdf_ASSET=Documentation=.pdf

Sorry for the delay.

As far as I can see, there are two current issues:

1. Regression caused by: 833f2cbf7091099bae ("ARM: dts: imx6: change
the core clock of spdif").

Looks like that this commit did much more than just changing the core
clock of spdif.

It does not mention why MLB clock has been added. Looking at MX6Q RM I
do not see the connection between MLB and SPDIF.

So I agree with Xavi's suggestion of using the dummy_clk instead of mlb clock.

Xavi,

Care to send a formal patch with your change?

2. SPDIF clock rate not accurate. Probably using PLL4 as SPDIF source
would help to get more accurate SPDIF clock rates.

Could you please try the untested change?

--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -623,7 +623,7 @@ static void __init imx6q_clocks_init(struct
device_node *ccm_node)
pr_warn("failed to set up CLKO: %d\n", ret);

/* Audio-related clocks configuration */
-   clk_set_parent(clk[IMX6QDL_CLK_SPDIF_SEL],
clk[IMX6QDL_CLK_PLL3_PFD3_454M]);
+   clk_set_parent(clk[IMX6QDL_CLK_SPDIF_SEL],
clk[IMX6QDL_CLK_PLL4_AUDIO_DIV]);

/* All existing boards with PCIe use LVDS1 */
if (IS_ENABLED(CONFIG_PCI_IMX6))

Regards,

Fabio Estevam


Re: [PATCH 0/2] Support non-ssi cpu-dai for sgtl5000

2016-08-29 Thread Fabio Estevam
On Mon, Aug 29, 2016 at 7:51 AM, Winter Wang  wrote:
> These patches support sgtl5000 to be attached to other non-ssi cpu-dais like 
> SAI.

Do we really need this?

We can use SAI with sgtl5000 just fine via simple card. Take a look at:
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/arch/arm/boot/dts/imx6ul-14x14-evk.dts?h=imx/fixes=bf3251e112a0139c8dec796c9f12f2e8f01a73ca


Re: [alsa-devel] [PATCH v2 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

2016-04-28 Thread Fabio Estevam
On Mon, Apr 25, 2016 at 3:36 PM, Caleb Crome <ca...@crome.org> wrote:
> The CCSR_SSI_SOR is a register that clears the TX and/or the RX fifo
> on the i.MX SSI port.  The fsl_ssi_trigger writes this register in
> order to clear the fifo at trigger time.
>
> However, since the CCSR_SSI_SOR register is not in the volatile list,
> the caching mechanism prevented the register write in the trigger
> function.  This caused the fifo to not be cleared (because the value
> was unchanged from the last time the register was written), and thus
> causes the channels in both TDM or simple I2S mode to slip and be in
> the wrong time slots on SSI restart.
>
> This has gone unnoticed for so long because with simple stereo mode,
> the consequence is that left and right are swapped, which isn't that
> noticeable.  However, it's catestrophic in some systems that
> require the channels to be in the right slots.
>
> Signed-off-by: Caleb Crome <ca...@crome.org>
> Suggested-by: Arnaud Mouiche <arnaud.moui...@invoxia.com>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults

2016-02-01 Thread Fabio Estevam
On Mon, Feb 1, 2016 at 7:30 PM, Maciej S. Szmigiero
 wrote:

> So can regcache initialization be changed to use register by register read
> in case raw read fails?
>
> Since other option for drivers like SSI which are memory mapped and
> don't offer ability to reset their register values to default would be to
> explicitly write driver hardcoded defaults also by doing
> register by register write on probe time.

Yes, I had to do the same for sgtl5000:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/soc/codecs/sgtl5000.c?id=af8ee11209e749c75eabf32b2a4ca631f396acf8

Would this approach work here too?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults

2016-02-01 Thread Fabio Estevam
Hi Maciej,

On Mon, Jan 18, 2016 at 5:07 PM, Maciej S. Szmigiero
 wrote:
> There is no guarantee that on fsl_ssi module load
> SSI registers will have their power-on-reset values.
>
> In fact, if the driver is reloaded the values in
> registers will be whatever they were set to previously.
>
> However, the cache needs to be fully populated at probe
> time to avoid non-atomic allocations during register
> access.
>
> Special case here is imx21-class SSI, since
> according to datasheet it don't have SACC{ST,EN,DIS}
> regs.
>
> This fixes hard lockup on fsl_ssi module reload,
> at least in AC'97 mode.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support 
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero 

I know I have already tested this and it worked fine on a mx6sabresd,
but running linux-next 20160201 on a mx6sl-evk the ssi driver does not
probe anymore:

[2.216954] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered
[2.223412] fsl-asoc-card sound: snd_soc_register_card failed (-517)
[2.230258] imx-wm8962 sound: ASoC: CPU DAI 202c000.ssi not registered
[2.236806] imx-wm8962 sound: snd_soc_register_card failed (-517)
[2.244782] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock
to 1970-01-01 00:01:14 UTC (74)
[2.285864] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered
[2.292335] fsl-asoc-card sound: snd_soc_register_card failed (-517)
[2.299572] imx-wm8962 sound: ASoC: CPU DAI 202c000.ssi not registered
[2.306121] imx-wm8962 sound: snd_soc_register_card failed (-517)

Reverting this patch fixes the problem.

Wandboard also has the same issue:

http://arm-soc.lixom.net/bootlogs/next/next-20160201/wandboard-arm-imx_v6_v7_defconfig.html

Any suggestions?

Thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults

2016-02-01 Thread Fabio Estevam
Hi Maciej,

On Mon, Feb 1, 2016 at 10:07 AM, Maciej S. Szmigiero
 wrote:
> Is regmap patch from
> http://www.spinics.net/lists/kernel/msg2161934.html
> applied to the tested tree?

Yes, linux-next 20160201 contains this patch.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

2016-01-18 Thread Fabio Estevam
Hi Maciej,

On Sun, Jan 17, 2016 at 8:02 PM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:

> Patch updated according to Timur's suggestions (needs regmap fix):
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c

Tested your patch against linux-next and it did not give me any warnings:

Tested-by: Fabio Estevam <fabio.este...@nxp.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults

2016-01-18 Thread Fabio Estevam
On Mon, Jan 18, 2016 at 5:07 PM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:
> There is no guarantee that on fsl_ssi module load
> SSI registers will have their power-on-reset values.
>
> In fact, if the driver is reloaded the values in
> registers will be whatever they were set to previously.
>
> However, the cache needs to be fully populated at probe
> time to avoid non-atomic allocations during register
> access.
>
> Special case here is imx21-class SSI, since
> according to datasheet it don't have SACC{ST,EN,DIS}
> regs.
>
> This fixes hard lockup on fsl_ssi module reload,
> at least in AC'97 mode.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support 
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>

Tested-by: Fabio Estevam <fabio.este...@nxp.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

2016-01-13 Thread Fabio Estevam
On Tue, Jan 12, 2016 at 4:13 PM, Lothar Waßmann  
wrote:

> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 14dfdee..c128823 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -258,7 +258,8 @@ config SND_SOC_IMX_SGTL5000
> select SND_SOC_SGTL5000
> select SND_SOC_IMX_PCM_DMA
> select SND_SOC_IMX_AUDMUX
> -   select SND_SOC_FSL_SSI
> +   select SND_SOC_FSL_SAI if SOC_IMX6UL
> +   select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX

MX6SX has SSI and SAI interfaces.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

2016-01-11 Thread Fabio Estevam
Hi Maciej,

On Sun, Dec 20, 2015 at 6:33 PM, Maciej S. Szmigiero
 wrote:
> There is no guarantee that on fsl_ssi module load
> SSI registers will have their power-on-reset values.
>
> In fact, if the driver is reloaded the values in
> registers will be whatever they were set to previously.
>
> This fixes hard lockup on fsl_ssi module reload,
> at least in AC'97 mode.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support 
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero 

This patch causes the following issue in linux-next:

[2.526984] [ cut here ]
[2.531632] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:2755
lockdep_trace_alloc+0xf4/0x124()
[2.540771] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[2.546175] Modules linked in:
[2.549447] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.4.0-rc8-next-20160111 #204
[2.557021] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[2.563553] Backtrace:
[2.566040] [] (dump_backtrace) from []
(show_stack+0x18/0x1c)
[2.573615]  r6:0ac3 r5: r4: r3:
[2.579362] [] (show_stack) from []
(dump_stack+0x88/0xa4)
[2.586607] [] (dump_stack) from []
(warn_slowpath_common+0x80/0xbc)
[2.594702]  r5:c0071ed0 r4:ef055b90
[2.598326] [] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x38/0x40)
[2.607028]  r8:0004 r7:0004 r6:024080c0 r5:024080c0 r4:6093
[2.613829] [] (warn_slowpath_fmt) from []
(lockdep_trace_alloc+0xf4/0x124)
[2.622532]  r3:c09a1634 r2:c099dc0c
[2.626161] [] (lockdep_trace_alloc) from []
(kmem_cache_alloc+0x30/0x174)
[2.634778]  r4:ef001f00 r3:c0b02a88
[2.638407] [] (kmem_cache_alloc) from []
(regcache_rbtree_write+0x150/0x724)
[2.647283]  r10: r9:0010 r8:0004 r7:0004
r6:002c r5:
[2.655203]  r4:
[2.657767] [] (regcache_rbtree_write) from []
(regcache_write+0x5c/0x64)
[2.666295]  r10:ef0f1c80 r9:ef0f6500 r8:0001 r7:ef055cbc
r6:0010 r5:
[2.674215]  r4:eeaaf000
[2.676778] [] (regcache_write) from []
(_regmap_read+0xa8/0xc0)
[2.684526]  r6:
[2.685780] mmc2: new DDR MMC card at address 0001
[2.686495] mmcblk1: mmc2:0001 SEM08G 7.40 GiB
[2.686792] mmcblk1boot0: mmc2:0001 SEM08G partition 1 2.00 MiB
[2.687092] mmcblk1boot1: mmc2:0001 SEM08G partition 2 2.00 MiB
[2.687388] mmcblk1rpmb: mmc2:0001 SEM08G partition 3 128 KiB
[2.713792]  r5:0010 r4:eeaaf000 r3:
[2.718660] [] (_regmap_read) from []
(regmap_read+0x44/0x64)
[2.726147]  r7:1000 r6:ef055cbc r5:0010 r4:eeaaf000
[2.731890] [] (regmap_read) from []
(_fsl_ssi_set_dai_fmt+0xa4/0x440)
[2.740159]  r6:1001 r5:eeaaf000 r4:eeaaee10 r3:01400454
[2.745897] [] (_fsl_ssi_set_dai_fmt) from []
(fsl_ssi_set_dai_fmt+0x1c/0x20)
[2.754773]  r10:ef0f1c80 r8:ef118800 r7:1001 r6:
r5:0001 r4:ef0f1700
[2.762706] [] (fsl_ssi_set_dai_fmt) from []
(snd_soc_runtime_set_dai_fmt+0x104/0x154)
[2.772375] [] (snd_soc_runtime_set_dai_fmt) from
[] (snd_soc_register_card+0xc14/0xdd0)
[2.782206]  r10:eeaa889c r9:0002 r8:eeaa8810 r7:ef118800
r6:0001 r5:
[2.790126]  r4:ef0f1c80 r3:
[2.793750] [] (snd_soc_register_card) from []
(devm_snd_soc_register_card+0x38/0x78)
[2.803321]  r10:ef20b420 r9: r8:eeaa8810 r7:ef1cf410
r6:eeaa889c r5:ef0f6490
[2.811240]  r4:eeaa889c
[2.813806] [] (devm_snd_soc_register_card) from
[] (imx_wm8962_probe+0x2fc/0x3a0)
[2.823116]  r7:ef1cf410 r6:eeaa889c r5:c085ad98 r4:ef1cf400
[2.828858] [] (imx_wm8962_probe) from []
(platform_drv_probe+0x58/0xb4)
[2.837300]  r10: r9:00de r8:c0b645f4 r7:c0b645f4
r6:fdfb r5:ef1cf410
[2.845220]  r4:fffe
[2.847788] [] (platform_drv_probe) from []
(driver_probe_device+0x1f8/0x2b4)
[2.856665]  r7: r6:c1379780 r5:c1379778 r4:ef1cf410
[2.862405] [] (driver_probe_device) from []
(__driver_attach+0x9c/0xa0)
[2.870846]  r10: r8:c0ad7b30 r7: r6:ef1cf444
r5:c0b645f4 r4:ef1cf410
[2.878776] [] (__driver_attach) from []
(bus_for_each_dev+0x5c/0x90)
[2.886956]  r6:c03d27b8 r5:c0b645f4 r4: r3:ef1b695c
[2.892695] [] (bus_for_each_dev) from []
(driver_attach+0x20/0x28)
[2.900703]  r6:c0b2f9f0 r5:ef0f1400 r4:c0b645f4
[2.905383] [] (driver_attach) from []
(bus_add_driver+0xec/0x1fc)
[2.913313] [] (bus_add_driver) from []
(driver_register+0x80/0xfc)
[2.921320]  r7:c0ae684c r6:ef0f63c0 r5:c0b06188 r4:c0b645f4
[2.927059] [] (driver_register) from []
(__platform_driver_register+0x38/0x4c)
[2.936109]  r5:c0b06188 r4:c0b06188
[2.939733] [] (__platform_driver_register) from
[] (imx_wm8962_driver_init+0x18/0x20)
[2.949398] [] (imx_wm8962_driver_init) from []
(do_one_initcall+0x88/0x1e4)
[2.958200] [] (do_one_initcall) 

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

2016-01-11 Thread Fabio Estevam
On Mon, Jan 11, 2016 at 10:04 AM, Fabio Estevam <feste...@gmail.com> wrote:

> This patch causes the following issue in linux-next:
>
> [2.526984] [ cut here ]
> [2.531632] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:2755
> lockdep_trace_alloc+0xf4/0x124()
> [2.540771] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [2.546175] Modules linked in:
> [2.549447] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.4.0-rc8-next-20160111 #204
> [2.557021] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [2.563553] Backtrace:
> [2.566040] [] (dump_backtrace) from []
> (show_stack+0x18/0x1c)
> [2.573615]  r6:0ac3 r5: r4: r3:
> [2.579362] [] (show_stack) from []
> (dump_stack+0x88/0xa4)
> [2.586607] [] (dump_stack) from []
> (warn_slowpath_common+0x80/0xbc)
> [2.594702]  r5:c0071ed0 r4:ef055b90
> [2.598326] [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x38/0x40)
> [2.607028]  r8:0004 r7:0004 r6:024080c0 r5:024080c0 r4:6093
> [2.613829] [] (warn_slowpath_fmt) from []
> (lockdep_trace_alloc+0xf4/0x124)
> [2.622532]  r3:c09a1634 r2:c099dc0c
> [2.626161] [] (lockdep_trace_alloc) from []
> (kmem_cache_alloc+0x30/0x174)
> [2.634778]  r4:ef001f00 r3:c0b02a88
> [2.638407] [] (kmem_cache_alloc) from []
> (regcache_rbtree_write+0x150/0x724)
> [2.647283]  r10: r9:0010 r8:0004 r7:0004
> r6:002c r5:
> [2.655203]  r4:
> [2.657767] [] (regcache_rbtree_write) from []
> (regcache_write+0x5c/0x64)

This fixes the warning:

--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -180,7 +180,6 @@ static const struct regmap_config fsl_ssi_regconfig = {
.volatile_reg = fsl_ssi_volatile_reg,
.precious_reg = fsl_ssi_precious_reg,
.writeable_reg = fsl_ssi_writeable_reg,
-   .cache_type = REGCACHE_RBTREE,
 };

Is this the correct fix?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

2016-01-11 Thread Fabio Estevam
Hi Maciej,

On Mon, Jan 11, 2016 at 11:57 AM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:
> Hi Fabio,

> This will disable register cache so it isn't right.
> Could you try REGCACHE_FLAT instead, please?

Yes, with REGCACHE_FLAT I don't get the warning.

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 1/3] ASoC: fsl_ssi: mark SACNT register volatile

2016-01-05 Thread Fabio Estevam
Timur,

On Thu, Dec 24, 2015 at 2:12 PM, Timur Tabi  wrote:
> On Sun, Dec 20, 2015 at 2:30 PM, Maciej S. Szmigiero
>  wrote:
>> SACNT register should be marked volatile since
>> its WR and RD bits are cleared by SSI after
>> completing the relevant operation.
>> This unbreaks AC'97 register access.
>>
>> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to 
>> support MEGA Fast")
>>
>> Signed-off-by: Maciej S. Szmigiero 
>
> These patches seem okay, but can we hold off merging them until I get
> back from vacation and have a chance to review them?

Have you had a chance to review these patches?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/3] ASoC: fsl_ssi: mark some registers precious

2015-12-23 Thread Fabio Estevam
On Sun, Dec 20, 2015 at 6:31 PM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:
> Mark some registers precious since their
> reads have side effects (like clearing flags).
>
> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

2015-12-23 Thread Fabio Estevam
On Sun, Dec 20, 2015 at 6:33 PM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:
> There is no guarantee that on fsl_ssi module load
> SSI registers will have their power-on-reset values.
>
> In fact, if the driver is reloaded the values in
> registers will be whatever they were set to previously.
>
> This fixes hard lockup on fsl_ssi module reload,
> at least in AC'97 mode.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support 
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] ASoC: fsl_ssi: mark SACNT register volatile

2015-12-23 Thread Fabio Estevam
On Sun, Dec 20, 2015 at 6:30 PM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:
> SACNT register should be marked volatile since
> its WR and RD bits are cleared by SSI after
> completing the relevant operation.
> This unbreaks AC'97 register access.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support 
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>

Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access

2015-07-30 Thread Fabio Estevam
Hi Maciej,

On Thu, Jul 30, 2015 at 11:33 AM, Maciej S. Szmigiero
m...@maciej.szmigiero.name wrote:

  static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
 @@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct 
 snd_ac97 *ac97,
 unsigned short val = -1;
 u32 reg_val;
 unsigned int lreg;
 +   int ret;
 +
 +   ret = clk_prepare_enable(fsl_ac97_data-clk);
 +   if (ret) {
 +   pr_err(ac97 read clk_prepare_enable failed: %d\n,
 +   ret);
 +   return -1;

return ret, please.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 1/3] ASoC: fsl_esai: Add driver suspend and resume to support MEGA Fast

2015-07-06 Thread Fabio Estevam
On Mon, Jul 6, 2015 at 6:50 AM, Zidan Wang zidan.w...@freescale.com wrote:
 For i.MX6 SoloX, there is a mode of the SoC to shutdown all power source of
 modules during system suspend and resume procedure. Thus, SAI needs to save

You meant ESAI, not SAI.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 2/3] ASoC: fsl_spdif: Add driver suspend and resume to support MEGA Fast

2015-07-06 Thread Fabio Estevam
On Mon, Jul 6, 2015 at 6:50 AM, Zidan Wang zidan.w...@freescale.com wrote:
 For i.MX6 SoloX, there is a mode of the SoC to shutdown all power source of
 modules during system suspend and resume procedure. Thus, SAI needs to save

s/SAI/SPDIF
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode

2015-06-27 Thread Fabio Estevam
Hi Maciej,

On Sat, Jun 27, 2015 at 7:51 PM, Maciej S. Szmigiero
m...@maciej.szmigiero.name wrote:
 Currently the AC'97 mode in fsl_ssi driver isn't functional.

Thanks for the fix. I look forward to test it on my udoo board.

 This patch implements the following changes to make it work
 properly:
 * IPG clock have to be enabled during AC'97 CODEC
 register access,
 * AC'97 DAI driver struct need the same probe method as
 I2S one to setup DMA params,
 * AC'97 bus can support asymmetric playback/capture rates,
 * Check whether setting AC'97 ops succeeded and
 clean them on removal so the driver can be reloaded,
 * AC'97 CODEC will be instantiated in AC'97 mode,
 * Set DAI format function small fixes in AC'97 mode.

It seems like a lot of changes in a single patch.

Care to split it into smaller pieces?

Thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode

2015-06-27 Thread Fabio Estevam
On Sat, Jun 27, 2015 at 7:51 PM, Maciej S. Szmigiero
m...@maciej.szmigiero.name wrote:

 +
 +   ret = clk_prepare_enable(fsl_ac97_data-clk);
 +   if (ret) {
 +   pr_err(ac97 read clk_prepare_enable failed: %d\n,
 +   ret);
 +   return -1;

'return ret' would be better here.

Thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH] ASoC: fsl_spdif: Don't try to round-up for clock divisor calculation

2015-05-25 Thread Fabio Estevam
Hi Nicolin,

On Mon, May 25, 2015 at 12:11 PM, Nicolin Chen nicoleots...@gmail.com wrote:

 Hi Mark,

 Is that possible for you to provisionally revert this patch?
 I wanted to wait for the test result from Fabio or Zidan in
 the Cc list because I don't have a test environment for SPDIF
 even though this change seems to make sense.

I currently don't have access to a SPDIF receiver to test it.

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 0/3] Add master mode, tmd and right-j mode support

2015-01-20 Thread Fabio Estevam
Hi Zidan,

On Tue, Jan 20, 2015 at 10:21 AM, Zidan Wang zidan.w...@freescale.com wrote:
 Add sai master mode support.
 Add tdm slots support.
 Add Right-J mode support.

 Zidan Wang (3):
   SoC: fsl_sai: add sai master mode support
   ASoC: fsl_sai: Add support for tdm slots operation
   ASoC: fsl_sai: Add support for Right-J mode

  sound/soc/fsl/fsl_sai.c | 164 
 
  sound/soc/fsl/fsl_sai.h |  13 +++-
  2 files changed, 164 insertions(+), 13 deletions(-)

Not related to your series, but do you have a patch for imx6sx-sdb.dts
that adds sai support?

In the FSL version they use 'fsl,sdma-event-remap' property to specify
the SAI sdma channels, but this is not present in mainline? How are
you dealing with it?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PROBLEM: USB isochronous urb leak on EHCI driver

2015-01-05 Thread Fabio Estevam
On Mon, Jan 5, 2015 at 1:12 PM, Michael Tessier
michael.tess...@axiontech.ca wrote:

 If sound is ok when using only 1 codec and becomes choppy when adding a
 second codec, then it means that this issue is still in the 3.x kernel. This
 answer will tell me if it is worth working on using a newer kernel or not.
 I have to say that I'm not a linux expert, so I see the migration to a newer
 kernel as a quite big amount of work...

We have support for mx51 on the latest kernel. All you need to do is
to describe your hardware on a device tree file. You can refer to
arch/arm/boot/dts/imx51-babbage.dts as an example.

Should be simple for you to make such test with the latest kernel.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PROBLEM: USB isochronous urb leak on EHCI driver

2014-12-15 Thread Fabio Estevam
On Mon, Dec 15, 2014 at 6:53 PM, Michael Tessier
michael.tess...@axiontech.ca wrote:

 Before attempting to upgrade to an earlier kernel driver (this is
 a fairly big amount of work), I would really like to know if this
 problem would still be in the 3.x kernels. Has anyone seen that
 issue in 3.x kernels?

In fact it is very simple to test USB on a 3.18 kernel with your hardware.

You only need a minimal dts file with the usb/serial nodes enabled.

Take a loot at arch/arm/boot/dts/imx51-babbage.dts for a reference.

I tested USB earlier today on this board with 3.18 and it worked fine.
You need this patch:
http://www.spinics.net/lists/arm-kernel/msg385739.html

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

2014-12-01 Thread Fabio Estevam
On Mon, Dec 1, 2014 at 6:30 PM, Lars-Peter Clausen l...@metafoo.de wrote:
 On 12/01/2014 09:11 PM, Timur Tabi wrote:

 On 12/01/2014 02:01 PM, Arnd Bergmann wrote:

 Does this mean that fsl_ssi.c should not be calling
 irq_of_parse_and_map?  How else should it get the IRQ?

 platform_get_irq()


 Ok, but that function also calls irq_create_of_mapping().  So it still
 appears that the only way to get the IRQ is to map it, but then we can't
 use
 devm_request_irq().


 Hm... that's new. But it's not really a driver issue anymore if it is done
 in the core. So I guess for now just use platform_get_irq() and ignore the
 other issue.

With the suggested changes below, the removal of the driver works fine on a mx6:

root@freescale /$ modprobe   snd-soc-fsl-ssi
root@freescale /$ modprobe snd-soc-imx-wm8962
[  319.517679] input: WM8962 Beep Generator as
/devices/soc0/soc/210.aips-bus/21a.i2c/i2c-0/0-001a/input/input7
[  319.543225] imx-wm8962 sound: wm8962 - 202c000.ssi mapping ok
root@freescale /$ rmmod  snd-soc-imx-wm8962
root@freescale /$ rmmod   snd-soc-fsl-ssi

 sound/soc/fsl/fsl_ssi.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 32a31d9..c528f16 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1361,7 +1361,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 return PTR_ERR(ssi_private-regs);
 }

-ssi_private-irq = irq_of_parse_and_map(np, 0);
+ssi_private-irq = platform_get_irq(pdev, 0);
 if (!ssi_private-irq) {
 dev_err(pdev-dev, no irq for node %s\n, np-full_name);
 return -ENXIO;
@@ -1387,7 +1387,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 if (ssi_private-soc-imx) {
 ret = fsl_ssi_imx_probe(pdev, ssi_private, iomem);
 if (ret)
-goto error_irqmap;
+return ret;
 }

 ret = snd_soc_register_component(pdev-dev, fsl_ssi_component,
@@ -1458,10 +1458,6 @@ error_asoc_register:
 if (ssi_private-soc-imx)
 fsl_ssi_imx_clean(pdev, ssi_private);

-error_irqmap:
-if (ssi_private-use_dma)
-irq_dispose_mapping(ssi_private-irq);
-
 return ret;
 }

@@ -1478,9 +1474,6 @@ static int fsl_ssi_remove(struct platform_device *pdev)
 if (ssi_private-soc-imx)
 fsl_ssi_imx_clean(pdev, ssi_private);

-if (ssi_private-use_dma)
-irq_dispose_mapping(ssi_private-irq);
-
 return 0;
 }

-- 
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

2014-12-01 Thread Fabio Estevam
On Mon, Dec 1, 2014 at 6:42 PM, Timur Tabi ti...@tabi.org wrote:

 Would the mapping continue to exist after the driver is unloaded?  Can you
 try multiple loads/unloads and see if interrupts still work?

I tried multiple loads/unloads and audio works fine with those changes.

About the ssi irq we have:

- With the ssi driver loaded:
root@freescale /home$ cat /proc/interrupts | grep ssi
 79:  0  0  0  0   GIC  79  202c000.ssi

- After removing the ssi driver:
root@freescale /home$ rmmod   snd-soc-fsl-ssi
root@freescale /home$ cat /proc/interrupts | grep ssi
root@freescale /home$

,so it seems to behave properly.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: Set default slot number for common cases

2014-01-09 Thread Fabio Estevam
On Thu, Jan 9, 2014 at 7:41 AM, Nicolin Chen guangyu.c...@freescale.com wrote:
 For those platforms using DAI master mode like I2S, it's better to pre-set
 a default slot number so that there's no need for these common cases to set
 the slot number from its machine driver any more.

 Signed-off-by: Nicolin Chen guangyu.c...@freescale.com
 ---
  sound/soc/fsl/fsl_ssi.c | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
 index 94dedcb..57ab45b 100644
 --- a/sound/soc/fsl/fsl_ssi.c
 +++ b/sound/soc/fsl/fsl_ssi.c
 @@ -711,6 +711,16 @@ static int fsl_ssi_setup(struct fsl_ssi_private 
 *ssi_private)
 if (ssi_private-imx_ac97)
 fsl_ssi_setup_ac97(ssi_private);

 +   /* Set a default slot number so that there is no need for those common
 +* cases like I2S mode to call the extra set_tdm_slot() any more.
 +*/

Incorrect style for multi-line comment.

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: Set default slot number for common cases

2014-01-09 Thread Fabio Estevam
On Thu, Jan 9, 2014 at 8:34 AM, Nicolin Chen guangyu.c...@freescale.com wrote:

 Is this for the initial line? The CodingStyle contains two types of multi-line

Yes, correct.

 comment, one of which drops the initial line just like mine, even though it's
 saying 'For files in net/ and drivers/net/ the preferred style', so I thought
 it shouldn't be quite bother.

Yes, net and drivers/net are different and checkpatch reports it accordingly.

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: Fixed wrong printf format identifier

2014-01-07 Thread Fabio Estevam
On Tue, Jan 7, 2014 at 4:04 AM, Alexander Shiyan shc_w...@mail.ru wrote:
 sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe':
 sound/soc/fsl/fsl_ssi.c:1180:6: warning: format '%d' expects argument
 of type 'int', but argument 3 has type 'long int' [-Wformat=]

 Reported-by: kbuild test robot fengguang...@intel.com
 Signed-off-by: Alexander Shiyan shc_w...@mail.ru

I have sent the same fix as well as I haven't seen your patch before I
submitted mine.

It is usually a good idea to specify in the commit log what was the
commit that caused the warning.

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [alsa-devel] [PATCH v4 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver

2013-08-13 Thread Fabio Estevam
On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
 +Required properties:
 +
 +  - compatible : Compatible list, contains fsl,chip-spdif. Using general

Can't we just use fsl,fsl-spdif instead?

 +  fsl,fsl-spdif will get the default SoC type -- imx6q-spdif.
 +

I think this is not the usual approach we do with dt.

 +static const struct of_device_id fsl_spdif_dt_ids[] = {
 +   { .compatible = fsl,fsl-spdif, },

Isn't only the first entry enough here?

 +   { .compatible = fsl,imx6q-spdif, },
 +   { .compatible = fsl,imx6sl-spdif, },
 +   { .compatible = fsl,imx53-spdif, },
 +   {}
 +};
 +MODULE_DEVICE_TABLE(of, fsl_spdif_dt_ids);
 +
 +static struct platform_driver fsl_spdif_driver = {
 +   .driver = {
 +   .name = fsl-spdif-dai,
 +   .owner = THIS_MODULE,
 +   .of_match_table = fsl_spdif_dt_ids,
 +   },
 +   .probe = fsl_spdif_probe,
 +   .remove = fsl_spdif_remove,
 +};
 +
 +module_platform_driver(fsl_spdif_driver);
 +
 +MODULE_AUTHOR(Freescale Semiconductor, Inc.);
 +MODULE_DESCRIPTION(Freescale S/PDIF CPU DAI Driver);
 +MODULE_LICENSE(GPL v2);
 +MODULE_ALIAS(platform:fsl_spdif);

This MODULE_ALIAS name does not match the name you provided earlier:

.name = fsl-spdif-dai
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [alsa-devel] [PATCH v4 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver

2013-08-13 Thread Fabio Estevam
On Tue, Aug 13, 2013 at 2:58 PM, Fabio Estevam feste...@gmail.com wrote:
 On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen b42...@freescale.com wrote:
 +Required properties:
 +
 +  - compatible : Compatible list, contains fsl,chip-spdif. Using general

 Can't we just use fsl,fsl-spdif instead?

Or maybe fsl,imx35-spdif, since mx35 was the first imx SoC with this
spdif IP block.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] of: use platform_device_add

2013-02-17 Thread Fabio Estevam
On Sun, Feb 17, 2013 at 4:43 AM, Shawn Guo shawn@linaro.org wrote:
 On Sun, Feb 17, 2013 at 11:03:35AM +0800, Shawn Guo wrote:
 On Fri, Jan 18, 2013 at 01:40:00AM +, Grant Likely wrote:
  This allows platform_device_add a chance to call insert_resource on all
  of the resources from OF. At a minimum this fills in proc/iomem and
  presumably makes resource tracking and conflict detection work better.
  However, it has the side effect of moving all OF generated platform
  devices from /sys/devices to /sys/devices/platform/. It /shouldn't/
  break userspace because userspace is not supposed to depend on the full
  path (because userspace always does what it is supposed to, right?).
 
  This may cause breakage if either:
  1) any two nodes in a given device tree have overlapping  staggered
 regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained
 within the other). In this case one of the devices will fail to
 register and an exception will be needed in platform_device_add() to
 complain but not fail.

 Grant,

 The patch introduce a regression on imx6q boot.

 It also breaks all of_amba_device users.

 of_amba_device_create() -- amba_device_add() -- request_resource()
 and fails.

Yes, correct: amba-pl011 does not register anymore after this patch,
which causes the serial console to be not functional.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Fabio Estevam
On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen peter.c...@freescale.com wrote:

 /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
 -   if (!cpu_is_mx51()) {
 +   if (!strcmp(pdev-id_entry-name, imx-udc-mx27)) {]]

Shouldn't this be:
 if (!strcmp(pdev-id_entry-name, imx-udc-mx51))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Fabio Estevam
On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann l...@karo-electronics.de 
wrote:

 The equivalent of !cpu_is_mx51() would be
 strcmp(pdev-id_entry-name, imx-udc-mx51) (without the '!') meaning
 id_entry-name is different from imx-udc-mx51.

Yes, agree.

strcmp(pdev-id_entry-name, imx-udc-mx51) is also better than
!strcmp(pdev-id_entry-name, imx-udc-mx27))

because in the case of another soc entry gets added, let's say
imx-udc-mxyy then

!strcmp(pdev-id_entry-name, imx-udc-mx27)) will not correspond to
!cpu_is_mx51() anymore.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD

2012-06-12 Thread Fabio Estevam
On Tue, Jun 12, 2012 at 4:40 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:

 Thanks for your patch. It does indeed load
 Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
 fine - but now when I want to use it:

 modprobe g_ether
 [   17.099363] g_ether gadget: using random self ethernet address
 [   17.105316] g_ether gadget: using random host ethernet address
 [   17.111974] usb0: MAC 1a:c7:9e:76:cc:45
 [   17.115866] usb0: HOST MAC 66:a2:4a:0a:46:17
 [   17.120199] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
 [   17.126861] g_ether gadget: g_ether ready

 these are the last words: System hangs completely. Same behavior with
 g_serial (these two I've tested).

Ok, I just sent a new patch to the linux-usb mailing list.

Tested it on a mx31 and mx51 and it probed g_ether fine. I don't have
a mx35 handy.


 Currently I can't investigate this further, not because of a bug - but a
 flu.

Hope you get better soon.

Regards,

Fabio Estevam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD

2012-06-10 Thread Fabio Estevam
Hi Christoph,

On Mon, Jun 4, 2012 at 8:37 AM, Christoph Fritz
chf.fr...@googlemail.com wrote:

 After that, I stumbled upon this dmesg:

 Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
 fsl-usb2-udc fsl-usb2-udc: clk_get(usb) failed
 fsl-usb2-udc: probe of fsl-usb2-udc failed with error -2

 Sascha, could you give me a hint?

Does the patch below fix your problem?

 drivers/usb/gadget/fsl_mxc_udc.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index dcbc0a2..c3ade6b 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -36,21 +36,21 @@ int fsl_udc_clk_init(struct platform_device *pdev)
pdata = pdev-dev.platform_data;

if (!cpu_is_mx35()  !cpu_is_mx25()) {
-   mxc_ahb_clk = clk_get(pdev-dev, usb_ahb);
+   mxc_ahb_clk = clk_get(pdev-dev, ipg);
if (IS_ERR(mxc_ahb_clk))
return PTR_ERR(mxc_ahb_clk);

-   ret = clk_enable(mxc_ahb_clk);
+   ret = clk_prepare_enable(mxc_ahb_clk);
if (ret  0) {
-   dev_err(pdev-dev, clk_enable(\usb_ahb\) failed\n);
+   dev_err(pdev-dev, clk_enable(\ipg\) failed\n);
goto eenahb;
}
}

/* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
-   mxc_usb_clk = clk_get(pdev-dev, usb);
+   mxc_usb_clk = clk_get(pdev-dev, per);
if (IS_ERR(mxc_usb_clk)) {
-   dev_err(pdev-dev, clk_get(\usb\) failed\n);
+   dev_err(pdev-dev, clk_get(\per\) failed\n);
ret = PTR_ERR(mxc_usb_clk);
goto egusb;
}
@@ -65,7 +65,7 @@ int fsl_udc_clk_init(struct platform_device *pdev)
}
}

-   ret = clk_enable(mxc_usb_clk);
+   ret = clk_prepare_enable(mxc_usb_clk);
if (ret  0) {
dev_err(pdev-dev, clk_enable(\usb_clk\) failed\n);
goto eenusb;
@@ -79,7 +79,7 @@ eclkrate:
mxc_usb_clk = NULL;
 egusb:
if (!cpu_is_mx35())
-   clk_disable(mxc_ahb_clk);
+   clk_disable_unprepare(mxc_ahb_clk);
 eenahb:
if (!cpu_is_mx35())
clk_put(mxc_ahb_clk);
@@ -104,7 +104,7 @@ void fsl_udc_clk_finalize(struct platform_device *pdev)

/* ULPI transceivers don't need usbpll */
if (pdata-phy_mode == FSL_USB2_PHY_ULPI) {
-   clk_disable(mxc_usb_clk);
+   clk_disable_unprepare(mxc_usb_clk);
clk_put(mxc_usb_clk);
mxc_usb_clk = NULL;
}
@@ -113,11 +113,11 @@ void fsl_udc_clk_finalize(struct platform_device *pdev)
 void fsl_udc_clk_release(void)
 {
if (mxc_usb_clk) {
-   clk_disable(mxc_usb_clk);
+   clk_disable_unprepare(mxc_usb_clk);
clk_put(mxc_usb_clk);
}
if (!cpu_is_mx35()) {
-   clk_disable(mxc_ahb_clk);
+   clk_disable_unprepare(mxc_ahb_clk);
clk_put(mxc_ahb_clk);
}
 }
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev