1. 07 Dec, 2022 1 commit
  2. 06 Dec, 2022 2 commits
    • Takashi Iwai's avatar
      Merge tag 'asoc-v6.2' of... · 8ec2d95f
      Takashi Iwai authored
      Merge tag 'asoc-v6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
      
      ASoC: Updates for v6.2
      
      This is a fairly sedate release for the core code, but there's been a
      lot of driver work especially around the x86 platforms and device tree
      updates:
      
       - More cleanups of the DAPM code from Morimoto-san.
       - Factoring out of mapping hw_params onto SoundWire configuration by
         Charles Keepax.
       - The ever ongoing overhauls of the Intel DSP code continue, including
         support for loading libraries and probes with IPC4 on SOF.
       - Support for more sample formats on JZ4740.
       - Lots of device tree conversions and fixups.
       - Support for Allwinner D1, a range of AMD and Intel systems, Mediatek
         systems with multiple DMICs, Nuvoton NAU8318, NXP fsl_rpmsg and
         i.MX93, Qualcomm AudioReach Enable, MFC and SAL, RealTek RT1318 and
         Rockchip RK3588
      
      There's more cross tree updates than usual, though all fairly minor:
      
       - Some OMAP board file updates that were depedencies for removing their
         providers in ASoC, as part of a wider effort removing the support for
         the relevant OMAP platforms.
       - A new I2C API required for updates to the new I2C probe API.
       - A DRM update making use of a new API for fixing the capabilities
         advertised via hdmi-codec.
      
      Since this is being sent early I might send some more stuff if you've
      not yet sent your pull request and there's more come in.
      8ec2d95f
    • Gaosheng Cui's avatar
      ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt · cf2ea3c8
      Gaosheng Cui authored
      I got a null-ptr-defer error report when I do the following tests
      on the qemu platform:
      
      make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,
      CONFIG_SND_MTS64=m
      
      Then making test scripts:
      cat>test_mod1.sh<<EOF
      modprobe snd-mts64
      modprobe snd-mts64
      EOF
      
      Executing the script, perhaps several times, we will get a null-ptr-defer
      report, as follow:
      
      syzkaller:~# ./test_mod.sh
      snd_mts64: probe of snd_mts64.0 failed with error -5
      modprobe: ERROR: could not insert 'snd_mts64': No such device
       BUG: kernel NULL pointer dereference, address: 0000000000000000
       #PF: supervisor write access in kernel mode
       #PF: error_code(0x0002) - not-present page
       PGD 0 P4D 0
       Oops: 0002 [#1] PREEMPT SMP PTI
       CPU: 0 PID: 205 Comm: modprobe Not tainted 6.1.0-rc8-00588-g76dcd734 #6
       Call Trace:
        <IRQ>
        snd_mts64_interrupt+0x24/0xa0 [snd_mts64]
        parport_irq_handler+0x37/0x50 [parport]
        __handle_irq_event_percpu+0x39/0x190
        handle_irq_event_percpu+0xa/0x30
        handle_irq_event+0x2f/0x50
        handle_edge_irq+0x99/0x1b0
        __common_interrupt+0x5d/0x100
        common_interrupt+0xa0/0xc0
        </IRQ>
        <TASK>
        asm_common_interrupt+0x22/0x40
       RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30
        parport_claim+0xbd/0x230 [parport]
        snd_mts64_probe+0x14a/0x465 [snd_mts64]
        platform_probe+0x3f/0xa0
        really_probe+0x129/0x2c0
        __driver_probe_device+0x6d/0xc0
        driver_probe_device+0x1a/0xa0
        __device_attach_driver+0x7a/0xb0
        bus_for_each_drv+0x62/0xb0
        __device_attach+0xe4/0x180
        bus_probe_device+0x82/0xa0
        device_add+0x550/0x920
        platform_device_add+0x106/0x220
        snd_mts64_attach+0x2e/0x80 [snd_mts64]
        port_check+0x14/0x20 [parport]
        bus_for_each_dev+0x6e/0xc0
        __parport_register_driver+0x7c/0xb0 [parport]
        snd_mts64_module_init+0x31/0x1000 [snd_mts64]
        do_one_initcall+0x3c/0x1f0
        do_init_module+0x46/0x1c6
        load_module+0x1d8d/0x1e10
        __do_sys_finit_module+0xa2/0xf0
        do_syscall_64+0x37/0x90
        entry_SYSCALL_64_after_hwframe+0x63/0xcd
        </TASK>
       Kernel panic - not syncing: Fatal exception in interrupt
       Rebooting in 1 seconds..
      
      The mts wa not initialized during interrupt,  we add check for
      mts to fix this bug.
      
      Fixes: 68ab801e ("[ALSA] Add snd-mts64 driver for ESI Miditerminal 4140")
      Signed-off-by: default avatarGaosheng Cui <cuigaosheng1@huawei.com>
      Link: https://lore.kernel.org/r/20221206061004.1222966-1-cuigaosheng1@huawei.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cf2ea3c8
  3. 05 Dec, 2022 17 commits
  4. 04 Dec, 2022 1 commit
    • Mark Brown's avatar
      ASoC/tda998x: Fix reporting of nonexistent capture streams · f19a2caa
      Mark Brown authored
      Merge series from Mark Brown <broonie@kernel.org>:
      
      The recently added pcm-test selftest has pointed out that systems with
      the tda998x driver end up advertising that they support capture when in
      reality as far as I can see the tda998x devices are transmit only.  The
      DAIs registered through hdmi-codec are bidirectional, meaning that for
      I2S systems when combined with a typical bidrectional CPU DAI the
      overall capability of the PCM is bidirectional.  In most cases the I2S
      links will clock OK but no useful audio will be returned which isn't so
      bad but we should still not advertise the useless capability, and some
      systems may notice problems for example due to pinmux management.
      
      This is happening due to the hdmi-codec helpers not providing any
      mechanism for indicating unidirectional audio so add one and use it in
      the tda998x driver.  It is likely other hdmi-codec users are also
      affected but I don't have those systems to hand.
      
      Mark Brown (2):
        ASoC: hdmi-codec: Allow playback and capture to be disabled
        drm: tda99x: Don't advertise non-existent capture support
      
       drivers/gpu/drm/i2c/tda998x_drv.c |  2 ++
       include/sound/hdmi-codec.h        |  4 ++++
       sound/soc/codecs/hdmi-codec.c     | 30 +++++++++++++++++++++++++-----
       3 files changed, 31 insertions(+), 5 deletions(-)
      
      base-commit: f0c4d9fc
      --
      2.30.2
      f19a2caa
  5. 02 Dec, 2022 2 commits
  6. 01 Dec, 2022 8 commits
  7. 30 Nov, 2022 3 commits
    • Takashi Sakamoto's avatar
      ALSA: dice: add support for Focusrite Saffire Pro 40 with TCD3070 ASIC · 2133dc91
      Takashi Sakamoto authored
      TC Applied Technologies (TCAT) produces TCD3070 as final DICE ASIC for
      communication in IEEE 1394 bus for IEC 61883-1/6 protocol. As long as I
      know, latter model of Focusrite Saffire Pro 40 is an application of the
      ASIC and only in the market for consumers.
      
      This patchset adds support for the device. The device has several
      remarkable points.
      
      1. No support for extended synchronization information section in TCAT
      general protocol. The value of GLOBAL_EXTENDED_STATUS register is always
      zero. Additionally, NOTIFY_EXT_STATUS message is never emitted.
      
      2. No support for TCAT protocol extension. Hard coding is required for
      format of CIP payload.
      
      3. During several seconds after changing sampling rate, the block to
      process PCM frames is under disfunction. When starting packet streaming
      during the state, the block is never function till configuring different
      sampling rate and several seconds.
      
      This commit adds support for the device. The item 1 and 2 can be
      adaptable, while item 3 is not. It's not preferable that user process
      is forced to sleep during the disfunction in the call of ioctl(2) with
      SNDRV_PCM_IOCTL_HW_PARAMS or SNDRV_PCM_IOCTL_PREPARE request. It's
      inconvenient but let user configure preferable sampling rate in advance
      of starting PCM substream.
      
      The content of configuration ROM in the device I used is available at:
       * https://github.com/takaswie/am-config-roms/
      
      I note that any mixer control operation is implemented by unique
      transaction. The frame of request consists of 16 bytes header followed
      by payload.
      
      header (4 quadlets):
      1st: the type of request, prefixed with 0x8000
      2nd: counter at 2 bytes in MSB side, the length of data at 2 bytes in LSB
           side
      3rd: parameter 0
      4th: parameter 1
      
      payload (variable length if need):
      5th-: data according to parameters
      
      The request frame is sent by block write request to 0x'ffff'e040'01c0.
      
      The frame of response is similar to the frame of request, but it is
      header only, thus fixed to 16 bytes. The response frame is sent to the
      address which is registered by lock transaction to 0x'ffff'e040'0008.
      
      If the operation results in batch of data, the 2nd quadlet of header
      includes the length of data like request. The data is itself readable
      by read block request to 0x'ffff'e040'0030, which includes both
      header and payload for data, thus the length to read should be the
      length of data plus 16 bytes for header
      
      The actual value of request, parameter 0, parameter 1, and data is
      unclear yet.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20221130143313.43880-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2133dc91
    • Artem Lukyanov's avatar
      ASoC: amd: yc: Add Xiaomi Redmi Book Pro 14 2022 into DMI table · c1dd6bf6
      Artem Lukyanov authored
      This model requires an additional detection quirk to enable the
      internal microphone - BIOS doesn't seem to support AcpDmicConnected
      (nothing in acpidump output).
      Signed-off-by: default avatarArtem Lukyanov <dukzcry@ya.ru>
      Link: https://lore.kernel.org/r/20221130085247.85126-1-dukzcry@ya.ruSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c1dd6bf6
    • Ricardo Ribalda's avatar
      ASoC: SOF: mediatek: add shutdown callback · e063330a
      Ricardo Ribalda authored
      If we do not shutdown the peripheral properly at shutdown, the whole system
      crashes after kexec() on the first io access.
      
      Let's implement the appropriate callback.
      Signed-off-by: default avatarRicardo Ribalda <ribalda@chromium.org>
      Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
      Link: https://lore.kernel.org/r/20221127-mtk-snd-v1-0-b7886faa612b@chromium.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      e063330a
  8. 29 Nov, 2022 6 commits