July 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v2 1/3] ASoC: Intel: bytcr_rt5651: Remove is_valleyview helper
by Hans de Goede 10 Jul '18

10 Jul '18

Remove is_valleyview helper, this is not necessary, we can simply call x86_match_cpu() directly instead. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/boards/bytcr_rt5651.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index ba2753e0e12a..80f47a45cb10 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -28,6 +28,7 @@ #include <linux/dmi.h> #include <linux/slab.h> #include <asm/cpu_device_id.h> +#include <asm/intel-family.h> #include <asm/platform_sst_audio.h> #include <sound/pcm.h> #include <sound/pcm_params.h> @@ -680,17 +681,10 @@ static char byt_rt5651_codec_aif_name[12]; /* = "rt5651-aif[1|2]" */ static char byt_rt5651_cpu_dai_name[10]; /* = "ssp[0|2]-port" */ static char byt_rt5651_long_name[40]; /* = "bytcr-rt5651-*-mic[-swapped-hp]" */ -static bool is_valleyview(void) -{ - static const struct x86_cpu_id cpu_ids[] = { - { X86_VENDOR_INTEL, 6, 55 }, /* Valleyview, Bay Trail */ - {} - }; - - if (!x86_match_cpu(cpu_ids)) - return false; - return true; -} +static const struct x86_cpu_id baytrail_cpu_ids[] = { + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_SILVERMONT1 }, /* Valleyview */ + {} +}; struct acpi_chan_package { /* ACPICA seems to require 64 bit integers */ u64 aif_value; /* 1: AIF1, 2: AIF2 */ @@ -741,7 +735,7 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) * swap SSP0 if bytcr is detected * (will be overridden if DMI quirk is detected) */ - if (is_valleyview()) { + if (x86_match_cpu(baytrail_cpu_ids)) { struct sst_platform_info *p_info = mach->pdata; const struct sst_res_info *res_info = p_info->res_info; -- 2.17.1

3 7

[alsa-devel] [PATCH v2] ASoC: Intel: bytcr_rt5651: Add support for externar amplifier enable GPIO
by Hans de Goede 10 Jul '18

10 Jul '18

