March 2017 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v5 6/6] pcm:plug: save converter config
by sutar.mounesh＠gmail.com 21 Mar '17

21 Mar '17

From: Andreas Pape <apape(a)de.adit-jv.com> Passed config is freed after call to open, thus it is invalid when trying to extract the converter name. So config entry is saved for later usage. Signed-off-by: Andreas Pape <apape(a)de.adit-jv.com> Signed-off-by: Mounesh Sutar <sutar.mounesh(a)gmail.com> diff --git a/src/pcm/pcm_plug.c b/src/pcm/pcm_plug.c index 266707b..c4375ec 100644 --- a/src/pcm/pcm_plug.c +++ b/src/pcm/pcm_plug.c @@ -50,7 +50,7 @@ typedef struct { snd_pcm_format_t sformat; int schannels; int srate; - const snd_config_t *rate_converter; + snd_config_t *rate_converter; enum snd_pcm_plug_route_policy route_policy; snd_pcm_route_ttable_entry_t *ttable; int ttable_ok; @@ -64,6 +64,10 @@ static int snd_pcm_plug_close(snd_pcm_t *pcm) snd_pcm_plug_t *plug = pcm->private_data; int err, result = 0; free(plug->ttable); + if (plug->rate_converter) { + snd_config_delete(plug->rate_converter); + plug->rate_converter = NULL; + } assert(plug->gen.slave == plug->req_slave); if (plug->gen.close_slave) { snd_pcm_unlink_hw_ptr(pcm, plug->req_slave); @@ -1108,7 +1112,6 @@ int snd_pcm_plug_open(snd_pcm_t **pcmp, plug->sformat = sformat; plug->schannels = schannels; plug->srate = srate; - plug->rate_converter = rate_converter; plug->gen.slave = plug->req_slave = slave; plug->gen.close_slave = close_slave; plug->route_policy = route_policy; @@ -1125,6 +1128,15 @@ int snd_pcm_plug_open(snd_pcm_t **pcmp, pcm->ops = &snd_pcm_plug_ops; pcm->fast_ops = slave->fast_ops; pcm->fast_op_arg = slave->fast_op_arg; + if (rate_converter) { + err = snd_config_copy(&plug->rate_converter, + (snd_config_t *)rate_converter); + if (err < 0) { + snd_pcm_free(pcm); + free(plug); + return err; + } + } pcm->private_data = plug; pcm->poll_fd = slave->poll_fd; pcm->poll_events = slave->poll_events; -- 2.7.4

3 2

[alsa-devel] [PATCH v2] ALSA: x86: Select CONFIG_HDMI_LPE_AUDIO as default
by Ian W MORRISON 21 Mar '17

21 Mar '17

The upstream kernel builds for distributions such as Ubuntu which now includes binary packages for v4.11 mainline kernel release candidates are promoted as a way of testing upstream kernels to to confirm that upstream has fixed a specific issue (see https://wiki.ubuntu.com/ Kernel/MainlineBuilds). Unfortunately the long awaited patch for providing HDMI audio support for Bay Trail and Cherry Trail devices does not include this support through a module built by default. Through including by default of the two associated CONFIG settings (SND_X86 and HDMI_LPE_AUDIO), upstream kernel builds would automatically provide the much desired HDMI audio support by default. This patch uses a Kconfig 'default' statement to include the driver as default. Changes in version 2: CONFIG_SND_X86 now a bool and changed default m to default y Signed-off-by: Ian W Morrison <linuxium(a)linuxium.com.au> --- sound/x86/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/x86/Kconfig b/sound/x86/Kconfig index 84c8f8fc..cac2270 100644 --- a/sound/x86/Kconfig +++ b/sound/x86/Kconfig @@ -1,6 +1,7 @@ menuconfig SND_X86 - tristate "X86 sound devices" + bool "X86 sound devices" depends on X86 + default y ---help--- X86 sound devices that don't fall under SoC or PCI categories @@ -9,6 +10,7 @@ if SND_X86 config HDMI_LPE_AUDIO tristate "HDMI audio without HDaudio on Intel Atom platforms" depends on DRM_I915 + default y select SND_PCM help Choose this option to support HDMI LPE Audio mode -- 1.9.1

2 10

[alsa-devel] [PATCH] ASoC: STI: Fix null ptr deference in IRQ handler
by Arnaud Pouliquen 21 Mar '17

21 Mar '17

With RTlinux a race condition has been found that leads to NULL ptr crash: - On CPU 0: uni_player_irq_handler is called to treat XRUN "(player->state == UNIPERIF_STATE_STOPPED)" is FALSE so status is checked, dev_err(player->dev, "FIFO underflow error detected") is printed and then snd_pcm_stream_lock should be called to lock stream for stopping. - On CPU 1: application stop and close the stream. Issue is that the stop and shutdown functions are executed while "FIFO underflow error detected" is printed. So when CPU 0 call snd_pcm_stream_lock is player->substream is already null. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)st.com> --- sound/soc/sti/uniperif_player.c | 9 +++------ sound/soc/sti/uniperif_reader.c | 8 +++++--- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/sound/soc/sti/uniperif_player.c b/sound/soc/sti/uniperif_player.c index 60ae31a..6fa9eee 100644 --- a/sound/soc/sti/uniperif_player.c +++ b/sound/soc/sti/uniperif_player.c @@ -65,8 +65,10 @@ static irqreturn_t uni_player_irq_handler(int irq, void *dev_id) unsigned int status; unsigned int tmp; + snd_pcm_stream_lock(player->substream); if (player->state == UNIPERIF_STATE_STOPPED) { /* Unexpected IRQ: do nothing */ + snd_pcm_stream_unlock(player->substream); return IRQ_NONE; } @@ -88,9 +90,7 @@ static irqreturn_t uni_player_irq_handler(int irq, void *dev_id) SET_UNIPERIF_ITM_BCLR_FIFO_ERROR(player); /* Stop the player */ - snd_pcm_stream_lock(player->substream); snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN); - snd_pcm_stream_unlock(player->substream); } ret = IRQ_HANDLED; @@ -104,9 +104,7 @@ static irqreturn_t uni_player_irq_handler(int irq, void *dev_id) SET_UNIPERIF_ITM_BCLR_DMA_ERROR(player); /* Stop the player */ - snd_pcm_stream_lock(player->substream); snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN); - snd_pcm_stream_unlock(player->substream); ret = IRQ_HANDLED; } @@ -138,13 +136,12 @@ static irqreturn_t uni_player_irq_handler(int irq, void *dev_id) dev_err(player->dev, "Underflow recovery failed\n"); /* Stop the player */ - snd_pcm_stream_lock(player->substream); snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN); - snd_pcm_stream_unlock(player->substream); ret = IRQ_HANDLED; } + snd_pcm_stream_unlock(player->substream); return ret; } diff --git a/sound/soc/sti/uniperif_reader.c b/sound/soc/sti/uniperif_reader.c index 5992c6a..9273f59 100644 --- a/sound/soc/sti/uniperif_reader.c +++ b/sound/soc/sti/uniperif_reader.c @@ -46,9 +46,11 @@ static irqreturn_t uni_reader_irq_handler(int irq, void *dev_id) struct uniperif *reader = dev_id; unsigned int status; + snd_pcm_stream_lock(reader->substream); if (reader->state == UNIPERIF_STATE_STOPPED) { /* Unexpected IRQ: do nothing */ dev_warn(reader->dev, "unexpected IRQ\n"); + snd_pcm_stream_unlock(reader->substream); return IRQ_HANDLED; } @@ -60,13 +62,13 @@ static irqreturn_t uni_reader_irq_handler(int irq, void *dev_id) if (unlikely(status & UNIPERIF_ITS_FIFO_ERROR_MASK(reader))) { dev_err(reader->dev, "FIFO error detected\n"); - snd_pcm_stream_lock(reader->substream); snd_pcm_stop(reader->substream, SNDRV_PCM_STATE_XRUN); - snd_pcm_stream_unlock(reader->substream); - return IRQ_HANDLED; + ret = IRQ_HANDLED; } + snd_pcm_stream_unlock(reader->substream); + return ret; } -- 1.9.1

