February 2019 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] Multiple codecs on one sound card for multi-channel sound card
by Yann CARDAILLAC 18 Feb '19

18 Feb '19

Hi guys, Where are we now with TDM on several codecs on the same TDM channel ? I'm sorry to dig out this old thread but I couldn't really find any proper information about that. I only plan to use 4 channel TDM with two codecs. I'm using IMX6's SSI as master for both codec. What I've got working today is 1 codec with ssi as I2S master. Do you have any pointer on what is achieved so far and how to implement it ? I'm using kernel *v4.14.78*. Any pointer to DTS achieving that or audio card doing that kind of thing would already be an amazing first hint.! Regards, Yann >Got it. Thanks Arnaud. >-Caleb > >On Thu, Sep 17, 2015 at 9:09 AM, arnaud.mouiche at invoxia.com <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel> ><arnaud.mouiche at invoxia.com <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>> wrote: >>>>>*> Le 17/09/2015 17:34, Caleb Crome a écrit : *>>>>>>* On Thu, Sep 17, 2015 at 7:33 AM, arnaud.mouiche at invoxia.com <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel> *>>>* <arnaud.mouiche at invoxia.com <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>> wrote: *>>>>>>>>* hello, *>>>>>>>*> Le 17/09/2015 15:38, Caleb Crome a écrit : *>>>>>>>>>>* On Thu, Sep 17, 2015 at 1:51 AM, arnaud.mouiche at invoxia.com <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel> *>>>>>* <arnaud.mouiche at invoxia.com <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>> wrote: *>>>>>>>>>>>>* Hello Caleb, *>>>>>>>>>>>>* freescale SSI is fine with more than 2 channels. *>>>>>>* I have planed to publish a set of patch in this direction but we still *>>>>>>* have *>>>>>>* some corner cases to fix first (rare issues with channels alignment) *>>>>>>>>>>* I'd love to see anything you're willing to show :-) *>>>>>>>>>>>* Yet, this following is far enough to have it working. *>>>>>>* And since the max/min rate is at the end the intersection of what the *>>>>>>* SSI, *>>>>>>* the codec and the card are declaring, it will not change anything until *>>>>>>* you *>>>>>>* connect the SSI to a codec with more than 2 channels, or a multi-codec *>>>>>>* solution. *>>>>*> *>>>>* What if I change channels_max to 16 for capture and playback? Last *>>>>>* time I tried, it would not keep the channels synchronized on the TDM *>>>>>* bus. I tried playing with the FIFO settings, which helped, but it *>>>>>* still would not start each channel in the right slot reliably. *>>>>>* Perhaps I was using an older kernel. *>>>>>>>>* you put the finger on what's hurting ! ;) *>>>>>>>>* In fact, we made 8 channels working in reliable way on imx50, with *>>>>* predictive latency ... with an old kernel (3.17) ... based on freescale *>>>>* BSP... on sound/soc/imx/imx-ssi.c (something that doesn't exist outside *>>>>* freescale BSP) *>>>>>>>>* Well, just to say it is doable on any recent imx since the hardware is *>>>>* not *>>>>* the issue. But the job was a set of awful hacks. *>>>>>>* Sorry, I don't quite understand. Are you saying that on a recent *>>>* kernel (say 4.1 or 4.2), you think it will just work. Or are yo *>>>* saying that even on a modern kernel it's a set of awful hacks? And *>>>* should I use fsl_ssi.c or imx-ssi.c (device tree/non device tree) *>>>* version? *>>>>* - I'm saying it is working on recent upstream kernel, using *>>* sound/soc/fsl/fsl_ssi.c, but with *>>* some channel sync issues in rare conditions (at least 4 channels case, *>>* opening multiple SSI at the same time). *>>* So, you should test on your side with you setup, and simply be prepared to *>>* not see it working as a charm. *>>>>* - we made it work perfectly, but on an old freescale BSP, where freescale *>>* rewrites a SSI driver different from the already 2 drivers (device tree/non *>>* device tree) available today in upstream + lot of awful hacks => so, this is *>>* not a hardware issue. *>>>>* - when I will have time, I will start from the upstream driver, and make it *>>* work correctly with 8 channels (or more) *>>>>* arnaud *>>>>>>>>* In short, what's your best current recommendation to get it working today? *>>>>>>>* My plan was to re-do all this job on an upstream kernel, in a way it can *>>>>* be *>>>>* accepted. *>>>>* Unfortunately you will have to wait, I'm under pressure for other stuff *>>>>* right now. *>>>>>>* Heh, understood. If there's anything I can do to help, let me know. *>>>>>>* Thanks, *>>>* -Caleb *>>>>>>>* Regards, *>>>>* arnaud *>>>>>>>>>>>>>* I'll give it a try again. Like I said, we'd love to get our *>>>>>* 16-channel board up and running on the MX6, so I'm definitely *>>>>>* motivated to put some work in to get it reliable. *>>>>>>>>>>* Thanks, *>>>>>* -Caleb *>>>>>>> -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Yann CARDAILLAC* Ingénieur Linux Embarqué [image: email] yann.cardaillac(a)smile.fr [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire

2 1

[alsa-devel] [PATCH V3] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
by S.j. Wang 18 Feb '19

18 Feb '19

The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to wrong register, correct it. Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Ackedy-by: Nicolin Chen <nicoleotsuka(a)gmail.com> --- Changes in v3 - Add Cc: <stable(a)vger.kernel.org> sound/soc/fsl/fsl_esai.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 57b484768a58..afe67c865330 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -398,7 +398,8 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) break; case SND_SOC_DAIFMT_RIGHT_J: /* Data on rising edge of bclk, frame high, right aligned */ - xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCR_xWA; + xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP; + xcr |= ESAI_xCR_xWA; break; case SND_SOC_DAIFMT_DSP_A: /* Data on rising edge of bclk, frame high, 1clk before data */ @@ -455,12 +456,12 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) return -EINVAL; } - mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR; + mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR | ESAI_xCR_xWA; regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, xcr); regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, mask, xcr); mask = ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCCR_xFSP | - ESAI_xCCR_xFSD | ESAI_xCCR_xCKD | ESAI_xCR_xWA; + ESAI_xCCR_xFSD | ESAI_xCCR_xCKD; regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR, mask, xccr); regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR, mask, xccr); -- 1.9.1

1 0

[alsa-devel] [PATCH V2] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
by S.j. Wang 18 Feb '19

18 Feb '19

Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") 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 <shengjiu.wang(a)nxp.com> Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Ackedy-by: Nicolin Chen <nicoleotsuka(a)gmail.com> --- Changes in v2 - add Fixes tag and cc stable kernel. sound/soc/fsl/fsl_esai.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 57b484768a58..afe67c865330 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -398,7 +398,8 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) break; case SND_SOC_DAIFMT_RIGHT_J: /* Data on rising edge of bclk, frame high, right aligned */ - xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCR_xWA; + xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP; + xcr |= ESAI_xCR_xWA; break; case SND_SOC_DAIFMT_DSP_A: /* Data on rising edge of bclk, frame high, 1clk before data */ @@ -455,12 +456,12 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) return -EINVAL; } - mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR; + mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR | ESAI_xCR_xWA; regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, xcr); regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, mask, xcr); mask = ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCCR_xFSP | - ESAI_xCCR_xFSD | ESAI_xCCR_xCKD | ESAI_xCR_xWA; + ESAI_xCCR_xFSD | ESAI_xCCR_xCKD; regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR, mask, xccr); regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR, mask, xccr); -- 1.9.1

2 2

Re: [alsa-devel] [PATCH -next] ASoC: samsung: i2s: Fix return value check in i2s_create_secondary_device()
by Krzysztof Kozlowski 18 Feb '19

18 Feb '19

On Sat, 16 Feb 2019 at 02:07, Wei Yongjun <weiyongjun1(a)huawei.com> wrote: > > In case of error, the function platform_device_register_simple() returns > ERR_PTR() and never returns NULL. The NULL test in the return value > check should be replaced with IS_ERR(). > > Fixes: 7196c64c7d0c ("ASoC: samsung: i2s: Restore support for the secondary PCM") > Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> > --- > sound/soc/samsung/i2s.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org> Best regards, Krzysztof

1 0

Re: [alsa-devel] [PATCH] ASoC: simple-card: fixup refcount_t underflow
by Daniel Baluta 18 Feb '19

18 Feb '19

