- 28 May, 2021 3 commits
-
-
Takashi Sakamoto authored
Models in below series start transmission of packet after receiving the sequence of packets: * Digidesign Digi00x family * RME Fireface series Additionally, models in Tascam FireWire series start multiplexing PCM frames into packets enough after receiving packets. It's required to transfer packets on-the-fly for the above models according to nominal sampling transfer frequency before starting sequence replay. This commit allows drivers to decide whether the engine transfers packet on-the-fly or not. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jpSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
ALSA IEC 61883-1/6 packet streaming engine uses pre-computed parameters ideal for nominal sampling transfer frequency (STF) to transfer packets to device since it was added 2011. As a result of user experience for a decade, it is clear that the sequence is not suitable to some actual devices. It takes the devices to generate noise, and causes any type of discontinuity in the series of packet transferred from the device. It's required for the engine to transfer packets according to effective STF. The effective STF is given by media clock recovered by the sequence of packet transferred from the target device. In the previous commit, the sequence is already cached. The media clock recovery can be achieved by analyzing the sequence. In technological world, many ideas are proposed for media clock recovery. However, the small part of them could be actually adopted in our case since floating point arithmetic is not mostly available in Linux kernel land. This commit adopts the simple way from them; sequence replay, which means that the sequence of parameters from incoming packet is used as is to transfer outgoing packets. The media clock is not computed internally, but the sequence of outgoing packet superficially looks to be generated by the media clock. The association between source and destination is decided when starting AMDTP domain. When the target device supports a pair of isochronous packet streams, the tx stream is source and the rx stream is destination. When it supports two pair of streams, each of tx stream is associated to corresponding rx stream in its order. When it supports less number of tx streams than rx streams, the fist tx stream is selected for all of rx streams. When it supports more tx streams than rx streams, the first tx packet is associated to the rx stream. As I noted in previous commit, the sequence of parameters from incoming packet is different between devices, time to time. It is worse idea to replay the sequence of parameters from a device for the sequence of packet to the other devices even if they are in the same category of device. Signed-off-by:
-
Takashi Sakamoto authored
In design of audio and music unit in IEEE 1394 bus, feedback of effective sampling transfer frequency (STF) is delivered by packets transferred from device. The devices supported by ALSA firewire stack are categorized to three groups regarding to it. * Group 1: * Echo Audio Fireworks board module * Oxford Semiconductor OXFW971 ASIC * Digidesign Digi00x family * Tascam FireWire series * RME Fireface series * Group 2: * BridgeCo. DM1000/DM1100/DM1500 ASICs for BeBoB solution * TC Applied Technologies DICE ASICs * Group 3: * Mark of the Unicord FireWire series In group 1, the effective STF is determined by the sequence of the number of events per packet. In group 2, the sequence of presentation timestamp expressed in syt field of CIP header is interpreted as well. In group 3, the presentation timestamp is expressed in source packet header (SPH) of each data block. I note that some models doesn't take care of effective STF with large internal buffer. It's reasonable to name it as group 0: * Group 0 * Oxford Semiconductor OXFW970 ASIC The effective STF is known to be slightly different from nominal STF for all of devices, and to be different between the devices. Furthermore, the effective STF is known to be shifted for long-period transmission. This makes it hard for software to satisfy the effective STF when processing packets to the device. The effective STF is deterministic as a result of analyzing the batch of packet transferred from the device. For the analysis, caching the sequence of parameter in the packet is required. This commit adds an option so that AMDTP domain structure takes AMDTP stream structure to cache the sequence of parameters in packet transferred from the device. The parameters are offset ticks of syt field against the cycle to receive the packet and the number of data blocks per packet. Signed-off-by:
-
- 27 May, 2021 4 commits
-
-
Colin Ian King authored
Don't populate the const array dsp_dma_stream_ids the stack but instead make it static. Makes the object code smaller by 21 bytes. Before: text data bss dec hex filename 189012 70376 192 259580 3f5fc ./sound/pci/hda/patch_ca0132.o After: text data bss dec hex filename 188927 70440 192 259559 3f5e7 ./sound/pci/hda/patch_ca0132.o (gcc version 10.3.0) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210526160616.3764119-1-colin.king@canonical.comSigned-off-by:
-
Pierre-Louis Bossart authored
Sparse throws the following warning: sound/pci/lx6464es/lx_core.c:677:34: error: self-comparison always evaluates to false This comparison and error message make no sense, let's remove them. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210526192957.449515-2-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Pierre-Louis Bossart authored
Sparse throws the following warning: sound/drivers/opl3/opl3_midi.c:183:60: error: self-comparison always evaluates to false This is likely a 16+ year old confusion between vp2 and vp. Suggested-by:
-
zuoqilin authored
Remove superfluous "break", as there is a "return" before them. Signed-off-by:
zuoqilin <zuoqilin@yulong.com> Link: https://lore.kernel.org/r/20210527030445.1201-1-zuoqilin1@163.comSigned-off-by:
-
- 25 May, 2021 15 commits
-
-
YueHaibing authored
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
YueHaibing authored
Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(), which makes the code a bit shorter and easier to read. Signed-off-by:
-
Yufen Yu authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Link: https://lore.kernel.org/r/20210524093811.612302-1-yuyufen@huawei.comSigned-off-by:
-
zuoqilin authored
Remove superfluous "break", as there is a "return" before them. Signed-off-by:
-
Takashi Sakamoto authored
In former commit, ALSA IEC 61883-1/6 packet streaming engine drops initial tx packets till the packet includes any event. This allows ALSA bebob driver not to give option to skip initial packet since the engine does drop the initial packet. However, M-Audio ProFire Lightbridge has a quirk to stop packet transmission after start multiplexing event to the packet. After several thousands cycles, it restart packet transmission again. This commit specializes the usage of initial skip option for the model. Additionally, this commit expands timeout enough to wait processing content of tx packet. Signed-off-by:
-
Takashi Sakamoto authored
The order to establish connection seems to be meaningless. Signed-off-by:
-
Takashi Sakamoto authored
The member of callbacked in AMDTP stream structure is not used anymore. Instead, ready_processing member is used to wake up yielding task of user process. Signed-off-by:
-
Takashi Sakamoto authored
The devices based on BeBoB ASICs or the devices in Tascam FireWire series transfer a batch of NODATA packet or empty packet in the beginning of packet streaming. To avoid processing them, current implementation uses an option to skip processing content of tx packet during some initial cycles. However, the hard-coded number is not enough useful. This commit drops content of packets till the packet includes any event firstly. The function of option is to skip processing content of tx packet with any event after dropping. Signed-off-by:
-
Takashi Iwai authored
Pull PCI rescan prep work. Link: https://lore.kernel.org/r/20210523090920.15345-1-tiwai@suse.de
-
Takashi Iwai authored
The normal PCM operations are already blocked during the card power off state in the PCM common ioctl handler, but the release isn't covered. As the PCM stream release may also access the hardware, let's block the release until the card power turns on. Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210523090920.15345-7-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The power_state argument of snd_power_wait() is superfluous, receiving only SNDRV_POWER_STATE_D0. Let's drop it in all callers for simplicity. Reviewed-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210523090920.15345-6-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Long long time ago, before the proper PM framework was introduced, it was still possible to reach SNDRV_CTL_IOCTL_POWER ioctl during the power off state. This ioctl existed as a main control for the suspend resume state in the past, but the feature was already dropped along with the standard PM framework. Now the read part, SNDRV_IOCTL_POWER_STATE ioctl, returns practically always D0, and we can do some minor optimization there. Reviewed-by:
-
Takashi Iwai authored
Now we have more fine-grained power controls in each kcontrol ops, the coarse checks of snd_power_wait() in a few control ioctls became superfluous. Let's drop them. Reviewed-by:
-
Takashi Iwai authored
Although the power state check is performed in various places (e.g. at the entrance of quite a few ioctls), there can be still some pending tasks that already went into the ioctl handler or other ops, and those may access the hardware even after the power state check. For example, kcontrol access ioctl paths that call info/get/put callbacks may update the hardware registers. If a system wants to assure the free from such hw access (like the case of PCI rescan feature we're going to implement in future), this situation must be avoided, and we have to sync such in-flight tasks finishing beforehand. For that purpose, this patch introduces a few new things in core code: - A refcount, power_ref, and a wait queue, power_ref_sleep, to the card object - A few new helpers, snd_power_ref(), snd_power_unref(), snd_power_ref_and_wait(), and snd_power_sync_ref() In the code paths that call kctl info/read/write/tlv ops, we check the power state with the newly introduced snd_power_ref_and_wait(). This function also takes the card.power_ref refcount for tracking this in-flight task. Once after the access finishes, snd_power_unref() is called to released the refcount in return. So the driver can sync via snd_power_sync_ref() assuring that all in-flight tasks have been finished. As of this patch, snd_power_sync_ref() is called only at snd_card_disconnect(), but it'll be used in other places in future. Note that atomic_t is used for power_ref intentionally instead of refcount_t. It's because of the design of refcount_t type; refcount_t cannot be zero-based, and it cannot do dec_and_test() call for multiple times, hence it's not suitable for our purpose. Also, this patch changes snd_power_wait() to accept only SNDRV_CTL_POWER_D0, which is the only value that makes sense. In later patch, the snd_power_wait() calls will be cleaned up. Reviewed-by:
-
Takashi Iwai authored
We need proper barriers to handle the power state change of the card from different CPUs. Reviewed-by:
-
- 22 May, 2021 7 commits
-
-
Takashi Sakamoto authored
In later commit, transfer delay is used in both IR and IT contexts. This commit refactors regardless of transfer delay. Signed-off-by:
-
Takashi Sakamoto authored
This commit dissolves sequence generator in terms of the number of data blocks per packet. Signed-off-by:
-
Takashi Sakamoto authored
This commit dissolves sequence generator in terms of syt offsets for packet. Signed-off-by:
-
Takashi Sakamoto authored
This commit refactors the arguments of helper function to generate the descriptors of packet. Signed-off-by:
-
Takashi Sakamoto authored
Current implementation pools the sequence in AMDTP domain. This is convenient regarding to memory usage and computation time, however inconvenient for the devices such that several rx streams are expected to transfer timing information independently. This commit refactors to pool the sequence per rx packet stream. Signed-off-by:
-
Takashi Sakamoto authored
Many devices are unaware of syt field in rx CIP for playback timing. This commit adds a flag to cancel processing syt field. Actually, syt calculation is required to decide the number of events per rx packet. The flag put 0xffff to CIP header of rx packet. On the other hand, The value of syt field in CIP header of tx packet is unavailable. The sequence of packet descriptor for tx packet includes 0 for the offset of syt field to avoid computation. Signed-off-by:
-
Takashi Sakamoto authored
The check of error is just done for the case that CIP header is available. This commit moves auto variable into the branch to process CIP header. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: c09010ee ("ALSA: firewire-lib: handle the case that empty isochronous packet payload for CIP") Suggested-by:
-
- 21 May, 2021 1 commit
-
-
Takashi Iwai authored
The cur variable indicating the currently selected clock source can be theoretically used as uninitialized after the recent commit 481f17c4 ("ALSA: usb-audio: Handle error for the current selector gracefully"). For addressing it, initialize it before use. Also, one place seems setting 0 to a wrong variable ret, instead of cur; otherwise it makes little sense. Since the initialization is done beforehand, we can get rid of this line, too. Fixes: 481f17c4 ("ALSA: usb-audio: Handle error for the current selector gracefully") Reported-by:
-
- 20 May, 2021 8 commits
-
-
Takashi Sakamoto authored
When starting AMDTP domain, tasks in process context yields running CPU till all of isochronous context get callback, with an assumption that it's OK to process content of packet. However several isochronous cycles are skipped to transfer rx packets, or the content of rx packets are dropped, to manage the timing to start processing the packets. This commit changes the timing for tasks in process context to wake up when processing content of packet is actually ready. Signed-off-by:
-
Takashi Sakamoto authored
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 authored
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 authored
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 authored
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 authored
This commit refactors regarding to the size of CIP header. Signed-off-by:
-
Takashi Sakamoto authored
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 authored
Some macros are added to refactor codes related to CIP header. Signed-off-by:
-
- 19 May, 2021 2 commits
-
-
Takashi Iwai authored
-
Takashi Iwai authored
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.deSigned-off-by:
-
