Skip to content

L
linux
Switch branch/tag
  1. 09 Jul, 2023 3 commits
  3. 06 Jul, 2023 10 commits
  5. 05 Jul, 2023 4 commits
  7. 04 Jul, 2023 1 commit
    • Johan Hovold's avatar
      ASoC: codecs: wcd938x: fix missing mbhc init error handling · 7dfae263
      Johan Hovold authored 
      MBHC initialisation can fail so add the missing error handling to avoid
dereferencing an error pointer when later configuring the jack:

    Unable to handle kernel paging request at virtual address fffffffffffffff8

    pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
    lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]

    Call trace:
     wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
     wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
     snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]
     qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]
     sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]
     snd_soc_link_init+0x28/0x90 [snd_soc_core]
     snd_soc_bind_card+0x628/0xbfc [snd_soc_core]
     snd_soc_register_card+0xec/0x104 [snd_soc_core]
     devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]
     sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]

Fixes: bcee7ed0 ("ASoC: codecs: wcd938x: add Multi Button Headset Control support")
Cc: stable@vger.kernel.org      # 5.15
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: default avatarJohan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20230703124701.11734-1-johan+linaro@kernel.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      7dfae263
  9. 03 Jul, 2023 1 commit
  11. 30 Jun, 2023 9 commits
  13. 29 Jun, 2023 3 commits
    • Sameer Pujar's avatar
      ASoC: rt5640: Fix sleep in atomic context · 70a6404f
      Sameer Pujar authored 
      Following prints are observed while testing audio on Jetson AGX Orin which
has onboard RT5640 audio codec:

  BUG: sleeping function called from invalid context at kernel/workqueue.c:3027
  in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0
  preempt_count: 10001, expected: 0
  RCU nest depth: 0, expected: 0
  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1e0/0x270
  ---[ end trace ad1c64905aac14a6 ]-

The IRQ handler rt5640_irq() runs in interrupt context and can sleep
during cancel_delayed_work_sync().

Fix this by running IRQ handler, rt5640_irq(), in thread context.
Hence replace request_irq() calls with devm_request_threaded_irq().

Fixes: 051dade3 ("ASoC: rt5640: Fix the wrong state of JD1 and JD2")
Cc: stable@vger.kernel.org
Cc: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1688015537-31682-4-git-send-email-spujar@nvidia.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      70a6404f
    • Sheetal's avatar
      ASoC: tegra: Fix ADX byte map · 6dfe70be
      Sheetal authored 
      Byte mask for channel-1 of stream-1 is not getting enabled and this
causes failures during ADX use cases. This happens because the byte
map value 0 matches the byte map array and put() callback returns
without enabling the corresponding bits in the byte mask.

ADX supports 4 output streams and each stream can have a maximum of
16 channels. Each byte in the input frame is uniquely mapped to a
byte in one of these 4 outputs. This mapping is done with the help of
byte map array via user space control setting. The byte map array
size in the driver is 16 and each array element is of size 4 bytes.
This corresponds to 64 byte map values.

Each byte in the byte map array can have any value between 0 to 255
to enable the corresponding bits in the byte mask. The value 256 is
used as a way to disable the byte map. However the byte map array
element cannot store this value. The put() callback disables the byte
mask for 256 value and byte map value is reset to 0 for this case.
This causes problems during subsequent runs since put() callback,
for value of 0, just returns without enabling the byte mask. In short,
the problem is coming because 0 and 256 control values are stored as
0 in the byte map array.

Right now fix the put() callback by actually looking at the byte mask
array state to identify if any change is needed and update the fields
accordingly. The get() callback needs an update as well to return the
correct control value that user has set before. Note that when user
set 256, the value is stored as 0 and byte mask is disabled. So byte
mask state is used to either return 256 or the value from byte map
array.

Given above, this looks bit complicated and all this happens because
the byte map array is tightly packed and cannot actually store the 256
value. Right now the priority is to fix the existing failure and a TODO
item is put to improve this logic.

