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

[alsa-devel] [PATCH] ASoC: atmel_ssc_dai: Remove wrong spinlock usage
by Gregory CLEMENT 18 Sep '19

18 Sep '19

A potential bug was reported in the email "[BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown"[1] Indeed in the function atmel_ssc_shutdown() free_irq() was called in a critical section protected by spinlock. However this spinlock is only used in atmel_ssc_shutdown() and atmel_ssc_startup() functions. After further analysis, it occurred that the call to these function are already protected by mutex used on the calling functions. Then we can remove the spinlock which will fix this bug as a side effect. Thanks to this patch the following message disappears: "BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909" [1]: https://www.spinics.net/lists/alsa-devel/msg71286.html Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> --- sound/soc/atmel/atmel_ssc_dai.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 6f89483ac88c..365957e86419 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -116,19 +116,16 @@ static struct atmel_pcm_dma_params ssc_dma_params[NUM_SSC_DEVICES][2] = { static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { { .name = "ssc0", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[0].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, { .name = "ssc1", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[1].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, { .name = "ssc2", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[2].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, @@ -317,13 +314,11 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, snd_soc_dai_set_dma_data(dai, substream, dma_params); - spin_lock_irq(&ssc_p->lock); if (ssc_p->dir_mask & dir_mask) { spin_unlock_irq(&ssc_p->lock); return -EBUSY; } ssc_p->dir_mask |= dir_mask; - spin_unlock_irq(&ssc_p->lock); return 0; } @@ -355,7 +350,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, dir_mask = 1 << dir; - spin_lock_irq(&ssc_p->lock); ssc_p->dir_mask &= ~dir_mask; if (!ssc_p->dir_mask) { if (ssc_p->initialized) { @@ -369,7 +363,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0; ssc_p->forced_divider = 0; } - spin_unlock_irq(&ssc_p->lock); /* Shutdown the SSC clock. */ pr_debug("atmel_ssc_dai: Stopping clock\n"); -- 2.23.0

2 2

[alsa-devel] alsa acting up
by liebrecht＠grossmann-venter.com 18 Sep '19

18 Sep '19

See images in links. 1) "http://grossmann-venter.com/visitors/ug/alsa/alsa-pulse-181vsl_unplug.png" 2) "http://grossmann-venter.com/visitors/ug/alsa/alsa-dont recognize1818VSLpng" 1) As soon as pulseaudio is started Alsa says 1818VSL is unplugged....? 2) Clearly Presonus 1818VSL is found as lsusb output says, but alsa has no clue about it. How do I get alsa to recognise 181VSL as it is found by lsusb so it is presnet on the system. It used to work fine but alsa just stopped working with 1818VSL recently for no reason. I know this is a developers group, but please at least answer where I can get help. Alsa help is absolutely non-existing. I also posted a bug with no response in another thread. Thanks.

1 0

[alsa-devel] [PATCH v5 0/5] Add HDMI jack support on RK3288
by Cheng-Yi Chiang 18 Sep '19

18 Sep '19

This patch series supports HDMI jack reporting on RK3288, which uses DRM dw-hdmi driver and hdmi-codec codec driver. The previous discussion about reporting jack status using hdmi-notifier and drm_audio_component is at https://lore.kernel.org/patchwork/patch/1083027/ The new approach is to use a callback mechanism that is specific to hdmi-codec. Changes from v4 to v5: - synopsys/Kconfig: Remove the incorrect dependency change in v4. - rockchip/Kconfig: Add dependency of hdmi-codec when it is really need for jack support. Cheng-Yi Chiang (5): ASoC: hdmi-codec: Add an op to set callback function for plug event drm: bridge: dw-hdmi: Report connector status using callback drm: dw-hdmi-i2s: Use fixed id for codec device ASoC: rockchip_max98090: Add dai_link for HDMI ASoC: rockchip_max98090: Add HDMI jack support .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 13 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 41 ++++++- include/drm/bridge/dw_hdmi.h | 4 + include/sound/hdmi-codec.h | 17 +++ sound/soc/codecs/hdmi-codec.c | 46 +++++++ sound/soc/rockchip/Kconfig | 3 +- sound/soc/rockchip/rk3288_hdmi_analog.c | 3 +- sound/soc/rockchip/rockchip_max98090.c | 116 ++++++++++++++---- 8 files changed, 216 insertions(+), 27 deletions(-) -- 2.22.0.510.g264f2c817a-goog

