- Mar 16, 2018
-
-
Karol Herbst authored
Fixes: 3c66c87d ("drm/nouveau/disp: remove hw-specific customisation of output paths") Suggested-by:
Ben Skeggs <skeggsb@redhat.com> Signed-off-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lukas Wunner authored
Unbinding nouveau on a dual GPU MacBook Pro oopses because we iterate over the bl_connectors list in nouveau_backlight_exit() but skipped initializing it in nouveau_backlight_init(). Stacktrace for posterity: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: nouveau_backlight_exit+0x2b/0x70 [nouveau] nouveau_display_destroy+0x29/0x80 [nouveau] nouveau_drm_unload+0x65/0xe0 [nouveau] drm_dev_unregister+0x3c/0xe0 [drm] drm_put_dev+0x2e/0x60 [drm] nouveau_drm_device_remove+0x47/0x70 [nouveau] pci_device_remove+0x36/0xb0 device_release_driver_internal+0x157/0x220 driver_detach+0x39/0x70 bus_remove_driver+0x51/0xd0 pci_unregister_driver+0x2a/0xa0 nouveau_drm_exit+0x15/0xfb0 [nouveau] SyS_delete_module+0x18c/0x290 system_call_fast_compare_end+0xc/0x6f Fixes: b53ac1ee ("drm/nouveau/bl: Do not register interface if Apple GMUX detected") Cc: stable@vger.kernel.org # v4.10+ Cc: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Māris Nartišs authored
Commit 7110c89bb8852ff8b0f88ce05b332b3fe22bd11e ("mmu: swap out round for ALIGN") replaced two calls to round/rounddown with ALIGN/ALIGN_DOWN, but erroneously applied ALIGN_DOWN to a different variable (addr) and left intended variable (tail) not rounded/ALIGNed. As a result screen corruption, X lockups are observable. An example of kernel log of affected system with NV98 card where it was bisected: nouveau 0000:01:00.0: gr: TRAP_M2MF 00000002 [IN] nouveau 0000:01:00.0: gr: TRAP_M2MF 00320951 400007c0 00000000 04000000 nouveau 0000:01:00.0: gr: 00200000 [] ch 1 [000fbbe000 DRM] subc 4 class 5039 mthd 0100 data 00000000 nouveau 0000:01:00.0: fb: trapped read at 0040000000 on channel 1 [0fbbe000 DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] reason 00000006 [NULL_DMAOBJ] Fixes bug 105173 ("[MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15") https://bugs.freedesktop.org/show_bug.cgi?id=105173 Fixes: 7110c89bb885 ("mmu: swap out round for ALIGN ") Tested-by:
Pierre Moreau <pierre.morrow@free.fr> Reviewed-by:
Pierre Moreau <pierre.morrow@free.fr> Signed-off-by:
Maris Nartiss <maris.nartiss@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org # v4.15+
-
- Feb 16, 2018
-
-
Thierry Reding authored
The recently introduced clock gate support breaks on Tegra chips because no thermal support is enabled for those devices. Conditionalize the code on the existence of thermal support to fix this. Fixes: b138eca6 ("drm/nouveau: Add support for basic clockgating on Kepler1") Cc: Martin Peres <martin.peres@free.fr> Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- Feb 02, 2018
-
-
Arnd Bergmann authored
gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] Adding a temporary variable to contain the divisor helps make it clear what is going on and avoids that warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Luis de Bethencourt authored
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by:
Luis de Bethencourt <luisbg@kernel.org> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
This adds the NvPmEnableGating config option to nouveau, which can be used to enable or disable clockgating for supported chipsets. Enabling can be done by passing config=NvPmEnableGating=1 To nouveau. If your chipset supports it, you'll see a message in your kernel log indicating that clockgating is enabled. Since clockgating has only had limited testing thus far, we leave this option disabled by default for now. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
That's right, there's still more power saving to go! Starting with kepler 2, nvidia hardware has an additional level of clockgating known as second level clockgating. The details of this are not exact, but it seems to work by waiting for a collection of dependent hardware blocks to be gated before taking affect. As with the previous series, this results in another noticeable drop in power consumption and is programmed in the same manner. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
Same as the previous patch, but for Kepler2 now Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more power hungry then they need to be, so the nvidia driver writes it's own more optimized set of BLCG settings before enabling CG_CTRL. This adds support for programming the optimized BLCG values during engine/subdev init, which enables rather significant power savings. This introduces the nvkm_therm_clkgate_init() helper, which we use to program the optimized BLCG settings before enabling clockgating with nvkm_therm_clkgate_enable. As well, this commit shares a lot more code with Fermi since BLCG is mostly the same there as far as we can tell. In the future, it's likely we'll reformat the clkgate_packs for kepler1 so that they share a list of mmio packs with Fermi. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after initializing the GPU fully nvkm_therm_clkgate_fini() - prepares clockgating for suspend or driver unload A lot of this code was originally going to be based off of fermi; however it turns out that while Fermi's the first line of GPUs that introduced this kind of power saving, Fermi requires more fine tuned control of the CG_CTRL registers from the driver while reclocking that we don't entirely understand yet. For the simple parts we will be sharing with Fermi for certain however, we at least add those into a new subdev/therm/gf100.h header. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We've still been directly using the legacy crtc gamma_set() hook even after conversion to atomic modesetting. For userspace clients this was fine, however, fbcon will use the atomic property when it's running on an atomic driver, which means we miss its colormap updates - which is particularly bad for 8bpp framebuffers! This commit converts the driver to use the atomic property + the helper function implementing the legacy hook on top of atomic. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
For some reason forgotten by history, we've been using a 1025-entry LUT mode, and sparsely filling it with the 256-entry LUT we're handed. Until we land support for the full atomic colour management properties, this commit switches to using the 257-entry mode to fix colour mapping with depth 30 framebuffers. Reported-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
This is what was done prior to the big refactor in kernel 3.8, and what was done by xf86-video-nv. Experimentally, it seems like there's some sort of issue with the high-res lut to be used there. Tested on G92. This ends up mattering because fbcon/fbdev chooses the C8 fb format for low-vram systems, which can occur with some IGP-based configurations with little "stolen" vram. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We need to double-buffer LUTs to handle their update atomically. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This is a common, awkward sequence. Let's wrap it up! Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Useful for debugging. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Gourav Samaiya <gsamaiya@nvidia.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Gourav Samaiya <gsamaiya@nvidia.com>
-
Ben Skeggs authored
It's entirely possibly that the other r375 code is relevant to r370 too, but I've not confirmed this, so I'll leave it where it is for now. NVIDIA's copyright headers maintained, as it's still all their code. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Gourav Samaiya <gsamaiya@nvidia.com>
-
Arnd Bergmann authored
gcc-8 reports drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd': include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation] We need one less byte or call strlcpy() to make it a nul-terminated string. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Christoph Böhmwalder authored
The kbuild test bot complained about a new coccinelle warning nearby, which sparked a discussion about the assignment to 'memory' inside of the conditional expression. See Link below for the original post. Fix the assignment to silence the coccinelle warning and also make the code look a little nicer. Link: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.html Signed-off-by:
Christoph Böhmwalder <christoph@boehmwalder.at> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com>
-
Karol Herbst authored
Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word, a 'movw' alias was added which takes an unsigned 16-bit immediate. However the actual hardware op still sign extends. v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op is gone (loads 0 into the dst reg). However due to a bug in envyas, the movw alias still existed, and selected the no-longer-present v3 16-bit immediate mov op. As a result usage of movw on v5 is the same as mov with a 0x0 argument. The proper fix throughout is to only ever use the 'movw' alias in combination with 'sethi'. Anything else should get the sign-extended validation to ensure that the intended value ends up in the destination register. Changes in fuc3 binaries is the result of a different encoding being selected for a mov with an 8-bit value. v2: added commit message written by Ilia, thanks for that! v3: messed up rebasing, now it should apply Signed-off-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- Feb 01, 2018
-
-
Daniel Vetter authored
In the past the ast driver relied upon the fbdev emulation helpers to call ->load_lut at boot-up. But since commit b8e2b019 Author: Peter Rosin <peda@axentia.se> Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette that's cleaned up and drivers are expected to boot into a consistent lut state. This patch fixes that. Fixes: b8e2b019 ("drm/fb-helper: factor out pseudo-palette") Cc: Peter Rosin <peda@axenita.se> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.14+ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123 Cc: Bill Fraser <bill.fraser@gmail.com> Reported-and-Tested-by:
Bill Fraser <bill.fraser@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2018-01-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next This contains a fix to restrict what lessee can do with masters and another one when waiting for timeouts on reservation objects. * tag 'drm-misc-next-fixes-2018-01-31' of git://anongit.freedesktop.org/drm/drm-misc: drm: Check for lessee in DROP_MASTER ioctl dma-buf: fix reservation_object_wait_timeout_rcu once more v2
-
- Jan 31, 2018
-
-
Keith Packard authored
Don't let a lessee control what the current DRM master is set to; that's the job of the "real" master. Otherwise, the lessee would disable all access to master operations for the owner and all lessees under it. This matches the same check made in the SET_MASTER ioctl. Signed-off-by:
Keith Packard <keithp@keithp.com> Fixes: 2ed077e4 ("drm: Add drm_object lease infrastructure [v5]") Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180119015159.1606-1-keithp@keithp.com
-
- Jan 25, 2018
-
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Fixes for 4.16: Fixes one Kconfig issue and a enable some panels to work properly. There is also a fix of error code return in sun4i. * tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc: drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig drm/panel: lvds: Handle the optional regulator case properly drm/sun4i: Fix error code in sun4i_tcon_bind()
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
A few more fixes for 4.16, nothing major. A few more fixes for 4.16. This is on top of the pull request from last week. Most notable change here is a fix to the link order for the now separate from amdgpu GPU scheduler to fix crashes when the modules are build into the kernel rather than as modules. * 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux: drm: fix gpu scheduler link order drm/amd/display: Demote error print to debug print when ATOM impl missing drm/amdgpu: Avoid leaking PM domain on driver unbind (v2) drm/amd/amdgpu: Add Polaris version check drm/amdgpu: Reenable manual GPU reset from sysfs drm/amdgpu: disable MMHUB power gating on raven drm/ttm: Don't unreserve swapped BOs that were previously reserved drm/ttm: Don't add swapped BOs to swap-LRU list drm/amdgpu: only check for ECC on Vega10 drm/amd/powerplay: Fix smu_table_entry.handle type drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count drm/radeon: fill in rb backend map on evergreen/ni. drm/amdgpu/gfx9: fix ngg enablement to clear gds reserved memory (v2) drm/ttm: only free pages rather than update global memory count together drm/amdgpu: fix CPU based VM updates drm/amdgpu: fix typo in amdgpu_vce_validate_bo drm/amdgpu: fix amdgpu_vm_pasid_fault_credit drm/ttm: check the return value of register_shrinker drm/radeon: fix sparse warning: Should it be static?
-
Christian König authored
It should initialize before the drivers using it. Signed-off-by:
Christian König <christian.koenig@amd.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736 Reviewed-by:
Mike Lothian <mike@fireburn.co.uk> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Harry Wentland authored
I assumed wrongfully that all relevant functions should be implemented. Apparently this isn't the case. Demote the print to debug level for now. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
- Jan 23, 2018
-
-
Christian König authored
We need to set shared_count even if we already have a fence to wait for. v2: init i to -1 as well Signed-off-by:
Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Tested-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122200003.6665-1-christian.koenig@amd.com
-
Alex Deucher authored
We only support vga_switcheroo and runtime pm on PX/HG systems so forcing runpm to 1 doesn't do anything useful anyway. Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so that the cleanup path is correct as well. This mirrors what radeon does as well. v2: rework the patch originally sent by Lukas (Alex) Acked-by:
Lukas Wunner <lukas@wunner.de> Reported-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> (v1) Cc: stable@vger.kernel.org
-
James Zhu authored
Add Polaris version check if firmware support UVD encode Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
James Zhu <James.Zhu@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Andrey Grodzovsky authored
Otherwise it keeps rejecting the reset. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
- Jan 20, 2018
-
-
Huang Rui authored
MMHUB power gating still has issue, and doesn't work on raven at current. So disable it for the moment. Signed-off-by:
Huang Rui <ray.huang@amd.com> Acked-by:
Hawking Zhang <Hawking.Zhang@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- Jan 19, 2018
-
-
Felix Kuehling authored
If ttm_bo_swapout doesn't own the lock, don't release it. Someone else probably depends on it still being locked. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Felix Kuehling authored
A BO that's already swapped would be added back to the swap-LRU list for example if its validation failed under high memory pressure. This could later lead to swapping it out again and leaking previous swap storage. This commit adds a condition to prevent that from happening. v2: Check page_flags instead of swap_storage Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Alex Deucher authored
RV doesn't support it. Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Andrey Grodzovsky authored
The handle describes kernel logical address, should be unsigned long and not uint32_t. Fixes KASAN error and GFP on driver unload. Reviewed-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Roger He authored
add this for correctly updating global mem count in ttm_mem_zone. before that when ttm_mem_global_alloc_page fails, we would update all dma_page's global mem count in ttm_dma->pages_list. but actually here we should not update for the last dma_page. v2: only the update of last dma_page is not right v3: use lower bits of dma_page vaddr Signed-off-by:
Roger He <Hongbo.He@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-