The rt5651 does not have a built-in speaker amplifier, so it is often used together with an external amplifier. On Cherry Trail boards this external amplifier's enable pin is driven through a GPIO, which is given as the first GPIO in the ACPI resources of the codec fwnode. This commit adds support to the bytcr_rt5651 for this GPIO, fixing the speaker not working on CHT devices with a rt5651 codec. Cc: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: -Handle the ext amp GPIO entirely in the machine driver, the ext-amp is not part of the codec, so it should not be controlled by the codec driver --- sound/soc/intel/boards/bytcr_rt5651.c | 65 +++++++++++++++++++++++++-- 1 file changed, 62 insertions(+), 3 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index d920725ce603..5301205496be 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -26,6 +26,8 @@ #include <linux/clk.h> #include <linux/device.h> #include <linux/dmi.h> +#include <linux/gpio/consumer.h> +#include <linux/gpio/machine.h> #include <linux/slab.h> #include <asm/cpu_device_id.h> #include <asm/intel-family.h> @@ -86,6 +88,7 @@ enum { struct byt_rt5651_private { struct clk *mclk; + struct gpio_desc *ext_amp_gpio; struct snd_soc_jack jack; }; @@ -208,6 +211,20 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w, return 0; } +static int rt5651_ext_amp_power_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_card *card = w->dapm->card; + struct byt_rt5651_private *priv = snd_soc_card_get_drvdata(card); + + if (SND_SOC_DAPM_EVENT_ON(event)) + gpiod_set_value_cansleep(priv->ext_amp_gpio, 1); + else + gpiod_set_value_cansleep(priv->ext_amp_gpio, 0); + + return 0; +} + static const struct snd_soc_dapm_widget byt_rt5651_widgets[] = { SND_SOC_DAPM_HP("Headphone", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), @@ -217,7 +234,9 @@ static const struct snd_soc_dapm_widget byt_rt5651_widgets[] = { SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, platform_clock_control, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), - + SND_SOC_DAPM_SUPPLY("Ext Amp Power", SND_SOC_NOPM, 0, 0, + rt5651_ext_amp_power_event, + SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMU), }; static const struct snd_soc_dapm_route byt_rt5651_audio_map[] = { @@ -225,6 +244,7 @@ static const struct snd_soc_dapm_route byt_rt5651_audio_map[] = { {"Headset Mic", NULL, "Platform Clock"}, {"Internal Mic", NULL, "Platform Clock"}, {"Speaker", NULL, "Platform Clock"}, + {"Speaker", NULL, "Ext Amp Power"}, {"Line In", NULL, "Platform Clock"}, {"Headset Mic", NULL, "micbias1"}, /* lowercase for rt5651 */ @@ -678,6 +698,18 @@ static const struct x86_cpu_id baytrail_cpu_ids[] = { {} }; +static const struct x86_cpu_id cherrytrail_cpu_ids[] = { + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_AIRMONT }, /* Braswell */ + {} +}; + +static const struct acpi_gpio_params ext_amp_enable_gpios = { 0, 0, false }; + +static const struct acpi_gpio_mapping byt_rt5651_gpios[] = { + { "ext-amp-enable-gpios", &ext_amp_enable_gpios, 1 }, + { }, +}; + struct acpi_chan_package { /* ACPICA seems to require 64 bit integers */ u64 aif_value; /* 1: AIF1, 2: AIF2 */ u64 mclock_value; /* usually 25MHz (0x17d7940), ignored */ @@ -793,9 +825,36 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) /* Must be called before register_card, also see declaration comment. */ ret_val = byt_rt5651_add_codec_device_props(codec_dev); - put_device(codec_dev); - if (ret_val) + if (ret_val) { + put_device(codec_dev); return ret_val; + } + + /* Cherry Trail devices use an external amplifier enable gpio */ + if (x86_match_cpu(cherrytrail_cpu_ids)) { + devm_acpi_dev_add_driver_gpios(codec_dev, byt_rt5651_gpios); + priv->ext_amp_gpio = devm_fwnode_get_index_gpiod_from_child( + &pdev->dev, "ext-amp-enable", 0, + codec_dev->fwnode, + GPIOD_OUT_LOW, "speaker-amp"); + if (IS_ERR(priv->ext_amp_gpio)) { + ret_val = PTR_ERR(priv->ext_amp_gpio); + switch (ret_val) { + case -ENOENT: + priv->ext_amp_gpio = NULL; + break; + default: + dev_err(&pdev->dev, "Failed to get ext-amp-enable GPIO: %d\n", + ret_val); + /* fall through */ + case -EPROBE_DEFER: + put_device(codec_dev); + return ret_val; + } + } + } + + put_device(codec_dev); log_quirks(&pdev->dev); -- 2.17.1

2 2

[alsa-devel] [PATCH 1/5] ASoC: rt5651: Fix workqueue cancel vs irq free race on remove
by Hans de Goede 10 Jul '18

10 Jul '18