4 12

[alsa-devel] alsa acting up
by liebrecht＠grossmann-venter.com 18 Sep '19

18 Sep '19

See images in links. 1) "http://grossmann-venter.com/visitors/ug/alsa/alsa-pulse-181vsl_unplug.png" 2) "http://grossmann-venter.com/visitors/ug/alsa/alsa-dont recognize1818VSLpng" 1) As soon as pulseaudio is started Alsa says 1818VSL is unplugged....? 2) Clearly Presonus 1818VSL is found as lsusb output says, but alsa has no clue about it. How do I get alsa to recognise 181VSL as it is found by lsusb so it is presnet on the system. It used to work fine but alsa just stopped working with 1818VSL recently for no reason. I know this is a developers group, but please at least answer where I can get help. Alsa help is absolutely non-existing. I also posted a bug with no response in another thread. Thanks.

1 0

Re: [alsa-devel] Alsa-devel Digest, Vol 149, Issue 28
by Channaiah Vanitha (RBEI/ECF3) 18 Sep '19

18 Sep '19

Hello Jaroslav-san, This mail is regarding : 3. Re: GIT: Regarding the issue we are facing in the commit 37728639ae05de702825d96bd1d42e24ae772248 (Jaroslav Kysela) Dne 03. 07. 19 v 14:17 Channaiah Vanitha (RBEI/ECF3) napsal(a): > Hello Jaroslav-san, > >> I think that it would be probably best to force the parameters for your hardware (--period-size and --buffer-size arguments for aplay or the time counterparts - --period-time and --buffer-time). The refining rules might not select the perfect configuration in some cases. > > I tried to force parameters "period-size" in multiples of 2ms as our hardware supports 2ms period time data and buffer-size=twice period size. > But still I face the issue. There is no exact 2ms period size for the rate 11025Hz, because it's float number 21.9780 (period size)... You may try values like 15,35,45,105 (anything which can match 11025 / PERIOD_SIZE without the remainder). Jaroslav We tried executing the playback use-case with below parameters as suggested. But still we able to see: Unable to install hw params. Kindly provide your feedback. The output from below Hardware : a. RCAR salvator-xs which supports 2 channel. b. IMX which supports 8 channel. root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=15 /dev/random Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 2000 PERIOD_SIZE: NONE PERIOD_BYTES: (264 276) PERIODS: (15 16) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=105 /dev/random Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 10000 PERIOD_SIZE: NONE PERIOD_BYTES: (1320 1332) PERIODS: (2 3) BUFFER_TIME: (29931 29932) BUFFER_SIZE: 330 BUFFER_BYTES: 3960 TICK_TIME: 0 root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=35 /dev/random Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 4000 PERIOD_SIZE: NONE PERIOD_BYTES: (528 540) PERIODS: (7 8) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=45 /dev/random Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6 aplay: set_params:1411: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 96 CHANNELS: 6 RATE: NONE PERIOD_TIME: 4000 PERIOD_SIZE: NONE PERIOD_BYTES: (528 540) PERIODS: (7 8) BUFFER_TIME: (31927 31928) BUFFER_SIZE: 352 BUFFER_BYTES: 4224 TICK_TIME: 0 Best regards, Vanitha Channaiah RBEI/ECF3 Tel. +91 80 6136-4436 -----Original Message----- From: Alsa-devel <alsa-devel-bounces(a)alsa-project.org> On Behalf Of alsa-devel-request(a)alsa-project.org Sent: Thursday, July 4, 2019 5:32 PM To: alsa-devel(a)alsa-project.org Subject: Alsa-devel Digest, Vol 149, Issue 28 Send Alsa-devel mailing list submissions to alsa-devel(a)alsa-project.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.alsa-project.org/mailman/listinfo/alsa-devel or, via email, send a message with subject or body 'help' to alsa-devel-request(a)alsa-project.org You can reach the person managing the list at alsa-devel-owner(a)alsa-project.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Alsa-devel digest..." Today's Topics: 1. Re: [PATCH v2 1/2] ASoC: SOF: add flag for position update ipc (Kai Vehmanen) 2. Re: [PATCH v2 2/2] ASoC: SOF: Intel: fix reset of host_period_bytes (Kai Vehmanen) 3. Re: GIT: Regarding the issue we are facing in the commit 37728639ae05de702825d96bd1d42e24ae772248 (Jaroslav Kysela) 4. Re: [PATCH v2 1/2] ASoC: SOF: add flag for position update ipc (Keyon Jie) 5. bug in playing 6-channel sound (Julian Bradfield) 6. Re: [PATCH v2 1/2] ASoC: SOF: add flag for position update ipc (Kai Vehmanen) 7. Re: [PATCH v2 34/35] sound/soc/codecs: Use kmemdup rather than duplicating its implementation (Richard Fitzgerald) 8. audio lost from speaker after reboot from windows on the device ALC295 (He, Bo) ---------------------------------------------------------------------- Message: 1 Date: Thu, 4 Jul 2019 13:03:06 +0300 (EEST) From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> To: Keyon Jie <yang.jie(a)linux.intel.com> Cc: alsa-devel(a)alsa-project.org, ranjani.sridharan(a)linux.intel.com, Marcin Rajwa <marcin.rajwa(a)linux.intel.com>, pierre-louis.bossart(a)linux.intel.com Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: SOF: add flag for position update ipc Message-ID: <alpine.DEB.2.21.1907041254100.4409@eliteleevi> Content-Type: text/plain; charset=US-ASCII Hi, patch looks good, but commit message could be improved. On Wed, 3 Jul 2019, Keyon Jie wrote: > In some cases, FW might need use the host_period_bytes even no > position update ipc reqiured from driver, here add another flag for > position update, and preserve host_period_bytes for FW to use. Speculation on what FW might do is not really needed. The host_period_bytes field has been overloaded with multiple semantics and this patch clears that, right. How about: "" Remove the special case semantics of 'host_period_bytes==0'. Add a new field 'no_period_irq' to signal whether period elapsed IPC should be sent and use 'host_period_bytes' only for period size. "" > This might require corresponding FW change and ABI alignment. This is not helpful -- we know this _is_ a minor ABI change and needs to be aligned with FW. Br, Kai ------------------------------ Message: 2 Date: Thu, 4 Jul 2019 13:05:21 +0300 (EEST) From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> To: Keyon Jie <yang.jie(a)linux.intel.com> Cc: alsa-devel(a)alsa-project.org, ranjani.sridharan(a)linux.intel.com, Marcin Rajwa <marcin.rajwa(a)linux.intel.com>, pierre-louis.bossart(a)linux.intel.com Subject: Re: [alsa-devel] [PATCH v2 2/2] ASoC: SOF: Intel: fix reset of host_period_bytes Message-ID: <alpine.DEB.2.21.1907041304101.4409@eliteleevi> Content-Type: text/plain; charset=US-ASCII Hi, On Wed, 3 Jul 2019, Keyon Jie wrote: > From: Marcin Rajwa <marcin.rajwa(a)linux.intel.com> > > This patch prevents the reset of host period bytes. > The parameter has been used to keep information about completion of > period copy. Right now we keep this information in period_irq. > > Signed-off-by: Marcin Rajwa <marcin.rajwa(a)linux.intel.com> > Signed-off-by: Keyon Jie <yang.jie(a)linux.intel.com> looks good, for this patch: Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> ------------------------------ Message: 3 Date: Thu, 4 Jul 2019 12:18:24 +0200 From: Jaroslav Kysela <perex(a)perex.cz> To: "Channaiah Vanitha (RBEI/ECF3)" <Vanitha.Channaiah(a)in.bosch.com> Cc: "Wischer Timo \(ADITG/ESS\)" <twischer(a)de.adit-jv.com>, "alsa-devel(a)alsa-project.org" <alsa-devel(a)alsa-project.org> Subject: Re: [alsa-devel] GIT: Regarding the issue we are facing in the commit 37728639ae05de702825d96bd1d42e24ae772248 Message-ID: <556614e1-acba-635c-beed-6484fb887299(a)perex.cz> Content-Type: text/plain; charset=utf-8 Dne 03. 07. 19 v 14:17 Channaiah Vanitha (RBEI/ECF3) napsal(a): > Hello Jaroslav-san, > >> I think that it would be probably best to force the parameters for your hardware (--period-size and --buffer-size arguments for aplay or the time counterparts - --period-time and --buffer-time). The refining rules might not select the perfect configuration in some cases. > > I tried to force parameters "period-size" in multiples of 2ms as our hardware supports 2ms period time data and buffer-size=twice period size. > But still I face the issue. There is no exact 2ms period size for the rate 11025Hz, because it's float number 21.9780 (period size)... You may try values like 15,35,45,105 (anything which can match 11025 / PERIOD_SIZE without the remainder). Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. ------------------------------ Message: 4 Date: Thu, 4 Jul 2019 18:29:20 +0800 From: Keyon Jie <yang.jie(a)linux.intel.com> To: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: alsa-devel(a)alsa-project.org, ranjani.sridharan(a)linux.intel.com, Marcin Rajwa <marcin.rajwa(a)linux.intel.com>, pierre-louis.bossart(a)linux.intel.com Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: SOF: add flag for position update ipc Message-ID: <3788800e-7050-d68a-bec6-5b443fd0d563(a)linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed On 2019/7/4 ??6:03, Kai Vehmanen wrote: > Hi, > > patch looks good, but commit message could be improved. > > On Wed, 3 Jul 2019, Keyon Jie wrote: > >> In some cases, FW might need use the host_period_bytes even no position >> update ipc reqiured from driver, here add another flag for position update, >> and preserve host_period_bytes for FW to use. > > Speculation on what FW might do is not really needed. The > host_period_bytes field has been overloaded with multiple > semantics and this patch clears that, right. How about: Well, to me it is flavor choice, Ranjani suggested to illustrate the use case where the FW will use this host_period_bytes, and I agreed this will help people to understand why we need this change. > > "" > Remove the special case semantics of 'host_period_bytes==0'. > Add a new field 'no_period_irq' to signal whether period elapsed > IPC should be sent and use 'host_period_bytes' only for > period size. > "" > >> This might require corresponding FW change and ABI alignment. > > This is not helpful -- we know this _is_ a minor ABI change > and needs to be aligned with FW. It is minor change, but the FW change is still required, otherwise, we will get extra position update IPCs which may confuse the driver, please refer to here: https://github.com/thesofproject/sof/pull/1592 Thanks, ~Keyon > > Br, Kai > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > https://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ------------------------------ Message: 5 Date: Thu, 4 Jul 2019 11:46:20 +0100 From: Julian Bradfield <jalsa-devel(a)jcbradfield.org> To: alsa-devel(a)alsa-project.org Subject: [alsa-devel] bug in playing 6-channel sound Message-ID: <23837.55548.631053.741245(a)vis.stevens-bradfield.com> Content-Type: text/plain; charset=us-ascii Some five years ago, the following post https://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/072265.… reported a failure to play six-channel sound, that could be worked around by setting the prealloc value for the device to various values *other than* the default 64. I have just run into this playing a movie from my laptop (Thinkpad Yoga X1, Intel HDA PCH sound card outputting through HDMI) running Xubuntu 18.04, up to date as at the time of posting. I see exactly the same problem as in that post, and the same workaround works for me - I tried prealloc values 63,65,32,128, and any of them is ok. I'm a bit baffled that such a problem has survived for several years. If any developer would like me to provide debugging information, please get in touch - I have some time available at present, but not enough to learn ALSA and debug it myself! I will remain subscribed to the list for a few weeks to read any followups. ------------------------------ Message: 6 Date: Thu, 4 Jul 2019 14:00:31 +0300 (EEST) From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> To: Keyon Jie <yang.jie(a)linux.intel.com> Cc: alsa-devel(a)alsa-project.org, Marcin Rajwa <marcin.rajwa(a)linux.intel.com>, ranjani.sridharan(a)linux.intel.com, Kai Vehmanen <kai.vehmanen(a)linux.intel.com>, pierre-louis.bossart(a)linux.intel.com Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: SOF: add flag for position update ipc Message-ID: <alpine.DEB.2.21.1907041344240.4409@eliteleevi> Content-Type: text/plain; charset=US-ASCII Hi, On Thu, 4 Jul 2019, Keyon Jie wrote: > Well, to me it is flavor choice, Ranjani suggested to illustrate the use > case where the FW will use this host_period_bytes, and I agreed this > will help people to understand why we need this change. hmm, ok. So maybe add "Allows FW to use 'host_period_bytes' field for its original purpose" to my proposed wording..? >> This is not helpful -- we know this _is_ a minor ABI change >> and needs to be aligned with FW. > It is minor change, but the FW change is still required, otherwise, we > will get extra position update IPCs which may confuse the driver, please [...] > https://github.com/thesofproject/sof/pull/1592 Ack, but we know this already so best to put the accurate description in the commit message. The "might require FW change" is a bit scary statement in a patch touching ABI structs. ;) ------------------------------ Message: 7 Date: Thu, 4 Jul 2019 12:47:29 +0100 From: Richard Fitzgerald <rf(a)opensource.cirrus.com> To: Fuqian Huang <huangfq.daxian(a)gmail.com> Cc: alsa-devel(a)alsa-project.org, patches(a)opensource.cirrus.com, Takashi Iwai <tiwai(a)suse.com>, Liam Girdwood <lgirdwood(a)gmail.com>, Mark Brown <broonie(a)kernel.org>, linux-kernel(a)vger.kernel.org Subject: Re: [alsa-devel] [PATCH v2 34/35] sound/soc/codecs: Use kmemdup rather than duplicating its implementation Message-ID: <52ee7351-19fc-4fd3-33f8-9392a4ad9526(a)opensource.cirrus.com> Content-Type: text/plain; charset="utf-8"; format=flowed Commit message title prefix should be "ASoC: wm0010:" not "sound/soc /codecs:". Take a look at other patches to the same files. > kmemdup is introduced to duplicate a region of memory in a neat way. > Rather than kmalloc/kzalloc + memcpy, which the programmer needs to > write the size twice (sometimes lead to mistakes), kmemdup improves > readability, leads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. > > Acked-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> > Signed-off-by: Fuqian Huang <huangfq.daxian(a)gmail.com> > --- > Changes in v2: > - Fix a typo in commit message (memset -> memcpy) > - Split into two patches > > sound/soc/codecs/wm0010.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c > index 727d6703c905..807826f30f58 100644 > --- a/sound/soc/codecs/wm0010.c > +++ b/sound/soc/codecs/wm0010.c > @@ -515,7 +515,7 @@ static int wm0010_stage2_load(struct snd_soc_component *component) > dev_dbg(component->dev, "Downloading %zu byte stage 2 loader\n", fw->size); > > /* Copy to local buffer first as vmalloc causes problems for dma */ > - img = kzalloc(fw->size, GFP_KERNEL | GFP_DMA); > + img = kmemdup(&fw->data[0], fw->size, GFP_KERNEL | GFP_DMA); > if (!img) { > ret = -ENOMEM; > goto abort2; > @@ -527,8 +527,6 @@ static int wm0010_stage2_load(struct snd_soc_component *component) > goto abort1; > } > > - memcpy(img, &fw->data[0], fw->size); > - > spi_message_init(&m); > memset(&t, 0, sizeof(t)); > t.rx_buf = out; > ------------------------------ Message: 8 Date: Thu, 4 Jul 2019 12:02:17 +0000 From: "He, Bo" <bo.he(a)intel.com> To: "kailang(a)realtek.com" <kailang(a)realtek.com>, "alsa-devel(a)alsa-project.org" <alsa-devel(a)alsa-project.org>, "linux-kernel(a)vger.kernel.org" <linux-kernel(a)vger.kernel.org> Cc: "chiu(a)endlessm.com" <chiu(a)endlessm.com>, "tiwai(a)suse.com" <tiwai(a)suse.com>, "drake(a)endlessm.com" <drake(a)endlessm.com>, "hui.wang(a)canonical.com" <hui.wang(a)canonical.com>, "jian-hong(a)endlessm.com" <jian-hong(a)endlessm.com> Subject: [alsa-devel] audio lost from speaker after reboot from windows on the device ALC295 Message-ID: <CD6925E8781EFD4D8E11882D20FC406D52AB58B6(a)SHSMSX104.ccr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Hi, patch_realtek.c maintainer: I see one issue that reboot from windows and boot to ubuntu, the audio lost from speaker, I suspect there are some bugs in patch_realtek.c drivers, the device is ALC295 and the device id is 0x10ec0295. I have done the below experiments: 1. reboot from windows to windows, the audio is persist . 2. reboot from windows to ubuntu, the audio lost from speaker, but can hear if I hotplug one earphone. 3. if the issue reproduce after reboot from windows, reboot the ubuntu can't restore the audio, I suspect it's warm reset. 4. if I write the port 0xcf9 with 0xe to do cold reset, the audio can restore. 5. if I do suspend/resume, the audio can restore, I suspect do cold boot and suspend will trigger the platform reset to reset the ALC295. 6. if I do double function reset (write the verb 0x7ff in alc_init), the audio is still can't restore. snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* Function reset */ snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* double Function reset */ 7. the issue is first found on kernel 4.19.50, I still see the issue with the latest kernel 5.2-rc2, is it possible windows change some default registers, but ALC295 don't initialize the register? ------------------------------ Subject: Digest Footer _______________________________________________ Alsa-devel mailing list Alsa-devel(a)alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ------------------------------ End of Alsa-devel Digest, Vol 149, Issue 28 *******************************************

