Re: [PATCH] ASoC: fsl_sai: Fix channel swap issue on i.MX8MP

[Fabio Estevam]

On Mon, Dec 18, 2023 at 7:10 AM Shengjiu Wang  wrote:
>
> When flag mclk_with_tere and mclk_direction_output enabled,
> The SAI transmitter or receiver will be enabled in very early
> stage, that if FSL_SAI_xMR is set by previous case,
> for example previous case is one channel, current case is
> two channels, then current case started with wrong xMR in
> the beginning, then channel swap happen.
>
> The patch is to clear xMR in hw_free() to avoid such
> channel swap issue.
>
> Signed-off-by: Shengjiu Wang 

Fixes tag, please.

Re: [PATCH] ASoC: fsl_sai: sw reset consumer on pause/stop

[Fabio Estevam]

On Thu, Sep 21, 2023 at 5:48 AM Emil Abildgaard Svendsen
 wrote:
>
> When in consumer mode with BCLK disabled (FSL_SAI_CSR_BCE = 0) the
> FIFO's can still contain data when resumed. It might also be possible
> with BCLK enabled but just less likely.
>
> When the FIFO's still contain data on resume it can cause channel
> shifting on e.g. XRUNS. A Software Reset will reset the FIFO's and make
> sure channels are aligned.
>
> Fixes: 269f399dc19f ("ASoC: fsl_sai: Disable bit clock with transmitter")
> Signed-off-by: Emil Svendsen 

Reviewed-by: Fabio Estevam 

Re: [PATCH v2 1/1] ASoC: imx-audmux: fix return value checks of clk_prepare_enable()

[Fabio Estevam]

On Sat, Jul 22, 2023 at 9:38 AM Yuanjun Gong  wrote:
>
> check the return value of clk_prepare_enable(), and if
> clk_prepare_enable() gets an unexpected return value,
> imx_audmux_suspend() and imx_audmux_resume() should return
> the error value.
>
> Signed-off-by: Yuanjun Gong 
> ---
>  sound/soc/fsl/imx-audmux.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
> index be003a117b39..9791e56158ef 100644
> --- a/sound/soc/fsl/imx-audmux.c
> +++ b/sound/soc/fsl/imx-audmux.c
> @@ -325,8 +325,11 @@ static void imx_audmux_remove(struct platform_device 
> *pdev)
>  static int imx_audmux_suspend(struct device *dev)
>  {
> int i;
> +   ssize_t ret;

Why not simply "int ret" instead?

Re: [PATCH] ASoC: fsl_spdif: Silence output on stop

[Fabio Estevam]

On Wed, Jul 19, 2023 at 1:48 PM Matus Gajdos  wrote:
>
> Clear TX registers on stop to prevent the SPDIF interface from sending
> last written word over and over again.
>
> Fixes: a2388a498ad2 ("ASoC: fsl: Add S/PDIF CPU DAI driver")
> Signed-off-by: Matus Gajdos 

Reviewed-by: Fabio Estevam 

Re: [PATCH] ASoC: fsl_spdif: Add support for 22.05 kHz sample rate

[Fabio Estevam]

On Wed, Jul 19, 2023 at 1:32 PM Matus Gajdos  wrote:
>
> Add support for 22.05 kHz sample rate for TX.
>
> Signed-off-by: Matus Gajdos 

Reviewed-by: Fabio Estevam 

Re: [PATCH] ASoC: fsl_sai: Disable bit clock with transmitter

[Fabio Estevam]

On Mon, Jul 17, 2023 at 9:55 AM Mark Brown  wrote:

> I'll just put a non-specific Cc stable tag on it, that should be enough
> to get it backported.

Sounds good. Thanks, Mark.

Re: [PATCH] ASoC: fsl_sai: Disable bit clock with transmitter

[Fabio Estevam]

On Wed, Jul 12, 2023 at 9:53 AM Matus Gajdos  wrote:
>
> Otherwise bit clock remains running writing invalid data to the DAC.
>
> Signed-off-by: Matus Gajdos 

Should this contain a Fixes tag so that it could be backported to
stable kernels?

Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode

[Fabio Estevam]

On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang  wrote:

> The clean way for fixing is to remove the code in fsl_sai_set_bclk()
> and add "fsl,sai-mclk-direction-output;" property in dts for some
> node.

Yes, after thinking more about it, I agree.

So what you are proposing is basically a revert of the patch in
Subject and I assume that the
reason you did the original patch was that you missed passing
fsl,sai-mclk-direction-output in DT.

I will send the revert.

Thanks

Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode

[Fabio Estevam]

Hi Andreas,

On Thu, Jul 6, 2023 at 9:34 AM Andreas Henriksson  wrote:

> I think your initial review comment was spot on Fabio. There probably
> needs to be a(n imx8mm) specific flag that says when this workaround
> should be applied and gate the code in bclk function on that.
> Atleast that's the only thing I can think of if my interpretation of the
> problem for imx8mm is correct.

Yes, deciding whether MCLK_EN should act as a clock gate based on
the number of SAI registers seems fragile to me.

I have sent a proposal as RFC. Please give it a try if you have a chance.

I would like Shengjiu to confirm if imx8mn and imx93 should also
behave like imx8mm in this aspect.

Cheers

Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode

[Fabio Estevam]

On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang  wrote:

> No, this is the code in probe().
> The code with the issue is in fsl_sai_set_bclk().

Yes, I put it in the wrong place.

> The clean way for fixing is to remove the code in fsl_sai_set_bclk()
> and add "fsl,sai-mclk-direction-output;" property in dts for some
> node.

Yes, what about this?

--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -507,7 +507,7 @@ static int fsl_sai_set_bclk(struct snd_soc_dai
*dai, bool tx, u32 freq)
   savediv / 2 - 1);
}

