- 04 Jun, 2021 1 commit
-
-
Yang Yingliang authored
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: e50dfac8 ("ALSA: firewire-motu: cache event ticks in source packet header per data block") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Acked-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210603143203.582017-1-yangyingliang@huawei.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 02 Jun, 2021 8 commits
-
-
Takashi Iwai authored
USB-audio driver behaves a bit strangely for the playback stream -- namely, it starts sending silent packets at PCM prepare state while the actual data is submitted at first when the trigger START is kicked off. This is a workaround for the behavior where URBs are processed too quickly at the beginning. That is, if we start submitting URBs at trigger START, the first few URBs will be immediately completed, and this would result in the immediate period-elapsed calls right after the start, which may confuse applications. OTOH, submitting the data after silent URBs would, of course, result in a certain delay of the actual data processing, and this is rather more serious problem on modern systems, in practice. This patch tries to revert the workaround and lets the URB submission starting at PCM trigger for the playback again. As far as I've tested with various backends (native ALSA, PA, JACK, PW), I haven't seen any problems (famous last words :) Note that the capture stream handling needs no such workaround, since the capture is driven per received URB. Link: https://lore.kernel.org/r/20210601162457.4877-6-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Just minor code refactoring. Like DOP DSD code, it can be better in a separate function for code readability. Link: https://lore.kernel.org/r/20210601162457.4877-5-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The PCM delay accounting in USB-audio driver is a bit complex to follow, and this is an attempt to improve the readability and provide some potential fix. Basically, the PCM position delay is calculated from two factors: the in-flight data on URBs and the USB frame counter. For the playback stream, we advance the hwptr already at submitting URBs. Those "in-flight" data amount is now tracked, and this is used as the base value for the PCM delay correction. The in-flight data is decreased again at URB completion in return. For the capture stream, OTOH, there is no in-flight data, hence the delay base is zero. The USB frame counter is used in addition for correcting the current position. The reference frame counter is updated at each submission and receiving time, and the difference from the current counter value is taken into account. In this patch, each in-flight data bytes is recorded in the new snd_usb_ctx.queued field, and the total in-flight amount is tracked in snd_usb_substream.inflight_bytes field, as the replacement of last_delay field. Note that updating the hwptr after URB completion doesn't work for PulseAudio who tries to scratch the buffer on the fly; USB-audio is basically a double-buffer implementation, hence the scratching the buffer can't work for the already submitted data. So we always update hwptr beforehand. It's not ideal, but the delay account should give enough correctness. Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
There are a bunch of lines calculating the buffer size in bytes at each time. Keep the value in subs->buffer_bytes and use it consistently for the code simplicity. Link: https://lore.kernel.org/r/20210601162457.4877-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
It's a local function, let's make it static. Link: https://lore.kernel.org/r/20210601162457.4877-2-tiwai@suse.deSigned-off-by:
-
Takashi Sakamoto authored
This commit takes ALSA firewire-motu driver to perform sequence replay for media clock recovery. Unlike the other types of device, the devices in MOTU FireWire series require two levels of sequence replay; the sequence of the number of data blocks per packet and the sequence of source packet header per data block. The former is already cached by ALSA IEC 61883-1/6 packet streaming engine and ready to be replayed. The latter is also cached by ALSA firewire-motu driver itself with a previous patch. This commit takes the driver to replay both of them from the caches. The sequence replay is tested with below models: * 828 mkII * Traveler * UltraLite * 828 mk3 FireWire * 828 mk3 Hybrid (except for high sampling transfer frequency * UltraLite mk3 FireWire * 4pre * AudioExpress Unfortunately, below models still don't generate better sound, requires more work: * 8pre * 828 mk3 Hybrid at high sampling transfer frequency As long as I know, MOTU protocol version 1 requires extra care of the format of data block, thus below models are not supported yet in this time: * 828 * 896 Signed-off-by:
-
Takashi Sakamoto authored
The devices in MOTU FireWire series put source packet header (SPH) into each data block of tx packet for presentation time of event. The format of timestamp is compliant to IEC 61883-1, with cycle and offset fields without sec field of 32 bit cycle time. This commit takes ALSA firewire-motu driver to cache the presentation time as offset from cycle in which the packet is transferred. Signed-off-by:
-
Takashi Sakamoto authored
ALSA firewire-motu driver has some magic numbers from IEC 61883-1 to operates source packet header (SPH). This commit replaces them with macros. Signed-off-by:
-
- 01 Jun, 2021 9 commits
-
-
Takashi Sakamoto authored
This commit takes ALSA bebob driver to perform sequence replay for media clock recovery. Many users have reported discontinuity of data block counter field of CIP header in tx packet from the devices based on BeBoB ASICs. In the worst case, the device corrupts not to respond to any transaction, then generate bus-reset voluntarily for recovery. The sequence replay for media clock recovery is expected to suppress most of the problems. In the beginning of packet streaming, the device transfers NODATA packets for a while, then multiplexes any event and syt information. ALSA IEC 61883-1/6 packet streaming engine has implementation for it to drop the initial NODATA packets. It starts sequence replay when detecting any event multiplexed to tx packets. The sequence replay is tested with below models: * Focusrite Saffire * Focusrite Saffire LE * Focusrite Saffire Pro 10 I/O * Focusrite Saffire Pro 26 I/O * M-Audio FireWire Solo * M-Audio FireWire Audiophile * M-Audio Ozonic * M-Audio FireWire 410 * M-Audio FireWire 1814 * Edirol FA-66 * ESI Quatafire 610 * Apogee Ensemble * Phonic Firefly 202 * Behringer F-Control Audio 610 Unfortunately, below models doesn't generate sound. This seems regression introduced recent few years: * Stanton Final Scratch ScratchAmp at middle sampling transfer frequency * Yamaha GO44 * Yamaha GO46 * Terratec Phase x24 As I reported, below model has quirk of discontinuity: * M-Audio ProFire Lightbridge DM1000/DM1100 ASICs in BeBoB solution are known to have bugs at switch of sampling transfer frequency between low/middle/high rates. The switch generates the similar problems about which I mention in the above. Some vendors customizes firmware so that the switch of frequency is done in vendor-specific registers, then restrict users to switch the frequency. For example of Focusrite Saffire Pro 10 i/o and 26 i/o, users allows to switch the frequency within the three steps; e.g. 44.1/48.0 kHz are available at low step. Between the steps, extra operation is required and it always generates bus-reset. Another example of Edirol FA-66, users are prohibited to switch the frequency by software. It's done by hardware switch and power-off. I note that the sequence replay is not a solution for the ASIC bugs. Users need to disconnect the device corrupted by the bug, then reconnect it to refresh state machine inner the ASIC. Signed-off-by:
-
Takashi Sakamoto authored
This commit takes ALSA dice driver to perform sequence replay for media clock recovery. Unlike the other types of device, DICE-based devices interpret the value of syt field of CIP header in rx packets as presentation time for audio playback, thus it's required for driver to compute value for outgoing packet adequate to the device. It's done by media clock recovery by handling tx packets. The device starts packet transmission immediately at operation to GLOBAL_ENABLE thus on-the-fly mode is not required. DICE ASICs supports several pairs of isochronous packet streams. Actually, maximum two pairs of streams are supported by devices. We have three cases regarding to the number of streams: 1. a pair of streams 2. two tx packet streams and one rx packet streams 3. one tx packet streams and two rx packet streams 4. two pair of streams The decision of playback timing is slightly different in the four cases. In the case 1, sequence replay in the pair results in suitable playback timing. In the case 2, sequence replay from the first tx packet stream to rx packet stream results in suitable playback timing. In the case 3, sequence replay from tx packet stream to all of rx packet stream results in suitable playback timing. Furthermore, the cycle to start receiving packets should be the same between all rx packet streams. In the case 4, sequence replay in each pair results in suitable playback timing. Furthermore, the cycle to start receiving packets should be the same between all rx packet streams. The sequence replay is tested with below models: * For case 1: * TC Electronic Konnekt 24d (DiceII) * TC Electronic Konnekt 8 (DiceII) * TC Electronic Konnekt Live (DiceII) * TC Electronic Impact Twin (DiceII) * TC Electronic Digital Konnekt X32 (DiceII) * TC Electronic Desktop Konnekt 6 (TCD2220) * Solid State Logic Duende Classic (DiceII) * Solid State Logic Duende Mini (DiceII) * PreSonus FireStudio Project (TCD2210) * PreSonus FireStudio Mobile (TCD2210) * Lexicon I-ONIX FW810s (TCD2220) * Avid Mbox 3 Pro (TCD2220) * For case 2 (but case 1 depends on sampling transfer frequency): * Alesis iO 26 (DiceII) * Alesis iO 14 (DiceII) * Alesis MultiMix 12 FireWire (DiceII) * Focusrite Saffire Pro 26 (TCD2220) * For case 3 (but case 1 depends on sampling transfer frequency): * M-Audio Profire 610 (TCD2220) * Loud Technology Mackie Onyx Blackbird (TCD2210) * For case 4: * TC Electronic Studio Konnekt 48 (DiceII + TCD2220) * PreSonus FireStudio (DiceII) * M-Audio Profire 2626 (TCD2220) * Focusrite Liquid Saffire 56 (TCD2220) * Focusrite Saffire Pro 40 (TCD2220) Signed-off-by:
-
Takashi Sakamoto authored
NOTIFY_CLOCK_ACCEPTED notification is always generated as a result of GLOBAL_CLOCK_SELECT operation, however NOTIFY_LOCK_CHG notification doesn't, as long as the selected clock is already configured. In the case, ALSA dice driver waits so long. It's inconvenient for some devices to lock to the sequence of value in syt field of CIP header in rx packets. This commit wait just for NOTIFY_CLOCK_ACCEPTED notification by reverting changes partially done by two commits below: * commit fbeac84d ("ALSA: dice: old firmware optimization for Dice notification") * commit aec045b8 ("ALSA: dice: change notification mask to detect lock status change") I note that the successful lock to the sequence of value in syt field of CIP header in rx packets results in NOTIFY_EXT_STATUS notification, then EXT_STATUS_ARX1_LOCKED bit stands in GLOBAL_EXTENDED_STATUS register. The notification can occur enough after receiving the batch of rx packets. When the sequence doesn't include value in syt field of CIP header in rx packets adequate to the device, the notification occurs again and the bit is off. Signed-off-by:
-
Takashi Sakamoto authored
This commit takes ALSA fireface driver to perform sequence replay for media clock recovery. The protocol specific to RME Fireface series is not compliant to IEC 61883-1/6 since it has no CIP header, therefore presentation time is not used for media clock recovery. The sequence of the number of data blocks per packet is important. I note that the device skips an isochronous cycle corresponding to an empty packet or a NODATA packet in blocking transmission method of IEC 61883-1/6. For sequence replay, the cycle is handled as receiving an empty packet. Furthermore, it doesn't start packet transmission till receiving any packet. The sequence replay is tested with below models: * Fireface 400 * Fireface 800 * Fireface 802 I note that it is better to initialize Fireface 400 in advance by initialization transaction implemented in snd-fireface-ctl-service of snd-firewire-ctl-services project. You can see whether initialized or not by HOST LED on the device. Unless, the device often stops packet transmission even if session starts. I guess the sequence replay also works well with below models: * Fireface UFX * Fireface UCX Signed-off-by:
-
Takashi Sakamoto authored
This commit takes ALSA firewire-tascam driver to perform sequence replay for media clock recovery. The protocol specific to Tascam FireWire series is not compliant to IEC 61883-1/6 in terms of syt field of CIP. The protocol doesn't use presentation time in received CIP for playback timing. The sequence of the number of data blocks per packet is important for media clock recovery. Although the devices in Tascam FireWire series transfer packets regardless of receiving packets, the tx packets includes no events in the beginning of streaming. It takes so long to multiplex any event into the packet after receiving the sequence of packets. As long as I experienced, it takes several thousands of isochronous cycle. Furthermore, just after changing sampling transmission frequency, it stops multiplexing event at once, then starts multiplexing again. The sequence replay is tested with below models: * FW-1884 * FW-1804 * FW-1082 Signed-off-by:
-
Takashi Sakamoto authored
This commit takes ALSA firewire-digi00x driver to perform sequence replay for media clock recovery. All of models in Digidesign digi00x family don't transfer isochronous packets till receiving isochronous packets. The on-the-fly mode is used for the purpose. They don't interpret presentation time expressed in syt field of received CIP, therefore the sequence of the number of data blocks per packet is important for media clock recovery. The sequence replay is tested with below models: * Digidesign Digi 002 * Digidesign Digi 002 Rack * Digidesign Digi 003 * Digidesign Digi 003 Rack Signed-off-by:
-
Takashi Sakamoto authored
This commit takes ALSA oxfw driver to perform sequence replay for media clock recovery. Unfortunately, OXFW970 ASIC and its firmware has a quirk called jumbo payload which skips several isochronous cycles for packet transmission, thus the sequence replay is just adopted to OXFW971 ASIC. As well as Fireworks, OXFW ASICs also ignores presentation time against the way in IEC 61883-1/6. The sequence replay is tested with below models: * Tascam FireOne * Stanton Magnetics SCS.1m * Apogee Duet FireWire For below models, the sequence replay is tested to be disabled: * Griffin FireWave * Behringer F-Control Audio 202 * Loud Technology Tapco Link.FireWire 4x6 * Loud Technology Mackie Onyx Satellite Signed-off-by:
-
Takashi Sakamoto authored
Echo Digital Audio Corporation had US patent US7599388B2 titled as 'System and method for high-bandwidth serial bus data transfer'. In the patent, dual-banked shared memory is used to deliver data between serial bus transmission and processor in FIFO way. The patent seems to be used for Fireworks board module. The mechanism is not compliant to synchronization based on presentation time expressed in syt field of CIP header. Fireworks board module takes care of the sequence of the number of data blocks per packet and just ignores the value of syt field. This commit takes fireworks driver to performs sequence replay for media clock recovery. As long as I tested, Audiofire 2 and 4 have a quirk to skip an isochronous cycle several thousands after starting packet transmission. The sequence replay is tested with below models: * Loud Technology Mackie 400f * Echo Audio Audiofire 12 (DSP model) * Echo Audio Audiofire 12 (FPGA model) * Echo Audio Audiofire 8 (DSP model) * Echo Audio Audiofire 8 (FPGA model) * Echo Audio Audiofire Pre8 * Echo Audio Audiofire 4 * Echo Audio Audiofire 2 Signed-off-by:
-
Takashi Sakamoto authored
In the design of Fireworks board module, the device does't adjust its media clock voluntarily by the sequence of presentation time expressed in syt field of CIP header of received packet. Signed-off-by:
-
- 30 May, 2021 1 commit
-
-
Shaokun Zhang authored
Function 'snd_usb_endpoint_suspend' is declared twice, so remove the repeated declaration. Signed-off-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> Link: https://lore.kernel.org/r/1622278926-63857-1-git-send-email-zhangshaokun@hisilicon.comSigned-off-by:
-
- 28 May, 2021 5 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> Link: https://lore.kernel.org/r/20210526121828.8460-1-yuehaibing@huawei.comSigned-off-by:
-
Takashi Sakamoto authored
Drivers of ALSA firewire stack can process packets for IT/IR context in process context when the process operates ALSA PCM character device by calling ioctl(2) with some requests. The ioctl requests are: * SNDRV_PCM_IOCTL_HWSYNC * SNDRV_PCM_IOCTL_SYNC_PTR * SNDRV_PCM_IOCTL_REWIND * SNDRV_PCM_IOCTL_FORWARD * SNDRV_PCM_IOCTL_WRITEI_FRAMES * SNDRV_PCM_IOCTL_READI_FRAMES * SNDRV_PCM_IOCTL_WRITEN_FRAMES * SNDRV_PCM_IOCTL_READN_FRAMES This means that general application can process PCM frames apart from hardware IRQ invocation, even if they are programmed by either IRQ-based scheduling model or Timer-based scheduling model. This commit add support for Timer-based scheduling model by allowing PCM runtime to suppress both process wakeup per period and scheduling hardware IRQ. SNDRV_PCM_INFO_BATCH is obsoleted since ALSA IEC 61883-1/6 packet streaming engine can report the number of transferred PCM frames within PCM period boundary. The granularity equals to SYT_INTERVAL in blocking transmission. In non-blocking transmission, it doesn't equal to SYT_INTERVAL but doesn't exceed. This patch is tested with PulseAudio, and --sched-model option of axfer with fix against the issue reported at: * https://lore.kernel.org/alsa-devel/687f9871-7484-1370-04d1-9c968e86f72b@linux.intel.com/#rSigned-off-by:
-
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 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 12 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 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:
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:
-
