similar to: [PATCH 0/2] Support for INA3221 power sensor

This is a complete rework from the first version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards. The power consumption is also exported via

This is a complete rework from the last version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards, but only the INA3221 bits are tested so far.

This is a complete rework from the first version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards. The power consumption is also exported via

This is a complete rework from the first version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards. The power consumption is also exported via

From: Martin Peres <martin.peres at free.fr> v2 (Karol Herbst <nouveau at karolherbst.de>): fix power_rail mapping for ina3221 minor code cleanups Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/core/device.h | 83 +++++++------- drm/nouveau/include/nvkm/subdev/bios/extdev.h | 4 +

Increase clock timeout of some unknown engines in order to avoid failure at high gpcclk rate. This fixes IBUS read faults on my GF119 when reclocking is manually enabled. Note that memory reclocking is completely broken and NvMemExec has to be disabled to allow core clock reclocking only. Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> ---

The power sensors can be configured to sample the readout values over time. Nvidia does this too, so nouveau should probably do that too. Karol Herbst (4): iccsense: remove read function iccsense: convert to linked list iccsense: split sensor into own struct iccsense: configure sensors like nvidia does drm/nouveau/include/nvkm/subdev/iccsense.h | 6 +- drm/nouveau/nouveau_hwmon.c

The power sensors can be configured to sample the readout values over time. Nvidia does this too, so nouveau should probably do that too. v2: use list_del and rework an error message Karol Herbst (4): iccsense: remove read function iccsense: convert to linked list iccsense: split sensor into own struct iccsense: configure sensors like nvidia does

based on Martins initial work v3: fix ina2x9 calculations v4: don't kmalloc(0), fix the lsb/pga stuff Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/subdev/bios/extdev.h | 3 + drm/nouveau/include/nvkm/subdev/i2c.h | 31 ++++++ drm/nouveau/include/nvkm/subdev/iccsense.h | 5 + drm/nouveau/nvkm/engine/device/base.c | 20

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. The meaning of this header field was confirmed with nvidia-smi -q: The rows "Min Power Limit", "Power Limit" and "Max Power Limit" are set to the "min", "avg" and "max" values from the referenced power budget entry respectively.

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. We should have this in the kernel before actually using it to catch errors and see how reliable this is, but as it seems it works on all GPUs as expected on Kepler und Maxwells with the power cap field set in the vbios. This series keeps things really simple for now until we figure out

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. We should have this in the kernel before actually using it to catch errors and see how reliable this is, but as it seems it works on all GPUs as expected on Kepler und Maxwells with the power cap field set in the vbios. This series keeps things really simple for now until we figure out

There is an optinal header field in the power budget table we can use to read out the power cap of the GPU. Sadly it is optional and if that field isn't sad, things beome complicated. Anyhow, this is good enough for most cards and we can use it later for capping the power consumption of the GPUs, but first, just export those values through hwmon. First design, will change stuff, want

Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it only gives VGA resolution on screen. Use the same chipset as nv134 then it shows FullHD. This commit copies fields from nv134_chipset to nv136_chipset for GTX 1060. Signed-off-by: Chris Chiu <chiu at endlessm.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++++++++++++++++++++++ 1 file changed, 29

Hello everyone, I would like to submit a simple patch to let nouveau able to detect GTX 1050 / 1050ti cards. TESTED and WORKING on my computer with my GPU (Gigabyte GTX 1050ti OC edition). drivers/gpu/drm/nouveau/nvkm/engine/device/ base.c gpu_nouveau_gp107.patch 2272a2273,2301 > static const struct nvkm_device_chip > nv137_chipset = { > .name = "GP107", > .bar =

From: Thierry Reding <treding at nvidia.com> Hi, the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why exactly is not clear, but there are slight differences between the SKUs that were tested. It turns out that the biggest issue is that on some devices (e.g. the one that I have), pulsing the GPU reset twice as is done in the current code (once as part of the power-ungate

From: Chris Chiu <chiu at endlessm.com> This new graphics card was failing to initialize with nouveau due to an "unknown chipset" error. Copy the GP106 configuration and rename for GP107/NV137. We don't know for certain that this is fully correct, but brief desktop testing suggests this is working fine. Signed-off-by: Chris Chiu <chiu at endlessm.com> Signed-off-by:

From: Thierry Reding <treding at nvidia.com> The gk20a implementation of instance memory uses vmap()/vunmap() to map memory regions into the kernel's virtual address space. These functions may sleep, so protecting them by a spin lock is not safe. This triggers a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this by using a mutex instead. Signed-off-by: Thierry Reding

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the