-   if (sai->soc_data->max_register >= FSL_SAI_MCTL) {
+   if (sai->soc_data->max_register >= FSL_SAI_MCTL  &&
sai->mclk_direction_output) {
/* SAI is in master mode at this point, so enable MCLK */
regmap_update_bits(sai->regmap, FSL_SAI_MCTL,
   FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN);

Re: [PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode

[Fabio Estevam]

Hi Andreas,

On Thu, Jul 6, 2023 at 5:47 AM Andreas Henriksson  wrote:

> We've been working on an i.MX8MP where MCLK needs to be input and found
> that this enables the MCLK as output despite not having set the
> `fsl,sai-mclk-direction-output;` devicetree property in our DT.
> Reverting the patch fixes the issues for us.
>
> I have to say that the code comment made me a bit confused, but once
> I found the commit message I understood why this code existed.
> If this is really i.MX8MM specific maybe mention that in the code
> comment and please make the code actually only trigger on i.MX8MM.
> It seems to me like these all fulfill the current criteria:
> imx7ulp, imx8mq, imx8mm, imx8mp, imx8ulp, imx93
>
> Should I report this in bugzilla.kernel.org ?

Should we do a fix like this?

--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1453,7 +1453,7 @@ static int fsl_sai_probe(struct platform_device *pdev)

/* Select MCLK direction */
if (sai->mclk_direction_output &&
-   sai->soc_data->max_register >= FSL_SAI_MCTL) {
+   sai->soc_data->max_register >= FSL_SAI_MCTL &&
sai->mclk_direction_output) {
regmap_update_bits(sai->regmap, FSL_SAI_MCTL,
   FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN);
}

Re: [PATCH 3/6] ASoC: fsl_easrc: define functions for memory to memory usage

[Fabio Estevam]

Hi Shengjiu,

On Wed, Jun 28, 2023 at 11:10 PM Shengjiu Wang  wrote:
>
> ASRC can be used on memory to memory case, define several
> functions for m2m usage and export them as function pointer.
>
> Signed-off-by: Shengjiu Wang 

Could you please explain what is the benefit of using M2M in the EASRC driver?

A few weeks ago, an imx8mn user reported that the EASRC with the
mainline kernel introduces huge delays.

Does M2M help with this aspect?

Thanks

Re: [PATCH] ASoC: fsl_sai: fix getting version from VERID

[Fabio Estevam]

On Tue, Feb 7, 2023 at 6:30 AM Shengjiu Wang  wrote:
>
> The version information is at the bit31 ~ bit16 in the VERID
> register, so need to right shift 16bit to get it, otherwise
> the result of comparison "sai->verid.version >= 0x0301" is
> wrong.
>
> Fixes: 99c1e74f25d4 ("ASoC: fsl_sai: store full version instead of 
> major/minor")
> Signed-off-by: Shengjiu Wang 

Reviewed-by: Fabio Estevam 

Re: [PATCH v1 0/2] Fix console probe delay when stdout-path isn't set

[Fabio Estevam]

we...@gmail.com>, ulf hansson , Neil Armstrong 
, Lorenzo Pieralisi , Al Cooper 
, linux-te...@vger.kernel.org, Jiri Slaby 
, linux-asp...@lists.ozlabs.org, Rob Herring 
, Florian Fainelli , Mateusz Holenko 
, Alexander Shiyan , kevin hilman 
, Broadcom internal kernel review list 
, Joel Stanley , Orson 
Zhai , paolo abeni , Patrice Chotard 
, Ray Jui , Vladimir Zapolskiy 
, linux-snps-...@lists.infradead.org, Timur Tabi 
, hideaki yoshifuji , 
io...@lists.linux-foundation.org, Laxman Dewangan , 
Sudeep Holla , Baolin Wang , Shawn Guo , "David S. Miller" , 
Baruch Siach , Liviu Dudau , Alexandre 
Torgue , Bjorn Andersson 
, Paul Cercueil , 
sparcli...@vger.kernel.org, linux-ri...@lists.infradead.org, joerg roedel 
, Russell King , Andy Gross 
, linux-ser...@vger.kernel.org, jakub kicinski 
, will deacon , Manivannan Sadhasivam 
, linux-media...@lists.infradead.org, Paul Walmsley 
, Matthias Brugger , Andy 
Shevchenko , Laurentiu Tudor 
, Taichi Sugaya , netdev 
, david ahern , Nicolas Ferre 
, Krzysztof Kozlowski , Palmer Dabbelt , Takao 
Orito , linuxppc-dev 
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


Hi Saravana,

On Mon, Jun 27, 2022 at 11:03 PM Saravana Kannan  wrote:
>
> Since the series that fixes console probe delay based on stdout-path[1] got
> pulled into driver-core-next, I made these patches on top of them.
>
> Even if stdout-path isn't set in DT, this patch should take console
> probe times back to how they were before the deferred_probe_timeout
> clean up series[2].
>
> Fabio/Ahmad/Sascha,
>
> Can you give this a shot please?

This series works fine for me (with and without stdout-path), thanks:

Tested-by: Fabio Estevam 

Re: [PATCH] ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe

[Fabio Estevam]

On Wed, May 11, 2022 at 3:58 AM Miaoqian Lin  wrote:
>
> of_find_i2c_device_by_node() takes a reference,
> In error paths, we should call put_device() to drop
> the reference to aviod refount leak.

s/aviod refount/avoid refcount

> Fixes: 81e8e4926167 ("ASoC: fsl: add sgtl5000 clock support for imx-sgtl5000")
> Signed-off-by: Miaoqian Lin 

Reviewed-by: Fabio Estevam 

Re: [PATCH v2 01/16] ASoC: eureka-tlv320: Update to modern clocking terminology

[Fabio Estevam]

On Tue, Sep 21, 2021 at 6:36 PM Mark Brown  wrote:
>
> As part of moving to remove the old style defines for the bus clocks update
> the eureka-tlv320 driver to use more modern terminology for clocking.
>
> Signed-off-by: Mark Brown 

For the whole series:

Reviewed-by: Fabio Estevam 

Re: [PATCH 03/16] ASoC: fsl-audmix: Update to modern clocking terminology

[Fabio Estevam]

On Tue, Sep 21, 2021 at 6:11 PM Mark Brown  wrote:
>
> As part of moving to remove the old style defines for the bus clocks update
> the fsl-audmix driver to use more modern terminology for clocking.
>
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/fsl/fsl_audmix.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
> index f931288e256c..db2dde597edc 100644
> --- a/sound/soc/fsl/fsl_audmix.c
> +++ b/sound/soc/fsl/fsl_audmix.c
> @@ -257,10 +257,10 @@ static int fsl_audmix_dai_set_fmt(struct snd_soc_dai 
> *dai, unsigned int fmt)
> return -EINVAL;
> }
>
> -   /* For playback the AUDMIX is slave, and for record is master */
> -   switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> -   case SND_SOC_DAIFMT_CBM_CFM:
> -   case SND_SOC_DAIFMT_CBS_CFS:
> +   /* For playback the AUDMIX is provider, and for record is consumer */
> +   switch (fmt & SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK) {

I think the comment should be the other way around:

   /* For playback the AUDMIX is consumer, and for record is provider */

Other than that, the series looks good.

Re: [PATCH] usb: gadget: fsl: properly remove remnant of MXC support

[Fabio Estevam]

Hi Li,

On Fri, Jun 11, 2021 at 9:31 PM Li Yang  wrote:
>
> Commit a390bef7db1f ("usb: gadget: fsl_mxc_udc: Remove the driver")
> didn't remove all the MXC related stuff which can cause build problem
> for LS1021 when enabled again in Kconfig.  This patch remove all the
> remnants.
>
> Signed-off-by: Li Yang 

Thanks for the fix:

Reviewed-by: Fabio Estevam 

Re: [PATCH] sound: soc: fsl: Remove unnecessary THIS_MODULE

[Fabio Estevam]

Hi Wang,

On Sat, Mar 13, 2021 at 5:25 AM Wang Qing  wrote:
>
> As THIS_MODULE has been set in module_platform_driver(), so remove it.
>
> Signed-off-by: Wang Qing 

Thanks for the patch, but someone else has already sent the same.

Re: [PATCH v2] ASoC: imx-hdmi: fix platform_no_drv_owner.cocci warnings

[Fabio Estevam]

Hi Yang,

On Thu, Mar 4, 2021 at 6:08 AM Yang Li  wrote:
>
> ./sound/soc/fsl/imx-hdmi.c:226:3-8: No need to set .owner here. The core
> will do it.
>
> Remove .owner field if calls are used which set it automatically
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 

Reviewed-by: Fabio Estevam 

Re: [PATCH] ASoC: hdmi-codec: fix platform_no_drv_owner.cocci warnings

[Fabio Estevam]

Hi Yang,

On Wed, Mar 3, 2021 at 5:54 AM Yang Li  wrote:
>
> ./sound/soc/fsl/imx-hdmi.c:226:3-8: No need to set .owner here. The core
> will do it.
>
> Remove .owner field if calls are used which set it automatically
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 

The patch looks good, but please send a v2 with the correct Subject.

It should mention imx-hdmi instead of hdmi-codec.

Thanks

Re: [PATCH] media: fsl-viu: Use proper check for presence of {out, in}_be32()

[Fabio Estevam]

Hi Michael,

On Fri, Nov 20, 2020 at 3:25 AM Michael Ellerman  wrote:

> I'd rather not have to carry this in arch code just for one driver.

Fair enough.

> Can't the driver just use ioread/write32be() on all platforms?

Yes, this is a better approach. I have just a patch doing that.

Thanks

[PATCH] media: fsl-viu: Use proper check for presence of {out, in}_be32()

[Fabio Estevam]

From: Geert Uytterhoeven 

When compile-testing on m68k or microblaze:

drivers/media/platform/fsl-viu.c:41:1: warning: "out_be32" redefined
drivers/media/platform/fsl-viu.c:42:1: warning: "in_be32" redefined

Fix this by replacing the check for PowerPC by checks for the presence
of {out,in}_be32().

As PowerPC implements the be32 accessors using inline functions instead
of macros, identity definions are added for all accessors to make the
above checks work.

Fixes: 29d750686331a1a9 ("media: fsl-viu: allow building it with COMPILE_TEST")
Signed-off-by: Geert Uytterhoeven 
[fabio: adapt to mainline]
Signed-off-by: Fabio Estevam 
---
 arch/powerpc/include/asm/io.h| 14 ++
 drivers/media/platform/fsl-viu.c |  5 +++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 58635960403c..fcb250db110d 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -194,6 +194,20 @@ static inline void out_be64(volatile u64 __iomem *addr, 
u64 val)
 #endif
 #endif /* __powerpc64__ */
 
+#define in_be16 in_be16
+#define in_be32 in_be32
+#define in_be64 in_be64
+#define in_le16 in_le16
+#define in_le32 in_le32
+#define in_le64 in_le64
+
+#define out_be16 out_be16
+#define out_be32 out_be32
+#define out_be64 out_be64
+#define out_le16 out_le16
+#define out_le32 out_le32
+#define out_le64 out_le64
+
 /*
  * Low level IO stream instructions are defined out of line for now
  */
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 4f2a0f992905..bb6c291ed6dc 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -31,9 +31,10 @@
 #define DRV_NAME   "fsl_viu"
 #define VIU_VERSION"0.5.1"
 
-/* Allow building this driver with COMPILE_TEST */
-#if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) && 
!defined(CONFIG_M68K)
+#ifndef out_be32
 #define out_be32(v, a) iowrite32be(a, (void __iomem *)v)
+#endif
+#ifndef in_be32
 #define in_be32(a) ioread32be((void __iomem *)a)
 #endif
 
-- 
2.17.1

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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()

[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()

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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()

[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()

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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