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

Re: [PATCH v4 2/5] ASoC: dt-bindings: Add dt binding for lpass hdmi
by Rob Herring 15 Sep '20

15 Sep '20

On Tue, Sep 08, 2020 at 05:44:39PM +0000, Srinivasa Rao Mandadapu wrote: > From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > > Adds bindings for lpass hdmi interface > which can support audio path over dp. > > Signed-off-by: Srinivasa Rao <srivasam(a)codeaurora.org> > Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > --- > .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 51 ++++++++++++++++++++-- > 1 file changed, 47 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml > index 09c9bd2..7c2ac0c 100644 > --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml > +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml > @@ -22,6 +22,7 @@ properties: > - qcom,lpass-cpu > - qcom,apq8016-lpass-cpu > - qcom,sc7180-lpass-cpu > + - qcom,sc7180-lpass-hdmi > > reg: > maxItems: 1 > @@ -60,10 +61,12 @@ properties: > const: 0 > > patternProperties: > - "(^mi2s-[0-9a-f]$|mi2s)": > + "^dai@[0-9a-f]$": > type: object > - description: Required properties for each DAI > - > + description: | > + LPASS CPU dai node for each I2S device. Bindings of each node > + depends on the specific driver providing the functionality and > + properties. > properties: > reg: > maxItems: 1 > @@ -145,6 +148,22 @@ allOf: > - iommus > - power-domains > > + - if: > + properties: > + compatible: > + contains: > + const: qcom,sc7180-lpass-hdmi > + then: > + properties: > + clock-names: > + items: > + - const: pcnoc-sway-clk > + - const: audio-core > + - const: pcnoc-mport-clk > + required: > + - iommus > + - power-domains > + > examples: > - | > #include <dt-bindings/sound/sc7180-lpass.h> > @@ -178,12 +197,36 @@ examples: > #address-cells = <1>; > #size-cells = <0>; > /* Optional to set different MI2S SD lines */ > - mi2s-primary@0 { > + dai@mi2s-primary { The unit address should be a number. As this is not failing checks, then you are missing an 'additionalProperties: false'. > reg = <MI2S_PRIMARY>; > qcom,playback-sd-lines = <1>; > qcom,capture-sd-lines = <0>; > }; > }; > + > + lpassh@62d87000 { > + compatible = "qcom,sc7180-lpass-hdmi"; > + > + reg = <0 0x62d87000 0 0x68000>; > + > + iommus = <&apps_smmu 0x1032 0>; > + > + power-domains = <&lpass_hm 0>; > + > + clocks = <&gcc 131>, > + <&lpasscc 6>, > + <&lpasscc 10>; > + > + clock-names = "pcnoc-sway-clk", "audio-core", > + "pcnoc-mport-clk"; > + > + #sound-dai-cells = <1>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + interrupts = <0 268 1>; > + }; > }; > > ... > -- > Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., > is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. >

1 0

[RFC] dpcm_fe_dai_do_trigger: implicit removal of _DRAIN cmd since v5.4
by Cezary Rojewski 15 Sep '20

15 Sep '20

Hello, Till v5.4 dpcm_fe_dai_do_trigger was supporting all pcm cmds as each case: SND_SOC_DPCM_TRIGGER_PRE/ _POST/ _BESPOKE was simply passing cmd's value to appropriate variant of _trigger(). Since the addition of: acbf27746ecfa96b290b54cc7f05273482ea128a ASoC: pcm: update FE/BE trigger order based on the command additional filters have been introduced for _PRE and _POST cases: switch (cmd) { case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: ret = dpcm_dai_trigger_fe_be(substream, cmd, true); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: ret = dpcm_dai_trigger_fe_be(substream, cmd, false); break; default: ret = -EINVAL; break; } effectively removing support for _DRAIN command - all requests will yield -EINVAL. _BESPOKE was left alone so support remained there. Now, is DPCM no longer supporting _DRAIN and that's how things should be -or- DPCM still intends to support _DRAIN and mentioned change is unintended regression? Czarek