On Fri, Feb 15, 2019 at 8:43 PM Takashi Iwai <tiwai(a)suse.de> wrote: > > On Fri, 15 Feb 2019 18:31:08 +0100, > Mark Brown wrote: > > > > On Fri, Feb 15, 2019 at 06:21:04PM +0100, Takashi Iwai wrote: > > > > > Actually it's not all. As mentioned in my earlier post, there are > > > more of refcount unbalance in the code. Lots of them, really. > > > > > Below is a patch I've fixed quickly over the whole scanning the sound > > > tree. Some might be incorrect, so more detailed review for each piece > > > of change is needed... > > > > Extra references aren't such a problem for practical systems since we > > don't actually ever free any of the DT (there's no mainline way to use > > overlays yet...), that's how none of this stuff ever gets noticed. I'm > > not surprised there's loads of missing frees TBH. In contrast if we've > > got extra frees they will get noticed and cause problems. > > Yeah, the rest are just leaks, and we have already tons of them :) > > The point is that the commit in question introduced multiple such > issues, so they should be addressed as well. > > But, the biggest problem is that OF api is very hard to use right... Hello Mark/Takashi, Just sent this https://lkml.org/lkml/2019/2/16/52 to fix the problem that was bugging me and to update the patch from Kuninori. Feel free to send a patch for the rest of the refcount issues :). Kuninori, if you consider necessary please add your Signed-off-by to the patch as it is mostly your work but I didn't know exactly how to give you credit for it :(. thanks, Daniel.

2 1

Re: [alsa-devel] [PATCH] ASoC: simple-card: fixup refcount_t underflow
by Kuninori Morimoto 18 Feb '19

18 Feb '19

Hi Takashi-san > > commit da215354eb55c ("ASoC: simple-card: merge simple-scu-card") > > merged simple-card and simple-scu-card. Then it had refcount > > underflow bug. This patch fixup it. > > We will get below error without this patch. > > > > OF: ERROR: Bad of_node_put() on /sound > > CPU: 3 PID: 237 Comm: kworker/3:1 Not tainted 5.0.0-rc6+ #1514 > > Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) > > Workqueue: events deferred_probe_work_func > > Call trace: > > dump_backtrace+0x0/0x150 > > show_stack+0x24/0x30 > > dump_stack+0xb0/0xec > > of_node_release+0xd0/0xd8 > > kobject_put+0x74/0xe8 > > of_node_put+0x24/0x30 > > __of_get_next_child+0x50/0x70 > > of_get_next_child+0x40/0x68 > > asoc_simple_card_probe+0x604/0x730 > > platform_drv_probe+0x58/0xa8 > > ... > > Reported-by: Vicente Bergas <vicencb(a)gmail.com> > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> > > Please don't forget to put Fixes tag for a regression fix. Oops, indeed. Thanks. will add it on v2 patch. > And, looking at the code in 5.0-rc, it seems still leaving the > reference in some condition. The 5.0-rc code corrected your patch > looks like: > > node = of_get_child_by_name(top, PREFIX "dai-link"); > if (!node) { > node = of_node_get(top); > loop = 0; > } > > do { > .... > node = of_get_next_child(top, node); > } while (loop && node); > > So when loop=0, it aborts the loop at the first iteration. If node is > non-NULL at that point, it still keeps the refcount taken in > of_get_next_child(). > > That is, you'd need to call of_node_put(node) after the loop. Ah.. yes.. > And, this leads me checking the whole code, and I'm afraid that we > have many similar unblanced refcounts. For example, a tricky one is > for_each_child_of_node() loop. When you abort at the middle of the > loop, you'd need to unreference the remaining node. But we return or > abort immediately without unreferencing in many places. > > Hrm... Yes, I had noticed this refcounts issue. The code can be very confusable for this refcounts... Best regards --- Kuninori Morimoto

1 0

Re: [alsa-devel] [PATCH] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
by Fabio Estevam 16 Feb '19

16 Feb '19

Hi Shengjiu, On Fri, Feb 15, 2019 at 9:04 AM S.j. Wang <shengjiu.wang(a)nxp.com> 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 <shengjiu.wang(a)nxp.com> Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Please add a Fixes tag and Cc stable. Also, it seems that Mark Brown is not on Cc. Please Cc him in v2. Thanks

1 0

Re: [alsa-devel] Saffire Pro 26 IO Restarting Issue
by Takashi Sakamoto 15 Feb '19

15 Feb '19

Hi, On Fri, Feb 15, 2019 at 12:49:19PM +0000, ackolonges fds wrote: > Hi All, > > I was wondering if there might be anyone on here that could give me any > pointers in getting my Focusrite Saffire Pro 26 i/o interface working with > Linux via FFADO? > > It's a new desktop PC (Ryzen 5 2600, 8GB RAM), dual booting Windows 10 and > Ubuntu 18.10, with a PCI Express, Texas Instruments XIO2213 Firewire card. > > I have tested this Saffire interface successfully on a MacBook Pro (it was > plug and play), and also on this very desktop computer in Windows 10. > However, when the interface is connected in Ubuntu 18.10, it repeatedly > and periodically resets itself about 10-15 seconds after booting up, in a > loop. If I run ffado-dbus-server while it's booting, it connects > successfully to the interface, and quickly running FFADO mixer afterwards > lets me see the controls available, for a short time until the interface > resets itself, cutting all the connections. > > Has anybody here ever heard of this kind of issue before? Or perhaps > someone may have some ideas that might aid in troubleshooting the issue? > > Thanks so much for any advice you may have, In case of Focusrite Saffire Pro I/O 10 and 26, a combination of ALSA bebob driver and pulseaudio brings this problem due to quirk of these two models reported in bugzilla.kernel.org[1]. I've already committed a solution and it was merged to pulseaudio[2], however it has never included into any releases of pulseaudio at present. Therefore you can see this issue on any desktop environment in released distribution such as the latest Ubuntu. You can avoid this issue by two handy solutions at a quick glance: 1. suppress pulseaudio to handle your device 2. suppress your system to load ALSA bebob driver For solution 1, it's the best way to edit 90-pulseaudio.rules in your system. $ systemctl --user stop pulseaudio.service pulseaudio.socket $ sudo nano /lib/udev/rules.d/90-pulseaudio.rules (modify the above file according to my patch[2].) $ systemctl --user start pulseaudio.service pulseaudio.socket For solution 2, it's the easiest way to add ALSA bebob driver to blacklist. $ sudo nano /etc/modprobe.d/blacklist-bebob.conf (add entry of 'blacklist snd-bebob') (then unplug and plugin your device) Sorry for the inconvenience. [1] https://bugzilla.kernel.org/show_bug.cgi?id=199365 [2] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/37358e42c49abe3… Regards Takashi Sakamoto

1 0

Re: [alsa-devel] [PATCH v5 0/3] Add NXP AUDMIX device and machine drivers
by Nicolin Chen 15 Feb '19

15 Feb '19

On Fri, Feb 15, 2019 at 02:01:32PM +0000, Viorel Suman wrote: > The patchset adds NXP Audio Mixer (AUDMIX) device and machine > drivers and related DT bindings documentation. For this series, Acked-by: Nicolin Chen <nicoleotsuka(a)gmail.com> And Rob gave his at the previous version already. Thanks. > Changes since V4: > 1. Removed "model" attribute from device driver DT bindings documentation > as suggested by Nicolin. > > Changes since V3: > 1. Removed machine driver DT bindings documentation. > 2. Trigger machine driver probe from device driver as suggested by Nicolin. > > Changes since V2: > 1. Moved "dais" node from machine driver DTS node to device driver DTS node > as suggested by Rob. > > Changes since V1: > 1. Original patch split into distinct patches for the device driver and > DT binding documentation. > 2. Replaced AMIX with AUDMIX in both code and file names as it looks more > RM-compliant. > 3. Removed polarity control from CPU DAI driver as suggested by Nicolin. > 4. Added machine driver and related DT binding documentation. > > Viorel Suman (3): > ASoC: fsl: Add Audio Mixer CPU DAI driver > ASoC: add fsl_audmix DT binding documentation > ASoC: fsl: Add Audio Mixer machine driver > > .../devicetree/bindings/sound/fsl,audmix.txt | 50 ++ > sound/soc/fsl/Kconfig | 16 + > sound/soc/fsl/Makefile | 5 + > sound/soc/fsl/fsl_audmix.c | 578 +++++++++++++++++++++ > sound/soc/fsl/fsl_audmix.h | 102 ++++ > sound/soc/fsl/imx-audmix.c | 327 ++++++++++++ > 6 files changed, 1078 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt > create mode 100644 sound/soc/fsl/fsl_audmix.c > create mode 100644 sound/soc/fsl/fsl_audmix.h > create mode 100644 sound/soc/fsl/imx-audmix.c > > -- > 2.7.4 >

1 0

Re: [alsa-devel] [PATCH] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
by Nicolin Chen 15 Feb '19

15 Feb '19

On Fri, Feb 15, 2019 at 11:04:38AM +0000, 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 <shengjiu.wang(a)nxp.com> Would need this for stable kernel too. Ackedy-by: Nicolin Chen <nicoleotsuka(a)gmail.com> Thanks. > --- > sound/soc/fsl/fsl_esai.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c > index 57b484768a58..afe67c865330 100644 > --- a/sound/soc/fsl/fsl_esai.c > +++ b/sound/soc/fsl/fsl_esai.c > @@ -398,7 +398,8 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) > break; > case SND_SOC_DAIFMT_RIGHT_J: > /* Data on rising edge of bclk, frame high, right aligned */ > - xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCR_xWA; > + xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP; > + xcr |= ESAI_xCR_xWA; > break; > case SND_SOC_DAIFMT_DSP_A: > /* Data on rising edge of bclk, frame high, 1clk before data */ > @@ -455,12 +456,12 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) > return -EINVAL; > } > > - mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR; > + mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR | ESAI_xCR_xWA; > regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, xcr); > regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, mask, xcr); > > mask = ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCCR_xFSP | > - ESAI_xCCR_xFSD | ESAI_xCCR_xCKD | ESAI_xCR_xWA; > + ESAI_xCCR_xFSD | ESAI_xCCR_xCKD; > regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR, mask, xccr); > regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR, mask, xccr); > > -- > 1.9.1 >

1 0