Skip to content

L
linux
Switch branch/tag
  1. 15 Oct, 2021 1 commit
  3. 14 Oct, 2021 7 commits
  5. 12 Oct, 2021 4 commits
    • Jonas Hahnfeld's avatar
      ALSA: usb-audio: Add quirk for VF0770 · 48827e1d
      Jonas Hahnfeld authored 
      The device advertises 8 formats, but only a rate of 48kHz is honored
by the hardware and 24 bits give chopped audio, so only report the
one working combination. This fixes out-of-the-box audio experience
with PipeWire which otherwise attempts to choose S24_3LE (while
PulseAudio defaulted to S16_LE).
Signed-off-by: default avatarJonas Hahnfeld <hahnjo@hahnjo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      48827e1d
    • Kai Vehmanen's avatar
      ALSA: hda: avoid write to STATESTS if controller is in reset · b37a1518
      Kai Vehmanen authored 
      The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
before performing controller reset. This code dates back to an old
bugfix in commit e8a7f136 ("[ALSA] hda-intel - Improve HD-audio
codec probing robustness"). Originally the code was added to
azx_reset().

The code was moved around in commit a41d1224 ("ALSA: hda - Embed bus
into controller object") and ended up to snd_hdac_bus_reset_link() and
called primarily via snd_hdac_bus_init_chip().

The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
called when controller is not in reset. In this case, STATESTS can be
cleared. This can be useful e.g. when forcing a controller reset to retry
codec probe. A normal non-power-on reset will not clear the bits.

However, this old logic is problematic when controller is already in
reset. The HDA specification states that controller must be taken out of
reset before writing to registers other than GCTL.CRST (1.0a spec,
3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
if the controller is already in reset per the HDA specification mentioned.

This has been harmless on older hardware. On newer generation of Intel
PCIe based HDA controllers, if configured to report issues, this write
will emit an unsupported request error. If ACPI Platform Error Interface
(APEI) is enabled in kernel, this will end up to kernel log.

Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
the function is called when controller is not in reset. Otherwise
clearing the bits is not possible and should be skipped.
Signed-off-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211012142935.3731820-1-kai.vehmanen@linux.intel.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b37a1518
    • Takashi Iwai's avatar
      ALSA: usb-audio: Less restriction for low-latency playback mode · 53451b6d
      Takashi Iwai authored 
      The recent support for the improved low-latency playback mode applied
the SNDRV_PCM_INFO_EXPLICIT_SYNC flag for the target streams, but this
was a slight overkill.  The use of the flag above disables effectively
both PCM status and control mmaps, while basically what we want to
track is only about the appl_ptr update.

For less restriction, use a more proper flag,
SNDRV_PCM_INFO_SYNC_APPLPTR instead, which disables only the control
mmap.

Fixes: d5f871f8 ("ALSA: usb-audio: Improved lowlatency playback support")
Link: https://lore.kernel.org/r/20211011103650.10182-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      53451b6d
    • Hui Wang's avatar
      ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW · a3fd1a98
      Hui Wang authored 
      We need to define the codec pin 0x1b to be the mic, but somehow
the mic doesn't support hot plugging detection, and Windows also has
this issue, so we set it to phantom headset-mic.

Also the determine_headset_type() often returns the omtp type by a
mistake when we plug a ctia headset, this makes the mic can't record
sound at all. Because most of the headset are ctia type nowadays and
some machines have the fixed ctia type audio jack, it is possible this
machine has the fixed ctia jack too. Here we set this mic jack to
fixed ctia type, this could avoid the mic type detection mistake and
make the ctia headset work stable.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537Reported-and-tested-by: default avatarmsd <msd.mmq@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a3fd1a98
  7. 11 Oct, 2021 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl · 228af5a4
      Takashi Iwai authored 
      Michael Forney reported an incorrect padding type that was defined in
the commit 80fe7430 ("ALSA: add new 32-bit layout for
snd_pcm_mmap_status/control") for PCM control mmap data.
His analysis is correct, and this caused the misplacements of PCM
control data on 32bit arch and 32bit compat mode.

The bug is that the __pad2 definition in __snd_pcm_mmap_control64
struct was wrongly with __pad_before_uframe, which should have been
__pad_after_uframe instead.  This struct is used in SYNC_PTR ioctl and
control mmap.  Basically this bug leads to two problems:

- The offset of avail_min field becomes wrong, it's placed right after
  appl_ptr without padding on little-endian

- When appl_ptr and avail_min are read as 64bit values in kernel side,
  the values become either zero or corrupted (mixed up)

One good news is that, because both user-space and kernel
misunderstand the wrong offset, at least, 32bit application running on
32bit kernel works as is.  Also, 64bit applications are unaffected
because the padding size is zero.  The remaining problem is the 32bit
compat mode; as mentioned in the above, avail_min is placed right
after appl_ptr on little-endian archs, 64bit kernel reads bogus values
for appl_ptr updates, which may lead to streaming bugs like jumping,
XRUN or whatever unexpected.
(However, we haven't heard any serious bug reports due to this over
years, so practically seen, it's fairly safe to assume that the impact
by this bug is limited.)

Ideally speaking, we should correct the wrong mmap status control
definition.  But this would cause again incompatibility with the
existing binaries, and fixing it (e.g. by renumbering ioctls) would be
really messy.

So, as of this patch, we only correct the behavior of 32bit compat
mode and keep the rest as is.  Namely, the SYNC_PTR ioctl is now
handled differently in compat mode to read/write the 32bit values at
the right offsets.  The control mmap of 32bit apps on 64bit kernels
has been already disabled (which is likely rather an overlook, but
this worked fine at this time :), so covering SYNC_PTR ioctl should
suffice as a fallback.

Fixes: 80fe7430 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
Reported-by: default avatarMichael Forney <mforney@mforney.org>
Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org>
Cc: Rich Felker <dalias@libc.org>
Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      228af5a4
    • Cameron Berkenpas's avatar
      ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2 · 023a062f
      Cameron Berkenpas authored 
      The previous patch's HDA verb initialization for the Lenovo 13s
sequence was slightly off. This updated verb sequence has been tested
and confirmed working.

Fixes: ad7cc2d4 ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarCameron Berkenpas <cam@neo-zeon.de>
Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      023a062f
  9. 10 Oct, 2021 1 commit
  11. 07 Oct, 2021 3 commits
  13. 06 Oct, 2021 1 commit
  15. 05 Oct, 2021 2 commits
  17. 04 Oct, 2021 2 commits
  19. 01 Oct, 2021 3 commits
  21. 30 Sep, 2021 14 commits
    • Takashi Iwai's avatar
      ALSA: seq: Fix a potential UAF by wrong private_free call order · 1f8763c5
      Takashi Iwai authored 
      John Keeping reported and posted a patch for a potential UAF in
rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be
called after the associated rawmidi object got already freed.
After a deeper look, it turned out that the bug is rather the
incorrect private_free call order for a snd_seq_device.  The
snd_seq_device private_free gets called at the release callback of the
sequencer device object, while this was rather expected to be executed
at the snd_device call chains that runs at the beginning of the whole
card-free procedure.  It's been broken since the rewrite of
sequencer-device binding (although it hasn't surfaced because the
sequencer device release happens usually right along with the card
device release).

This patch corrects the private_free call to be done in the right
place, at snd_seq_device_dev_free().

Fixes: 7c37ae5c ("ALSA: seq: Rewrite sequencer device binding with standard bus")
Reported-and-tested-by: default avatarJohn Keeping <john@metanate.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1f8763c5
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid killing in-flight URBs during draining · 813a17ca
      Takashi Iwai authored 
      While draining a stream, ALSA PCM core stops the stream by issuing
snd_pcm_stop() after all data has been sent out.  And, at PCM trigger
stop, currently USB-audio driver kills the in-flight URBs explicitly,
then at sync-stop ops, sync with the finish of all remaining URBs.
This might result in a drop of the drained samples as most of
USB-audio devices / hosts allow relatively long in-flight samples (as
a sort of FIFO).

For avoiding the trimming, this patch changes the stream-stop behavior
during PCM draining state.  Under that condition, the pending URBs
won't be killed.  The leftover in-flight URBs are caught by the
sync-stop operation that shall be performed after the trigger-stop
operation.

Link: https://lore.kernel.org/r/20210929080844.11583-10-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      813a17ca
    • Takashi Iwai's avatar
      ALSA: usb-audio: Improved lowlatency playback support · d5f871f8
      Takashi Iwai authored 
      This is another attempt to improve further the handling of playback
stream in the low latency mode.  The latest workaround in commit
4267c5a8 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily.  In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.

Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode.  The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold.  The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs.  In the complete
callback, we try to fill the data and submit as much as possible
again.  When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition.  In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.

The following things are changed to achieve the behavior above:

* The endpoint prepare callback is changed to return an error code;
  when there is no enough data available, it may return -EAGAIN.
  Currently only prepare_playback_urb() returns the error.

  The evaluation of the available data is a bit messy here; we can't
  check with snd_pcm_avail() at the point of prepare callback (as
  runtime->status->hwptr hasn't been updated yet), hence we manually
  estimate the appl_ptr and compare with the internal hwptr_done to
  calculate the available frames.

* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
  callback returns -EAGAIN, and puts the remaining URBs to the ready
  list for the later submission.

* snd_complete_urb() treats the URBs in the low-latency mode similarly
  like the implicit feedback mode, and submissions are done in
  (now exported) snd_usb_queue_pending_output_urbs().

* snd_usb_queue_pending_output_urbs() again checks the error value
  from the prepare callback.  If it's -EAGAIN for the normal stream
  (i.e. not implicit feedback mode), we push it back to the ready list
  again.

* PCM ack callback is introduced for the playback stream, and it calls
  snd_usb_queue_pending_output_urbs() if there is no in-flight URB
  while the stream is running.  This corresponds to the case where the
  system needs the appl_ptr update for re-submitting a new URB.

* snd_usb_queue_pending_output_urbs() and the prepare EP callback
  receive in_stream_lock argument, which is a bool flag indicating the
  call path from PCM ack.  It's needed for avoiding the deadlock of
  snd_pcm_period_elapsed() calls.

* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
  low-latency mode is deployed.  This assures catching each applptr
  update even in the mmap mode.

Fixes: 4267c5a8 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d5f871f8
    • Takashi Iwai's avatar
      ALSA: usb-audio: Add spinlock to stop_urbs() · 0ef74366
      Takashi Iwai authored 
      In theory, stop_urbs() may be called concurrently.
Although we have the state check beforehand, it's safer to apply
ep->lock during the critical list head manipulations.

Link: https://lore.kernel.org/r/20210929080844.11583-8-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0ef74366
    • Takashi Iwai's avatar
      ALSA: usb-audio: Check available frames for the next packet size · d215f63d
      Takashi Iwai authored 
      This is yet more preparation for the upcoming changes.

Extend snd_usb_endpoint_next_packet_size() to check the available
frames and return -EAGAIN if the next packet size is equal or exceeds
the given size.  This will be needed for avoiding XRUN during the low
latency operation.

As of this patch, avail=0 is passed, i.e. the check is skipped and no
behavior change.

Link: https://lore.kernel.org/r/20210929080844.11583-7-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d215f63d
    • Takashi Iwai's avatar
      ALSA: usb-audio: Disable low-latency mode for implicit feedback sync · bceee753
      Takashi Iwai authored 
      When a playback stream runs in the implicit feedback mode, its
operation is passive and won't start unless the capture packet is
received.  This behavior contradicts with the low-latency playback
mode, and we should turn off lowlatency_playback flag accordingly.

In theory, we may take the low-latency mode when the playback-first
quirk is set, but it still conflicts with the later operation with the
fixed packet numbers, so it's disabled all together for now.

Link: https://lore.kernel.org/r/20210929080844.11583-6-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bceee753
    • Takashi Iwai's avatar
      ALSA: usb-audio: Disable low-latency playback for free-wheel mode · e581f1ce
      Takashi Iwai authored 
      The free-wheel stream operation like dmix may not update the appl_ptr
appropriately, and it doesn't fit with the low-latency playback mode.
Disable the low-latency playback operation when the stream is set up
in such a mode.

Link: https://lore.kernel.org/r/20210929080844.11583-5-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e581f1ce
    • Takashi Iwai's avatar
      ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playback · 9c9a3b9d
      Takashi Iwai authored 
      This is a preparation patch for the upcoming low-latency improvement
changes.

Rename early_playback_start flag with lowlatency_playback as it's more
intuitive.  The new flag is basically a reverse meaning.

Along with the rename, factor out the code to set the flag to a
function.  This makes the complex condition checks simpler.

Also, the same flag is introduced to snd_usb_endpoint, too, that is
carried from the snd_usb_substream flag.  Currently the endpoint flag
isn't still referred, but will be used in later patches.

Link: https://lore.kernel.org/r/20210929080844.11583-4-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9c9a3b9d
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix possible race at sync of urb completions · 86a42ad0
      Takashi Iwai authored 
      USB-audio driver tries to sync with the clear of all pending URBs in
wait_clear_urbs(), and it waits for all bits in active_mask getting
cleared.  This works fine for the normal operations, but when a stream
is managed in the implicit feedback mode, there is still a very thin
race window: namely, in snd_complete_usb(), the active_mask bit for
the current URB is once cleared before re-submitted in
queue_pending_output_urbs().  If wait_clear_urbs() is called during
that period, it may pass the test and go forward even though there may
be a still pending URB.

For covering it, this patch adds a new counter to each endpoint to
keep the number of in-flight URBs, and changes wait_clear_urbs()
checking this number instead.  The counter is decremented at the end
of URB complete, hence the reference is kept as long as the URB
complete is in process.

Link: https://lore.kernel.org/r/20210929080844.11583-3-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      86a42ad0
    • Takashi Iwai's avatar
      ALSA: usb-audio: Restrict rates for the shared clocks · 4e7cf1fb
      Takashi Iwai authored 
      When a single clock source is shared among several endpoints, we have
to keep the same rate on all active endpoints as long as the clock is
being used.  For dealing with such a case, this patch adds one more
check in the hw params constraint for the rate to take the shared
clocks into account.  The current rate is evaluated from the endpoint
list that applies the same clock source.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190418
Link: https://lore.kernel.org/r/20210929080844.11583-2-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4e7cf1fb
    • John Liu's avatar
      ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop · eb676622
      John Liu authored 
      The Dell Precision 5560 laptop appears to use the 4-speakers-on-ALC289
audio just like its sibling product XPS 9510, so it requires the same
quirk to enable woofer output. Tested on my Dell Precision 5560.
Signed-off-by: default avatarJohn Liu <johnliu55tw@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930115316.659-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      eb676622
    • Takashi Iwai's avatar
      ALSA: hda: Use position buffer for SKL+ again · c4ca3871
      Takashi Iwai authored 
      The commit f87e7f25 ("ALSA: hda - Improved position reporting on
SKL+") changed the PCM position report for SKL+ chips to use DPIB, but
according to Pierre, DPIB is no best choice for the accurate position
reports and it often reports too early.  The recommended method is
rather the classical position buffer.

This patch makes the PCM position reporting on SKL+ back to the
position buffer again.

Fixes: f87e7f25 ("ALSA: hda - Improved position reporting on SKL+")
Suggested-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210929072934.6809-3-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c4ca3871
    • Takashi Iwai's avatar
      ALSA: hda: Reduce udelay() at SKL+ position reporting · 46243b85
      Takashi Iwai authored 
      The position reporting on Intel Skylake and later chips via
azx_get_pos_skl() contains a udelay(20) call for the capture streams.
A call for this alone doesn't sound too harmful.  However, as the
pointer PCM ops is one of the hottest path in the PCM operations --
especially for the timer-scheduled operations like PulseAudio -- such
a delay hogs CPU usage significantly in the total performance.

The code there was taken from the original code in ASoC SST Skylake
driver blindly.  The udelay() is a workaround for the case where the
reported position is behind the period boundary at the timing
triggered from interrupts; applications often expect that the full
data is available for the whole period when returned (and also that's
the definition of the ALSA PCM period).

OTOH, HD-audio (legacy) driver has already some workarounds for the
delayed position reporting due to its relatively large FIFO, such as
the BDL position adjustment and the delayed period-elapsed call in the
work.  That said, the udelay() is almost superfluous for HD-audio
driver unlike SST, and we can drop the udelay().

Though, the current code doesn't guarantee the full period readiness
as mentioned in the above, but rather it checks the wallclock and
detects the unexpected jump.  That's one missing piece, and the drop
of udelay() needs a bit more sanity checks for the delayed handling.

This patch implements those: the drop of udelay() call in
azx_get_pos_skl() and the more proper check of hwptr in
azx_position_ok().  The latter change is applied only for the case
where the stream is running in the normal mode without
no_period_wakeup flag.  When no_period_wakeup is set, it essentially
ignores the period handling and rather concentrates only on the
current position; which implies that we don't need to care about the
period boundary at all.

Fixes: f87e7f25 ("ALSA: hda - Improved position reporting on SKL+")
Reported-by: default avatarJens Axboe <axboe@kernel.dk>
Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210929072934.6809-2-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      46243b85
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer · 8ec59ac3
      Takashi Iwai authored 
      The check of the returned error code is missing in
scarlett2_update_monitor_other().  Let's fix it.

Fixes: d5bda7e0 ("ALSA: usb-audio: scarlett2: Add support for the talkback feature")
Reported-by: default avatarkernel test robot <lkp@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/202109131831.9IodEzRx-lkp@intel.com
Link: https://lore.kernel.org/r/20210929073540.9611-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8ec59ac3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7