2 1

Re: [PATCH v4 1/5] ASoC: Add sc7180-lpass binding header hdmi define
by Rob Herring 15 Sep '20

15 Sep '20

On Tue, 08 Sep 2020 17:44:33 +0000, Srinivasa Rao Mandadapu wrote: > From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > > Add header defining hdmi dai-id for SC7180 lpass soc > in dt bindings. > > Signed-off-by: Srinivasa Rao <srivasam(a)codeaurora.org> > Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > --- > include/dt-bindings/sound/sc7180-lpass.h | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring <robh(a)kernel.org>

1 0

a saner API for allocating DMA addressable pages v2
by Christoph Hellwig 15 Sep '20

15 Sep '20

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a little unsure about the API naming, as alloc_pages sort of implies a struct page return value, but we return a kernel virtual address. The other alternative would be to name the API dma_alloc_noncoherent, but the whole non-coherent naming seems to put people off. As a follow up I plan to move the implementation of the DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given that is also is a fundamentally non coherent allocation. The replacement for that flag would then return a struct page, as it is allowed to actually return pages without a kernel mapping as the name suggested (although most of the time they will actually have a kernel mapping..) In addition to the conversions of the existing non-coherent DMA users, I've also added a patch to convert the firewire ohci driver to use the new dma_alloc_pages API. Note that I haven't carried over any Tested-by: tags for the noncoherent allocation conversions as there was a bit of a patch reshuffle, but the result should be the same. The first patch is queued up for 5.9 in the media tree, but included here for completeness. A git tree is available here: git://git.infradead.org/users/hch/misc.git dma_alloc_pages Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_p… Changes since v1: - rebased on the latests dma-mapping tree, which merged many of the cleanups - fix an argument passing typo in 53c700, caught by sparse - rename a few macro arguments in 53c700 - pass the right device to the DMA API in the lib82596 drivers - fix memory ownershiptransfers in sgiseeq - better document what a page in the direct kernel mapping means - split into dma_alloc_pages that returns a struct page and is in the direct mapping vs dma_alloc_noncoherent that can be vmapped - conver the firewire ohci driver to dma_alloc_pages Diffstat:

3 24

Re: [PATCH 03/17] drm/exynos: stop setting DMA_ATTR_NON_CONSISTENT
by Christoph Hellwig 15 Sep '20

15 Sep '20

On Mon, Sep 14, 2020 at 06:34:02PM +0300, Sergei Shtylyov wrote: > On 9/14/20 5:44 PM, Christoph Hellwig wrote: > > > DMA_ATTR_NON_CONSISTENT is a no-op except on PARISC and some mips > > configs, so don't set it in this ARM specific driver. > > Hm, PARICS and ARM capitalized but mips in lower case? :-) I guess it should also be PA-RISC if we start nitpicking..

1 0

Possible bug for ubuntu 20.04 with CONFIG_SND_MAX_CARDS=256
by Olivier SCHMITT 15 Sep '20

15 Sep '20

Hello dear all, I have been compiling kernels for a long time with CONFIG_SND_MAX_CARDS = 256 and increasing the sample rate. I switched to ubuntu 20.04 server lts. Everything is working fine until I compile alsa-lib. git clone git: //git.alsa-project.org/alsa-lib.git alsa-lib ./gitcompile --with-max-cards = 256 But after the make install, the plughw, dmix and dnsoop disappear. Do you have an idea? I uploaded alsa-info on: http://alsa-project.org/db/?f=8860b8bbb5abd5a84d3002717d68206db7da4a9c Thanks in advance.

1 0

[PATCH 1/2] leds: trigger: audio: Add audio jack plugging indicator led
by Hui Wang 15 Sep '20

15 Sep '20

