summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-12-11cpuidle: Add cpuidle.governor= command line parameterRafael J. Wysocki
Add cpuidle.governor= command line parameter to allow the default cpuidle governor to be replaced. That is useful, for example, if someone running a tickful kernel wants to use the menu governor on it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-11cpuidle: poll_state: Disregard disable idle statesRafael J. Wysocki
When computing the limit of time to spend in the loop in poll_idle(), use the target residency of the first enabled idle state deeper than state 0 instead of always using the target residency of state 1. This helps when state 1 is disabled for diagnostics, for instance. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-11OPP: Use opp_table->regulators to verify no regulator caseViresh Kumar
The value of opp_table->regulator_count is not very consistent right now and it may end up being 0 while we do have a "opp-microvolt" property in the OPP table. It was kept that way as we used to check if any regulators are set with the OPP core for a device or not using value of regulator_count. Lets use opp_table->regulators for that purpose as the meaning of regulator_count is going to change in the later patches. Reported-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-12-11Merge back staging AVS changes for v4.21.Rafael J. Wysocki
2018-12-11sched/cpufreq: Add the SPDX tagsDaniel Lezcano
The SPDX tags are not present in cpufreq.c and cpufreq_schedutil.c. Add them and remove the license descriptions Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-11x86/dump_pagetables: Fix LDT remap address markerKirill A. Shutemov
The LDT remap placement has been changed. It's now placed before the direct mapping in the kernel virtual address space for both paging modes. Change address markers order accordingly. Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: luto@kernel.org Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: jgross@suse.com Cc: bhe@redhat.com Cc: hans.van.kranenburg@mendix.com Cc: linux-mm@kvack.org Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20181130202328.65359-3-kirill.shutemov@linux.intel.com
2018-12-11x86/mm: Fix guard hole handlingKirill A. Shutemov
There is a guard hole at the beginning of the kernel address space, also used by hypervisors. It occupies 16 PGD entries. This reserved range is not defined explicitely, it is calculated relative to other entities: direct mapping and user space ranges. The calculation got broken by recent changes of the kernel memory layout: LDT remap range is now mapped before direct mapping and makes the calculation invalid. The breakage leads to crash on Xen dom0 boot[1]. Define the reserved range explicitely. It's part of kernel ABI (hypervisors expect it to be stable) and must not depend on changes in the rest of kernel memory layout. [1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") Reported-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: luto@kernel.org Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: bhe@redhat.com Cc: linux-mm@kvack.org Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shutemov@linux.intel.com
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>
generated by cgit (git 2.34.1) at 2025-09-22 12:12:29 +0000