2 6

[alsa-devel] sound: another deadlock in snd_seq_pool_done
by Dmitry Vyukov 21 Mar '17

21 Mar '17

Hello, The following program creates processes deadlocked in snd_seq_pool_done: https://gist.githubusercontent.com/dvyukov/97efc9cb6d63b1b2c7b737b82cc8b0d6… After few seconds I get: # ps afxu | grep a.out root 8660 2.0 0.0 0 0 pts/0 Zl 16:27 0:00 [a.out] <defunct> # kill -9 8660 # cat /proc/8660/status Name: a.out State: Z (zombie) Tgid: 8660 Ngid: 0 Pid: 8660 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 0 Groups: 0 NStgid: 8660 NSpid: 8660 NSpgid: 8660 NSsid: 2971 Threads: 2 SigQ: 1/3304 SigPnd: 0000000000000000 ShdPnd: 0000000000000100 SigBlk: 0000000000000000 SigIgn: 0000000180000000 SigCgt: 0000000000000440 CapInh: 0000000000000000 CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Cpus_allowed: f Cpus_allowed_list: 0-3 Mems_allowed: 00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 12 nonvoluntary_ctxt_switches: 0 # cat /proc/8660/task/*/stack [<ffffffff835406db>] snd_seq_pool_done+0x31b/0x620 sound/core/seq/seq_memory.c:436 [<ffffffff8353a11e>] snd_seq_ioctl_set_client_pool+0x1ae/0x600 sound/core/seq/seq_clientmgr.c:1836 [<ffffffff835382ba>] snd_seq_ioctl+0x2da/0x4d0 sound/core/seq/seq_clientmgr.c:2130 [<ffffffff81aced2f>] vfs_ioctl fs/ioctl.c:45 [inline] [<ffffffff81aced2f>] do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:685 [<ffffffff81ad038f>] SYSC_ioctl fs/ioctl.c:700 [inline] [<ffffffff81ad038f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 [<ffffffff8457dc41>] entry_SYSCALL_64_fastpath+0x1f/0xc2