Fixes: 3c97881b ("ASoC: tegra: Fix kcontrol put callback in ADX")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarSheetal <sheetal@nvidia.com>
Reviewed-by: default avatarMohan Kumar D <mkumard@nvidia.com>
Reviewed-by: default avatarSameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1688015537-31682-3-git-send-email-spujar@nvidia.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      6dfe70be
    • Sheetal's avatar
      ASoC: tegra: Fix AMX byte map · 49bd7b08
      Sheetal authored 
      Byte mask for channel-1 of stream-1 is not getting enabled and this
causes failures during AMX use cases. This happens because the byte
map value 0 matches the byte map array and put() callback returns
without enabling the corresponding bits in the byte mask.

AMX supports 4 input streams and each stream can take a maximum of
16 channels. Each byte in the output frame is uniquely mapped to a
byte in one of these 4 inputs. This mapping is done with the help of
byte map array via user space control setting. The byte map array
size in the driver is 16 and each array element is of size 4 bytes.
This corresponds to 64 byte map values.

Each byte in the byte map array can have any value between 0 to 255
to enable the corresponding bits in the byte mask. The value 256 is
used as a way to disable the byte map. However the byte map array
element cannot store this value. The put() callback disables the byte
mask for 256 value and byte map value is reset to 0 for this case.
This causes problems during subsequent runs since put() callback,
for value of 0, just returns without enabling the byte mask. In short,
the problem is coming because 0 and 256 control values are stored as
0 in the byte map array.

Right now fix the put() callback by actually looking at the byte mask
array state to identify if any change is needed and update the fields
accordingly. The get() callback needs an update as well to return the
correct control value that user has set before. Note that when user
sets 256, the value is stored as 0 and byte mask is disabled. So byte
mask state is used to either return 256 or the value from byte map
array.

Given above, this looks bit complicated and all this happens because
the byte map array is tightly packed and cannot actually store the 256
value. Right now the priority is to fix the existing failure and a TODO
item is put to improve this logic.

Fixes: 8db78ace ("ASoC: tegra: Fix kcontrol put callback in AMX")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarSheetal <sheetal@nvidia.com>
Reviewed-by: default avatarMohan Kumar D <mkumard@nvidia.com>
Reviewed-by: default avatarSameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1688015537-31682-2-git-send-email-spujar@nvidia.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      49bd7b08
  15. 26 Jun, 2023 7 commits
  17. 23 Jun, 2023 2 commits
    • Mark Brown's avatar
      ASoC: core: Always store of_node when getting DAI link component · 2d0cad04
      Mark Brown authored 
      The generic snd_soc_dai_get_dlc() contains a default translation function
for DAI names which has factored out common code in a number of card
drivers, resolving the dai_name and of_node either using a driver provided
translation function or with a generic implementation. Unfortunately the
of_node can't be set by the translation function since it currently doesn't
have an interface to do that but snd_soc_dai_get_dlc() only initialises the
of_node in the case where there is no translation function.

This breaks the Meson support after conversion to use the generic helpers
since the DPCM cards for it check which component of the SoC is connected
to each link by checking the compatible for the component and the Meson
components provide a custom operation so don't use the generic code.

Fix this and potentially other cards by unconditionally storing the node in
the dai_link_component, there shouldn't be a binding specific of_node
selected since that's how we determine the translation function.

Fixes: 2e1dbea1 ("ASoC: meson: use snd_soc_{of_}get_dlc()")
Fixes: 3c8b5861 ("ASoC: soc-core.c: add index on snd_soc_of_get_dai_name()")
Link: https://lore.kernel.org/r/Message-Id: <20230623-asoc-fix-meson-probe-v1-1-82b2c2ec5ca4@kernel.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      2d0cad04
    • Dan Carpenter's avatar
      ASoC: tas2781: Fix error code in tas2781_load_calibration() · ed959833
      Dan Carpenter authored 
      Return -EINVAL instead of success on this error path.

Fixes: 915f5ead ("ASoC: tas2781: firmware lib")
Signed-off-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/Message-Id: <729bb6b3-bc1d-4b3d-8b65-077a492c753c@moroto.mountain>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      ed959833
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7