DICE ASICs support several pairs of isochronous packet streaming and
expect software to queue packets with the same timing information into
the same isochronous cycle.
This commit adds structure member to manage the cycle to start
processing packet in several IT contexts. The cycle is decided when
batch of isochronous cycle is skipped in callback to isochronous context
for IRQ target.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's several hundred cycles from starting isochronous contexts and the
actual cycle to start processing content of packet. It's useless to
start the context for IRQ target apart from the other contexts.
This commit refactors helper function to start AMDTP domain in the point.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Current implementation of ALSA IEC 61883-1/6 packet streaming engine
allows drivers to decide isochronous cycle to start IR context. This
option is mainly used to avoid processing the sequence of packet with
some quirks; e.g. discontinuity of counter. However, it's inconvenient
to fail to continue packet processing when the target device doesn't
start transmission of packet till the decided cycle.
This commit changes the behaviour. As an alternative to the start cycle
for IR context, the cycle count to drop content of packet in the beginning
of IR context.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
DICE ASICs support several pairs of isochronous packet streaming. It's
convenient for drivers to process content of the packet in the same cycle
timing.
This commit adds structure member to manage the cycle to start
processing packet in several IR contexts. The cycle is decided in the
first callback of the IR contexts. The content of packet is dropped
till the cycle.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's convenient to calculate the size of context payload apart from
the size of isochronous packet payload.
This commit adds a helper function for it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we bail out when the device returns an error or an invalid
value for the current clock selector value via
uac_clock_selector_get_val(). But it's possible that the device is
really uninitialized and waits for the setup of the proper route at
first.
For handling such a case, this patch lets the driver dealing with the
error or the invalid error more gracefully, choosing the clock source
automatically instead.
Link: https://lore.kernel.org/r/20210518152112.8016-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch just does refactoring of the UAC2/3 clock setup code.
There should be no functional changes. The major changes are:
* Provide union objects for pointing both UAC2 and UAC3 objects
* Unify clock source, selector and multiplier helper functions
* Unify __uac_clock_find_source() to deal with both UAC2 and UAC3
equally
Link: https://lore.kernel.org/r/20210518152112.8016-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The array bounds check on clock_names is currently checking the size
of the entire array rather than the number of elements in the array
leading to a potential array bounds read error. Fix this by using
the ARRAY_SIZE macro instead of sizeof.
Addresses-Coverity: ("Out-of-bounds read")
Fixes: 08fdced60c ("ALSA: rawmidi: Add framing mode")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210519105424.55221-1-colin.king@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit fulfils sequence descriptors for skipped cycle when
it's one cycle. This is preparation for future integration.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518130048.146596-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Within devices supported by drivers in ALSA firewire stack, OXFW-based
devices and Fireface devices are known to skip isochronous cycle for
packet transmission. The former is due to the jumbo payload quirk. The
latter is due to vendor protocol in which empty packet is not
transferred in blocking mode.
Although nothing to do just for handling events of the packet, packet
continuity is necessarily for media clock recovery. This commit checks
whether any cycle is continue or not.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518130048.146596-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some macros and functions are renamed so that they compute isochronous
cycle within maximum count of second in isochronous context of 1394
OHCI.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518130048.146596-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Two quadlets are at least included in isochronous packet payload for
Common Isochronous Packet (CIP) format in IEC 61883-1. However, it's
better to equip ALSA IEC 61883-1/6 packet streaming engine for contrary
packet.
This commit handles isochronous cycle to process such packet so that the
cycle is skipped.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518130048.146596-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA OXFW supports two types of ASICS; OXFW970 and OXFW971. The former
is known to have a quirk we call 'jumbo payload' that some isochronous
cycles are skipped to transfer isochronous packets during handling
asynchronous transaction. The quirk seems to correspond to firmware
initially delivered by Oxford Semiconductor since the quirk is not
confirmed for Mackie Onyx Satellite in which the revised firmware is
available. The quirk is not confirmed in the latter.
This commit adds code comment to describe the quirk.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Loud Technologies Mackie Onyx Satellite is identified as the model with
OXFW970 ASIC.
This commit adds explicit entry for the model.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Loud Technologies Tapco Link.FireWire 4x6 is identified as the model
with OXFW970 ASIC.
This commit adds explicit entry for the model.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit changes condition statement to call mackie models detection
just for the device entry. Additionally, comment is added for Onyx 1640i.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
All of the devices known to be based on OXFW ASICs have the same layout
of configuration ROM, in which unit directory includes vendor, model,
specifier_id and version immediate values. Especially, the pair of
specifier_id and version is fixed to represent AV/C general protocol.
This commit refactors device entries to fulfil with these 4 elements.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It brings some inconvenience in practice to use enumerated type for
variable to which bitwise OR with enumerator constant is assigned.
This commit replaces declarations of enumerated type with int type.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 0edabdfe89.
I've explained that optional FireWire card for d.2 is also built-in to
d.2 Pro, however it's wrong. The optional card uses DM1000 ASIC and has
'Mackie DJ Mixer' in its model name of configuration ROM. On the other
hand, built-in FireWire card for d.2 Pro and d.4 Pro uses OXFW971 ASIC
and has 'd.Pro' in its model name according to manuals and user
experiences. The former card is not the card for d.2 Pro. They are similar
in appearance but different internally.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At high sampling transfer frequency, TC Electronic Konnekt Live
transfers/receives 6 audio data frames in multi bit linear audio data
channel of data block in CIP payload. Current hard-coded stream format
is wrong.
Cc: <stable@vger.kernel.org>
Fixes: f1f0f330b1 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518012612.37268-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA dice driver detects jumbo payload at high sampling transfer frequency
for below models:
* Avid M-Box 3 Pro
* M-Audio Profire 610
* M-Audio Profire 2626
Although many DICE-based devices have a quirk at high sampling transfer
frequency to multiplex double number of PCM frames into data block than
the number in IEC 61883-1/6, the above devices are just compliant to
IEC 61883-1/6.
This commit disables the mode of double_pcm_frames for the models.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518012510.37126-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Minor code refactoring by merging the superfluous function calls.
The functions were split in the past for covering pre-history USB
driver code, but this is utterly useless.
Link: https://lore.kernel.org/r/20210517131545.27252-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently us428ctls_shmem pages are allocated dynamically upon the
mmap call, but this is quite racy. Since the shared memory itself is
mandatory for the mmap, let's allocate it at the beginning of the card
initialization. Also, fix the initialization of the wait queue, too.
Link: https://lore.kernel.org/r/20210517131545.27252-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCM shmem pages are allocated in snd_usx2y_usbpcm_prepare().
Theoretically the prepare callback may be called simultaneously for
both playback and capture, hence this allocation can be racy.
Make sure that the allocation is performed exclusively by extending
the pcm_mutex lock to cover the allocation code, too.
Link: https://lore.kernel.org/r/20210517131545.27252-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Theoretically the initialization functions in usx2y drivers may be
called multiple times as the driver gets initialized via hwpdep
ioctl. Meanwhile, those functions including memory allocations don't
check whether they are called twice, and they forget the old
resources, which would lead to memory leaks.
This patch adds the sanity checks about the doubly initializations to
give kernel WARNING, and returns an error in such a case. Also, each
allocation assures to release the resources at its error path
properly.
Link: https://lore.kernel.org/r/20210517131545.27252-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The initialization os usx2y driver is multi-staged, and the PCM and
other device creations are done after the DSP is loaded and
initialized. Upon the initialization, when an error happens, the
driver tries to call snd_card_free(). But this is dangerous, and in
general, the driver cannot kill itself during its operation.
Hence better to drop the snd_card_free() call from there.
Link: https://lore.kernel.org/r/20210517131545.27252-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
usx2y drivers may expose the allocated pages via mmap, but it performs
zero-clear only for the struct size, not aligned with the page size.
This leaves out some uninitialized trailing bytes.
This patch fixes the clearance to cover all memory that are exposed to
user-space.
Link: https://lore.kernel.org/r/20210517131545.27252-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes various trivial coding-style issues in usx2y code,
such as:
* the assginments in if condition
* comparison order with constants
* NULL / zero checks
* unsigned -> unsigned int
* addition of braces in control blocks
* debug print with function names
* move local variables in block into function head
* reduction of too nested indentations
No functional changes.
Link: https://lore.kernel.org/r/20210517131545.27252-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch corrects merely the spaces in the usx2y code, including the
superfluous trailing space in the debug prints and a slight reformat
of some comment lines. Nothing really touches about the code itself.
Link: https://lore.kernel.org/r/20210517131545.27252-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For improving readability, convert camelCase fields, variables and
functions to the plain names with underscore. Also align the macros
to be capital letters.
All done via sed, no functional changes.
Note that you'll still see many coding style issues even after this
patch; the fixes will follow.
Link: https://lore.kernel.org/r/20210517131545.27252-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds a new framing mode that frames all MIDI data into
32-byte frames with a timestamp.
The main benefit is that we can get accurate timestamps even if
userspace wakeup and processing is not immediate.
Testing on a Celeron N3150 with this mode has a max jitter of 2.8 ms,
compared to the in-kernel seq implementation which has a max jitter
of 5 ms during idle and much worse when running scheduler stress tests
in parallel.
Signed-off-by: David Henningsson <coding@diwic.se>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210515071533.55332-1-coding@diwic.se
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The interrupt handler of intel8x0 calls snd_intel8x0_update() whenever
the hardware sets the corresponding status bit for each stream. This
works fine for most cases as long as the hardware behaves properly.
But when the hardware gives a wrong bit set, this leads to a zero-
division Oops, and reportedly, this seems what happened on a VM.
For fixing the crash, this patch adds a internal flag indicating that
the stream is ready to be updated, and check it (as well as the flag
being in suspended) to ignore such spurious update.
Cc: <stable@vger.kernel.org>
Reported-and-tested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Link: https://lore.kernel.org/r/s5h5yzi7uh0.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix smatch warning:
sound/isa/gus/gus_main.c:396 snd_gus_check_version() error:
strcpy() 'card->longname' too large for 'card->shortname' (80 vs 32)
Even if this is not a real bug since the longest length of card->longname
now is 31, replace strcpy() with strscpy() in order to avoid possible
future mistake.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20210514070507.16600-1-yuehaibing@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Variable dac is set to zero, but this value is never read as it is
overwritten or not used later on, hence it is a redundant assignment
and can be removed.
Clean up the following clang-analyzer warning:
sound/pci/hda/hda_generic.c:1436:4: warning: Value stored to 'dac' is
never read [clang-analyzer-deadcode.DeadStores].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/1620904271-76027-1-git-send-email-jiapeng.chong@linux.alibaba.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>