1 0

Re: [alsa-devel] [PATCH 2/3] ASoC: fsl_asrc: update supported sample format
by S.j. Wang 18 Sep '19

18 Sep '19

Hi > > On Fri, Sep 13, 2019 at 05:48:40AM +0000, S.j. Wang wrote: > > Hi > > > > > > > > On Tue, Sep 10, 2019 at 02:07:25AM +0000, S.j. Wang wrote: > > > > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote: > > > > > > The ASRC support 24bit/16bit/8bit input width, so S20_3LE > > > > > > format should not be supported, it is word width is 20bit. > > > > > > > > > > I thought 3LE used 24-bit physical width. And the driver assigns > > > > > ASRC_WIDTH_24_BIT to "width" for all non-16bit cases, so 20-bit > > > > > would go for that 24-bit slot also. I don't clearly recall if I > > > > > had explicitly tested S20_3LE, but I feel it should work since I put > there... > > > > > > > > For S20_3LE, the width is 20bit, but the ASRC only support 24bit, > > > > if set the ASRMCR1n.IWD= 24bit, because the actual width is 20 > > > > bit, the volume is Lower than expected, it likes 24bit data right shift 4 > bit. > > > > So it is not supported. > > > > > > Hmm..S20_3LE right-aligns 20 bits in a 24-bit slot? I thought > > > they're left aligned... > > > > > > If this is the case...shouldn't we have the same lower-volume > > > problem for all hardwares that support S20_3LE now? > > > > Actually some hardware/module when they do transmission from FIFO to > > shift register, they can select the start bit, for example from the > > 20th bit. but not all module have this capability. > > > > For ASRC, it haven't. IWD can only cover the data width, there is no > > Other bit for slot width. > > Okay..let's drop the S20_3LE then. But would it be possible for you to > elaborate the reasoning into the commit message also? Just for case when > people ask why we remove it simply. > > Thanks OK. Best regards Wang shengjiu

