Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 8月, 2020 16 次提交
  3. 19 8月, 2020 1 次提交
  5. 17 8月, 2020 1 次提交
  7. 14 8月, 2020 1 次提交
  9. 12 8月, 2020 2 次提交
  11. 11 8月, 2020 1 次提交
  13. 10 8月, 2020 1 次提交
  15. 07 8月, 2020 1 次提交
  17. 06 8月, 2020 1 次提交
  19. 05 8月, 2020 3 次提交
    • M
      ALSA: hda/tegra: Add 100us dma stop delay · ed4d0a4a
      由 Mohan Kumar 提交于 
      Tegra HDA has audio data buffer for upto tens of frames, this buffer
can help to avoid underflow. HW will keep issuing new data fetch
request when buffers are not full and current BDL is not done. When SW
disable DMA RUN bit for a stream, HW can't cancel the already issued data
fetch request and hence it can't stop DMA. HW has to wait for all issued
data fetch request get data returned before it stops DMA.

This HW behavior is not in sync with HDA spec which says DMA RUN bit
should be cleared within 1 audio frame. For Tegra, DMA RUN bit was
active for more than one audio frame, due to this the timeout in
snd_hdac_stream_sync function is not helping. When Stream reset set
and clear happens during DMA RUN bit active state it results in Memory
Decode error.

Unfortunately, there is no way to detect when these data accesses have
completed, but testing has shown that a 100us delay between Stream reset
set and clear operation for Tegra avoids the memory decode error.
Therefore, adding a 100us dma stop delay.
Signed-off-by: NMohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20200805095221.5476-4-mkumard@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      ed4d0a4a
    • M
      ASoC: hda/tegra: Set buffer alignment to 128 bytes · 6c17e9dd
      由 Mohan Kumar 提交于 
      Set chip->align_buffer_size to 1 for Tegra platforms to make the buffer
alignment to be multiple of 128 bytes. This fix is applied as gstreamer
alsasink gets stuck with the default buffer-time and latency-time
parameters with 4 byte buffer alignment.
Signed-off-by: NMohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20200805095221.5476-2-mkumard@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      6c17e9dd
    • K
      ALSA: hda/hdmi: Add quirk to force connectivity · cd72c317
      由 Kai-Heng Feng 提交于 
      HDMI on some platforms doesn't enable audio support because its Port
Connectivity [31:30] is set to AC_JACK_PORT_NONE:
Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0b000094: OUT Detect HBR HDMI DP
  Pin Default 0x58560010: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Devices: 0
  Connection: 3
     0x02 0x03* 0x04

For now, use a quirk to force connectivity based on SSID. If there are
more platforms affected by the same issue, we can eye for a more generic
solution.
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200804155836.16252-1-kai.heng.feng@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      cd72c317
  21. 03 8月, 2020 4 次提交
  23. 02 8月, 2020 1 次提交
  25. 30 7月, 2020 1 次提交
  27. 29 7月, 2020 1 次提交
  29. 28 7月, 2020 2 次提交
    • T
      ALSA: hda/hdmi: Fix keep_power assignment for non-component devices · c2c3657f
      由 Takashi Iwai 提交于 
      It's been reported that, when neither nouveau nor Nvidia graphics
driver is used, the screen starts flickering.  And, after comparing
between the working case (stable 4.4.x) and the broken case, it turned
out that the problem comes from the audio component binding.  The
Nvidia and AMD audio binding code clears the bus->keep_power flag
whenever snd_hdac_acomp_init() succeeds.  But this doesn't mean that
the component is actually bound, but it merely indicates that it's
ready for binding.  So, when both nouveau and Nvidia are blacklisted
or not ready, the driver keeps running without the audio component but
also with bus->keep_power = false.  This made the driver runtime PM
kicked in and powering down when unused, which results in flickering
in the graphics side, as it seems.

For fixing the bug, this patch moves the bus->keep_power flag change
into generic_acomp_notifier_set() that is the function called from the
master_bind callback of component ops; i.e. it's guaranteed that the
binding succeeded.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208609
Fixes: 5a858e79 ("ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728082033.23933-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      c2c3657f
    • T
      ALSA: hda: Workaround for spurious wakeups on some Intel platforms · a6630529
      由 Takashi Iwai 提交于 
      We've received a regression report on Intel HD-audio controller that
wakes up immediately after S3 suspend.  The bisection leads to the
commit c4c8dd6e ("ALSA: hda: Skip controller resume if not
needed").  This commit replaces the system-suspend to use
pm_runtime_force_suspend() instead of the direct call of
__azx_runtime_suspend().  However, by some really mysterious reason,
pm_runtime_force_suspend() causes a spurious wakeup (although it calls
the same __azx_runtime_suspend() internally).

As an ugly workaround for now, revert the behavior to call
__azx_runtime_suspend() and __azx_runtime_resume() for those old Intel
platforms that may exhibit such a problem, while keeping the new
standard pm_runtime_force_suspend() and pm_runtime_force_resume()
pair for the remaining chips.

Fixes: c4c8dd6e ("ALSA: hda: Skip controller resume if not needed")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208649
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200727164443.4233-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      a6630529
  31. 27 7月, 2020 1 次提交
  33. 25 7月, 2020 2 次提交