- 11 May, 2020 1 commit
-
-
Takashi Sakamoto authored
This is trivial commit but fulfill missing entries in Kconfig for devices supported by ALSA firewire-motu driver. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200511022540.161363-1-o-takashi@sakamocchi.jpSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 10 May, 2020 6 commits
-
-
Takashi Sakamoto authored
Fireface UFX was shipped by RME GmbH in 2010, and now discontinued. Although this model has some enhanced feature which Fireface 802 doesn't have (e.g. on-board USB mass storage device class, configuration interface with color display), the functionality relevant to packet communication on IEEE 1394 bus seems to be the same as Fireface 802 (e.g. available number of channels for PCM frame in each sampling transfer frequency). With the assumption, this commit adds support for Fireface UFX. In ALSA fireface driver, these two models are handled as the same one. Signed-off-by:
-
Takashi Sakamoto authored
Fireface 802 was shipped by RME GmbH in 2014. This model supports later protocol for management of isochronous communication and synchronization of sampling transmission frequency. This model consists of below ICs: * TI TSB41AB2 * Xilinx Spartan-6 FPGA XC6SLX16 * TI TMS320 C6747 * SMSC USB3250 Especially, this model just supports IEEE 1394a, against its name which evokes Fireface 800. This commit adds support for Fireface 802 (tested). Userspace applications can transfer PCM frames and MIDI messages via ALSA PCM/Rawmidi interface. I note that 4 channels for ADAt1 and ADAT2 are disabled at higher sampling transfer frequency since isochronous resources reservation fails due to bandwidth limitation of IEEE 1394a. The value read from LATTER_SYNC_STATUS register is slightly different from the one of Fireface UCX. The higher 4 bits and lower 4 bits are swapped within the same byte. Without any assist of userspace application, transmitted MIDI messages from the device are not going to be processed. For detail, please refer to my comment in code of latter protocol. $ python crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0404ffff bus_info_length 4, crc_length 4, crc 65535 (should be 26805) 404 31333934 bus_name "1394" 408 20008000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 8 (512) 40c 000a3504 company_id 000a35 | 410 38077423 device_id 0438077423 | EUI-64 000a350438077423 root directory ----------------------------------------------------------------- 414 0005ffff directory_length 5, crc 65535 (should be 9514) 418 0c0083c0 node capabilities per IEEE 1394 41c 03000a35 vendor 420 8100000b --> descriptor leaf at 44c 424 8d000007 --> eui-64 leaf at 440 428 d1000001 --> unit directory at 42c unit directory at 42c ----------------------------------------------------------------- 42c 0004ffff directory_length 4, crc 65535 (should be 45134) 430 12000a35 specifier id 434 13000005 version 438 17101800 model 43c 81000008 --> descriptor leaf at 45c eui-64 leaf at 440 ----------------------------------------------------------------- 440 0002ffff leaf_length 2, crc 65535 (should be 60131) 444 000a3504 company_id 000a35 | 448 38077423 device_id 0438077423 | EUI-64 000a350438077423 descriptor leaf at 44c ----------------------------------------------------------------- 44c 0003ffff leaf_length 3, crc 65535 (should be 469) 450 00000000 textual descriptor 454 00000000 minimal ASCII 458 524d4521 "RME!" descriptor leaf at 45c ----------------------------------------------------------------- 45c 0005ffff leaf_length 5, crc 65535 (should be 10561) 460 00000000 textual descriptor 464 00000000 minimal ASCII 468 46697265 "Fire" 46c 66616365 "face" 470 20383032 " 802" Signed-off-by: -
Takashi Sakamoto authored
This commit uses enumeration constants as index of table for the list of name of sound card. Signed-off-by:
-
Takashi Sakamoto authored
In RME fireface series, version field of unit directory in configuration ROM is used to distinguish each model. The value of field is known and it's better to use enumeration constants for code representation. This commit adds enumeration constants for model identification. Signed-off-by:
-
Takashi Sakamoto authored
In the latter models of RME Fireface series, device start to transfer packets several dozens of milliseconds. On the other hand, ALSA fireface driver starts IR context 2 milliseconds after the start. This results in loss to handle incoming packets on the context. This commit changes to start IR context immediately instead of postponement. For Fireface 800, this affects nothing because the device transfer packets 100 milliseconds or so after the start and this is within wait timeout. Cc: <stable@vger.kernel.org> Fixes: acfedcbe ("ALSA: firewire-lib: postpone to start IR context") Signed-off-by:
-
Takashi Sakamoto authored
128000 and 192000 are congruence modulo 32000, thus it's wrong to distinguish them as multiple of 32000 and 48000 by modulo 32000 at first. Additionally, used condition statement to detect quadruple speed can cause missing bit flag. Furthermore, counter to ensure the configuration is wrong and it causes false positive. This commit fixes the above three bugs. Cc: <stable@vger.kernel.org> Fixes: 60aec494 ("ALSA: fireface: support allocate_resources operation in latter protocol") Signed-off-by:
-
- 08 May, 2020 11 commits
-
-
Takashi Sakamoto authored
In previous commit, the sequence of syt offset and the number of data blocks per packet is calculated for pool in AMDTP domain structure in advance of processing outgoing packets. This commit uses the sequence for outgoing packet processing to obsolete per-stream processing of the sequence. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, sequence of syt offset and the number of data blocks is generated when packets for outgoing stream are going to be queued. This commit generates and pools the sequence independently of the processing of outgoing packets for future extension. Signed-off-by:
-
Takashi Sakamoto authored
For future extension, storage is required to store packet sequence in incoming AMDTP stream to recover media clock for outgoing AMDTP stream. This commit adds the storage to AMDTP domain for this purpose. The packet sequence is represented by 'struct seq_desc' which has two members; syt_offset and the number of data blocks. The size of storage is decided according to the size of packet queue. Signed-off-by:
-
Takashi Sakamoto authored
When calculating the number of data blocks per packet, some states are stored in AMDTP stream structure. This is inconvenient when reuse the calculation from non-stream structure. This commit applies refactoring to helper function for the calculation so that the function doesn't touch AMDTP stream structure. Signed-off-by:
-
Takashi Sakamoto authored
When calculating syt offset, some states are stored in AMDTP stream structure. This is inconvenient when reuse the calculation from non-stream structure. This commit applies refactoring to helper function for the calculation so that the function doesn't touch AMDTP stream structure. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation for outgoing AMDTP packet, the value of syt field in CIP header is computed when calculating syt offset. For future extension, it's convenient to split the computation and calculation. This commit splits them. Signed-off-by:
-
Takashi Sakamoto authored
Although the parameter for packet queue and IRQ timing is calculated when AMDTP stream starts, the calculated parameters are the same between streams in AMDTP domain. This commit moves the calculation and decide the parameters when AMDTP domain starts. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, AMDTP domain structure and AMDTP stream structure has one way of reference from the former to the latter. For future extension, bidirectional reference is needed. This commit adds a member into stream structure to refer to domain structure to which the stream belongs. Signed-off-by:
-
Takashi Sakamoto authored
In descriptor of isochronous context in 1394 OHCI, the field of second has 3 bit, thus the maximum value is 8. The value is used for correct cycle calculation. This commit replaces hard-coded value with macro to obsolete magic number. Signed-off-by:
-
Takashi Sakamoto authored
Although the value of FDF is used just for outgoing stream, the assignment to union member is done for both directions of stream. At present this causes no issue because the value of same position is reassigned later for opposite stream. However, it's better to add if statement. Fixes: d3d10a4a ("ALSA: firewire-lib: use union for directional parameters") Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by:
-
- 07 May, 2020 4 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Cezary Rojewski authored
Update intel-dspcfg with FLAG_SST_ONLY_IF_DMIC option and use it for Skylake and Kabylake platforms when DMIC is present. Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200506203951.6369-1-cezary.rojewski@intel.comSigned-off-by:
-
Samuel Zou authored
Fix the following coccinelle warning: sound/drivers/portman2x4.c:460:34-35: WARNING: sum of probable bitmasks, consider | Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Samuel Zou <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1588834135-14842-1-git-send-email-zou_wei@huawei.comSigned-off-by:
-
Samuel Zou authored
Fix the following coccinelle warnings: sound/ppc/pmac.c:729:57-58: WARNING: sum of probable bitmasks, consider | sound/ppc/pmac.c:229:37-38: WARNING: sum of probable bitmasks, consider | Reported-by:
-
- 06 May, 2020 1 commit
-
-
Jason Yan authored
Fix the following coccicheck warning: include/sound/hdaudio.h:210:73-74: WARNING: return of 0/1 in function 'snd_hdac_is_in_pm' with return type bool include/sound/hdaudio.h:211:76-77: WARNING: return of 0/1 in function 'snd_hdac_is_power_on' with return type bool Signed-off-by:
Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200506061716.19209-1-yanaijie@huawei.comSigned-off-by:
-
- 05 May, 2020 2 commits
-
-
Kai-Heng Feng authored
Use hdac_to_hda_codec() instead of container_of(). No functional change intended. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200505030357.28004-2-kai.heng.feng@canonical.comSigned-off-by:
-
Kai-Heng Feng authored
Use dev_to_hdac_dev() instead of container_of(). No functional change intended. Signed-off-by:
-
- 04 May, 2020 3 commits
-
-
Sameer Pujar authored
Tegra194 has 4 SDO lines and with this configuration playback fails for 44.1K/48K, 2-channel and 16-bps. It results in below print, "aplay: pcm_write:2011: write error: Input/output error" Below relation is used to derive stripe control and is referenced from HD Audio Specification: Revision 1.0a. { ((num_channels * bits_per_sample) / number of SDOs) >= 8 } Due to a legacy HW design problem, playback issue is hit while using a stripe value resulting from above formula when ratio is '8'. Thus it is recommended that the ratio must be greater than '8'. Since the number of SDO lines is in powers of 2, next available ratio '16' is used as a limiting factor on Tegra194 to workaround the problem. Signed-off-by:Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1588580176-2801-4-git-send-email-spujar@nvidia.comSigned-off-by:
-
Sameer Pujar authored
Stripe control programming is governed by following formula, which is referenced from the HD Audio specification(Revision 1.0a). { ((num_channels * bits_per_sample) / number of SDOs) >= 8 } Currently above is implemented in snd_hdac_get_stream_stripe_ctl(). This patch introduces a structure member to store the default factor of '8'. If any HW wants to use a different value, this member can be easily updated. Signed-off-by: -
Sameer Pujar authored
Tegra194 supports 4 SDO lines but GCAP register indicates 2 lines. Thus it does not reflect the true capability of the HW. This patch presents a workaround by updating NSDO value accordingly in T_AZA_DBG_CFG_2 register. Signed-off-by:
-
- 02 May, 2020 2 commits
-
-
Vasily Khoruzhick authored
At least POD HD500 uses message-based communication, both sides can send messages. Add poll callback so application can wait for device messages without using busy loop. Signed-off-by:
Vasily Khoruzhick <anarsoul@gmail.com> Link: https://lore.kernel.org/r/20200502193120.79115-3-anarsoul@gmail.comSigned-off-by:
-
Vasily Khoruzhick authored
Currently line6 hwdep interface ignores O_NONBLOCK flag when opening device and it renders it somewhat useless when using poll. Check for O_NONBLOCK flag when opening device and don't block read() if it is set. Signed-off-by:
-
- 01 May, 2020 2 commits
-
-
Dan Carpenter authored
The "header->number" comes from the ioctl and it needs to be clamped to prevent out of bounds writes. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200501094011.GA960082@mwandaSigned-off-by:
-
Takashi Iwai authored
Cover with a proper ifdef around the variable declaration for fixing the following compilation warning without CONFIG_LEDS_TRIGGER_AUDIO: sound/pci/hda/patch_realtek.c: In function 'alc_fixup_hp_gpio_led': sound/pci/hda/patch_realtek.c:4134:6: warning: unused variable 'err' [-Wunused-variable] Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 87dc3648 ("ALSA: hda/realtek - Add LED class support for micmute LED") Link: https://lore.kernel.org/r/20200501072857.13720-1-tiwai@suse.deSigned-off-by:
-
- 30 Apr, 2020 3 commits
-
-
Kai-Heng Feng authored
Currently DMIC controls micmute LED via "audio mute LED trigger". However, unlike Dell and Lenovo platforms, HP platforms don't provide a way to control micmute LED via ACPI, it's controlled by HDA codec instead. So let's register an LED class for micmute so other subsystems like DMIC can facilitate the codec-controlled LED. Signed-off-by:
-
Kai-Heng Feng authored
Though the system uses DMIC, headset mic still uses the HDA, let's use GPIO 0x1 to control the micmute LED. The micmute LED GPIO has a different polarity to the mute LED GPIO, we can use the newly added micmute_led_polarity to indicate that. Signed-off-by:
-
Kai-Heng Feng authored
Currently mute LED and micmute LED share the same GPIO polarity. So split the polarity for mute and micmute, in case they have different polarities. Signed-off-by:
-
- 29 Apr, 2020 1 commit
-
-
YueHaibing authored
There's no callers in-tree. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200429132805.18712-1-yuehaibing@huawei.comSigned-off-by:
-
- 24 Apr, 2020 4 commits
-
-
Takashi Iwai authored
The linked list entry from FIFO is peeked at queue_pending_output_urbs() but the actual element pop-out is performed outside the spinlock, and it's potentially racy. Do delete the link at the right place inside the spinlock. Fixes: 8fdff6a3 ("ALSA: snd-usb: implement new endpoint streaming model") Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.deSigned-off-by:
-
Alexander Tsoy authored
Frame size computation has been fixed and the workaround is no longer needed. Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200424022449.14972-2-alexander@tsoy.meSigned-off-by:
-
Alexander Tsoy authored
For computation of the the next frame size current value of fs/fps and accumulated fractional parts of fs/fps are used, where values are stored in Q16.16 format. This is quite natural for computing frame size for asynchronous endpoints driven by explicit feedback, since in this case fs/fps is a value provided by the feedback endpoint and it's already in the Q format. If an error is accumulated over time, the device can adjust fs/fps value to prevent buffer overruns/underruns. But for synchronous endpoints the accuracy provided by these computations is not enough. Due to accumulated error the driver periodically produces frames with incorrect size (+/- 1 audio sample). This patch fixes this issue by implementing a different algorithm for frame size computation. It is based on accumulating of the remainders from division fs/fps and it doesn't accumulate errors over time. This new method is enabled for synchronous and adaptive playback endpoints. Signed-off-by:
-
Takashi Iwai authored
Back-merge 5.7-rc devel branch for further changes. Signed-off-by:
-
