- 08 Aug, 2024 32 commits
-
-
Takashi Iwai authored
Use the standard print API instead of open-coded printk(). Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-33-tiwai@suse.de
-
Takashi Iwai authored
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. Some functions are changed to receive snd_card pointer for referring to the device pointer for dev_*() calls, 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 card pointer is stored in struct snd_opti9xx and snd_miro to be referred for dev_*() calls. 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 card pointer is stored in struct snd_opl3sa2 to be referred for dev_*() calls. 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 commented-out debug prints and dead code are dropped as well. 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. For referring to the device, introduce snd_card pointer to struct snd_es18xx. 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. For referring to the device, introduce snd_card pointer to struct snd_es1688. 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. 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:
-
