summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-12-11Merge branch 'for-next' of ↵Rafael J. Wysocki
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq Pull devfreq framework changes for v4.21 from MyungJoo Ham: "This includes the suspend-frequency support for devfreq, which is similar with suspend_freq in cpufreq." * 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq: PM / devfreq: add devfreq_suspend/resume() functions PM / devfreq: add support for suspend/resume of a devfreq device PM / devfreq: refactor set_target frequency function
2018-12-11ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_doneYueHaibing
gcc warning this: drivers/net/ieee802154/ca8210.c:730:10: warning: comparison is always false due to limited range of data type [-Wtype-limits] 'len' is u8 type, we get it from buf[1] adding 2, which can overflow. This patch change the type of 'len' to unsigned int to avoid this,also fix the gcc warning. Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
2018-12-11ALSA: hda/ca0132 - make pci_iounmap() call conditionalArnd Bergmann
When building without CONFIG_PCI, we can (depending on the architecture) get a link failure: ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined! Adding a compile-time check for PCI gets it to work correctly on 32-bit ARM. Fixes: d99501b8575d ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11ALSA: hda/hdmi: Always set display_power_control for Intel HSW+ codecsTakashi Iwai
We've excluded the display_power_control flag for Intel HSW and BDW codecs as the HD-audio controllers of the corresponding platforms take care of the display power as well. But the recent refactoring separates the controller and the codec power accounting, so it's fine to call the display PM even for HSW/BDW codecs. This is less confusing since we can avoid this well-hidden condition. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11ASoC: hdac_hdmi: Add missing display power-off at driver removalTakashi Iwai
The display power is in unbalance at removing the driver since it misses the snd_hdac_display_power(OFF) call. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11ALSA: hda: Make snd_hdac_display_power() void functionTakashi Iwai
After the recent refactoring, snd_hdac_display_power() doesn't return any error, hence it can be defined to return void. This makes many error checks redundant and allows us to reduce them gracefully. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11ALSA: hda/intel: Properly free the display power at error pathTakashi Iwai
When an error occurs in azx_probe_continue(), we should release the display power. However, the current code ignores it and releases the display power only for HSW/BDW cases. Fix it. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11ALSA: hda/intel: Drop superfluous AZX_DCAPS_I915_POWERWELL checksTakashi Iwai
snd_hdac_display_power() can be called even for a HDA controller without DRM binding. The same is true for other helpers, snd_hdac_i915_set_bclk() and snd_hdac_set_codec_wakeup(). So all superfluous AZX_DCAPS_I915_POWERWELL checks in hda_intel.c can be dropped, and the definition of AZX_DCAPS_I915_POWERWELL itself can be removed as well. This simplifies the code a lot. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11ALSA: hda: Refactor display power managementTakashi Iwai
The current HD-audio code manages the DRM audio power via too complex redirections, and this seems even still unbalanced in a corner case as Intel DRM CI has been intermittently reporting. This patch is a big surgery for addressing the complexity and the possible unbalance. Basically the patch changes the display PM in the following ways: - Both HD-audio controller and codec drivers call a single helper, snd_hdac_display_power(). (Formerly, the display power control from a codec was done indirectly via link_power bus ops.) - snd_hdac_display_power() receives the codec address index. For turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER. - snd_hdac_display_power() doesn't manage refcounts any longer, but keeps the power status in bitmap. If any of controller or codecs is turned on, the function updates the DRM power state via get_power() or put_power(). Also this refactor allows us more cleanup: - The link_power bus ops is dropped, so there is no longer indirect management, as mentioned in the above. - hdac_device link_power_control flag is moved to hda_codec display_power_control flag, as it's only for HDA legacy. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11drm/nouveau/ce/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/disp/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/dma/tu106: initial supportBen Skeggs
Appears to be compatible with GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/therm/tu106: initial supportBen Skeggs
Appears to be compatible with GP100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/pmu/tu106: initial supportBen Skeggs
Appears to be compatible with GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fault/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/bar/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/mmu/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/ltc/tu106: initial supportBen Skeggs
Appears to be compatible with GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fb/tu106: initial supportBen Skeggs
Appears to be compatible with GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/imem/tu106: initial supportBen Skeggs
Appears to be compatible with NV50. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/tmr/tu106: initial supportBen Skeggs
Appears to be compatible with GK20A. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/bus/tu106: initial supportBen Skeggs
Appears to be compatible with GF100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/mc/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fuse/tu106: initial supportBen Skeggs
Appears to be compatible with GM107. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/i2c/tu106: initial supportBen Skeggs
Appears to be compatible with GM200. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/gpio/tu106: initial supportBen Skeggs
Appears to be compatible with GK104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/ibus/tu106: initial supportBen Skeggs
Appears to be compatible with GM200. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/top/tu106: initial supportBen Skeggs
Appears to be compatible with GK104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/devinit/tu106: initial supportBen Skeggs
Appears to be compatible with TU104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/bios/tu106: initial supportBen Skeggs
No real surprised here so far. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/pci/tu106: initial supportBen Skeggs
Appears to be compatible with GP100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/core: recognise TU106Ben Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/core: increase maximum number of nvdec instances to 3Ben Skeggs
RTX2070 appears to have 3 copies of the engine. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/kms/tu104: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/ce/tu104: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/tu104: initial supportBen Skeggs
Various different bits and pieces vs GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/disp/tu104: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/dma/tu104: initial supportBen Skeggs
Appears to be compatible with GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/therm/tu104: initial supportBen Skeggs
Appears to be compatible with GP100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/pmu/tu104: initial supportBen Skeggs
Appears to be compatible with GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fault/tu104: initial supportBen Skeggs
New registers. Currently uncertain how exactly to mask fault buffer interrupts. This will likely be corrected at around the same time as the new MC interrupt stuff has been properly figured out and implemented. For the moment, it shouldn't matter too much. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/bar/tu104: initial supportBen Skeggs
New registers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/mmu/tu104: initial supportBen Skeggs
New flush method. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/ltc/tu104: initial supportBen Skeggs
Appears to be compatible with GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fb/tu104: initial supportBen Skeggs
Appears to be compatible with GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/imem/tu104: initial supportBen Skeggs
Appears to be compatible with NV50. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/tmr/tu104: initial supportBen Skeggs
Appears to be compatible with GK20A. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/bus/tu104: initial supportBen Skeggs
Appears to be compatible with GF100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/mc/tu104: initial supportBen Skeggs
Things are a bit different here on Turing, and will require further changes yet once I've investigated them more thoroughly. For now though, the existing GP100 code is compatible enough with one small hack to forward on fault buffer interrupts. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-13 16:01:57 +0000