The value isn't used yet; the subsequent commits will do that.
This ignores the existence of rates above 48 kHz, which is fine, as the
hardware will just switch to the fallback clock source when fed with a
rate which is incompatible with the base clock multiplier, which
currently is always x1.
The sample rate display in /proc spdif-in is adjusted to reflect our
understanding of the input rates.
This is tested only with an 0404b card without sync card, so there is a
lot of room for improvement.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The actually available clock sources depend on the available audio input
ports and dedicated clock input ports.
This includes refactoring the code to be data-driven to remain
manageable.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far, we set the fallback as a side effect of setting the source. But
the fallback makes no sense at all when an internal clock is selected.
Defaulting to 48k for S/PDIF & ADAT makes sense, but as that is the
global default and we're not changing it automatically any more, it's
just fine to leave it entirely to the explicit setting.
This changes the name of the pre-existing control to something more
appropriate (regardless of the split), so users will need to adjust
their mixer settings.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As the updated MIDI 2.0 spec has been published freshly, this is a
catch up to add the support for new specs, especially UMP v1.1
features, on Linux kernel.
The new UMP v1.1 introduced the concept of Function Blocks (FB), which
is a kind of superset of USB MIDI 2.0 Group Terminal Blocks (GTB).
The patch set adds the support for FB as the primary information
source while keeping the parse of GTB as fallback. Also UMP v1.1
supports the groupless messages, the protocol switch, static FBs, and
other new fundamental features, and those are supported as well.
Link: https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange
Link: https://lore.kernel.org/r/20230612081054.17200-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
UMP v1.1 spec allows to inform whether the function blocks are static
and not dynamically updated. Add a new flag bit to
snd_ump_endpoint_info to reflect that attribute, too.
The flag is set when a USB MIDI device is still in the old MIDI 2.0
without UMP 1.1 support. Then the driver falls back to GTBs, and they
are supposed to be static-only.
Link: https://lore.kernel.org/r/20230612081054.17200-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
UMP v1.1 supports the protocol switch via a UMP Stream message. When
it's received, we need to take care of the midi_version field in the
corresponding sequencer client, too.
This patch introduces a new ops to notify the protocol change to
snd_seq_ump_ops for handling it.
Link: https://lore.kernel.org/r/20230612081054.17200-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For allowing applications to track the FB active changes, this patch
adds the notification from the system port at each time a FB change is
handled and the active flag or re-grouping happens.
Link: https://lore.kernel.org/r/20230612081054.17200-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch implements the handling of the dynamic update of FB info.
When the FB info update is received after the initial parsing, it
means the dynamic FB info update. We compare the result, and if the
actual update is detected, it's notified via a new ops,
notify_fb_change, to the sequencer client, and the corresponding
sequencer ports are updated accordingly.
Link: https://lore.kernel.org/r/20230612081054.17200-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The UMP Utility and Stream messages are "groupless", i.e. an incoming
groupless packet should be sent only to the UMP EP port, and the event
with the groupless message is sent to UMP EP as is without the group
translation per port.
Also, the former reserved bit 0 for the client group filter is now
used for groupless events. When the bit 0 is set, the groupless
events are filtered out and skipped.
Link: https://lore.kernel.org/r/20230612081054.17200-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a new option to enable/disable the UMP Endpoint probing.
Some firmware seems screwed up when such a new command issued, and
this option allows user to suppress it.
Link: https://lore.kernel.org/r/20230612081054.17200-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Try to parse the UMP Endpoint and UMP Function Blocks for building the
topology at first. Only when those are missing (e.g. on an older USB
MIDI 2.0 spec or a unidirectional endpoint), the driver still creates
blocks based on USB group terminal block information as fallback.
Link: https://lore.kernel.org/r/20230612081054.17200-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the basic support for UMP Endpoint and UMP Function
Block parsing, which are extended in the new UMP v1.1 spec.
The patch provides a new helper function to perform the query of the
UMP Endpoint information and builds up the UMP blocks based on UMP
Function Block information. For the communication over the UMP
Endpoint, it opens the rawmidi device once internally, inquiries the
UMP Endpoint and Function Block info by sending new UMP Stream
messages, and waits for the response for each query.
The new UMP spec allows to update the FB info and change its
associated groups or its activeness on the fly, too. For catching it,
the UMP core keeps watching the incoming UMP messages, and
snd_ump_receive() handles the incoming UMP Stream messages to refresh
the FB info.
Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a few more fields to snd_ump_endpoint_info and snd_ump_block_info
that are added in the new v1.1 spec. Those are filled by the UMP Stream
messages.
The rawmidi protocol version is bumped to 2.0.4 to indicate those
updates.
Also, update the proc outputs to show the newly introduced fields.
Link: https://lore.kernel.org/r/20230612081054.17200-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HDA can only support single register read and write operations so does not
benefit from block writes. This means it gets no benefit from using the
rbtree register cache over the maple tree register cache so convert it to
use maple trees instead, it is more modern.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230609-alsa-hda-maple-v1-1-a2b725c8b8f5@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This test covers the new Virtual PCM Test Driver, including the capturing,
playback and ioctl redefinition functionalities for both interleaved and
non-interleaved access modes. This test is also helpful as an usage example
of the 'pcmtest' driver.
We have a lot of different virtual media drivers, which can be used for
testing of the userspace applications and media subsystem middle layer.
However, all of them are aimed at testing the video functionality and
simulating the video devices. For audio devices we have only snd-dummy
module, which is good in simulating the correct behavior of an ALSA device.
I decided to write a tool, which would help to test the userspace ALSA
programs (and the PCM middle layer as well) under unusual circumstances
to figure out how they would behave. So I came up with this Virtual PCM
Test Driver.
This new Virtual PCM Test Driver has several features which can be useful
during the userspace ALSA applications testing/fuzzing, or testing/fuzzing
of the PCM middle layer. Not all of them can be implemented using the
existing virtual drivers (like dummy or loopback). Here is what can this
driver do:
- Simulate both capture and playback processes
- Generate random or pattern-based capture data
- Check the playback stream for containing the looped pattern
- Inject delays into the playback and capturing processes
- Inject errors during the PCM callbacks
Also, this driver can check the playback stream for containing the
predefined pattern, which is used in the corresponding selftest to check
the PCM middle layer data transferring functionality. Additionally, this
driver redefines the default RESET ioctl, and the selftest covers this PCM
API functionality as well.
The driver supports both interleaved and non-interleaved access modes, and
have separate pattern buffers for each channel. The driver supports up to
4 channels and up to 8 substreams.
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606193254.20791-3-ivan.orlov0322@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have a lot of different virtual media drivers, which can be used for
testing of the userspace applications and media subsystem middle layer.
However, all of them are aimed at testing the video functionality and
simulating the video devices. For audio devices we have only snd-dummy
module, which is good in simulating the correct behavior of an ALSA device.
I decided to write a tool, which would help to test the userspace ALSA
programs (and the PCM middle layer as well) under unusual circumstances
to figure out how they would behave. So I came up with this Virtual PCM
Test Driver.
This new Virtual PCM Test Driver has several features which can be useful
during the userspace ALSA applications testing/fuzzing, or testing/fuzzing
of the PCM middle layer. Not all of them can be implemented using the
existing virtual drivers (like dummy or loopback). Here is what can this
driver do:
- Simulate both capture and playback processes
- Generate random or pattern-based capture data
- Inject delays into the playback and capturing processes
- Inject errors during the PCM callbacks
Also, this driver can check the playback stream for containing the
predefined pattern, which is used in the corresponding selftest to check
the PCM middle layer data transferring functionality. Additionally, this
driver redefines the default RESET ioctl, and the selftest covers this PCM
API functionality as well.
The driver supports both interleaved and non-interleaved access modes, and
have separate pattern buffers for each channel. The driver supports up to
4 channels and up to 8 substreams.
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606193254.20791-2-ivan.orlov0322@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add documentation for the new Virtual PCM Test Driver. It covers all
possible usage cases: errors and delay injections, random and
pattern-based data generation, playback and ioctl redefinition
functionalities testing.
We have a lot of different virtual media drivers, which can be used for
testing of the userspace applications and media subsystem middle layer.
However, all of them are aimed at testing the video functionality and
simulating the video devices. For audio devices we have only snd-dummy
module, which is good in simulating the correct behavior of an ALSA device.
I decided to write a tool, which would help to test the userspace ALSA
programs (and the PCM middle layer as well) under unusual circumstances
to figure out how they would behave. So I came up with this Virtual PCM
Test Driver.
This new Virtual PCM Test Driver has several features which can be useful
during the userspace ALSA applications testing/fuzzing, or testing/fuzzing
of the PCM middle layer. Not all of them can be implemented using the
existing virtual drivers (like dummy or loopback). Here is what can this
driver do:
- Simulate both capture and playback processes
- Check the playback stream for containing the looped pattern
- Generate random or pattern-based capture data
- Inject delays into the playback and capturing processes
- Inject errors during the PCM callbacks
Also, this driver can check the playback stream for containing the
predefined pattern, which is used in the corresponding selftest to check
the PCM middle layer data transferring functionality. Additionally, this
driver redefines the default RESET ioctl, and the selftest covers this PCM
API functionality as well.
The driver supports both interleaved and non-interleaved access modes, and
have separate pattern buffers for each channel. The driver supports up to
4 channels and up to 8 substreams.
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606193254.20791-1-ivan.orlov0322@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On loongson controller, the value of WALLCLK register
is always 0, which is meaningless, so we return directly.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/185df71ef413ab190460eb377703214ee7288aeb.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On loongson controller, after calling snd_hdac_stream_updateb()
to enable DMA engine, the SDnCTL.STRM will become to zero. We
need to access SDnCTL in dword to keep SDnCTL.STRM is not changed.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/27aeddf5ebbe7c69631cec0e489c1b264be94990.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On loongson controller, RIRBSTS.RINTFL cannot be cleared,
azx_interrupt() is called all the time. We disable RIRB
interrupt, and use polling mode by default.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/d309a75424d438b958d90d797b4f1ba45468e090.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We don't need to change the numid at each time snd_ctl_rename_id() is
called, as the control element size itself doesn't change. Let's keep
the previous numid value.
Along with it, add a note about calling this function only in the
card init phase.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606094035.14808-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Ensure Firmware Load control and Firmware Type control
returns 1 when the value changes.
Remove fw_mutex from firmware load control put, since it is
unnecessary, and prevents any possibility of mutex inversion.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230606103436.455348-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently the read event packet size in snd_seq_read() is defined by
client->midi_version value that is guaranteed to be zero if UMP isn't
enabled. But the static analyzer doesn't know of the fact, and it
still suspects as if it were leading to a potential overflow.
Add the more explicit check of CONFIG_SND_SEQ_UMP to determine the
aligned_size value for avoiding the confusion.
Fixes: 46397622a3 ("ALSA: seq: Add UMP support")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202305261415.NY0vapZK-lkp@intel.com/
Link: https://lore.kernel.org/r/20230605144758.6677-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- Include the FX bus map, without which the already present send routing
info would require looking up the documentation.
- Include the physical I/O channels as known to the driver
- Make the multi-channel capture map actually name the mapped input
channels rather than "FXBUS" (Audigy) or even "???" (SbLive)
- The latter two are omitted for E-MU cards, as their physical I/O is
routed through the FPGA
- While at it, make the "Card" field somewhat more useful
This includes de-duplicating the label tables between emuproc and emufx,
updating/improving the FX bus label table, and making the SB Live! 5.1
multi-track capture channel mapping hack data-driven.
Tested-by: Jonathan Dowland <jon@dow.land>
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Include the routing information, which can be actually read back.
Somewhat as a drive-by, make the register dump format less obscure - the
previous one made no sense at all.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems to make little sense to include the FX send routing, but not
the amounts.
This also simplifies the code somewhat, and lines up the output.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The limits were appropriate only for the 2nd set.
FWIW, the channel count 4 for the 2nd set is suspicious as well - at
least P17V_PLAYBACK_FIFO_PTR actually has 8 channels, and comments on
HCFG2 hint at that as well. But all bitmasks are documented only for 4
channels. Anyway, rectifying that is out of scope for this patch.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The 2nd register set belongs to the P16V chip (or embedded P17V module),
so there is nothing to show when no such part is present. Gen2 E-MU
cards have a P17V, but it's entirely unused, so we hide it there as
well.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After commit b8a1a4cd5a ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://lore.kernel.org/r/20230525203640.677826-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On SB cards the number of captured channels is derived from the voice
mask mixer control. But for E-MU cards this wasn't actually "wired up",
so changing the mask would simply mess up the recording.
We could fix that, but the channel routing through the FPGA makes the
masking redundant. So instead we hide the control, and let the user
specify the PCM channel count the traditional way.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The hardware can deal with primes up to 7 and power-of-two multiples
thereof; the limitation is reflected by the possible buffer sizes.
Note that setting the voice mask will not allow more than 16 channels
even on Sound Blaster Audigy anymore, as 32 seems a bit excessive (the
code overall appears to think so, just not in this case).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We need to specify that the hardware supports non-standard rates, as
otherwise the sound core creates a constraint which limits the rate to
the specified standard rates. That also made the rate constraint we were
already adding meaningless.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The buffer size register sets the size of the whole buffer, not just one
period. We actually handled it like that, except that the constraint was
set on the wrong parameter. The period size is implicitly constrained by
the buffer size and the fixed period count of 2.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We use independent voices for the channels, so we need to make an effort
to ensure that they are actually in sync.
The hardware doesn't provide atomicity, so we may need to retry a few
times, due to NMIs, PCI contention, and the wrong phase of the moon.
Solution inspired by kX-project.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236023-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For unclear reasons, the extra voice was set up with half the buffer
size instead of the period size. Commit 27ae958cf6 ("emu10k1 driver -
add multichannel device hw:x,3 [2-8/8]") mentions half-loop interrupts,
so maybe this was an artifact of an earlier iteration of the patch.
While at it, also fix periods_min of the regular playback - one period
makes just no sense.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236023-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The #endif is placed obviously at a wrong position, which caused a
build error on the big endian machine.
Fixes: 0b5288f5fe ("ALSA: ump: Add legacy raw MIDI support")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20230524135448.3ecad334@canb.auug.org.au
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Oswald Buddenhagen
Takashi Iwai
Takashi Sakamoto
Mark Brown
Ivan Orlov
Yanteng Si
Stefan Binding
Uwe Kleine-König
Stephen Rothwell