Displaying 20 results from an estimated 800 matches similar to: "[RFC PATCH] drm/nouveau/therm: initial implementation of new gp1xx temperature sensor"
2017 Sep 01
0
[PATCH v2] drm/nouveau/therm: initial implementation of new gp1xx temperature sensor
v2:
- add nv138 and drop nv13b chipsets (Ilia Mirkin)
- refactor out status variable and instead mask tsensor (Ilia Mirkin)
- switch SHADOWed state message away from nvkm_error() (Ilia Mirkin)
- rename internal temperature variable (Karol Herbst)
Signed-off-by: Rhys Kidd <rhyskidd at gmail.com>
---
.../gpu/drm/nouveau/include/nvkm/subdev/therm.h | 1 +
2017 Jan 22
1
[GP107 chipset][PATCH] Recognise GP107 chipset (GTX 1050/1050ti)
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 =
2016 Dec 12
2
[PATCH] drm/nouveau: fix unknown chipset for GTX 1060
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
2017 Feb 14
1
[PATCH] drm/nouveau/core: recognise GP107 chipset
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:
2018 Jan 25
3
[PATCH] drm/nouveau/therm/gp100: Do not report temperature when subdev is shadowed
This fixes wrong temperature outputs e.g. 511°C if the card is asleep.
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de>
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
index
2018 Jan 26
2
[PATCH] drm/nouveau/therm/gp100: Do not report temperature when subdev is shadowed
Not sure if i understand completely what you intend to say here, with
this we prevent hwmon from reporting utterly wrong temperature values
returning an error (we could return -EBUSY or somehting instead,
granted), yet if the device is shadowed, getting a sane temp value out
of is seems unlikely to me!
Greetings,
Tobias
On 1/26/18 12:40 PM, Karol Herbst wrote:
> no, we can't do that.
2020 Aug 12
6
[PATCH] drm/nouveau: Add fine-grain temperature reporting
Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
new gp1xx temperature sensor") added support for reading finer-grain
temperatures, but continued to report temperatures in 1 degree Celsius
increments via nvkm_therm_temp_get().
Rather than altering nvkm_therm_temp_get() to report finer-grain
temperatures, which would be inconvenient for other users of the
2020 Sep 16
2
[PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter
The temp_get() function currently returns negative error numbers or a
temperature. However, the thermal sensors can (in theory) measure
negative temperatures. Some implementations of temp_get() correctly
clamp negative temperature readings to 0 so that users do not mistake
them for errors, but some, like gp100_temp_get(), do not.
Rather than relying on implementations remembering to clamp values,
2020 Sep 16
2
[PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter
On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst <kherbst at redhat.com> wrote:
>
> On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote:
> >
> > The temp_get() function currently returns negative error numbers or a
> > temperature. However, the thermal sensors can (in theory) measure
> > negative temperatures. Some implementations of
2017 Nov 22
2
[PATCH 03/32] therm: Split return code and value in nvkm_get_temp
On 17/11/17 02:04, Karol Herbst wrote:
> The current hwmon code doesn't check if the returned value was actually an
> error.
>
> Since Kepler temperature sensors are able to report negative values. Those
> negative values are not for error reporting, but rather when you buried
> your GPU in snow somewhere in Antarctica and still want a valid
> temperature to be reported
2017 Oct 08
1
[RFC PATCH 01/29] therm: split return code and value in nvkm_get_temp
As you changed the return value of `temp_get()` to solely be the error code, or
absence of an error, I would change all those tests that checked whether the
returned value was strictly less, or greater than, 0 to now only compare
against 0 (no error). For example,
if (therm && therm->attr_get && nvkm_therm_temp_get(therm, &val) < 0)
if
2017 Nov 22
1
[PATCH 03/32] therm: Split return code and value in nvkm_get_temp
On 22/11/17 03:42, Karol Herbst wrote:
> On Wed, Nov 22, 2017 at 1:32 AM, Martin Peres <martin.peres at free.fr> wrote:
>> On 17/11/17 02:04, Karol Herbst wrote:
>>> The current hwmon code doesn't check if the returned value was actually an
>>> error.
>>>
>>> Since Kepler temperature sensors are able to report negative values. Those
2017 Nov 10
2
GP10B regression
Hello everyone,
it seems that GP10B support has regressed recently. With linux-next, I
need to modify device/base.c to set
.mmu = gp10b_mmu_new
for GP10B (makes sense - I guess this was left as gf100_mmu_new as a
typo) to probe. After that, running a trivial testcase (running a NOP
method in 3D class) fails with
[ 110.084649] nouveau 17000000.gpu: fifo: read fault at 0000011000
engine 06
2017 Jul 03
0
[PATCH] initial support (display-only) for GP108
Forked from GP107 implementation. Secboot/gr left out as we don't have
signed blobs from NVIDIA in linux-firmware.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
drm/nouveau/nvkm/engine/device/base.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git
2017 Nov 17
35
[PATCH 00/32] Updated State of my clk patches
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,
2017 Sep 15
42
[RFC PATCH 00/29] Current State of my clk patches
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
2018 Jan 26
1
[RFC v2 1/4] drm/nouveau: Add support for basic clockgating on Kepler1
On Fri, Jan 26, 2018 at 4:35 AM, Lyude Paul <lyude at redhat.com> wrote:
> 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
2018 Jan 26
6
[RFC v2 0/4] Implement full clockgating for Kepler1 and 2
Next version of my patchseries for adding clockgating support for
kepler1 and 2 on nouveau. The first version of this series can be found
here:
https://patchwork.freedesktop.org/series/36504/
Some minor changes:
- Clarified that SLCG stands for 'secondary level clockgating', thanks
for the small tip nvidia!
- Removed the concept of levels, this was more useful for debugging
then
2017 Mar 29
15
[PATCH 00/15] Support for GP10B chipset
GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for
its base engines after reworking secboot a bit to accomodate its calling
convention better.
This patchset has been tested rendering simple off-screen buffers using Mesa
and yielded the expected result.
Alexandre Courbot (15):
secboot: allow to boot multiple falcons
secboot: pass instance to LS firmware loaders
secboot:
2018 Jan 15
6
[RFC 0/4] Implement full clockgating for Kepler1 and 2
It's here! After a lot of investigation, rewrites, and traces, I present
the patch series to implement all known levels of clockgating for
Kepler1 and Kepler2 GPUs.
Starting with Fermi GPUs (this is probably present on earlier GPUs as
well, but with a far less easy to manage interface), nvidia added two
clockgating levels that are handled mostly in firmware (with the
exception of course, of