2 6

[alsa-devel] [PATCH] ALSA: x86: Make CONFIG_SND_X86 bool
by Takashi Iwai 21 Mar '17

21 Mar '17

CONFIG_SND_X86 is a menu config to filter only for x86-specific drivers in its sub-menu, and this doesn't have to be tristate but rather it should be a bool. Also, like other sub-menu configs, it's more user-friendly to be default=y; it's merely a menu config and the actual drivers are configured in the sub-menu, after all. Fixes: 287599cf2d77 ("ALSA: add Intel HDMI LPE audio driver for BYT/CHT-T") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/x86/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/x86/Kconfig b/sound/x86/Kconfig index 84c8f8fc597c..8adf4d1bd46e 100644 --- a/sound/x86/Kconfig +++ b/sound/x86/Kconfig @@ -1,6 +1,7 @@ menuconfig SND_X86 - tristate "X86 sound devices" + bool "X86 sound devices" depends on X86 + default y ---help--- X86 sound devices that don't fall under SoC or PCI categories -- 2.11.1

1 0

[alsa-devel] [PATCH v4 6/6] pcm:plug: save converter config
by sutar.mounesh＠gmail.com 21 Mar '17

21 Mar '17

From: Andreas Pape <apape(a)de.adit-jv.com> Passed config is freed after call to open, thus it is invalid when trying to extract the converter name. So config entry is saved for later usage. Signed-off-by: Andreas Pape <apape(a)de.adit-jv.com> Signed-off-by: Mounesh Sutar <sutar.mounesh(a)gmail.com> diff --git a/src/pcm/pcm_plug.c b/src/pcm/pcm_plug.c index 266707b..f1ae814 100644 --- a/src/pcm/pcm_plug.c +++ b/src/pcm/pcm_plug.c @@ -64,6 +64,10 @@ static int snd_pcm_plug_close(snd_pcm_t *pcm) snd_pcm_plug_t *plug = pcm->private_data; int err, result = 0; free(plug->ttable); + if (plug->rate_converter) { + snd_config_delete((snd_config_t*)plug->rate_converter); + plug->rate_converter = NULL; + } assert(plug->gen.slave == plug->req_slave); if (plug->gen.close_slave) { snd_pcm_unlink_hw_ptr(pcm, plug->req_slave); @@ -1108,7 +1112,6 @@ int snd_pcm_plug_open(snd_pcm_t **pcmp, plug->sformat = sformat; plug->schannels = schannels; plug->srate = srate; - plug->rate_converter = rate_converter; plug->gen.slave = plug->req_slave = slave; plug->gen.close_slave = close_slave; plug->route_policy = route_policy; @@ -1125,6 +1128,14 @@ int snd_pcm_plug_open(snd_pcm_t **pcmp, pcm->ops = &snd_pcm_plug_ops; pcm->fast_ops = slave->fast_ops; pcm->fast_op_arg = slave->fast_op_arg; + if (rate_converter) { + if ((err = snd_config_copy((snd_config_t**)&plug->rate_converter, + (snd_config_t *)rate_converter)) < 0) { + snd_pcm_free(pcm); + free(plug); + return err; + } + } pcm->private_data = plug; pcm->poll_fd = slave->poll_fd; pcm->poll_events = slave->poll_events; -- 2.7.4

2 1

Re: [alsa-devel] [RESEND PATCH v2 1/2] ASoC: stm32: add bindings for SAI
by Olivier MOYSAN 21 Mar '17

21 Mar '17

Hello Rob, On 03/18/2017 09:43 PM, Rob Herring wrote: > On Thu, Mar 16, 2017 at 5:50 AM, Olivier MOYSAN <olivier.moysan(a)st.com> wrote: >> Hello Rob, >> >> Thanks for your feedback. >> >> On 03/15/2017 06:46 PM, Rob Herring wrote: >>> On Tue, Mar 07, 2017 at 10:44:31AM +0100, olivier moysan wrote: >>>> This patch adds documentation of device tree bindings for the >>>> STM32 SAI ASoC driver. >>>> >>>> Signed-off-by: olivier moysan <olivier.moysan(a)st.com> >>>> --- >>>> .../devicetree/bindings/sound/st,stm32-sai.txt | 79 ++++++++++++++++++++++ >>>> 1 file changed, 79 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-sai.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt >>>> new file mode 100644 >>>> index 0000000..b3be26d >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt >>>> @@ -0,0 +1,79 @@ >>>> +STMicroelectronics STM32 Serial Audio Interface (SAI). >>>> + >>>> +The SAI interface (Serial Audio Interface) offers a wide set of audio protocols >>>> +as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97. >>>> +The SAI contains two independent audio sub-blocks. Each sub-block has >>>> +its own clock generator and I/O lines controller. >>>> + >>>> +Required properties: >>>> + - compatible: Should be "st,stm32f4-sai" >>>> + - reg: Base address and size of SAI common register set. >>>> + - clocks: Must contain phandle and clock specifier pairs for each entry >>>> + in clock-names. >>>> + - clock-names: Must contain "clk_x8k" and "clk_x11k" >>>> + "clk_x8k": SAI parent clock for sampling rates multiple of 8kHz. >>>> + "clk_x11k": SAI parent clock for sampling rates multiple of 11.025kHz. >>> >>> clk_ is redundant. >>> >> >> Do you mean, removing clk_ prefix ? > > Yes. > >> >>>> + - interrupts: cpu DAI interrupt line shared by SAI sub-blocks >>>> + >>>> +Note: Each SAI controller should have an alias correctly numbered >>>> +in "aliases" node, to provide explicit name to CPU DAI. >>> >>> No, it shouldn't. Why do you need that? >>> >> >> Yes, this is not mandatory. This is convenient to identify sai >> controller, as we may have up to 8 instances. >> I can make it optional, or remove it if you think it is not relevant. > > Remove it. > One more thing regarding aliases. In future patches, I will add alsa controls to configure sai. Some stm32 socs exhibit several sai (4 instances for H7) It will be necessary to identify to which sai each control apply, through the control names: SAI1A control X SAI2A control X ... sub-node compatible already allows to identify A or B sub-instance. An alternative to alias, may be to use dev_name information to identify sai instance. But this does not produce user friendly control names. Another way is to use compatible also. The drawback here is to multiply compatible names. (many soc families and many instances) What is your recommendation ? If there is another solution, I did not consider, please let me know. >> >>> >>>> + >>>> +Optional properties: >>>> + - resets: Reference to a reset controller asserting the SAI >>>> + >>>> +SAI subnodes: >>>> +Two subnodes corresponding to SAI sub-block instances A et B can be defined. >>>> +Subnode can be omitted for unsused sub-block. >>>> + >>>> +SAI subnodes required properties: >>>> + - compatible: Should be "st,stm32-sai-sub-a" or "st,stm32-sai-sub-b" >>>> + for SAI sub-block A or B respectively. >>>> + - reg: Base address and size of SAI sub-block register set. >>>> + - clocks: Must contain one phandle and clock specifier pair >>>> + for sai_ck which feeds the internal clock generator. >>>> + - clock-names: Must contain "sai_ck". >>>> + - dmas: see Documentation/devicetree/bindings/dma/stm32-dma.txt >>>> + - dma-names: identifier string for each DMA request line >>>> + "tx": if sai sub-block is configured as playback DAI >>>> + "rx": if sai sub-block is configured as capture DAI >>>> + - pinctrl-names: should contain only value "default" >>>> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt >>>> + >>>> +Example: >>>> +sai1: sai1@40015800 { >>>> + compatible = "st,stm32f4-sai"; >>>> + reg = <0x40015800 0x400>; >> >> reg = <0x40015800 0x4>; >> >>>> + clocks = <&rcc 1 CLK_SAIQ_PDIV>, <&rcc 1 CLK_I2SQ_PDIV>; >>>> + clock-names = "clk_x8k", "clk_x11k"; >>>> + interrupts = <87>; >>>> + resets = <&rcc 310>; >>>> + >>>> + sai1b: sai@1 { >>> >>> unit address needs a reg property. >>> >>> audio-controller@1 >>> >> >> Right. This needs to be updated as follows: >> sai1b: sai1b@40015824 { > > audio-controller@... > >> ... >> reg = <0x40015824 0x1C>; >> ... >> }; >> >>>> + #sound-dai-cells = <0>; >>>> + compatible = "st,stm32-sai-sub-b"; >>>> + clocks = <&rcc 1 CLK_SAI2>; >>>> + clock-names = "sai_ck"; >>>> + dmas = <&dma2 5 0 0x400 0x1>; >>>> + dma-names = "tx"; >>>> + }; >>>> +}; >>>> + >>>> +sound { >>>> + compatible = "simple-audio-card"; >>> >>> Perhaps you want to use the graph-card here. It's getting close to >>> merging. >>> >> >> mclk-fs property is required when SAI is configured as master. >> It seems that mclk-fs is not supported in current version >> of audio graph card. So I thing I should keep simple card for the time >> being. Anyway, I plan further updates for SAI, so I will >> have opportunity to change to graph card at that time. > > Well, it's not easy to switch later and maintain compatibility. Is it > complicated to add mclk-fs property? The intent is graph-card supports > everything simple-card supports. > > Rob > Right, it should not be too complicated to add mclk-fs support to graph-card. BRs olivier

1 0

[alsa-devel] [PATCH] ALSA: x86: Remove CONFIG_SND_X86 as unnecessary
by Ian W MORRISON 21 Mar '17

21 Mar '17

Create a specific menu for the CONFIG_HDMI_LPE_AUDIO setting. Add additional narrative to further explain the function of the CONFIG_HDMI_LPE_AUDIO setting. Remove subsequently unnecessary CONFIG_SND_X86 setting. Signed-off-by: Ian W Morrison <linuxium(a)linuxium.com.au> --- sound/x86/Kconfig | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/sound/x86/Kconfig b/sound/x86/Kconfig index 84c8f8fc..a89d769 100644 --- a/sound/x86/Kconfig +++ b/sound/x86/Kconfig @@ -1,10 +1,5 @@ -menuconfig SND_X86 - tristate "X86 sound devices" - depends on X86 - ---help--- - X86 sound devices that don't fall under SoC or PCI categories - -if SND_X86 +menu "HDMI LPE for SoC audio support" + comment "Required for HDMI audio support on Intel Baytrail and Cherrytrail" config HDMI_LPE_AUDIO tristate "HDMI audio without HDaudio on Intel Atom platforms" @@ -13,4 +8,4 @@ config HDMI_LPE_AUDIO help Choose this option to support HDMI LPE Audio mode -endif # SND_X86 +endmenu -- 1.9.1

2 3

Re: [alsa-devel] [PATCH v2] ALSA: x86: Select CONFIG_HDMI_LPE_AUDIO as default
by Ian W MORRISON 21 Mar '17

21 Mar '17

On 21 March 2017 at 09:02, Ian W MORRISON <ianwmorrison(a)gmail.com> wrote: > > > On 21 March 2017 at 04:57, Takashi Iwai <tiwai(a)suse.de> wrote: > >> On Mon, 20 Mar 2017 16:12:01 +0100, >> Ian W MORRISON wrote: >> > >> > On 20 March 2017 at 21:04, Takashi Iwai <tiwai(a)suse.de> wrote: >> > >> > > On Mon, 20 Mar 2017 10:41:07 +0100, >> > > Ian W MORRISON wrote: >> > > > >> > > > On 20 March 2017 at 19:41, Takashi Iwai <tiwai(a)suse.de> wrote: >> > > > >> > > > > On Mon, 20 Mar 2017 09:17:30 +0100, >> > > > > Ian W MORRISON wrote: >> > > > > > >> > > > > > Oops ... forgot to copy alsa-devel and Pierre-Louis. >> > > > > > >> > > > > > On 20 March 2017 at 18:59, Takashi Iwai <tiwai(a)suse.de> wrote: >> > > > > > >> > > > > > > On Mon, 20 Mar 2017 08:42:32 +0100, >> > > > > > > Ian W MORRISON wrote: >> > > > > > > > >> > > > > > > > The upstream kernel builds for distributions such as Ubuntu >> > > which now >> > > > > > > > includes binary packages for v4.11 mainline kernel release >> > > > > candidates are >> > > > > > > > promoted as a way of testing upstream kernels to to confirm >> that >> > > > > upstream >> > > > > > > > has fixed a specific issue (see https://wiki.ubuntu.com/ >> > > > > > > > Kernel/MainlineBuilds). >> > > > > > > > >> > > > > > > > Unfortunately the long awaited patch for providing HDMI >> audio >> > > > > support for >> > > > > > > > Bay Trail and Cherry Trail devices does not include this >> support >> > > > > through >> > > > > > > a >> > > > > > > > module built by default. >> > > > > > > > >> > > > > > > > Through including by default of the two associated CONFIG >> > > settings >> > > > > > > (SND_X86 >> > > > > > > > and HDMI_LPE_AUDIO), upstream kernel builds would >> automatically >> > > > > provide >> > > > > > > the >> > > > > > > > much desired HDMI audio support by default. >> > > > > > > > >> > > > > > > > This patch uses a Kconfig 'default' statement to include the >> > > driver >> > > > > as >> > > > > > > > default. >> > > > > > > > >> > > > > > > > Changes in version 2: CONFIG_SND_X86 now a bool and changed >> > > default >> > > > > m to >> > > > > > > > default y >> > > > > > > > >> > > > > > > > Signed-off-by: Ian W Morrison <linuxium(a)linuxium.com.au> >> > > > > > > > --- >> > > > > > > > sound/x86/Kconfig | 4 +++- >> > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) >> > > > > > > > >> > > > > > > > diff --git a/sound/x86/Kconfig b/sound/x86/Kconfig >> > > > > > > > index 84c8f8fc..cac2270 100644 >> > > > > > > > --- a/sound/x86/Kconfig >> > > > > > > > +++ b/sound/x86/Kconfig >> > > > > > > > @@ -1,6 +1,7 @@ >> > > > > > > > menuconfig SND_X86 >> > > > > > > > - tristate "X86 sound devices" >> > > > > > > > + bool "X86 sound devices" >> > > > > > > > depends on X86 >> > > > > > > > + default y >> > > > > > > >> > > > > > > This one is OK, but ... >> > > > > > > >> > > > > > > > ---help--- >> > > > > > > > X86 sound devices that don't fall under SoC or PCI >> > > > > categories >> > > > > > > > >> > > > > > > > @@ -9,6 +10,7 @@ if SND_X86 >> > > > > > > > config HDMI_LPE_AUDIO >> > > > > > > > tristate "HDMI audio without HDaudio on Intel Atom >> > > platforms" >> > > > > > > > depends on DRM_I915 >> > > > > > > > + default y >> > > > > > > >> > > > > > > ... this is wrong. Each driver config itself should be left >> > > > > > > unspecified. >> > > > > > > >> > > > > > > It's distributor's job to choose the right config here. >> > > > > > > >> > > > > > > Actually this goes back to one of my earlier points: A >> distributor >> > > > > doesn't >> > > > > > have to set 'HDMI' as HDMI audio is automatically provided. >> > > > > >> > > > > Provided by who...? >> > > > > >> > > > >> > > > >> > > > I suppose it is provided as a result of the architecture one runs >> the >> > > > primary Makefile on. With 'uname -m' returning 'x86_64' running >> 'make >> > > > defconfig' results in 'CONFIG_HDMI=y' being set so >> > > 'drivers/video/Makefile' >> > > > automatically makes 'drivers/video/hdmi.c' and as >> > > > 'arch/x86/configs/x86_64_defconfig' includes 'CONFIG_DRM=y' and >> > > > 'CONFIG_DRM_I915=y' and 'drivers/gpu/drm/i915/Makefile' makes >> > > > 'intel_audio.c'. >> > > >> > > The defconfig stuff supports only the limited device sets that are >> > > supposed to be very common. Is HDMI_LPE_AUDIO classified really as >> > > such a thing? I don't know... >> > > >> > > >> > In this instance I'd suggest that HDMI_LPE_AUDIO is common as without it >> > you do not get HDMI audio on all x86_64 devices. However see my comment >> > below. >> > >> > >> > > >> > > > > > This is just an >> > > > > > extension because by setting 'HDMI_LPE_AUDIO' the missing audio >> > > support >> > > > > for >> > > > > > BYT and CHT SoCs is then provided. Therefore, in this albeit >> unusual >> > > > > > instance, I reason is it appropriate to set HDMI_LPE_AUDIO so >> that >> > > audio >> > > > > is >> > > > > > automatically provided regardless of distribution. If a >> distributor >> > > > > didn't >> > > > > > want to allow audio for BYT and CHT SoC based devices running >> their >> > > > > distro >> > > > > > then they could always remove it from their distro specific >> config. >> > > > > >> > > > > It's a wrong approach. What we're discussing about is just a >> > > > > configuration for a new individual driver, and the same rule >> should be >> > > > > applied to it like others. >> > > > > >> > > > > Check other drivers. See whether default=y (or =m) is set to >> > > > > CONFIG_E1000E, as a random example. With your argument, it >> should be >> > > > > set to y or m as default, since the Ethernet functionality is >> already >> > > > > provided by the network core. >> > > > > >> > > > > In general, we don't set the default values to the driver configs >> > > > > unless there is a VERY specific reason to do so. >> > > > > >> > > > > >> > > > I'm trying to get HDMI audio by default for BYT & CHT SoC but >> currently >> > > > this requires 'CONFIG_HDMI_LPE_AUDIO' set with a value of 'm'. I >> don't >> > > want >> > > > to argue a 'special case' or promote a 'wrong approach' but just >> get HDMI >> > > > audio working so is there another way to achieve this? >> > > >> > > What's wrong with manually setting CONFIG_HDMI_LPE_AUDIO=m or =y? >> > > IOW, do all features on your CHT/BYT machines work without adjusting >> > > manually after defconfig? If you have to do it in anyway, what makes >> > > it special for HDMI_LPD_AUDIO? >> > > >> > > >> > I've just tested various scenarios using a variety of devices with >> > v4.11-rc3. Having CONFIG_HDMI_LPE_AUDIO set by default is sufficient to >> get >> > audio on BYT/CHT devices over HDMI. >> > >> > For example installing Ubuntu 16.04.2 on a BYT/CHT device, then >> upgrading >> > the kernel to v4.11-rc3 using the deb-binary from >> http://kernel.ubuntu.com/~ >> > kernel-ppa/mainline/v4.11-rc3/ (an example of a current distro which is >> > compiling without setting CONFIG_HDMI_LPE_AUDIO) and there is no audio >> over >> > HDMI. Alternatively downloading v4.11-rc3 source, making defconfig, >> > manually setting CONFIG_HDMI_LPE_AUDIO, compiling and installing the >> > kernel on the BYT/CHT device will give you audio over HDMI. >> > >> > If the BYT/CHT device has other sound cards (e.g accessed via a >> headphone >> > jack) then audio without setting CONFIG_HDMI_LPE_AUDIO may be possible >> > depending on the codec used and whether it is provided by default in the >> > kernel. So for example a Tronsmart Ara (CHT) device has audio over >> > headphones using the pre-compiled deb-binary above but no audio over >> HDMI. >> > Whereas with a (1st gen) Intel Compute Stick (BYT) device no audio is >> > possible using the pre-compiled deb-binary as the device only has an >> HDMI >> > port. To get sound you must therefore currently use a self-compiled >> kernel >> > with CONFIG_HDMI_LPE_AUDIO set. >> > >> > Whilst Canonical may set CONFIG_HDMI_LPE_AUDIO to provide audio on >> BYT/CHT >> > devices by when is unknown and there is no guarantee they actually will. >> > >> > This will be similar for all other distros with the worst case scenario >> > that no distributor adds CONFIG_HDMI_LPE_AUDIO to their configs >> resulting >> > in (arguably) little point including HDMI LPE audio support in the >> kernel. >> > >> > I've laboured the point about 'BYT/CHT devices audio over HDMI' but to >> > answer your question completely there are other BYT/CHT devices >> (typically >> > tablets) that need a whole other bunch of patches to fix this and that. >> > They may need specialist kernel configs with specific settings but that >> is >> > a separate issue to the basic functional need of having audio over HDMI. >> > >> > Does the above explanation justify my current approach or is there an >> > alternative that can be considered? >> >> Sorry, no, you've explained how much you love the HDMI audio, but it >> doesn't answer my question clearly. >> > > Whatever love there was is diminishing rapidly! > > Let me set the context: the range of BYT/CHT devices sold as HDMI sticks > or HDMI boxes which are designed to connect to an HDMI output device (TV or > monitor) and typically have Windows installed as the OS and are used > primarily as media PCs, HTPCs or as 'mini' PCs. They become essentially > useless for their designated purpose when installed with a mainstream Linux > based OS such as Ubuntu at the moment because there is no audio over HDMI. > > >> >> My question is simple: are *all* features the upstream kernel supports >> for your device now (e.g. input, network or whatever) enabled by the >> pure arch/x86/configs/x86_64_defconfig *without* manually setting the >> configs to y or m? I bet you likely have to set some configs there >> manually to m or y. >> >> > No. CONFIG_HDMI_LPE_AUDIO is the only config that needs to be manually set > to get *all* features from the upstream kernel. > > >> Then, if the manual selection for such missing configs is acceptable, >> what makes the HDMI audio so special and it must be set to y/m as >> default, while other devices aren't set like that...? That's the >> question. >> >> >> > The requested patch sets CONFIG_HDMI_LPE_AUDIO so mainstream Linux distro > kernels would automatically provide the new kernel feature of HDMI LPE > audio support. > Further analysis of Canonical's v4.11-rcN build compared with other available distro builds of v4.11-rcN leads me to conclude that given CONFIG_HDMI_LPE_AUDIO is not set by default then Canonical's config is at fault. Consequently I have raised a bug report ( https://bugs.launchpad.net/ubuntu/+bug/1674523) in order to (hopefully) address the issue. I will additionally submit a further patch that (arguably) improves the current Kconfig file for the CONFIG_HDMI_LPE_AUDIO setting by creating a specific menu for the CONFIG_HDMI_LPE_AUDIO setting, adding additional narrative to further explain the function of the CONFIG_HDMI_LPE_AUDIO setting and removing the subsequently unnecessary CONFIG_SND_X86 setting. As a result, this patch ([PATCH v2] ALSA: x86: Select CONFIG_HDMI_LPE_AUDIO as default) is withdrawn. > > >> thanks, >> >> Takashi >> > >

1 0

[alsa-devel] [PATCH v5 0/9] ASoC: add OF-graph base simple-card
by Kuninori Morimoto 21 Mar '17

21 Mar '17

Hi Rob, Mark These are v5 of OF-graph base audio card patch-set. It fixed small things which was pointed by Rob. 1) - 3) : new OF-graph helper functions 4) - 5) : expand "label", "dai-format" 6) - 9) : OF-graph base simple-card Kuninori Morimoto (9): of_graph: add of_graph_get_remote_endpoint() of_graph: add of_graph_get_port_parent() of_graph: add of_graph_get_endpoint_count() ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name ASoC: soc-core: enable "dai-name" on snd_soc_of_parse_daifmt() ASoC: add snd_soc_get_dai_id() ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai() ASoC: add audio-graph-card document ASoC: add audio-graph-card support .../devicetree/bindings/sound/audio-graph-card.txt | 124 +++++++++ drivers/of/base.c | 60 +++- include/linux/of_graph.h | 21 ++ include/sound/simple_card_utils.h | 10 + include/sound/soc.h | 1 + sound/soc/generic/Kconfig | 8 + sound/soc/generic/Makefile | 2 + sound/soc/generic/audio-graph-card.c | 308 +++++++++++++++++++++ sound/soc/generic/simple-card-utils.c | 54 +++- sound/soc/soc-core.c | 32 ++- 10 files changed, 604 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.txt create mode 100644 sound/soc/generic/audio-graph-card.c -- 1.9.1

1 0