Skip to content

L
linux
Switch branch/tag
  1. 28 Oct, 2019 2 commits
  3. 26 Oct, 2019 1 commit
  5. 25 Oct, 2019 1 commit
  7. 24 Oct, 2019 3 commits
  9. 23 Oct, 2019 3 commits
  11. 22 Oct, 2019 1 commit
  13. 21 Oct, 2019 5 commits
  15. 19 Oct, 2019 6 commits
  17. 18 Oct, 2019 16 commits
  19. 17 Oct, 2019 2 commits
    • Lukas Wunner's avatar
      ALSA: hda - Force runtime PM on Nvidia HDMI codecs · 94989e31
      Lukas Wunner authored 
      Przemysław Kopa reports that since commit b516ea58 ("PCI: Enable
NVIDIA HDA controllers"), the discrete GPU Nvidia GeForce GT 540M on his
2011 Samsung laptop refuses to runtime suspend, resulting in a power
regression and excessive heat.

Rivera Valdez witnesses the same issue with a GeForce GT 525M (GF108M)
of the same era, as does another Arch Linux user named "R0AR" with a
more recent GeForce GTX 1050 Ti (GP107M).

The commit exposes the discrete GPU's HDA controller and all four codecs
on the controller do not set the CLKSTOP and EPSS bits in the Supported
Power States Response.  They also do not set the PS-ClkStopOk bit in the
Get Power State Response.  hda_codec_runtime_suspend() therefore does
not call snd_hdac_codec_link_down(), which prevents each codec and the
PCI device from runtime suspending.

The same issue is present on some AMD discrete GPUs and we addressed it
by forcing runtime PM despite the bits not being set, see commit
57cb54e5 ("ALSA: hda - Force to link down at runtime suspend on
ATI/AMD HDMI").

Do the same for Nvidia HDMI codecs.

Fixes: b516ea58 ("PCI: Enable NVIDIA HDA controllers")
Link: https://bbs.archlinux.org/viewtopic.php?pid=1865512
Link: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c81Reported-by: default avatarPrzemysław Kopa <prymoo@gmail.com>
Reported-by: default avatarRivera Valdez <riveravaldez@ysinembargo.com>
Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
Cc: Daniel Drake <dan@reactivated.net>
Cc: stable@vger.kernel.org # v5.3+
Link: https://lore.kernel.org/r/3086bc75135c1e3567c5bc4f3cc4ff5cbf7a56c2.1571324194.git.lukas@wunner.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      94989e31
    • Takashi Sakamoto's avatar
      ALSA: fireface: use the same size of period for PCM substreams in AMDTP streams · 3aac3263
      Takashi Sakamoto authored 
      In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.

The number of PCM substreams on AMDTP streams in domain is recorded in
own structure. Usage of this count is an alternative of the above check.
This is better because the count is incremented in pcm.hw_params earlier
than pcm.trigger.

This commit replaces the check with the substream count and the value for
the size of PCM period. Unlike the other drivers in ALSA firewire stack,
no MIDI substream is multiplexed into AMDTP stream.

I note that Fireface AMDTP protocol has a quirk that tx stream includes
blank isochronous cycle. The packet for blank cycle is equivalent to
empty or NODATA packet in IEC 61883-6, thus the protocol is similar to
blocking transmission method of IEC 61883-6. On the other hand, rx
stream adopts non-blocking transmission method. Although the difference
of transmission method between tx/rx streams precisely brings different
timing for a certain amount of events due to their different calculation
for data blocks per packet, it's possible to approximate enough amount
of events mostly has the same timing. Actually current ALSA IEC 61883-1/6
engine uses large amount of data blocks for each hardware IRQ
(=16 packets).
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-18-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3aac3263
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7