- 08 Mar, 2024 2 commits
-
-
Simon Trimmer authored
Add the HID for the CS35L54 and CS35L57 Boosted Smart Amplifiers. These have the same control interface as the CS35L56 so are handled by the cs35l56-hda driver. Signed-off-by:
Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Message-ID: <20240308135900.603192-3-rf@opensource.cirrus.com>
-
Simon Trimmer authored
The CS35L54 and CS35L57 are Boosted Smart Amplifiers. The CS35L54 has I2C/SPI control and I2S/TDM audio. The CS35L57 also has SoundWire control and audio. The hardware differences between L54, L56 and L57 do not affect the driver control interface so they can all be handled by the same driver. Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
- 07 Mar, 2024 2 commits
-
-
Richard Fitzgerald authored
hda_component.h uses hda_codec_dev from sound/hda_codec.h. Include sound/hda_codec.h instead of assuming that it has already been included by the parent .c file. This isn't causing any problems with current code, so no need to backport to older kernels. Signed-off-by:
-
Richard Fitzgerald authored
Add the conventional include guards around the content of the hda_component.h header file. This prevents double-declaration of struct hda_component if the header gets included multiple times. This isn't causing any problems with current code, so no need to backport to older kernels. Signed-off-by:
-
- 04 Mar, 2024 7 commits
-
-
Takashi Iwai authored
There was one overlooked place to be replaced with snd_ctl_find_id_mixer() for code simplification. No functional change, only code refactoring. Link: https://lore.kernel.org/r/20240304082158.8583-1-tiwai@suse.deSigned-off-by:
-
Cezary Rojewski authored
Use the macro to improve readability. Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by:
-
Cezary Rojewski authored
Be cohesive and use same pattern in each error message. Signed-off-by:
-
Cezary Rojewski authored
HDMI codecs which are present and functional from audio perspective lack i915 support on drm side what results in -ENODEV during the probing sequence. There is no reason to perform recovery procedure e.g.: reset the HDAudio controller if this is the case. Signed-off-by:
-
Cezary Rojewski authored
If i915 does not support given platform but the hardware i.e.: HDAudio codec is still there, the codec-probing procedure will succeed for such device but the follow up initialization will always end up with -ENODEV. While bus could filter out address '2' which Intel's HDMI/DP codecs always enumerate on, more robust approach is to check for i915 presence before registering display codecs. Signed-off-by:
-
Cezary Rojewski authored
Commit 78f613ba ("drm/i915: finish removal of CNL") and its friends removed support for i915 for all CNL-based platforms. HDAudio library, however, still treats such platforms as valid candidates for i915 binding. Update query mechanism to reflect changes made in drm tree. At the same time, i915 support for LKF-based platforms has not been provided so remove them from valid binding candidates. Link: https://lore.kernel.org/all/20210728215946.1573015-1-lucas.demarchi@intel.com/Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Kenny Levinsen authored
When building feature controls from a unit without a name, we try to derive a name first from the feature unit's input, then fall back to the output terminal. If a feature unit connects directly to a "USB Streaming" input terminal rather than a mixer or other virtual type, the control receives the somewhat meaningless name "PCM", even if the output had a descriptive type such as "Headset" or "Speaker". Here is an example of such AudioControl descriptor from a USB headset which ends up named "PCM Playback" and is therefore not recognized as headphones by userspace: AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0101 USB Streaming bAssocTerminal 5 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0402 Headset bAssocTerminal 4 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 4 bControlSize 2 bmaControls(0) 0x0002 Volume Control bmaControls(1) 0x0000 bmaControls(2) 0x0000 iFeature 0 Other headsets and DACs I tried that used their output terminal for naming only did so due to their input being an unnamed sidetone mixer. Instead of always starting with the input terminal, check the type of it first. If it seems uninteresting, invert the order and use the output terminal first for naming. This makes userspace recognize headsets with simple controls as headphones, and leads to more consistent naming of playback devices based on their outputs irrespective of sidetone mixers. Signed-off-by:Kenny Levinsen <kl@kl.wtf> Link: https://lore.kernel.org/r/20240301231107.42679-1-kl@kl.wtfSigned-off-by:
-
- 01 Mar, 2024 1 commit
-
-
Nathan Chancellor authored
Clang prior to 17.0.0 has a bug in its asm goto jump scope analysis to determine that no variables with the cleanup attribute are skipped by an indirect jump. Instead of only checking the scope of each label that is a possible target of each asm goto statement, it checks the scope of every label, which can cause an error when a variable with the cleanup attribute is used between two asm goto statements with different scopes, even if they have completely different label targets: sound/core/hwdep.c:273:8: error: cannot jump from this asm goto statement to one of its possible targets if (get_user(device, (int __user *)arg)) ^ arch/powerpc/include/asm/uaccess.h:295:5: note: expanded from macro 'get_user' __get_user(x, _gu_addr) : \ ^ arch/powerpc/include/asm/uaccess.h:283:2: note: expanded from macro '__get_user' __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \ ^ arch/powerpc/include/asm/uaccess.h:199:3: note: expanded from macro '__get_user_size_allowed' __get_user_size_goto(x, ptr, size, __gus_failed); \ ^ arch/powerpc/include/asm/uaccess.h:187:10: note: expanded from macro '__get_user_size_goto' case 1: __get_user_asm_goto(x, (u8 __user *)ptr, label, "lbz"); break; \ ^ arch/powerpc/include/asm/uaccess.h:158:2: note: expanded from macro '__get_user_asm_goto' asm_volatile_goto( \ ^ include/linux/compiler_types.h:366:33: note: expanded from macro 'asm_volatile_goto' #define asm_volatile_goto(x...) asm goto(x) ^ sound/core/hwdep.c:291:9: note: possible target of asm goto statement if (put_user(device, (int __user *)arg)) ^ arch/powerpc/include/asm/uaccess.h:66:5: note: expanded from macro 'put_user' __put_user(x, _pu_addr) : -EFAULT; \ ^ arch/powerpc/include/asm/uaccess.h:52:9: note: expanded from macro '__put_user' \ ^ sound/core/hwdep.c:276:4: note: jump bypasses initialization of variable with __attribute__((cleanup)) scoped_guard(mutex, ®ister_mutex) { ^ include/linux/cleanup.h:169:20: note: expanded from macro 'scoped_guard' for (CLASS(_name, scope)(args), \ To avoid this issue, move the put_user() call out of the scoped_guard() scope, which allows the asm goto scope analysis to see that the variable with the cleanup attribute will never be skipped by the asm goto statements. There should be no functional change because prior to the refactoring, put_user() was not called under register_mutex, so this call does not even need to be in the scoped_guard() in the first place. Fixes: e6684d08 ("ALSA: hwdep: Use guard() for locking") Closes: https://github.com/ClangBuiltLinux/linux/issues/2003Signed-off-by:Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20240301-fix-snd-hwdep-guard-v1-1-6aab033f3f83@kernel.orgSigned-off-by:
-
- 28 Feb, 2024 25 commits
-
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. A couple of functions that use snd_card_ref() and *_unref() are also cleaned up with a defined class, too. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
The setup_mutex in PCM oss code can be simplified with guard(). (params_lock is tough and not trivial to covert, though.) Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
Define guard() usage for PCM stream locking and use it in appropriate places. The pair of snd_pcm_stream_lock() and snd_pcm_stream_unlock() can be presented with guard(pcm_stream_lock) now. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. There are a few remaining explicit mutex and spinlock calls, and those are the places where the temporary unlock/relocking happens -- which guard() doens't cover well yet. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. The lops calls under multiple rwsems are factored out as a simple macro, so that it can be called easily from snd_ctl_dev_register() and snd_ctl_dev_disconnect(). There are a few remaining explicit rwsem and spinlock calls, and those are the places where the lock downgrade happens or where the temporary unlock/relocking happens -- which guard() doens't cover well yet. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. There are still a few remaining explicit mutex_lock/unlock calls, and those are for the places where we do temporary unlock/relock, which doesn't fit well with the guard(), so far. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. For making changes easier, some functions widen the application of register_mutex, but those shouldn't influence on any actual performance. Also, one code block was factored out as a function so that guard() can be applied cleanly without much indentation. There are still a few remaining explicit spin_lock/unlock calls, and those are for the places where we do temporary unlock/relock, which doesn't fit well with the guard(), so far. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. The explicit mutex_lock/unlock are still seen only in snd_compress_wait_for_drain() which does temporary unlock/relocking. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by:
-
Takashi Iwai authored
There were a few sparse warnings about the cast of strong-typed snd_pcm_format_t. Fix them with cast with __force. For spreading the ugly mess, put them in the definitions WRONG_FORMAT_1 and WRONG_FORMAT_2 and use them in the callers. Fixes: 3e39acf5 ("ALSA: core: Add sound core KUnit test") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202402270303.PmvmQrJV-lkp@intel.com Link: https://lore.kernel.org/r/20240227104912.18921-1-tiwai@suse.deSigned-off-by:
-
- 23 Feb, 2024 3 commits
-
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by:
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by:
-
Takashi Iwai authored
Now we have a nice definition of CLASS(fd) that can be applied as a clean up for the fdget/fdput pairs in snd_pcm_link(). No functional changes, only code refactoring. Signed-off-by:
-
