similar to: [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

Last update here: https://lists.freedesktop.org/archives/nouveau/2017-September/028848.html Basically big cleanup, reordering, simplifications and some renaming to make the code easier to read and to review. I also moved some bugfixes to the front so they can be merged prior the other patches. There was also a bug related to the therm daemon triggering a pstate change leading to PMU lockups,

Date: Sat, 15 Apr 2023 22:02:31 +0200 Five strings which did not contain a data format specification should be put into a sequence. Thus use the corresponding function ?seq_puts?. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring at users.sourceforge.net> --- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 10 +++++----- 1 file changed, 5

overall it is for the most part the same as my older version. I cleaned up some copyright things, so that it is more like the others. Also I moved the print about the max speed supported into preinit and did some other minor cleanups in the 3rd commit. Happy testing (and performance for prime offloading setups) Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement

On Mon, Jul 15, 2024 at 7:49?AM Markus Elfring <Markus.Elfring at web.de> wrote: > > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Mon, 15 Jul 2024 13:36:54 +0200 > > Single characters should be put into a sequence. > Thus use the corresponding function ?seq_putc? for one selected call. > > This issue was transformed by using the Coccinelle

overall the same as the old stuff, but with better namings and tirivialy improved code here and there Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf: parse the pci speed from the

From: Markus Elfring <elfring at users.sourceforge.net> Date: Mon, 15 Jul 2024 13:36:54 +0200 Single characters should be put into a sequence. Thus use the corresponding function ?seq_putc? for one selected call. This issue was transformed by using the Coccinelle software. Suggested-by: Christophe Jaillet <christophe.jaillet at wanadoo.fr> Signed-off-by: Markus Elfring <elfring

nouveau_debugfs(drm) will never be NULL, because we're taking the value of the potentially null device pointer and adding to it so it isn't 0x0. So, check if drm is NULL instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Karol Herbst <karolherbst at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

On 2017-09-15 — 17:11, Karol Herbst wrote: > This makes the code easier, because we can compare the id with > pstate->pstate and saves us from the trouble of iterating over the pstates > to match the index. I don’t remember whether I have already done this comment before, but I am not sure where your iterating over the pstates savings are, as in this patch at least, you iterate as

This series addresses various issues inside the reclocking code: 1. after resume the set clocks are reset 2. reclocking not possible while GPU is suspended 3. racy reclocking while GPU is suspending and leading to hangs Some of the patches were part of the bigger reclocking series I sent months ago, some things have changed though. This is also preparation work of changing the clock state due to

This series addresses various issues inside the reclocking code: 1. after resume the set clocks are reset 2. reclocking not possible while GPU is suspended 3. nouveau always does full reclocks even if only a change of the voltage is required Some of the patches were part of the bigger reclocking series I sent months ago, some things have changed though. This is also preparation work of

This is a small patch series that adds a strap_peek file into our debugfs, and sets the size of the vbios.rom debugfs file so that nvbios can easily be used to parse the vbios even on systems where the normal BIOS retrieval methods (for example, laptops that need ACPI to access the vbios for the nvidia GPU) won't work. This should make it a little easier to collect vbioses. Lyude Paul (2):

I made a little changes in this series: 1. merge the two last patches together 2. unify the private data interface with the drm debugfs one now it should be very obvious for a new dev on how to add new files to debugfs and how to get access to the nouveau structs Karol Herbst (5): debugfs: add infrastructure to add files with other fops than only read debugfs: rename functions to

Just wanted to post updated versions of my last series/patches. Reviews welcomed. It would be also nice if we agree on features I should focus upstreaming, so that this work can be better splitted or reordered. Sadly most of my patches depend on the rather big clk subdev rework and I think those patches shows best, why I think this rework is actually needed and makes things much easier to add

not much changed since the last time I sent those patches out, but there are a couple of annoying bug fixes, which users would probably never hit unless they do rmmod/modprobe nouveau cycles. Biggest change is that I force the link to a 8.0 speed rather than the speed the GPU came up with. Also this series depends on the PCIe improvement patches I sent out recently. Karol Herbst (4): pci:

Changes since last sent: * add a patch to set the device into DRM_SWITCH_POWER_CHANGING state (can be dropped actually, I thought I was needing it, came up with a different approach and forgot to delete it, doesn't hurt though) * expose information about runtime suspending to nvkm so that we can run the pcie workaround only on runtime suspend Karol Herbst (8): pci: disable ASPM

Signed-off-by: Karol Herbst <kherbst at redhat.com> Reviewed-by: Lyude Paul <lyude at redhat.com> --- drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++++---- drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++++++++++ drm/nouveau/nvkm/subdev/pci/priv.h | 5 +++++ 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c

Date: Sat, 15 Apr 2023 21:24:43 +0200 The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function ?nouveau_debugfs_pstate_get?. Thus avoid the risk for undefined behaviour by moving the assignment for the variable ?ctrl? behind the null pointer check. This issue was detected by using the Coccinelle software. Fixes:

this patch series implements PCIe speed changes for Tesla and newer. The Kepler and Fermi bits are tested on my cards at home. Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf:

On Fri, 13 Sep 2019 at 21:33, Karol Herbst <kherbst at redhat.com> wrote: > > Apperantly things go south if we suspend the device with a PCIe link speed > set to 2.5. Fixes runtime suspend on my gp107. > > This all looks like some bug inside the pci subsystem and I would prefer a > fix there instead of nouveau, but maybe there is no real nice way of doing > that outside

Hi, I used to experience kernel panics caused by CPUx hard lockup once almost everyday. I'm running Ubuntu 14.10 on vanilla linux kernel 3.19.2 on Core i7-3770 with Gallium 0.4 on NV108. The panic log looked like: [ 9227.509744] ------------[ cut here ]------------ [ 9227.509750] WARNING: CPU: 0 PID: 0 at kernel/watchdog.c:290 watchdog_overflow_callback+0x92/0xc0() [ 9227.509751] Watchdog