1 0

[alsa-devel] Build failure after merge of the sound-current
by Mark Brown 17 Sep '19

17 Sep '19

After merging the sound-current tree, today's linux-next build for x86 allmodconfig failed like this: In file included from /home/broonie/next/next/sound/soc/intel/boards/sof_rt5682.c:23: /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h: In function 'soc_intel_is_cml': /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h:39:23: error: 'INTEL_FAM6_KABYLAKE_MOBILE' undeclared (first use in this function); did you mean 'INTEL_FAM6_KABYLAKE_L'? SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h:39:23: note: each undeclared identifier is reported only once for each function it appears in SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ /home/broonie/next/next/sound/soc/intel/boards/../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ make[5]: *** [/home/broonie/next/next/scripts/Makefile.build:281: sound/soc/intel/boards/sof_rt5682.o] Error 1 make[4]: *** [/home/broonie/next/next/scripts/Makefile.build:497: sound/soc/intel/boards] Error 2 make[4]: *** Waiting for unfinished jobs.... In file included from /home/broonie/next/next/sound/soc/intel/atom/sst/sst_acpi.c:35: /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h: In function 'soc_intel_is_cml': /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:23: error: 'INTEL_FAM6_KABYLAKE_MOBILE' undeclared (first use in this function); did you mean 'INTEL_FAM6_KABYLAKE_L'? SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:23: note: each undeclared identifier is reported only once for each function it appears in SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ /home/broonie/next/next/sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ make[6]: *** [/home/broonie/next/next/scripts/Makefile.build:281: sound/soc/intel/atom/sst/sst_acpi.o] Error 1 make[5]: *** [/home/broonie/next/next/scripts/Makefile.build:497: sound/soc/intel/atom/sst] Error 2 make[4]: *** [/home/broonie/next/next/scripts/Makefile.build:497: sound/soc/intel/atom] Error 2 make[3]: *** [/home/broonie/next/next/scripts/Makefile.build:497: sound/soc/intel] Error 2 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [/home/broonie/next/next/scripts/Makefile.build:497: sound/soc] Error 2 make[1]: *** [/home/broonie/next/next/Makefile:1087: sound] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:179: sub-make] Error 2 Command exited with non-zero status 2 caused by commit c643c189f0fec116 (ASoC: Intel: boards: Add Cometlake machine driver support) IIRC there was some previous discussion of a dependency on other changes here but I thought that was resolved? I've reverted that commit for today.