On the Lenovo P520 front panel, there is a headset plugging indicator led. According to LENOVO's requirement, this led should be on if the front headset audio jack is plugged, otherwise the led should be off. We tested with windows, if we plugged a headphone/headset in that jack, the led was on, if we removed the headphone/headset from that jack, the led was off. Here we add JACKPLUG led in the ledtrig_audio, then we could call ledtrig_audio_set() in the alsa driver to control that led. Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- drivers/leds/trigger/Kconfig | 4 ++-- drivers/leds/trigger/ledtrig-audio.c | 7 +++++-- include/linux/leds.h | 1 + 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index ce9429ca6dde..a61893a6e3e4 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -138,10 +138,10 @@ config LEDS_TRIGGER_PATTERN If unsure, say N config LEDS_TRIGGER_AUDIO - tristate "Audio Mute LED Trigger" + tristate "Audio Mute and Jack Plugging LED Trigger" help This allows LEDs to be controlled by audio drivers for following - the audio mute and mic-mute changes. + the audio mute, mic-mute and jack plugging changes. If unsure, say N endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/ledtrig-audio.c b/drivers/leds/trigger/ledtrig-audio.c index f76621e88482..fa66bb982400 100644 --- a/drivers/leds/trigger/ledtrig-audio.c +++ b/drivers/leds/trigger/ledtrig-audio.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 // -// Audio Mute LED trigger +// Audio Mute And Jack Plugging LED trigger // #include <linux/kernel.h> @@ -29,6 +29,8 @@ static int __init ledtrig_audio_init(void) &ledtrig_audio[LED_AUDIO_MUTE]); led_trigger_register_simple("audio-micmute", &ledtrig_audio[LED_AUDIO_MICMUTE]); + led_trigger_register_simple("audio-jackplug", + &ledtrig_audio[LED_AUDIO_JACKPLUG]); return 0; } module_init(ledtrig_audio_init); @@ -37,8 +39,9 @@ static void __exit ledtrig_audio_exit(void) { led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_MUTE]); led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_MICMUTE]); + led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_JACKPLUG]); } module_exit(ledtrig_audio_exit); -MODULE_DESCRIPTION("LED trigger for audio mute control"); +MODULE_DESCRIPTION("LED trigger for audio mute and jack plugging control"); MODULE_LICENSE("GPL v2"); diff --git a/include/linux/leds.h b/include/linux/leds.h index 6a8d6409c993..1858c2d30ecd 100644 --- a/include/linux/leds.h +++ b/include/linux/leds.h @@ -584,6 +584,7 @@ struct led_pattern { enum led_audio { LED_AUDIO_MUTE, /* master mute LED */ LED_AUDIO_MICMUTE, /* mic mute LED */ + LED_AUDIO_JACKPLUG, /* audio jack plug indicator LED */ NUM_AUDIO_LEDS }; -- 2.17.1

1 2

increase CONFIG_SND_MAX_CARDS and avalable sample rate
by Olivier SCHMITT 14 Sep '20

14 Sep '20

Hello dear all, It's possible de increase CONFIG_SND_MAX_CARDS to 256 and increse sample rate to 384khz. Actualy i build my own kernel as: sed -i 's/SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_192000,/SNDRV_PCM_RATE_CONTINUOUS,/g' ./sound/drivers/aloop.c sed -i 's/192000/768000/g' ./sound/drivers/aloop.c grep -rnl './' -e "CONFIG_SND_MAX_CARDS=32" | xargs -i@ sed -i 's/CONFIG_SND_MAX_CARDS=32/CONFIG_SND_MAX_CARDS=256/g' @ search and replace 32 by 256 in and ./debian.master/config/annotations:CONFIG_SND_MAX_CARDS and for alsa utils: git clone git://git.alsa-project.org/alsa-lib.git alsa-lib ./gitcompile --with-max-cards=256 make install git clone git://git.alsa-project.org/alsa-utils.git alsa-utils ./gitcompile --with-max-cards=256 make install Thanks in advance.

1 0

[PATCH v2 00/11] USB: new USB control message helper functions
by Greg Kroah-Hartman 14 Sep '20

14 Sep '20

