Several hw_params functions narrows the interval via min/max rule in
the very similar way, so factor out those into a helper function and
use commonly.
No functional changes, just minor code refactoring.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-12-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a preliminary work for the upcoming hw-constraint change for
the implicit feedback mode.
Currently snd_usb_autoresume() is called at the end of
setup_hwinfo(). It's a bit confusing; because of this implicit
refcount usage, the caller side needs to call snd_usb_autosuspend()
later in the error path although it's not seen inside the function.
Instead, it's clearer to call both snd_usb_autoresume() and suspend()
in the very same function.
It's only refactoring and no functional changes.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of parsing and evaluating the sync endpoint and the implicit
feedback mode at each time the audio stream is opened, let's parse it
once at the probe time, as the all needed information can be obtained
statically from the descriptor or from the quirk.
This patch extends audioformat struct to record the sync endpoint,
interface and altsetting as well as the implicit feedback flag, which
are filled at parsing the streams. Then, set_sync_endpoint() is much
simplified just to follow the already parsed data.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There are a few rooms for improvements wrt the debug prints:
- The EP debug print is shown only at starting, not at stopping
- The EP debug print contains useless object addresses
- Some helpers show the urb and the EP object addresses, too
This patch addresses those shortcomings.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sync EP setup isn't cleared at stopping the stream but expected to
be cleared at the next stream start. This may leave the sync link
setup stale and can spoof wrongly when full duplex streams were
running in the implicit fb sync. Let's initialize them properly at
start and end of the stream.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Factor out the code to obtain snd_usb_endpoint object matching with
the given endpoint. It'll be used in the later patch to add the
implicit feedback hw-constraint.
No functional change by this patch itself.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems that many UAC2 devices are with the implicit feedback, but
they couldn't be probed properly because the assumption the driver
takes currently isn't applied: they have the single endpoint for both
data and implicit-fb streams, while we checked only the classical sync
endpoints assigned to the next altsetting in the same interface.
This patch extends the search to match with those typical cases where
the implicit fb stream is found in the next interface number.
While we're at it, slightly refactor the code, not returning 0/-ERROR
but use the standard bool to success/failur, which is more intuitive
in this particular case.
Reported-by: Dylan Robinson <dylan_robinson@motu.com>
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The current driver code assumes blindly that all found sample rates for
the same endpoint from the UAC2 and UAC3 descriptors can be used no
matter which altsetting, but actually this was wrong: some devices
accept only limited sample rates in each altsetting. For determining
which altsetting supports which rate, we need to verify each sample rate
and check the validity via UAC2_AS_VAL_ALT_SETTINGS. This control
reports back the available altsettings as a bitmap.
This patch implements the missing piece above, the verification and
reconstructs the sample rate tables based on the result.
An open question is how to deal with the altsettings that ended up
with no valid sample rates after verification. At least, there is a
device that showed this problem although the sample rates did work in
the later usage (see bug link). For now, we accept such an altset as
is, assuming that it's a firmware bug.
Reported-by: Dylan Robinson <dylan_robinson@motu.com>
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203
Link: https://lore.kernel.org/r/20201123085347.19667-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCM trigger callback is atomic, hence we must not call a function
like usb_set_interface() there. Calling it from there would lead to a
kernel Oops.
Fix it by moving the usb_set_interface() call to set_sync_endpoint().
Also, apply the snd_usb_set_interface_quirk() for consistency, too.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the current code, when the device provides the discrete sample rate
tables with unusual sample rates, the driver tries to gather the whole
values from the audioformat entries and create a hw-constraint rule to
restrict with this single rate list. This is rather inefficient and
may overlook the rates that are associated only with the certain
audioformat entries.
This patch improves the hw constraint setup by rewriting the existing
hw_rule_rate(). The discrete sample rates (identified by rate_table
and nr_rates of format entry) are checked in the existing
hw_rule_rate() instead of extra rules; in the case of discrete rates,
the function compares with each rate table entry and calculates the
min/max values from there. For the contiguous rates, the behavior
doesn't change.
Along with it, snd_usb_pcm_check_knot() and snb_usb_substream
rate_list field become superfluous, thus those are dropped.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Found one more Logitech device, BCC950 ConferenceCam, which needs
the same delay here. This makes 3 out of 3 devices I have tried.
Therefore, add a delay for all Logitech devices as it does not hurt.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Cc: <stable@vger.kernel.org> # 4.19.y, 5.4.y
Link: https://lore.kernel.org/r/20201117122803.24310-1-joakim.tjernlund@infinera.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes audio distortion on playback for the Allen&Heath
Qu-16.
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201104115717.GA19046@b4.vu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes audio distortion on playback for the Yamaha MODX.
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Tested-by: Frank Slotta <frank.slotta@posteo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201104120705.GA19126@b4.vu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Khadas audio devices ( USB_ID_VENDOR 0x3353 )
have DSD-capable implementations from XMOS
need add new usb vendor id for recognition
Signed-off-by: Artem Lapkin <art@khadas.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201103103311.5435-1-art@khadas.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Zoom UAC-2 USB audio interface provides an async playback endpoint
("1 OUT (ASYNC)") and capture endpoint ("2 IN (ASYNC)"), both with
2-channel S32_LE in 44.1, 48, 88.2, 96, 176.4, or 192
kilosamples/s. The device provides explicit feedback to adjust the
host's playback rate, but the feedback appears unstable and biased
relative to the device's capture rate.
"alsaloop -t 1000" experiences playback underruns and tries to
resample the captured audio to match the varying playback
rate. Forcing the kernel to use implicit feedback appears to
produce more stable results. This causes the host to transmit one
playback sample for each capture sample received. (Zoom North America
has been notified of this change.)
Signed-off-by: Keith Winstein <keithw@cs.stanford.edu>
Tested-by: Keith Winstein <keithw@cs.stanford.edu>
Cc: <stable@vger.kernel.org>
BugLink: https://lore.kernel.org/r/20201027071841.GA164525@trolley.csail.mit.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a few additional small and trivial fixes.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl+SkUgOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9ixA/9GMw908i3U2kzd3GcJNRZXZ6C1q9kJ/vbKI2u
4l7G7cQ+VI5Yqd+ac3Dq8oe1bwkNyUDFtHwVDM7XXxbD0tOOT5WcZWss8nMMuZpM
IRiYot0YpwV7QM80lB/YXHRLrUKT+3TG0RUgO0MO8ji6V4IkSbbhWVHp6B2qVLec
2H3fkxA5OLy4d0fiwZHzuZo4fGLo82fXvvmjy8ZStqluJt6etgArQU9fsJNqE085
RqQwlcfMvLhbyv5n9HAwt9aFa4PZoYdNdn0VHk6UiqKsdr5Vbob138lsDxVBvJbn
qcE5CjoCaes87PdtxO4vcA5ykuIeMXOXUTFN/vSemU1zHnjioEzpvKixT5E9oR3g
0AY2d5rZkTgcQnP9xyNJb2K6+NkEsu5OSWmg9OX2oU+Mvn+zazox0jGNIspoD1He
9sJVPFWVd2p0ObQ8sLCD8L22EUNYaJpNyOkDq6A/R9lzxjL4u1jyrvdt+jqsXiCW
jBVG+yDpqHij6GqQDiIA+dCr7ZAJuWUDIRlOU0R4I/UH9hdfuXvSEjhra1lU+1Ft
KTtMjfyhodSR2e4zSUItRIetKpDDwwdXiBhK0DjEHnZl0LfryFNWh7KPErFL7L9o
lWVHDmcRAsCx2PFJEJHpHONaUi6zyzcQ3UTYoDrzc5FEzbO+c7CyAtGJPsgzq9r5
PFZM4X8=
=sYVq
-----END PGP SIGNATURE-----
Merge tag 'sound-fix-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Just a few additional small and trivial fixes"
* tag 'sound-fix-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix the return value if cb func is already registered
ALSA: usb-audio: Line6 Pod Go interface requires static clock rate quirk
ALSA: hda/ca0132: make some const arrays static, makes object smaller
ALSA: sparc: dbri: fix repeated word 'the'
Recently released Line6 Pod Go requires static clock rate quirk to make
its usb audio interface working. Added its usb id to the list of similar
line6 devices.
Signed-off-by: Lukasz Halman <lukasz.halman@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201020061409.GA24382@TAG009442538903
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The amount of changes is smaller at this round (what a surprise),
but lots of activity is seen. Most of changes are about ASoC
driver development, especially Intel platforms.
Here are some highlights:
General:
* Replace all tasklet usages with other alternatives
* Cleanup of the ASoC error unwinding code
* Fixes for trivial issues caught by static checker
* Spell fixes allover the places
ALSA Core:
* Lockdep fix for control devices
* Fix for potential OSS sequencer mutex stalls
HD-audio and USB-audio:
* SoundBlaster AE-7 support
* Changes in quirk table for the rename handling
* Quirks for HP and ASUS machines, Pioneer DJ DJM-250MK2.
ASoC:
* Lots of updates for Intel SOF and SoundWire enablement
* Replacement of the DSP driver for some older x86 systems;
the new code was written from scratch, better maintenance
expected
* Helpers for parsing auxiluary devices from the device tree
* New support for AllWinner A64, Cirrus Logic CS4234, Mediatek
MT6359 Microchip S/PDIF TX and RX controllers, Realtek RT1015P,
and Texas Instruments J721E, TAS2110, TAS2564 and TAS2764
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl+HHD4OHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9eAw//Wgs9LfQE3rBcsGVNTHimW2cPzbdHVK1eth6N
pFT6rdEG2N+ALR0ESA26CSBniJocqxNvXYzaYT0fy+7tS/chOjhkfr6SttYPDmwc
q2u1SQIqdx41Q0DVUXYxSLVExjT4Rx96qeibLy5pi8DsbL0DOVa7PkVDl1XHXNJ0
iSZwA18gCRdezpoOCD+UF8EBplULjYfPp0xstqjaQzTCpJQ5C1xpbZdHWfhTWsKo
H98d4GL4yUUbJb5/Wi7uqiUGhPIxgBUMVkaY+uRifeNA/MGD5rUZQaf8ft6uQFUL
D5RCUksJiQfyrj++g9/mzOWVRCFZ6MvaAmEW4xwlPvTsP2uIVIqS5RH8Z2BhwjXr
J8/4gPuCtoEKbfsOOCOG9MlGsquf9LBeiH5KZ7gqb7ilu4tICR2zXtBr6U7e64Wd
LsPROQnr/+lxIlEJjlhiarf1jXMfo4glxuoLsDcIH+Baf0lTiMNoBVIZTUdJ0urq
Srh++Bk/WGvoVJe1PHp7IfhZCoBACozPXq7EifbnCsUM+cVtQtjWrydyi8k/Yona
5EfS5wQdEH6JvQirkmGJm8kNMu+e3hW2HzoJqV2Z2DUMMnCSra62KD0wPA/wRchu
mkC47875a+jgo58fq4bX9hzGi2CrE/TMYdii6I2bbAm/Mp7czXZfO0LOTWDc4Bs5
T8qt+HI=
=nWAp
-----END PGP SIGNATURE-----
Merge tag 'sound-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"The amount of changes is smaller at this round (what a surprise), but
lots of activity is seen. Most of changes are about ASoC driver
development, especially Intel platforms. Here are some highlights:
General:
- Replace all tasklet usages with other alternatives
- Cleanup of the ASoC error unwinding code
- Fixes for trivial issues caught by static checker
- Spell fixes allover the places
ALSA Core:
- Lockdep fix for control devices
- Fix for potential OSS sequencer mutex stalls
HD-audio and USB-audio:
- SoundBlaster AE-7 support
- Changes in quirk table for the rename handling
- Quirks for HP and ASUS machines, Pioneer DJ DJM-250MK2.
ASoC:
- Lots of updates for Intel SOF and SoundWire enablement
- Replacement of the DSP driver for some older x86 systems; the new
code was written from scratch, better maintenance expected
- Helpers for parsing auxiluary devices from the device tree
- New support for AllWinner A64, Cirrus Logic CS4234, Mediatek MT6359
Microchip S/PDIF TX and RX controllers, Realtek RT1015P, and Texas
Instruments J721E, TAS2110, TAS2564 and TAS2764"
* tag 'sound-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (498 commits)
ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close
ALSA: hda: fix jack detection with Realtek codecs when in D3
ALSA: fireworks: use semicolons rather than commas to separate statements
ALSA: hda: use semicolons rather than commas to separate statements
ALSA: hda/i915 - fix list corruption with concurrent probes
ASoC: dmaengine: Document support for TX only or RX only streams
ASoC: mchp-spdiftx: remove 'TX' from playback stream name
ASoC: ti: davinci-mcasp: Use &pdev->dev for early dev_warn
ASoC: tas2764: Add the driver for the TAS2764
dt-bindings: tas2764: Add the TAS2764 binding doc
ASoC: Intel: catpt: Add explicit DMADEVICES kconfig dependency
ASoC: Intel: catpt: Fix compilation when CONFIG_MODULES is disabled
ASoC: stm32: dfsdm: add actual resolution trace
ASoC: stm32: dfsdm: change rate limits
ASoC: qcom: sc7180: Add support for audio over DP
Asoc: qcom: lpass-platform : Increase buffer size
ASoC: qcom: Add support for lpass hdmi driver
Asoc: qcom: lpass:Update lpaif_dmactl members order
Asoc:qcom:lpass-cpu:Update dts property read API
ASoC: dt-bindings: Add dt binding for lpass hdmi
...
The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, and they can handle data off
of the stack, so move the driver over to using those calls instead,
saving some logic when dynamically allocating memory.
v2: API change of use usb_control_msg_send() and usb_control_msg_recv()
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-9-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200923134348.23862-13-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, so move the driver over to
using those calls instead, saving some logic in the wrapper functions
that were being used in this driver.
This also resolves a long-staging bug where data on the stack was being
sent in a USB control message, which was not allowed.
v2: API change of usb_control_msg_send()
Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-8-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200923134348.23862-11-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_control_msg_send() call can handle data on the stack, as well as
returning an error if a "short" write happens, so move the driver over
to using that call instead. This ends up removing a helper function
that is no longer needed.
v2: API change in usb_control_msg_send()
Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-7-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200923134348.23862-10-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch extends support for DJM-250MK2 and allows mapping
playback and capture channels to available sources.
Configures the card through USB commands.
Signed-off-by: František Kučera <franta-linux@frantovo.cz>
Link: https://lore.kernel.org/r/20200922144206.10472-1-konference@frantovo.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 34dedd2a83.
According to Realtek, volume FU works for line-in.
I can confirm volume control works after device firmware is updated.
Fixes: 34dedd2a83 ("ALSA: usb-audio: Disable Lenovo P620 Rear line-in volume control")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200915103925.12777-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A USB device will always haev a bi-directional endpoint 0, that's just
how the devices work, so no need to check for that in a few quirk tests
as it will always pass.
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Alexander Tsoy <alexander@tsoy.me>
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200914153756.3412156-12-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_control_msg_send() call can return an error if a "short" write
happens, so move the driver over to using that call instead.
Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-10-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, and they can handle data off
of the stack, so move the driver over to using those calls instead,
saving some logic when dynamically allocating memory.
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-9-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_control_msg_send() and usb_control_msg_recv() calls can return
an error if a "short" write/read happens, so move the driver over to
using those calls instead, saving some logic in the wrapper functions
that were being used in this driver.
This also resolves a long-staging bug where data on the stack was being
sent in a USB control message, which was not allowed.
Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-8-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_control_msg_send() call can handle data on the stack, as well as
returning an error if a "short" write happens, so move the driver over
to using that call instead. This ends up removing a helper function
that is no longer needed.
Cc: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-7-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
snd_usb_pipe_sanity_check() is a great function, so let's move it into
the USB core so that other parts of the kernel, including the USB core,
can call it.
Name it usb_pipe_type_check() to match the existing
usb_urb_ep_type_check() call, which now uses this function.
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Eli Billauer <eli.billauer@gmail.com>
Cc: Emiliano Ingrassia <ingrassia@epigenesys.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Alexander Tsoy <alexander@tsoy.me>
Cc: "Geoffrey D. Bennett" <g@b4.vu>
Cc: Jussi Laako <jussi@sonarnerd.net>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Dmitry Panchenko <dmitry@d-systems.ee>
Cc: Chris Wulff <crwulff@gmail.com>
Cc: Jesus Ramos <jesus-ramos@live.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200914153756.3412156-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In UA101 driver, a tasklet is still
used for handling the output URBs. It can be achieved gracefully with
a work queued in the high-prio system workqueue, too.
This patch replaces the tasklet usage in UA101 driver with a simple
work.
Link: https://lore.kernel.org/r/20200903104131.21097-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In USB-audio driver, a tasklet is
still used in MIDI interface code for handling the output byte
stream. It can be achieved gracefully with a work queued in the
high-prio system workqueue.
This patch replaces the tasklet usage in USB-audio driver with a
simple work.
Link: https://lore.kernel.org/r/20200903104131.21097-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Back-merge to apply the tasklet conversion patches that are based
on the already applied tasklet API changes on 5.9-rc4.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Link: https://lore.kernel.org/r/20200902040221.354941-11-allen.lkml@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Link: https://lore.kernel.org/r/20200902040221.354941-10-allen.lkml@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch extends support for DJM-250MK2 and allows recording.
However, DVS is not possible yet (see the comment in code).
Signed-off-by: František Kučera <franta-linux@frantovo.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200825153113.6352-1-konference@frantovo.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai