- 08 Aug, 2024 21 commits
-
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-22-tiwai@suse.de
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Use the standard print API instead of open-coded printk(). Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
There are quite a few commented-out debug prints that have never been used in the production code. Let's rip them off for code cleanness. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use pr_*() macro instead of open-coded printk() just for code simplification. Reviewed-by:
-
Takashi Iwai authored
Use pr_err() instead of open-coded printk() just for code simplification. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The commented old debug prints are dropped, too. Reviewed-by:
-
Takashi Iwai authored
The vx_core.dev field has never been set but referred incorrectly at firmware loading. Pass the proper device pointer from card->dev at request_firmware(), and drop the unused dev field from vx_core, too. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Some debug prints are cleaned up with a macro, too. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The commented-out debug prints got removed, too. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The assignment of mpu->rmidi was moved to an earlier place, so that dev_*() can access to the proper device pointer. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
- 07 Aug, 2024 6 commits
-
-
Takashi Iwai authored
The recent extension added a new ALSA sequencer port info flag bit SNDRV_SEQ_PORT_FLG_IS_MIDI1, but it's not reported back when inquired. Fix it to report properly. Fixes: 0079c9d1 ("ALSA: ump: Handle MIDI 1.0 Function Block in MIDI 2.0 protocol") Signed-off-by:
-
Takashi Iwai authored
When a sequencer port assigned to a UMP Group that is specific to MIDI 1.0 among MIDI 2.0 client, mark it explicitly in the proc output, so that user can see it easily. This is an exceptional case where the message isn't converted to MIDI 1.0 even if the client is running in MIDI 2.0 mode. Signed-off-by:
-
Takashi Iwai authored
When a FB is created from a GTB instead of UMP FB Info inquiry, we missed the update of the corresponding UMP Group attributes. Export the call of updater and let it be called from the USB driver. Fixes: 0642a3c5 ("ALSA: ump: Update substream name from assigned FB names") Signed-off-by:
-
Takashi Iwai authored
When a MIDI 1.0 protocol is specified in a GTB entry while others are set in MIDI 2.0, it should be seen as a legacy MIDI 1.0 port. Since recently we allow drivers to set a flag SNDRV_UMP_BLOCK_IS_MIDI1 to a FB for that purpose. This patch tries to set that flag when the device shows such a configuration. Signed-off-by:
-
Takashi Iwai authored
It's valid to give different protocols via multiple GTBs; e.g. a MIDI 1.0 port is embedded in a MIDI 2.0 device that talks with MIDI 2.0 protocol. However, the current driver implementation assumes only a single protocol over the whole Endpoint, and it can't handle such a scenario. This patch changes the driver's behavior to parse GTBs to accept multiple protocols. Instead of switching to the last given protocol, it adds the protocol capability bits now. Meanwhile, the default protocol is chosen by the first given protocol in GTBs. Practically seen, this should be a minor issue, as new devices should specify the protocols properly via UMP Endpoint Info messages, so this is rather just covering a corner case. Signed-off-by:
-
Takashi Iwai authored
When the protocol capability bits are changed via Endpoint Info update notification, we should check the validity of the current protocol and reset it if needed, too. Signed-off-by:
-
- 06 Aug, 2024 2 commits
-
-
Takashi Iwai authored
For an invalid input value that is out of the given range, currently USB-audio driver corrects the value silently and accepts without errors. This is no wrong behavior, per se, but the recent kselftest rather wants to have an error in such a case, hence a different behavior is expected now. This patch adds a sanity check at each control put for the standard mixer types and returns an error if an invalid value is given. Note that this covers only the standard mixer types. The mixer quirks that have own control callbacks would need different coverage. Link: https://patch.msgid.link/20240806124651.28203-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The UMP v1.1 spec says in the section 6.2.1: "If a UMP Endpoint declares MIDI 2.0 Protocol but a Function Block represents a MIDI 1.0 connection, then may optionally be used for messages to/from that Function Block." It implies that the driver can (and should) keep MIDI 1.0 CVM exceptionally for those FBs even if UMP Endpoint is running in MIDI 2.0 protocol, and the current driver lacks of it. This patch extends the sequencer port info to indicate a MIDI 1.0 port, and tries to send/receive MIDI 1.0 CVM as is when this port is the source or sink. The sequencer port flag is set by the driver at parsing FBs and GTBs although application can set it to its own user-space clients, too. Link: https://patch.msgid.link/20240806070024.14301-1-tiwai@suse.deSigned-off-by:
-
- 01 Aug, 2024 8 commits
-
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87plqvk51y.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Takashi Iwai authored
The recent changes in IOMMU made the non-contiguous page allocations as default, hence we can simply use the standard DMA allocation for the S/G pages as well. In this patch, we simplify the code by trying the standard DMA allocation at first, instead of dma_alloc_noncontiguous(). For the case without IOMMU, we still need to manage the S/G pages manually, so we keep the same fallback routines like before. The fallback types (SNDRV_DMA_TYPE_DEV_SG_FALLBACK & co) are dropped / folded into SNDRV_DMA_TYPE_DEV_SG and co now. The allocation via the standard DMA call overrides the type accordingly, hence we don't have to have extra fallback types any longer. OTOH, SNDRV_DMA_TYPE_DEV_SG is no longer an alias but became its own type back again. Note that this patch requires another prerequisite fix for memmalloc helper to use the DMA API for WC pages on x86. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219087 Link: https://patch.msgid.link/20240801064808.31205-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The memalloc helper used a house-made code for allocation of WC pages on x86, since the standard DMA API doesn't cover it well. Meanwhile, the manually allocated pages won't work together with IOMMU, resulting in faults, so we should switch to the DMA API in that case, instead. This patch tries to switch back to DMA API for WC pages on x86, but with some additional tweaks that are missing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219087 Link: https://patch.msgid.link/20240801064808.31205-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
One snd_power_unref() was forgotten and left at __snd_ctl_elem_info() in the previous change for reorganizing the locking order. Fixes: fcc62b19 ("ALSA: control: Take power_ref lock primarily") Link: https://github.com/thesofproject/linux/pull/5127 Link: https://patch.msgid.link/20240801064203.30284-1-tiwai@suse.deSigned-off-by:
-
- 30 Jul, 2024 3 commits
-
-
Takashi Iwai authored
The code path for kcontrol accesses have often nested locks of both card's controls_rwsem and power_ref, and applies in that order. However, what could take much longer is the latter, power_ref; it waits for the power state of the device, and it pretty much depends on the user's action. This patch swaps the locking order of those locks to a more natural way, namely, power_ref -> controls_rwsem, in order to shorten the time of possible nested locks. For consistency, power_ref is taken always in the top-level caller side (that is, *_user() functions and the ioctl handler itself). Link: https://patch.msgid.link/20240729160659.4516-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We want sometimes to keep the runtime PM disabled persistently just like we did for the PM deny-list in the previous change, e.g. for testing some buggy device. This patch enhances the existing pm_blacklist option for achieving it easily. The default behavior doesn't change -- the driver looks up the deny list and disables the runtime PM if matches. However, when pm_blacklist=1 option is set, now the driver disables the runtime PM completely, just like the deny-list does. Update the documentation for this option, too. Link: https://patch.msgid.link/20240729141519.18398-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We have a runtime PM deny-list for the devices that show the problems (typically click noises) at runtime suspend/resume, and when it matches, the driver disables the default runtime PM. However, we still allow the runtime PM changed via power_save module option dynamically, and the desktop system often tweaks it. This ended up with a re-enablement of the runtime PM that surprises users, suddenly suffering from the noises. This patch changes the driver behavior slightly: when the device is listed in the deny-list, ignore the power_save option change and keep the original (that is, off) runtime PM state. Link: https://patch.msgid.link/20240729141519.18398-1-tiwai@suse.deSigned-off-by:
-