3 5

[alsa-devel] [PATCH v2 0/3] Several SAI fixes
by Daniel Baluta 17 Sep '19

17 Sep '19

This series contains several fixes for SAI. They are unrelated but grouped them in a patch series to be easier applied. Daniel Baluta (1): ASoC: fsl_sai: Fix TCSR.TE/RCSR.RE in synchronous mode Mihai Serban (1): ASoC: fsl_sai: Fix noise when using EDMA Shengjiu Wang (1): ASoC: fsl_sai: Fix xMR setting in synchronous mode sound/soc/fsl/fsl_sai.c | 31 ++++++++++++++++++++++--------- sound/soc/fsl/fsl_sai.h | 1 + 2 files changed, 23 insertions(+), 9 deletions(-) -- 2.17.1

3 7

[alsa-devel] [PATCH v4 0/9] adapt SOF to use snd-hda-codec-hdmi
by Kai Vehmanen 17 Sep '19

17 Sep '19

Hi all, here's the 4th round for this series that adapts SOF to use snd-hda-codec-hdmi (patch_hdmi.c) codec driver instead of hdac_hdmi (soc/codecs/hdac_hdmi.c). The primary goal is to unify the HDMI codec implementation between DSP and non-DSP HDA configurations, offer same interface to user-space and reduce maintenance load for all. v4 changes: - Change order of patches to not break bisect (Pierre's feedback). - Improve the explanation in commit message for mst_no_extra_pcms, patch 1. (Pierre's feedback). - Fix errors in PCM constraints for HDMI (Pierre's feedback). - Fix an issue on Ice Lake platforms (patch 3). Feature and testing info: - Tested on multiple Intel platforms supported by SOF. - Tested with ALSA console tools as well as with Pulseaudio. - requires Pulseaudio 12.x or newer, see https://lists.freedesktop.org/archives/pulseaudio-discuss/2019-August/03135… - HDMI, DP, DP-MST with multi-monitor use-scenarios work ok. - New feature for SOF: ELD /proc fs works just like in DSP-less mode. - New feature for SOF: jack detection works out-of-the-box with Pulseaudio (no need for card specific UCM for HDMI) Kai Vehmanen (9): ALSA: hda/hdmi - implement mst_no_extra_pcms flag ASoC: hdac_hda: add support for HDMI/DP as a HDA codec ASoC: Intel: skl-hda-dsp-generic: use snd-hda-codec-hdmi ASoC: Intel: skl-hda-dsp-generic: fix include guard name ASoC: SOF: Intel: add support for snd-hda-codec-hdmi ASoC: Intel: bxt-da7219-max98357a: common hdmi codec support ASoC: Intel: glk_rt5682_max98357a: common hdmi codec support ASoC: intel: sof_rt5682: common hdmi codec support ASoC: Intel: bxt_rt298: common hdmi codec support include/sound/hda_codec.h | 1 + include/sound/soc-acpi.h | 2 + sound/pci/hda/patch_hdmi.c | 19 +++- sound/soc/codecs/hdac_hda.c | 100 +++++++++++++++--- sound/soc/codecs/hdac_hda.h | 12 ++- sound/soc/intel/boards/bxt_da7219_max98357a.c | 11 ++ sound/soc/intel/boards/bxt_rt298.c | 11 ++ sound/soc/intel/boards/glk_rt5682_max98357a.c | 11 ++ sound/soc/intel/boards/hda_dsp_common.h | 93 ++++++++++++++++ sound/soc/intel/boards/skl_hda_dsp_common.c | 10 +- sound/soc/intel/boards/skl_hda_dsp_common.h | 27 ++++- sound/soc/intel/boards/skl_hda_dsp_generic.c | 1 + sound/soc/intel/boards/sof_rt5682.c | 11 ++ sound/soc/sof/intel/Kconfig | 10 ++ sound/soc/sof/intel/hda-codec.c | 19 +++- sound/soc/sof/intel/hda.c | 6 ++ sound/soc/sof/intel/hda.h | 6 +- 17 files changed, 323 insertions(+), 27 deletions(-) create mode 100644 sound/soc/intel/boards/hda_dsp_common.h -- 2.17.1