On removal we must free the IRQ *before* cancelling the jack-detect work, so that the jack-detect work cannot be rescheduled by the IRQ. Before this commit we were cancelling the jack-detect work from the driver remove callback, while relying on devm to free the IRQ, which happens after the remove callback. This is the wrong order. This commit uses a devm-action to register a devm callback which cancels the work, before requesting the IRQ (devm tears things down in reverse order). This also allows us to remove the now empty remove driver callback. Cc: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/codecs/rt5651.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c index 6b5669f3e85d..39d2c67cd064 100644 --- a/sound/soc/codecs/rt5651.c +++ b/sound/soc/codecs/rt5651.c @@ -1696,6 +1696,13 @@ static irqreturn_t rt5651_irq(int irq, void *data) return IRQ_HANDLED; } +static void rt5651_cancel_work(void *data) +{ + struct rt5651_priv *rt5651 = data; + + cancel_work_sync(&rt5651->jack_detect_work); +} + static int rt5651_set_jack(struct snd_soc_component *component, struct snd_soc_jack *hp_jack, void *data) { @@ -2036,6 +2043,11 @@ static int rt5651_i2c_probe(struct i2c_client *i2c, INIT_WORK(&rt5651->jack_detect_work, rt5651_jack_detect_work); + /* Make sure work is stopped on probe-error / remove */ + ret = devm_add_action_or_reset(&i2c->dev, rt5651_cancel_work, rt5651); + if (ret) + return ret; + ret = devm_snd_soc_register_component(&i2c->dev, &soc_component_dev_rt5651, rt5651_dai, ARRAY_SIZE(rt5651_dai)); @@ -2043,15 +2055,6 @@ static int rt5651_i2c_probe(struct i2c_client *i2c, return ret; } -static int rt5651_i2c_remove(struct i2c_client *i2c) -{ - struct rt5651_priv *rt5651 = i2c_get_clientdata(i2c); - - cancel_work_sync(&rt5651->jack_detect_work); - - return 0; -} - static struct i2c_driver rt5651_i2c_driver = { .driver = { .name = "rt5651", @@ -2059,7 +2062,6 @@ static struct i2c_driver rt5651_i2c_driver = { .of_match_table = of_match_ptr(rt5651_of_match), }, .probe = rt5651_i2c_probe, - .remove = rt5651_i2c_remove, .id_table = rt5651_i2c_id, }; module_i2c_driver(rt5651_i2c_driver); -- 2.17.1

3 11

[alsa-devel] [PATCH] dma: add support for reporting pause and resume separately
by Marek Szyprowski 09 Jul '18

09 Jul '18

'cmd_pause' DMA channel capability means that respective DMA engine supports both pausing and resuming given DMA channel. However, in some cases it is important to know if DMA channel can be paused without the need to resume it. This is a typical requirement for proper residue reading on transfer timeout in UART drivers. There are also some DMA engines with limited hardware, which doesn't really support resuming. Reporting pause and resume capabilities separately allows UART drivers to properly check for the really required capabilities and operate in DMA mode also in systems with limited DMA hardware. On the other hand drivers, which rely on full channel suspend/resume support, should now check for both 'pause' and 'resume' features. Existing clients of dma_get_slave_caps() have been checked and the only driver which rely on proper channel resuming is soc-generic-dmaengine-pcm driver, which has been updated to check the newly added capability. Existing 'cmd_pause' now only indicates that DMA engine support pausing given DMA channel. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- This patch is a follow-up of the Vinod's advise from the following discussion: https://www.spinics.net/lists/linux-samsung-soc/msg63166.html --- drivers/dma/dmaengine.c | 8 ++------ include/linux/dmaengine.h | 5 ++++- sound/soc/soc-generic-dmaengine-pcm.c | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index 08ba8473a284..84ac38dbdb65 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -500,12 +500,8 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps) caps->max_burst = device->max_burst; caps->residue_granularity = device->residue_granularity; caps->descriptor_reuse = device->descriptor_reuse; - - /* - * Some devices implement only pause (e.g. to get residuum) but no - * resume. However cmd_pause is advertised as pause AND resume. - */ - caps->cmd_pause = !!(device->device_pause && device->device_resume); + caps->cmd_pause = !!device->device_pause; + caps->cmd_resume = !!device->device_resume; caps->cmd_terminate = !!device->device_terminate_all; return 0; diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index 861be5cab1df..c8c3a7a93802 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -415,7 +415,9 @@ enum dma_residue_granularity { * each type, the dma controller should set BIT(<TYPE>) and same * should be checked by controller as well * @max_burst: max burst capability per-transfer - * @cmd_pause: true, if pause and thereby resume is supported + * @cmd_pause: true, if pause is supported (i.e. for reading residue or + * for resume later) + * @cmd_resume: true, if resume is supported * @cmd_terminate: true, if terminate cmd is supported * @residue_granularity: granularity of the reported transfer residue * @descriptor_reuse: if a descriptor can be reused by client and @@ -427,6 +429,7 @@ struct dma_slave_caps { u32 directions; u32 max_burst; bool cmd_pause; + bool cmd_resume; bool cmd_terminate; enum dma_residue_granularity residue_granularity; bool descriptor_reuse; diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index 56a541b9ff9e..76c46d793843 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -156,7 +156,7 @@ static int dmaengine_pcm_set_runtime_hwparams(struct snd_pcm_substream *substrea ret = dma_get_slave_caps(chan, &dma_caps); if (ret == 0) { - if (dma_caps.cmd_pause) + if (dma_caps.cmd_pause && dma_caps.cmd_resume) hw.info |= SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME; if (dma_caps.residue_granularity <= DMA_RESIDUE_GRANULARITY_SEGMENT) hw.info |= SNDRV_PCM_INFO_BATCH; -- 2.17.1

4 6

Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
by Alex Deucher 09 Jul '18

09 Jul '18

On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu(a)amd.com> wrote: > Hi Lukas, > > Thanks to your explanation, and see comments in line. > > > Do you need to runtime resume the HDA controller even if user space isn't > streaming audio? Why, and in which situation exactly? > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing. > > You're saying above that the HDA controller isn't runtime resumed on > hotplug of a display. Is that necessary to retrieve ELD or something? > I'm not sure if there's code in the HDA driver to acquire a runtime PM > ref on HPD, but maybe it's necessary. Or maybe the code is there but > somehow no HPD interrupt is received by the HDA driver? > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not. On the gfx side at least, we can get a hotplug event via ACPI (depending on the OEM design) if displays are attached/detached while the dGPU is powered down. I suppose the gfx driver could call into the audio driver during one of those events. On the gfx side at least we just generate the gfx hotplug event and let userspace deal with it. Alex > > Thanks > JimQu > > ________________________________________ > 发件人: Lukas Wunner <lukas(a)wunner.de> > 发送时间: 2018年7月9日 17:27 > 收件人: Qu, Jim > 抄送: alsa-devel(a)alsa-project.org; dri-devel(a)lists.freedesktop.org; Deucher, Alexander; amd-gfx(a)lists.freedesktop.org > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote: >> Now, I found the audio device will auto suspend even if the gpu is active, >> and if I plug in a HDMI device it also do not resume back. >> >> 1. Did you encounter similar issue before? >> 2. audio will auto suspend as default at beginning of boot, is it expect >> behaviour? > > Yes, that's expected. Once you start streaming audio to attached displays, > user space opens the codec device and this causes the HDA controller to > runtime resume. If the discrete GPU is suspended at that moment, it will > be powered on and kept powered on as long as user space is streaming audio. > > Do you need to runtime resume the HDA controller even if user space isn't > streaming audio? Why, and in which situation exactly? > > You're saying above that the HDA controller isn't runtime resumed on > hotplug of a display. Is that necessary to retrieve ELD or something? > I'm not sure if there's code in the HDA driver to acquire a runtime PM > ref on HPD, but maybe it's necessary. Or maybe the code is there but > somehow no HPD interrupt is received by the HDA driver? > > Thanks, > > Lukas > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel

5 12

Re: [alsa-devel] 答复: ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
by Takashi Iwai 09 Jul '18

09 Jul '18

On Mon, 09 Jul 2018 17:53:19 +0200, Qu, Jim wrote: > > Hi All, > > Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU. I'm confused. So you mean that the HDMI detection on Intel GPU doesn't work with the hybrid GPUs? And no audio codec on discrete GPU...? Why do we need vga_switcheroo at all, then? Takashi > > Thanks > JimQu > > -----邮件原件----- > 发件人: Lukas Wunner <lukas(a)wunner.de> > 发送时间: 2018年7月9日 23:48 > 收件人: Takashi Iwai <tiwai(a)suse.de> > 抄送: Alex Deucher <alexdeucher(a)gmail.com>; alsa-devel(a)alsa-project.org; amd-gfx(a)lists.freedesktop.org; Qu, Jim <Jim.Qu(a)amd.com>; dri-devel(a)lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher(a)amd.com> > 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id > > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote: > > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote: > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu(a)amd.com> wrote: > > > > > You're saying above that the HDA controller isn't runtime > > > > > resumed on hotplug of a display. Is that necessary to retrieve ELD or something? > > > > > I'm not sure if there's code in the HDA driver to acquire a > > > > > runtime PM ref on HPD, but maybe it's necessary. Or maybe the > > > > > code is there but somehow no HPD interrupt is received by the HDA driver? > > > > > > > > So far, I do not find any code about audio response HPD in kernel. > > > > the HPD interrupt will sent to user mode via uevent, not sure > > > > whether audio user mode driver can receive the event or not. > > > > > > On the gfx side at least, we can get a hotplug event via ACPI > > > (depending on the OEM design) if displays are attached/detached > > > while the dGPU is powered down. I suppose the gfx driver could call > > > into the audio driver during one of those events. On the gfx side > > > at least we just generate the gfx hotplug event and let userspace deal with it. > > > > IMO, a more proper way would be to have the direct communication > > between the graphics driver and the audio driver like i915 driver > > does. Then the audio driver can get plug/unplug event at more > > accurate timing without races. > > Since v4.17, every time the GPU is powered up, the HDA controller is runtime resumed to PCI_D0. (See the call to pci_wakeup_bus() in > vga_switcheroo_runtime_resume() added by dcac86b7d0.) > > If the HDA controller can't detect presence of an HDMI display even if it's in PCI_D0, then I suppose that needs to be adressed in the HDA driver. Thus so far I don't see the need to call from amdgpu into the HDA driver. > > Thanks, > > Lukas

2 2

Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
by Alex Deucher 09 Jul '18

09 Jul '18

On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu(a)amd.com> wrote: > Hi Lukas, > > Thanks to your explanation, and see comments in line. > > > Do you need to runtime resume the HDA controller even if user space isn't > streaming audio? Why, and in which situation exactly? > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing. Sounds like a bug in the HDA driver. The HDA driver should cache what it needs or power it back up when there is an ioctl/etc. that requires something that can't be cached. Alex > > You're saying above that the HDA controller isn't runtime resumed on > hotplug of a display. Is that necessary to retrieve ELD or something? > I'm not sure if there's code in the HDA driver to acquire a runtime PM > ref on HPD, but maybe it's necessary. Or maybe the code is there but > somehow no HPD interrupt is received by the HDA driver? > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not. > > Thanks > JimQu > > ________________________________________ > 发件人: Lukas Wunner <lukas(a)wunner.de> > 发送时间: 2018年7月9日 17:27 > 收件人: Qu, Jim > 抄送: alsa-devel(a)alsa-project.org; dri-devel(a)lists.freedesktop.org; Deucher, Alexander; amd-gfx(a)lists.freedesktop.org > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote: >> Now, I found the audio device will auto suspend even if the gpu is active, >> and if I plug in a HDMI device it also do not resume back. >> >> 1. Did you encounter similar issue before? >> 2. audio will auto suspend as default at beginning of boot, is it expect >> behaviour? > > Yes, that's expected. Once you start streaming audio to attached displays, > user space opens the codec device and this causes the HDA controller to > runtime resume. If the discrete GPU is suspended at that moment, it will > be powered on and kept powered on as long as user space is streaming audio. > > Do you need to runtime resume the HDA controller even if user space isn't > streaming audio? Why, and in which situation exactly? > > You're saying above that the HDA controller isn't runtime resumed on > hotplug of a display. Is that necessary to retrieve ELD or something? > I'm not sure if there's code in the HDA driver to acquire a runtime PM > ref on HPD, but maybe it's necessary. Or maybe the code is there but > somehow no HPD interrupt is received by the HDA driver? > > Thanks, > > Lukas > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel

2 1

[alsa-devel] [RESEND][PATCH] ASoC: hdac_hdmi: Program pin-port-mux during jack report event
by Sriram Periyasamy 09 Jul '18

09 Jul '18

During d3/d0 cycle, the connection selection index of all pins points to the default value. This needs to be restored to ensure audio is restored after d3/d0 cycle. So store the connection selection index and program it during jack report event which gets invoked in cases like d3/d0 cycle, hot plug detection when multiple displays are connected. Signed-off-by: Sriram Periyasamy <sriramx.periyasamy(a)intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale(a)intel.com> Signed-off-by: Jeeja KP <jeeja.kp(a)intel.com> Signed-off-by: Guneshwor Singh <guneshwor.o.singh(a)intel.com> Acked-by: Vinod Koul <vkoul(a)kernel.org> --- sound/soc/codecs/hdac_hdmi.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 84f7a7a36e4b..7eb5a7138483 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -32,6 +32,7 @@ #include <sound/hda_chmap.h> #include "../../hda/local.h" #include "hdac_hdmi.h" +#include <sound/hda_regmap.h> #define NAME_SIZE 32 @@ -83,6 +84,7 @@ struct hdac_hdmi_pin { struct list_head head; hda_nid_t nid; bool mst_capable; + int conn_index; struct hdac_hdmi_port *ports; int num_ports; struct hdac_ext_device *edev; @@ -141,6 +143,9 @@ struct hdac_hdmi_priv { #define hdev_to_hdmi_priv(_hdev) ((to_ehdac_device(_hdev))->private_data) +static int hdac_hdmi_port_select_set(struct hdac_ext_device *edev, + struct hdac_hdmi_port *port); + static struct hdac_hdmi_pcm * hdac_hdmi_get_pcm_from_cvt(struct hdac_hdmi_priv *hdmi, struct hdac_hdmi_cvt *cvt) @@ -159,6 +164,7 @@ static void hdac_hdmi_jack_report(struct hdac_hdmi_pcm *pcm, struct hdac_hdmi_port *port, bool is_connect) { struct hdac_ext_device *edev = port->pin->edev; + int cmd, err; if (is_connect) snd_soc_dapm_enable_pin(port->dapm, port->jack_pin); @@ -166,6 +172,29 @@ static void hdac_hdmi_jack_report(struct hdac_hdmi_pcm *pcm, snd_soc_dapm_disable_pin(port->dapm, port->jack_pin); if (is_connect) { + /* set the device if pin is mst_capable */ + if (hdac_hdmi_port_select_set(edev, port) < 0) { + dev_err(&edev->hdev.dev, + "port %d device select fail\n", port->id); + return; + } + /* + * Restore the connection selection index of the + * respective pin. + */ + if (port->pin->conn_index > 0) { + cmd = snd_hdac_regmap_encode_verb(port->pin->nid, + AC_VERB_SET_CONNECT_SEL); + err = snd_hdac_regmap_write_raw(&edev->hdev, cmd, + port->pin->conn_index - 1); + if (err < 0) { + dev_err(&edev->hdev.dev, + "pin %d conn select index fail %d\n", + port->pin->nid, err); + return; + } + } + /* * Report Jack connect event when a device is connected * for the first time where same PCM is attached to multiple @@ -903,6 +932,9 @@ static int hdac_hdmi_set_pin_port_mux(struct snd_kcontrol *kcontrol, } } + if (ucontrol->value.enumerated.item[0] > 0) + port->pin->conn_index = ucontrol->value.enumerated.item[0]; + /* * Jack status is not reported during device probe as the * PCMs are not registered by then. So report it here. -- 2.7.4

2 7

[alsa-devel] Applied "ASoC: adau171x1: Connect playback DAI to the DSP" to the asoc tree
by Mark Brown 09 Jul '18

09 Jul '18

The patch ASoC: adau171x1: Connect playback DAI to the DSP has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 5bea327962fa296efd16f2d3369dd339ddd7ce6f Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Fri, 6 Jul 2018 16:19:14 +0300 Subject: [PATCH] ASoC: adau171x1: Connect playback DAI to the DSP The playback DAI is connected to the DSP and the DSP might be sourcing signals from the playback stream. Add a DAPM route between the two to make sure that the playback DAI is powered up, when the DSP is active. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/adau17x1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/adau17x1.c b/sound/soc/codecs/adau17x1.c index ae41edd1c406..57169b8ff14e 100644 --- a/sound/soc/codecs/adau17x1.c +++ b/sound/soc/codecs/adau17x1.c @@ -299,6 +299,7 @@ static const struct snd_soc_dapm_route adau17x1_dsp_dapm_routes[] = { { "DSP", NULL, "Left Decimator" }, { "DSP", NULL, "Right Decimator" }, + { "DSP", NULL, "Playback" }, }; static const struct snd_soc_dapm_route adau17x1_no_dsp_dapm_routes[] = { -- 2.18.0.rc2

1 0

[alsa-devel] [PATCH] ASoC: pxa: make SND_PXA_SOC_SSP depend on PLAT_PXA
by Arnd Bergmann 09 Jul '18

09 Jul '18

For the moment, we can't enable CONFIG_SND_PXA_SOC_SSP unless we are building for ARM PXA or MMP: WARNING: unmet direct dependencies detected for PXA_SSP Depends on [n]: PLAT_PXA [=n] Selected by [y]: - SND_PXA_SOC_SSP [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] This adds an explicit dependency for it. Fixes: 0a94cf345740 ("ASoC: pxa: make SND_PXA2XX_SOC_I2S selectable") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/pxa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index 2fc02c227f69..776e148b0aa2 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -34,6 +34,7 @@ config SND_PXA2XX_SOC_I2S config SND_PXA_SOC_SSP tristate "Soc Audio via PXA2xx/PXA3xx SSP ports" + depends on PLAT_PXA select PXA_SSP select SND_PXA2XX_LIB -- 2.9.0

2 1