In a recent discussion about a USB networking bug found by syzbot, and fixed by Himadri Pandya, the design of the existing usb_control_msg() call was brought up as not being the "nicest" thing to use by Dmitry Vyukov: https://lore.kernel.org/r/CACT4Y+YbDODLRFn8M5QcY4CazhpeCaunJnP_udXtAs0rYoAS… The function makes it hard to get right, in that it will return the number of bytes sent/received, but almost no one checks to see if a short read/write happens. With a malicious, or broken, USB device, this can cause drivers to act on data that they did not anticipate, and sometimes copy internal kernel data out to userspace. So let's fix this up by creating two new functions, usb_control_msg_send() and usb_control_msg_recv(). These functions either complete the full transation, or they return an error, a short send/recv is now an error. They also accept data off of the stack, saving individual drivers the pain of having to constantly allocate memory on their own for tiny messages, thereby saving overall kernel code space. The api also does not require a raw USB "pipe" to be sent to the function, as we know the direction, so just pass in the endpoint number instead, again making it easier on the USB driver author to use. This series first takes a helper function out of the sound core for verifying USB endpoints to be able to use internally, and then adds the new functions, converts over some internal USB code to use them, and then starts to clean up some drivers using these new functions, as an example of the savings that can happen by using these functions. Thanks to Dmitry and Himadri for the idea on how to do all of this. greg k-h Changes from v1: - added acks from Takashi Iwai - dropped changes to one function in patch 04 thanks to review from Alan Stern - typo fix in comment in patch 01 - added new patch 11 to remove some unneeded checks in the sound drivers for endpoint statuses that would always be true. *** BLURB HERE *** Greg Kroah-Hartman (11): USB: move snd_usb_pipe_sanity_check into the USB core USB: add usb_control_msg_send() and usb_control_msg_recv() USB: core: message.c: use usb_control_msg_send() in a few places USB: core: hub.c: use usb_control_msg_send() in a few places USB: legousbtower: use usb_control_msg_recv() sound: usx2y: move to use usb_control_msg_send() sound: 6fire: move to use usb_control_msg_send() and usb_control_msg_recv() sound: line6: move to use usb_control_msg_send() and usb_control_msg_recv() sound: hiface: move to use usb_control_msg_send() Bluetooth: ath3k: use usb_control_msg_send() and usb_control_msg_recv() ALSA: remove calls to usb_pipe_type_check for control endpoints drivers/bluetooth/ath3k.c | 90 +++++------------ drivers/usb/core/hub.c | 99 ++++++++---------- drivers/usb/core/message.c | 171 ++++++++++++++++++++++++++++---- drivers/usb/core/urb.c | 31 ++++-- drivers/usb/misc/legousbtower.c | 60 ++++------- include/linux/usb.h | 7 ++ sound/usb/6fire/firmware.c | 38 +++---- sound/usb/helper.c | 16 +-- sound/usb/helper.h | 1 - sound/usb/hiface/pcm.c | 14 ++- sound/usb/line6/driver.c | 69 +++++-------- sound/usb/line6/podhd.c | 17 ++-- sound/usb/line6/toneport.c | 8 +- sound/usb/mixer_scarlett_gen2.c | 2 +- sound/usb/quirks.c | 12 +-- sound/usb/usx2y/us122l.c | 42 ++------ 16 files changed, 335 insertions(+), 342 deletions(-) -- 2.28.0

3 15

Re: [PATCH] ASoC: tas6424: disable regulators when probe error
by Mark Brown 14 Sep '20

14 Sep '20

On Mon, Sep 14, 2020 at 11:52:15PM +0900, Chanho Park wrote: > On Mon, Sep 14, 2020 at 8:27 PM Mark Brown <broonie(a)kernel.org> wrote: > > Please think hard before including complete backtraces in upstream > > reports, they are very large and contain almost no useful information > > relative to their size so often obscure the relevant content in your > > message. If part of the backtrace is usefully illustrative (it often is > > for search engines if nothing else) then it's usually better to pull out > > the relevant sections. > Thanks for your suggestion. > I'll respin this patch without the call stack messages. It's fine, I've already applied it - just please bear this in mind for future things.

1 0