- 22 May, 2020 6 commits
-
-
Takashi Sakamoto authored
In MOTU protocol, data block consists of SPH and 24-bit chunks aligned to quadlet. The number of chunks per data block is specific to model. For models with optical interface, the number differs depending on I/O settings for the interface (ADAT, TOSLINK). Currently the number is calculated from flags in model-specific data. However this is weak in the case that the model has quirks. Actually, for quirks of some models, flags are used against their original meanings. This commit adds model-specific table of chunk count. For future integration, this table is based on the calculation. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200519111641.123211-7-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
Now protocol structure becomes useless. This commit drops it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200519111641.123211-6-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
This commit adds helper functions which wraps function call for each protocol. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200519111641.123211-5-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
This commit adds enumerations of protocol version to localize protocol data. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200519111641.123211-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The most of members in spec data is used in each protocol file. It's better to capsulate the data to the file. This commit moves the data to the file for protocol version 3. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200519111641.123211-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The most of members in spec data is used in each protocol file. It's better to capsulate the data to the file. This commit moves the data to the file for protocol version 2. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200519111641.123211-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 16 May, 2020 3 commits
-
-
Takashi Iwai authored
snd_hdac_bus_queue_event() and snd_hdac_bus_exec_verb() are used only internally in HD-audio core. Let's drop the exports and move the declarations into local.h. Link: https://lore.kernel.org/r/20200516062854.22141-3-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The inline function is nowhere used. Drop it. Link: https://lore.kernel.org/r/20200516062854.22141-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The unsol event handling code has a loop retrieving the read/write indices and the arrays without locking while the append to the array may happen concurrently. This may lead to some inconsistency. Although there hasn't been any proof of this bad results, it's still safer to protect the racy accesses. This patch adds the spinlock protection around the unsol handling loop for addressing it. Here we take bus->reg_lock as the writer side snd_hdac_bus_queue_event() is also protected by that lock. Link: https://lore.kernel.org/r/20200516062556.30951-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 15 May, 2020 2 commits
-
-
Erwin Burema authored
For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this. This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex") Fixes: c2491779 ("ALSA: usb-audio: add implicit fb quirk for MOTU M Series") Signed-off-by: Erwin Burema <e.burema@gmail.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207023 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=103751 Link: https://lore.kernel.org/r/2410739.SCZni40SNb@alpha-wolfSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Thomas Ebeling authored
In my initial patch, these were set too low. Fixes: 3e8f3bd0 ("ALSA: usb-audio: RME Babyface Pro mixer patch") Signed-off-by: Thomas Ebeling <penguins@bollie.de> Link: https://lore.kernel.org/r/20200515114556.vtspnonzvp4xp44m@bollie.ca9.euSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200510074301.116224-7-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200510074301.116224-6-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200510074301.116224-5-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200510074301.116224-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200510074301.116224-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200510074301.116224-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-11-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-10-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-9-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-8-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-7-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-6-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-5-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200508043635.349339-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200507185245.GA14270@embeddedorSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 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: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedorSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Iwai <tiwai@suse.de>
-
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: Hulk Robot <hulkci@huawei.com> Signed-off-by: Samuel Zou <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1588823647-12480-1-git-send-email-zou_wei@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 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: Takashi Iwai <tiwai@suse.de>
-
- 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: Takashi Iwai <tiwai@suse.de>
-
Kai-Heng Feng authored
Use dev_to_hdac_dev() 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-1-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 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: Takashi Iwai <tiwai@suse.de>
-
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 <spujar@nvidia.com> Link: https://lore.kernel.org/r/1588580176-2801-3-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
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: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1588580176-2801-2-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 02 May, 2020 1 commit
-
-
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: Takashi Iwai <tiwai@suse.de>
-