3 16

[alsa-devel] [PATCH v5] dt-bindings: ASoC: Add tas2770 smart PA dt bindings
by shifu0704＠thundersoft.com 17 Sep '19

17 Sep '19

From: Frank Shi <shifu0704(a)thundersoft.com> Add tas2770 smart PA dt bindings Signed-off-by: Frank Shi <shifu0704(a)thundersoft.com> --- .../devicetree/bindings/sound/tas2770.txt | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas2770.txt diff --git a/Documentation/devicetree/bindings/sound/tas2770.txt b/Documentation/devicetree/bindings/sound/tas2770.txt new file mode 100644 index 0000000..ede6bb3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2770.txt @@ -0,0 +1,37 @@ +Texas Instruments TAS2770 Smart PA + +The TAS2770 is a mono, digital input Class-D audio amplifier optimized for +efficiently driving high peak power into small loudspeakers. +Integrated speaker voltage and current sense provides for +real time monitoring of loudspeaker behavior. + +Required properties: + + - compatible: - Should contain "ti,tas2770". + - reg: - The i2c address. Should contain <0x4c>, <0x4d>,<0x4e>, or <0x4f>. + - #address-cells - Should be <1>. + - #size-cells - Should be <0>. + - ti,asi-format: - Sets TDM RX capture edge. 0->Rising; 1->Falling. + - ti,imon-slot-no:- TDM TX current sense time slot. + - ti,vmon-slot-no:- TDM TX voltage sense time slot. + +Optional properties: + +- interrupt-parent: the phandle to the interrupt controller which provides + the interrupt. +- interrupts: interrupt specification for data-ready. + +Examples: + + tas2770@4c { + compatible = "ti,tas2770"; + reg = <0x4c>; + #address-cells = <1>; + #size-cells = <0>; + interrupt-parent = <&msm_gpio>; + interrupts = <97 0>; + ti,asi-format = <0>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + -- 2.7.4

2 3