[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #48 from Marco Trevisan (Treviño) --- Nothing particular. Enabling debug option, when running glxgears (which indeed gets a speedup) I just get things such as: [39145.588483] nouveau: DRM::0002: suspend children... [39145.588486] nouveau: DRM::0002: suspend running... [39145.588488] nouveau: DRM::0002: suspend completed in 3us [39145.588491] nouveau: DRM::0080: suspend running... [39146.089636] nouveau: DRM::0080: suspend completed in 501355us [39146.089638] nouveau: DRM::: suspend running... [39146.089638] nouveau: DRM::: suspend completed in 501363us -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #47 from Ben Skeggs --- (In reply to Marco Trevisan (Treviño) from comment #46) > Created attachment 123084 [details] > kernel 4.4 - dmesg: 950MX SMF 108 patch > > Trying the patch by SMF gives out more or less the same output: > > [34924.970827] pci :02:00.0: optimus capabilities: enabled, status > dynamic power, hda bios codec supported > [34924.970830] VGA switcheroo: detected Optimus DSM method > \_SB_.PCI0.PEG2.PEGP handle > [34924.970935] nouveau :02:00.0: NVIDIA GM108 (1180d0a2) > [34924.995153] nouveau :02:00.0: bios: version 82.08.57.00.22 > [34925.039282] nouveau :02:00.0: fb: 2048 MiB DDR3 > [34925.039291] nouveau :02:00.0: priv: HUB0: 1200a0 0001 (19408217) > [34925.039333] nouveau :02:00.0: priv: HUB0: 10ecc0 (1e40822c) > [34926.318695] vga_switcheroo: enabled > [34926.318863] [TTM] Zone kernel: Available graphics memory: 16119644 kiB > [34926.318880] [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [34926.318881] [TTM] Initializing pool allocator > [34926.318892] [TTM] Initializing DMA pool allocator > [34926.318899] nouveau :02:00.0: DRM: VRAM: 2048 MiB > [34926.318900] nouveau :02:00.0: DRM: GART: 1048576 MiB > [34926.318902] nouveau :02:00.0: DRM: Pointer to TMDS table invalid > [34926.318904] nouveau :02:00.0: DRM: DCB version 4.0 > [34926.318905] nouveau :02:00.0: DRM: Pointer to flat panel table invalid > [34926.435387] nouveau :02:00.0: DRM: MM: using COPY for buffer copies > [34926.435394] [drm] Initialized nouveau 1.3.1 20120801 for :02:00.0 on > minor > > See also attached dmesg Can you also run something with "DRI_PRIME=1" (to use the NVIDIA GPU) and see if you get any additional dmesg output from nouveau? I've been looking at an older GM108 trace to try and add support for it (I don't have the hw myself), and see some things in that that need fixing and should cause errors from the hw if the graphics engine is used. Thanks, Ben. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94990] Latest 4.6rc4 kernel, no booting on gtx970
https://bugs.freedesktop.org/show_bug.cgi?id=94990 --- Comment #12 from Alexandre Courbot --- This line in the log looks kinda suspicious to me: [2.278551] nouveau :01:00.0: enabling device ( -> 0003) I am not seeing it on my end ; could this mean that the Geforce card is a secondary display device, and that the integrated Intel graphics is the main one? In this case maybe you need this patch, which is not in -rc4: https://lists.freedesktop.org/archives/nouveau/2016-April/024523.html Also I am surprised by the report that the screen goes blank after this - failure to initialize GR should not interfere with the ability to display a framebuffer (only acceleration will be disabled). Let's make another experiment: can you move /lib/firmware/nvidia/gm204 somewhere else, reboot (you will see a complain about missing firmware files in the boot log), and tell us whether the display is active after that? Thanks! -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94990] Latest 4.6rc4 kernel, no booting on gtx970
https://bugs.freedesktop.org/show_bug.cgi?id=94990 --- Comment #11 from Alexandre Courbot --- Successfully booted with your config on 4.6-rc4 and a GM206 (GTX 960). I am trying to get my hands on a GTX970 to see if this is specific to the card. Are you able/willing to compile custom Nouveau modules in order to get more debug information? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #46 from Marco Trevisan (Treviño) --- Created attachment 123084 --> https://bugs.freedesktop.org/attachment.cgi?id=123084&action=edit kernel 4.4 - dmesg: 950MX SMF 108 path Trying the patch by SMF gives out more or less the same output: [34924.970827] pci :02:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported [34924.970830] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG2.PEGP handle [34924.970935] nouveau :02:00.0: NVIDIA GM108 (1180d0a2) [34924.995153] nouveau :02:00.0: bios: version 82.08.57.00.22 [34925.039282] nouveau :02:00.0: fb: 2048 MiB DDR3 [34925.039291] nouveau :02:00.0: priv: HUB0: 1200a0 0001 (19408217) [34925.039333] nouveau :02:00.0: priv: HUB0: 10ecc0 (1e40822c) [34926.318695] vga_switcheroo: enabled [34926.318863] [TTM] Zone kernel: Available graphics memory: 16119644 kiB [34926.318880] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [34926.318881] [TTM] Initializing pool allocator [34926.318892] [TTM] Initializing DMA pool allocator [34926.318899] nouveau :02:00.0: DRM: VRAM: 2048 MiB [34926.318900] nouveau :02:00.0: DRM: GART: 1048576 MiB [34926.318902] nouveau :02:00.0: DRM: Pointer to TMDS table invalid [34926.318904] nouveau :02:00.0: DRM: DCB version 4.0 [34926.318905] nouveau :02:00.0: DRM: Pointer to flat panel table invalid [34926.435387] nouveau :02:00.0: DRM: MM: using COPY for buffer copies [34926.435394] [drm] Initialized nouveau 1.3.1 20120801 for :02:00.0 on minor See also attached dmesg -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 Marco Trevisan (Treviño) changed: What|Removed |Added Attachment #123084|kernel 4.4 - dmesg: 950MX |kernel 4.4 - dmesg: 950MX description|SMF 108 path|SMF 108 patch Attachment #123084|dmesg-950MX-SMF-118-patch.l |dmesg-950MX-SMF-108-patch.l filename|og |og -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #45 from Marco Trevisan (Treviño) --- Nvidia 940MX is affected as well: 02:00.0 3D controller: NVIDIA Corporation Device 134d (rev a2) [32394.818085] pci :02:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported [32394.818087] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG2.PEGP handle [32394.818170] nouveau :02:00.0: unknown chipset (1180d0a2) [32394.818199] nouveau: probe of :02:00.0 failed with error -12 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 69882] [NVE6] GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=69882 --- Comment #21 from Lucas Ribeiro --- Just tried karolherbst nouveau reclocking tree: https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v4 Using this module and reclocking to pstate 07 fixed the hangs I was having before. Maybe this fixes 660 hangs too. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 21/37] clk: save the max clock we can set
On 18/04/16 22:13, Karol Herbst wrote:
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/clk.h | 1 +
drm/nouveau/nvkm/subdev/clk/base.c| 2 ++
2 files changed, 3 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/clk.h
b/drm/nouveau/include/nvkm/subdev/clk.h
index 99ee05c..61d99fd 100644
--- a/drm/nouveau/include/nvkm/subdev/clk.h
+++ b/drm/nouveau/include/nvkm/subdev/clk.h
@@ -105,6 +105,7 @@ struct nvkm_clk {
u8 boost_mode;
u32 base_khz;
u32 boost_khz;
+ u32 max_khz;
/*XXX: die, these are here *only* to support the completely
* bat-shit insane what-was-nouveau_hw.c code
diff --git a/drm/nouveau/nvkm/subdev/clk/base.c
b/drm/nouveau/nvkm/subdev/clk/base.c
index a9a3666..1ca25dd 100644
--- a/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drm/nouveau/nvkm/subdev/clk/base.c
@@ -257,6 +257,8 @@ nvkm_cstate_new(struct nvkm_clk *clk, int idx, struct
nvkm_pstate *pstate)
u32 freq = nvkm_clk_adjust(clk, true, pstate->pstate,
domain->bios, cstepX.freq);
cstate->domain[domain->name] = freq;
+ if (domain->flags & NVKM_CLK_DOM_FLAG_BASECLK)
+ clk->max_khz = max(clk->max_khz, freq);
}
domain++;
}
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 20/37] volt: add coefficients
On 20/04/16 00:54, Ilia Mirkin wrote: On Tue, Apr 19, 2016 at 5:52 PM, Martin Peres wrote: + result = ((s64)info.arg[0] * 15625) >> 18; + result += ((s64)info.arg[1] * volt->speedo * 15625) >> 18; + result += ((s64)info.arg[2] * temp * 15625) >> 10; + result += ((s64)info.arg[3] * volt->speedo * temp * 15625) >> 18; + result += ((s64)info.arg[4] * volt->speedo * volt->speedo * 15625) >> 30; + result += ((s64)info.arg[5] * temp * temp * 15625) >> 18; + break; Well, I can only say that these values got us really really close to what nvidia does... On around 10 GPUs... So... until we know better, let's stick to them. Hopefully, we can figure out where this 15625 comes from. This patch is: 5^6. Really it's 10^6, but it's silly to multiply by 10^6 and then divide by powers of 2. Instead that's factored out... That makes sense. I must have missed this on the IRC discussion. Major congrats to Karol and you for figuring out all of this! @Ben: I really think this is the right thing to do, it really was solid work for Karol's part. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 20/37] volt: add coefficients
On Tue, Apr 19, 2016 at 5:52 PM, Martin Peres wrote: >> + result = ((s64)info.arg[0] * 15625) >> >> 18; >> + result += ((s64)info.arg[1] * volt->speedo >> * 15625) >> 18; >> + result += ((s64)info.arg[2] * temp * >> 15625) >> 10; >> + result += ((s64)info.arg[3] * volt->speedo >> * temp * 15625) >> 18; >> + result += ((s64)info.arg[4] * volt->speedo >> * volt->speedo * 15625) >> 30; >> + result += ((s64)info.arg[5] * temp * temp >> * 15625) >> 18; >> + break; > > > Well, I can only say that these values got us really really close to what > nvidia does... On around 10 GPUs... So... until we know better, let's stick > to them. > > Hopefully, we can figure out where this 15625 comes from. This patch is: 5^6. Really it's 10^6, but it's silly to multiply by 10^6 and then divide by powers of 2. Instead that's factored out... -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 69882] [NVE6] GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=69882 --- Comment #20 from Lucas Ribeiro --- Also having random lockups on a GTX 660 Ti (NVE4 according to glxinfo), since kernel 4.1 I guess, using DRI2. [0.267666] nouveau :02:00.0: NVIDIA GK104 (0e4030a2) [0.378583] nouveau :02:00.0: bios: version 80.04.4b.00.1a [0.379302] nouveau :02:00.0: fb: 2048 MiB GDDR5 Now on gentoo ~amd64 using: sys-kernel/gentoo-sources-4.5.1 x11-base/xorg-server-1.18.3 x11-drivers/xf86-video-nouveau-1.0.12 Should I make a new entry for this card? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 20/37] volt: add coefficients
On 18/04/16 22:13, Karol Herbst wrote:
I am sure that those are a bit different, but while testing the biggest error
compared to nvidia was -1.5%.
Is this still true? I thought we were *much* closer now.
Without this change we are most of the time around 10% below nvidias voltage,
so this change causes no harm and improves the situation a lot already.
Yeah, this is definitely not up to date!
These coefficients were REed by modifing the voltage map entries and by
calculating the set voltage back until I was able to forecast which voltage
nvidia sets for a given voltage map entry.
v4: use better coefficients and speedo
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/volt/base.c | 38 +++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index cecfac6..5e35d96 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -110,13 +110,47 @@ nvkm_volt_map(struct nvkm_volt *volt, u8 id, u8 temp)
vmap = nvbios_vmap_entry_parse(bios, id, &ver, &len, &info);
if (vmap) {
+ s64 result;
+
+ if (volt->speedo < 0)
+ return volt->speedo;
Hmm, so you will refuse reclocking if the speedo cannot be read...
Fair-enough, but I would like to see a warning in the kernel logs.
+
+ if (ver == 0x10 || (ver == 0x20 && info.mode == 0)) {
+ result = (s64)info.arg[0] / 10;
+ result += ((s64)info.arg[1] * volt->speedo) / 10;
+ result += ((s64)info.arg[2] * volt->speedo *
volt->speedo) / 10;
+ } else if (ver == 0x20) {
+ switch (info.mode) {
+ /* 0x0 handled above! */
+ case 0x1:
+ result = ((s64)info.arg[0] * 15625) >> 18;
+ result += ((s64)info.arg[1] * volt->speedo * 15625)
>> 18;
+ result += ((s64)info.arg[2] * temp * 15625) >>
10;
+ result += ((s64)info.arg[3] * volt->speedo * temp *
15625) >> 18;
+ result += ((s64)info.arg[4] * volt->speedo *
volt->speedo * 15625) >> 30;
+ result += ((s64)info.arg[5] * temp * temp * 15625)
>> 18;
+ break;
Well, I can only say that these values got us really really close to
what nvidia does... On around 10 GPUs... So... until we know better,
let's stick to them.
Hopefully, we can figure out where this 15625 comes from. This patch is:
Reviewed-by: Martin Peres
+ case 0x3:
+ result = (info.min + info.max) / 2;
+ break;
+ case 0x2:
+ default:
+ result = info.min;
+ break;
+ }
+ } else {
+ return -ENODEV;
+ }
+
+ result = min(max(result, (s64)info.min), (s64)info.max);
+
if (info.link != 0xff) {
int ret = nvkm_volt_map(volt, info.link, temp);
if (ret < 0)
return ret;
- info.min += ret;
+ result += ret;
}
- return info.min;
+ return result;
}
return id ? id * 1 : -ENODEV;
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 19/37] volt: add gf100 subdev with speedo
On 18/04/16 22:13, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/volt.h | 1 +
drm/nouveau/nvkm/engine/device/base.c | 17 +-
drm/nouveau/nvkm/subdev/volt/Kbuild| 1 +
drm/nouveau/nvkm/subdev/volt/gf100.c | 59 ++
4 files changed, 70 insertions(+), 8 deletions(-)
create mode 100644 drm/nouveau/nvkm/subdev/volt/gf100.c
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index 4cb0292..25588c7 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -30,6 +30,7 @@ int nvkm_volt_get(struct nvkm_volt *);
int nvkm_volt_set_id(struct nvkm_volt *, u8 id, u8 min_id, int condition);
int nv40_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
+int gf100_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
int gk104_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
int gk20a_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
int gm20b_volt_new(struct nvkm_device *, int, struct nvkm_volt **);
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index a364efe..528780c 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -1357,7 +1357,7 @@ nvc0_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.ce[1] = gf100_ce_new,
.disp = gt215_disp_new,
@@ -1394,7 +1394,7 @@ nvc1_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.disp = gt215_disp_new,
.dma = gf100_dma_new,
@@ -1430,7 +1430,7 @@ nvc3_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.disp = gt215_disp_new,
.dma = gf100_dma_new,
@@ -1466,7 +1466,7 @@ nvc4_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.ce[1] = gf100_ce_new,
.disp = gt215_disp_new,
@@ -1503,7 +1503,7 @@ nvc8_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.ce[1] = gf100_ce_new,
.disp = gt215_disp_new,
@@ -1540,7 +1540,7 @@ nvce_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.ce[1] = gf100_ce_new,
.disp = gt215_disp_new,
@@ -1577,7 +1577,7 @@ nvcf_chipset = {
.pmu = gf100_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.disp = gt215_disp_new,
.dma = gf100_dma_new,
@@ -1612,6 +1612,7 @@ nvd7_chipset = {
.pci = gf106_pci_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.disp = gf119_disp_new,
.dma = gf119_dma_new,
@@ -1647,7 +1648,7 @@ nvd9_chipset = {
.pmu = gf119_pmu_new,
.therm = gf119_therm_new,
.timer = nv41_timer_new,
- .volt = nv40_volt_new,
+ .volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
.disp = gf119_disp_new,
.dma = gf119_dma_new,
diff --git a/drm/nouveau/nvkm/subdev/volt/Kbuild
b/drm/nouveau/nvkm/subdev/volt/Kbuild
index c340762..bcd179b 100644
--- a/drm/nouveau/nvkm/subdev/volt/Kbuild
+++ b/drm/nouveau/nvkm/subdev/volt/Kbuild
@@ -1,6 +1,7 @@
nvkm-y += nvkm/subdev/volt/base.o
nvkm-y += nvkm/subdev/volt/gpio.o
nvkm-y += nvkm/subdev/volt/nv40.o
+nvkm-y += nvkm/subdev/volt/gf100.o
nvkm-y += nvkm/subdev/volt/gk104.o
nvkm-y += nvkm/subdev/volt/gk20a.o
nvkm-y += nvkm/subdev/volt/gm20b.o
diff --git a/drm/nouveau/nvkm/subdev/volt/gf100.c
b/drm/nouveau/nvkm/subdev/volt/gf100.c
new file mode 100644
index 000..16dc0f1
--- /dev/null
+++ b/drm/nouveau/nvkm/subdev/volt/gf100.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2016 Karol Herbst
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software
Re: [Nouveau] [PATCH v4 16/37] volt: don't require perfect fit
On 18/04/16 22:13, Karol Herbst wrote:
if we calculate the voltage in the table right, we get all kinds of values,
which never fit the hardware steps, so we use the closest higher value the
hardware can do.
v3: simplify the implementation
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/volt/base.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index d72bd4a..028c6e2 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -51,18 +51,30 @@ static int
nvkm_volt_set(struct nvkm_volt *volt, u32 uv)
{
struct nvkm_subdev *subdev = &volt->subdev;
- int i, ret = -EINVAL;
+ int i, ret = -EINVAL, best_err = uv, best = -1;
"best_err = uv" is not a safe value. You may set best_err to the maximum
voltage, anything under that may fail in theory.
With this fixed, this is:
Reviewed-by: Martin Peres
if (volt->func->volt_set)
return volt->func->volt_set(volt, uv);
for (i = 0; i < volt->vid_nr; i++) {
- if (volt->vid[i].uv == uv) {
- ret = volt->func->vid_set(volt, volt->vid[i].vid);
- nvkm_debug(subdev, "set %duv: %d\n", uv, ret);
+ int err = volt->vid[i].uv - uv;
+ if (err < 0 || err > best_err)
+ continue;
+
+ best_err = err;
+ best = i;
+ if (best_err == 0)
break;
- }
}
+
+ if (best == -1) {
+ nvkm_error(subdev, "couldn't set %iuv\n", uv);
+ return ret;
+ }
+
+ ret = volt->func->vid_set(volt, volt->vid[best].vid);
+ nvkm_debug(subdev, "set req %duv to %duv: %d\n", uv,
+ volt->vid[best].uv, ret);
return ret;
}
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 17/37] bios/vmap: unk0 field is the mode
On 18/04/16 22:13, Karol Herbst wrote:
this selects which formula is used to calculate the voltage.
depending on the value, the entry maps to a different voltage and even enables
if the temperature has any effect or not. This is easy to observe with the
binary driver.
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/bios/vmap.h | 2 +-
drm/nouveau/nvkm/subdev/bios/vmap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
index ae2f27b..8fa1294 100644
--- a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
+++ b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
@@ -11,7 +11,7 @@ u16 nvbios_vmap_parse(struct nvkm_bios *, u8 *ver, u8 *hdr,
u8 *cnt, u8 *len,
struct nvbios_vmap *);
struct nvbios_vmap_entry {
- u8 unk0;
+ u8 mode;
u8 link;
u32 min;
u32 max;
diff --git a/drm/nouveau/nvkm/subdev/bios/vmap.c
b/drm/nouveau/nvkm/subdev/bios/vmap.c
index f2295e1..32bd8b1 100644
--- a/drm/nouveau/nvkm/subdev/bios/vmap.c
+++ b/drm/nouveau/nvkm/subdev/bios/vmap.c
@@ -105,7 +105,7 @@ nvbios_vmap_entry_parse(struct nvkm_bios *bios, int idx, u8
*ver, u8 *len,
info->arg[2] = nvbios_rd32(bios, vmap + 0x10);
break;
case 0x20:
- info->unk0 = nvbios_rd08(bios, vmap + 0x00);
+ info->mode = nvbios_rd08(bios, vmap + 0x00);
info->link = nvbios_rd08(bios, vmap + 0x01);
info->min= nvbios_rd32(bios, vmap + 0x02);
info->max= nvbios_rd32(bios, vmap + 0x06);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 18/37] volt: add speedo
On 18/04/16 22:13, Karol Herbst wrote:
Signed-off-by: Karol Herbst
---
bin/nv_cmp_volt.c | 2 +-
drm/nouveau/include/nvkm/subdev/volt.h | 2 ++
drm/nouveau/nvkm/subdev/volt/base.c| 12
drm/nouveau/nvkm/subdev/volt/priv.h| 1 +
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/bin/nv_cmp_volt.c b/bin/nv_cmp_volt.c
index 34147b9..e61056c 100644
--- a/bin/nv_cmp_volt.c
+++ b/bin/nv_cmp_volt.c
@@ -53,7 +53,7 @@ main(int argc, char **argv)
ret = u_device("lib", argv[0], "error", true, true,
(1ULL << NVKM_SUBDEV_CLK) |
-// (1ULL << NVKM_SUBDEV_FUSE) |
+ (1ULL << NVKM_SUBDEV_FUSE) |
This change comes a little early, as fuse would be an implementation
detail (coming in the next patch) to read the speedo.
Either way, I do not really care, as this won't go in the kernel anyway
and it does not hurt to enable this a little early.
Reviewed-by: Martin Peres
(1ULL << NVKM_SUBDEV_GPIO) |
// (1ULL << NVKM_SUBDEV_I2C) |
(1ULL << NVKM_SUBDEV_PCI) |
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index f223577..4cb0292 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -20,6 +20,8 @@ struct nvkm_volt {
u8 max0_id;
u8 max1_id;
u8 max2_id;
+
+ int speedo;
};
int nvkm_volt_map(struct nvkm_volt *volt, u8 id, u8 temperature);
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index 028c6e2..cecfac6 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -201,6 +201,14 @@ nvkm_volt_parse_bios(struct nvkm_bios *bios, struct
nvkm_volt *volt)
}
static int
+nvkm_volt_speedo_read(struct nvkm_volt *volt)
+{
+ if (volt->func->speedo_read)
+ return volt->func->speedo_read(volt);
+ return -EINVAL;
+}
+
+static int
nvkm_volt_init(struct nvkm_subdev *subdev)
{
struct nvkm_volt *volt = nvkm_volt(subdev);
@@ -262,6 +270,10 @@ nvkm_volt_ctor(const struct nvkm_volt_func *func, struct
nvkm_device *device,
volt->vid[i].vid, volt->vid[i].uv);
}
}
+
+ volt->speedo = nvkm_volt_speedo_read(volt);
+ if (volt->speedo > 0)
+ nvkm_debug(&volt->subdev, "speedo %x\n", volt->speedo);
}
int
diff --git a/drm/nouveau/nvkm/subdev/volt/priv.h
b/drm/nouveau/nvkm/subdev/volt/priv.h
index d5140d9..9b34e9f 100644
--- a/drm/nouveau/nvkm/subdev/volt/priv.h
+++ b/drm/nouveau/nvkm/subdev/volt/priv.h
@@ -14,6 +14,7 @@ struct nvkm_volt_func {
int (*vid_get)(struct nvkm_volt *);
int (*vid_set)(struct nvkm_volt *, u8 vid);
int (*set_id)(struct nvkm_volt *, u8 id, int condition);
+ int (*speedo_read)(struct nvkm_volt *);
};
int nvkm_voltgpio_init(struct nvkm_volt *);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 15/37] clk: allow boosting only when NvBoost is set
On 18/04/16 22:13, Karol Herbst wrote:
0: base clock from the vbios is max clock
1: boost only to boost clock from the vbios (default)
As commented upon on IRC, I would prefer us to play it super safe and
stick to the base
clock until we have power monitoring working, at which point we may make
1 the default.
Please change it to keep my R-b :)
2: boost to max clock available
v2: moved into nvkm_cstate_valid
v4: check the existence of the clocks before limiting
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/clk.h | 9 -
drm/nouveau/nvkm/subdev/clk/base.c| 33 -
drm/nouveau/nvkm/subdev/clk/gf100.c | 2 +-
drm/nouveau/nvkm/subdev/clk/gk104.c | 2 +-
4 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drm/nouveau/include/nvkm/subdev/clk.h
b/drm/nouveau/include/nvkm/subdev/clk.h
index 6226f0d..99ee05c 100644
--- a/drm/nouveau/include/nvkm/subdev/clk.h
+++ b/drm/nouveau/include/nvkm/subdev/clk.h
@@ -68,7 +68,8 @@ struct nvkm_pstate {
struct nvkm_domain {
enum nv_clk_src name;
u8 bios; /* 0xff for none */
-#define NVKM_CLK_DOM_FLAG_CORE 0x01
+#define NVKM_CLK_DOM_FLAG_CORE0x01
+#define NVKM_CLK_DOM_FLAG_BASECLK 0x02
u8 flags;
const char *mname;
int mdiv;
@@ -98,6 +99,12 @@ struct nvkm_clk {
int dstate; /* display adjustment (min+) */
bool allow_reclock;
+#define NVKM_CLK_BOOST_NONE 0x0
+#define NVKM_CLK_BOOST_AVG 0x1
+#define NVKM_CLK_BOOST_FULL 0x2
+ u8 boost_mode;
+ u32 base_khz;
+ u32 boost_khz;
/*XXX: die, these are here *only* to support the completely
* bat-shit insane what-was-nouveau_hw.c code
diff --git a/drm/nouveau/nvkm/subdev/clk/base.c
b/drm/nouveau/nvkm/subdev/clk/base.c
index 21f6369..a9a3666 100644
--- a/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drm/nouveau/nvkm/subdev/clk/base.c
@@ -24,6 +24,7 @@
#include "priv.h"
#include
+#include
#include
#include
#include
@@ -77,9 +78,25 @@ nvkm_clk_adjust(struct nvkm_clk *clk, bool adjust,
static bool
nvkm_cstate_valid(struct nvkm_clk *clk, struct nvkm_cstate *cstate, u32
max_volt, int temp)
{
+ const struct nvkm_domain *domain = clk->domains;
struct nvkm_volt *volt = clk->subdev.device->volt;
int voltage;
+ while (domain && domain->name != nv_clk_src_max) {
+ if (domain->flags & NVKM_CLK_DOM_FLAG_BASECLK) {
+ u32 freq = cstate->domain[domain->name];
+ switch (clk->boost_mode) {
+ case NVKM_CLK_BOOST_NONE:
+ if (clk->base_khz && freq > clk->base_khz)
+ return false;
+ case NVKM_CLK_BOOST_AVG:
+ if (clk->boost_khz && freq > clk->boost_khz)
+ return false;
+ }
+ }
+ domain++;
+ }
+
if (!volt)
return true;
@@ -641,10 +658,24 @@ int
nvkm_clk_ctor(const struct nvkm_clk_func *func, struct nvkm_device *device,
int index, bool allow_reclock, struct nvkm_clk *clk)
{
+ struct nvkm_subdev *subdev = &clk->subdev;
+ struct nvkm_bios *bios = device->bios;
int ret, idx, arglen;
const char *mode;
+ struct nvbios_baseclk_header h;
+
+ nvkm_subdev_ctor(&nvkm_clk, device, index, subdev);
+
+ clk->boost_mode = nvkm_longopt(device->cfgopt, "NvBoost",
+ NVKM_CLK_BOOST_AVG);
+ if (bios && !nvbios_baseclock_parse(bios, &h)) {
+ struct nvbios_baseclk_entry base, boost;
+ if (!nvbios_baseclock_entry(bios, &h, h.boost_id, &boost))
+ clk->boost_khz = boost.clock_mhz * 1000;
+ if (!nvbios_baseclock_entry(bios, &h, h.base_id, &base))
+ clk->base_khz = base.clock_mhz * 1000;
+ }
- nvkm_subdev_ctor(&nvkm_clk, device, index, &clk->subdev);
clk->func = func;
INIT_LIST_HEAD(&clk->states);
clk->domains = func->domains;
diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c
b/drm/nouveau/nvkm/subdev/clk/gf100.c
index 78c449b..71b7c9f 100644
--- a/drm/nouveau/nvkm/subdev/clk/gf100.c
+++ b/drm/nouveau/nvkm/subdev/clk/gf100.c
@@ -443,7 +443,7 @@ gf100_clk = {
{ nv_clk_src_hubk06 , 0x00 },
{ nv_clk_src_hubk01 , 0x01 },
{ nv_clk_src_copy , 0x02 },
- { nv_clk_src_gpc, 0x03, 0, "core", 2000 },
+ { nv_clk_src_gpc, 0x03, NVKM_CLK_DOM_FLAG_BASECLK, "core",
2000 },
{ nv_clk_src_rop, 0x04 },
{ nv_clk_src_mem, 0x05, 0, "memory", 1000 },
{ nv_clk_src_vdec , 0x06 },
diff --git a/drm/nouveau/nvkm/subdev/clk/gk104.c
b/drm/nouveau/nvkm/subdev/clk/gk104.c
index 9
Re: [Nouveau] [PATCH v4 13/37] clk: respect voltage limits in nvkm_cstate_prog
On 18/04/16 22:13, Karol Herbst wrote:
we should never allow to select a cstate which current voltage (depending on
the temperature) is higher than
1. the max volt entries in the voltage map table
2. what tha gpu actually can volt to.
this resolves all remaining volting errors on fermi and newer.
v3: use find_best for all cstates before actually trying
add nvkm_cstate_get function to get cstate by index
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/clk/base.c | 83 +-
1 file changed, 74 insertions(+), 9 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/clk/base.c
b/drm/nouveau/nvkm/subdev/clk/base.c
index fecf58f..21f6369 100644
--- a/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drm/nouveau/nvkm/subdev/clk/base.c
@@ -74,6 +74,78 @@ nvkm_clk_adjust(struct nvkm_clk *clk, bool adjust,
/**
* C-States
*/
+static bool
+nvkm_cstate_valid(struct nvkm_clk *clk, struct nvkm_cstate *cstate, u32
max_volt, int temp)
+{
+ struct nvkm_volt *volt = clk->subdev.device->volt;
+ int voltage;
+
+ if (!volt)
+ return true;
+
+ voltage = nvkm_volt_map(volt, cstate->voltage, temp);
+ if (voltage < 0)
+ return false;
+ return voltage <= min(max_volt, volt->max_uv) &&
+ voltage >= volt->min_uv;
+}
+
+static struct nvkm_cstate *
+nvkm_cstate_find_best(struct nvkm_clk *clk, struct nvkm_pstate *pstate,
+ struct nvkm_cstate *start)
+{
+ struct nvkm_device *device = clk->subdev.device;
+ struct nvkm_therm *therm = device->therm;
+ struct nvkm_volt *volt = device->volt;
+ struct nvkm_cstate *cstate;
+ int max_volt, temp = 0;
+
+ if (!pstate || !start)
+ return NULL;
+
+ if (!volt)
+ return start;
+
+ if (therm) {
+ /* ignore error code */
+ temp = max(0, nvkm_therm_temp_get(therm));
+ }
+
+ max_volt = volt->max_uv;
+ if (volt->max0_id != 0xff)
+ max_volt = min(max_volt,
+ nvkm_volt_map(volt, volt->max0_id, temp));
+ if (volt->max1_id != 0xff)
+ max_volt = min(max_volt,
+ nvkm_volt_map(volt, volt->max1_id, temp));
+ if (volt->max2_id != 0xff)
+ max_volt = min(max_volt,
+ nvkm_volt_map(volt, volt->max2_id, temp));
+
+ for (cstate = start; &cstate->head != &pstate->list;
+cstate = list_entry(cstate->head.prev, typeof(*cstate), head)) {
+ if (nvkm_cstate_valid(clk, cstate, max_volt, temp))
+ break;
+ }
+
+ return cstate;
+}
+
+static struct nvkm_cstate *
+nvkm_cstate_get(struct nvkm_clk *clk, struct nvkm_pstate *pstate, int cstatei)
+{
+ struct nvkm_cstate *cstate;
+ if (cstatei == -1)
+ return list_entry(pstate->list.prev, typeof(*cstate), head);
+ else {
+ list_for_each_entry(cstate, &pstate->list, head) {
+ if (cstate->cstate == cstatei)
+ return cstate;
+ }
+ }
+ return NULL;
+}
+
static int
nvkm_cstate_prog(struct nvkm_clk *clk, struct nvkm_pstate *pstate, int
cstatei)
{
@@ -85,15 +157,8 @@ nvkm_cstate_prog(struct nvkm_clk *clk, struct nvkm_pstate
*pstate, int cstatei)
int ret;
if (!list_empty(&pstate->list)) {
- if (cstatei == -1)
- cstate = list_entry(pstate->list.prev, typeof(*cstate),
- head);
- else {
- list_for_each_entry(cstate, &pstate->list, head) {
- if (cstate->cstate == cstatei)
- break;
- }
- }
+ cstate = nvkm_cstate_get(clk, pstate, cstatei);
+ cstate = nvkm_cstate_find_best(clk, pstate, cstate);
} else {
cstate = &pstate->base;
}
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 10/37] add daemon to compare nouveau with blob voltage
On 18/04/16 22:13, Karol Herbst wrote:
this tool can be run alongside the nvidia driver to print information about
the current p/cstate, which voltage was set by nvidia and what nouveau would
set in the same situation.
v4: parse default options
Signed-off-by: Karol Herbst
---
bin/nv_cmp_volt.c | 139 ++
1 file changed, 139 insertions(+)
create mode 100644 bin/nv_cmp_volt.c
diff --git a/bin/nv_cmp_volt.c b/bin/nv_cmp_volt.c
new file mode 100644
index 000..c63d91b
--- /dev/null
+++ b/bin/nv_cmp_volt.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright 2016 Karol Herbst
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Karol Herbst
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "util.h"
+
+int
+main(int argc, char **argv)
+{
+ struct nvif_client if_client;
+ struct nvif_device if_device;
+ struct nvkm_clk *clk;
+ struct nvkm_volt *volt;
+ struct nvkm_device *device;
+ int ret, c;
+ int old_voltage = 0, old_nouveau_voltage = 0, old_pstate = 0;
+ int old_cstate = 0, old_temp = 0;
+
+ while ((c = getopt(argc, argv, U_GETOPT)) != -1) {
+ switch (c) {
+ default:
+ if (!u_option(c))
+ return 1;
+ break;
+ }
+ }
+
+ ret = u_device("lib", argv[0], "error", true, true,
+ (1ULL << NVKM_SUBDEV_CLK) |
+// (1ULL << NVKM_SUBDEV_FUSE) |
+ (1ULL << NVKM_SUBDEV_GPIO) |
+// (1ULL << NVKM_SUBDEV_I2C) |
+ (1ULL << NVKM_SUBDEV_PCI) |
+// (1ULL << NVKM_SUBDEV_THERM) |
+// (1ULL << NVKM_SUBDEV_TIMER) |
// is not a C thing, it is only in c++. Please use /* */
Now, this is also a good place to say why ptherm is problematic for you
and how you will just read the reg instead.
+ (1ULL << NVKM_SUBDEV_VBIOS) |
+ (1ULL << NVKM_SUBDEV_VOLT),
+ 0x, &if_client, &if_device);
+
+ if (ret < 0)
+ return ret;
+
+ device = nvxx_device(&if_device);
+ clk = device->clk;
+// therm = device->therm;
I would say get rid of this commented code.
+ volt = device->volt;
+
+ printf("current voltage (µV), expected voltage (µV), abs diff (µV),"
+ "rel diff nouveau/nvidia (%%), pstate, cstate, temperature"
+ "(°C)\n");
+ while (true) {
+ int gpc_clock = nvkm_clk_read(clk, nv_clk_src_gpc);
+ int mem_clock = nvkm_clk_read(clk, nv_clk_src_mem);
+ struct nvkm_pstate *pstate = NULL, *best_pstate = NULL;
+ struct nvkm_cstate *cstate = NULL, *best_cstate = NULL;
+ int mem_err, gpc_err;
+ int new_voltage, new_nouveau_voltage, new_pstate, new_cstate;
+ int new_temp;
+
/* try to map the clocks set by NVIDIA to the closest pstate/cstate */
+ list_for_each_entry(pstate, &clk->states, head) {
+ list_for_each_entry(cstate, &pstate->list, head) {
+ if (!best_pstate) {
+ best_pstate = pstate;
+ best_cstate = cstate;
+ gpc_err =
abs(cstate->domain[nv_clk_src_gpc] - gpc_clock);
+ mem_err =
abs(cstate->domain[nv_clk_src_mem] - mem_clock);
+ continue;
+ }
+
+ if (abs(cstate->domain[nv_clk_src_gpc] - gpc_clock) <=
gpc_err &&
+ abs(cstate->domain[nv_clk_src_mem] -
mem_clock) <= mem_err) {
+ best_
Re: [Nouveau] [PATCH v4 11/37] volt: add temperature parameter to nvkm_volt_map
On 18/04/16 22:13, Karol Herbst wrote:
the voltage entries actually may map to a different voltage depending on the
current temperature.
v2: only read the temperatue when actually needed
temperatue -> temperature
Signed-off-by: Karol Herbst
---
bin/nv_cmp_volt.c | 2 +-
drm/nouveau/include/nvkm/subdev/volt.h | 2 +-
drm/nouveau/nvkm/subdev/volt/base.c| 14 ++
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/bin/nv_cmp_volt.c b/bin/nv_cmp_volt.c
index c63d91b..34147b9 100644
--- a/bin/nv_cmp_volt.c
+++ b/bin/nv_cmp_volt.c
@@ -117,7 +117,7 @@ main(int argc, char **argv)
new_voltage = nvkm_volt_get(volt);
new_temp = nvkm_rd32(device,
0x20400);//nvkm_therm_temp_get(therm);
- new_nouveau_voltage = max(nvkm_volt_map(volt,
best_cstate->voltage), nvkm_volt_map(volt, best_pstate->base.voltage));
+ new_nouveau_voltage = max(nvkm_volt_map(volt,
best_cstate->voltage, new_temp), nvkm_volt_map(volt, best_pstate->base.voltage,
new_temp));
new_pstate = best_pstate->pstate;
new_cstate = best_cstate->cstate;
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h b/drm/nouveau/include/nvkm/subdev/volt.h
index 870d212..f223577 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -22,7 +22,7 @@ struct nvkm_volt {
u8 max2_id;
};
-int nvkm_volt_map(struct nvkm_volt *volt, u8 id);
+int nvkm_volt_map(struct nvkm_volt *volt, u8 id, u8 temperature);
int nvkm_volt_map_min(struct nvkm_volt *volt, u8 id);
int nvkm_volt_get(struct nvkm_volt *);
int nvkm_volt_set_id(struct nvkm_volt *, u8 id, u8 min_id, int condition);
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index 6fb9d2e..d72bd4a 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
int
nvkm_volt_get(struct nvkm_volt *volt)
@@ -88,7 +89,7 @@ nvkm_volt_map_min(struct nvkm_volt *volt, u8 id)
}
int
-nvkm_volt_map(struct nvkm_volt *volt, u8 id)
+nvkm_volt_map(struct nvkm_volt *volt, u8 id, u8 temp)
{
struct nvkm_bios *bios = volt->subdev.device->bios;
struct nvbios_vmap_entry info;
@@ -98,7 +99,7 @@ nvkm_volt_map(struct nvkm_volt *volt, u8 id)
vmap = nvbios_vmap_entry_parse(bios, id, &ver, &len, &info);
if (vmap) {
if (info.link != 0xff) {
- int ret = nvkm_volt_map(volt, info.link);
+ int ret = nvkm_volt_map(volt, info.link, temp);
if (ret < 0)
return ret;
info.min += ret;
@@ -112,18 +113,23 @@ nvkm_volt_map(struct nvkm_volt *volt, u8 id)
int
nvkm_volt_set_id(struct nvkm_volt *volt, u8 id, u8 min_id, int condition)
{
+ struct nvkm_therm *therm = volt->subdev.device->therm;
int ret;
/* Set the default temperature to 0°C as it always produces the
* highest possible voltage which is the safest from a stability point of
* view. This may be overridden later if the temperature can be read.
*/
+ int temp = 0;
if (volt->func->set_id)
return volt->func->set_id(volt, id, condition);
- ret = nvkm_volt_map(volt, id);
+ if (therm)
+ temp = nvkm_therm_temp_get(therm);
temp = max(0, nvkm_therm_temp_get(therm));
+
+ ret = nvkm_volt_map(volt, id, max(temp, 0));
s/max(temp, 0)/temp/g
if (ret >= 0) {
int prev = nvkm_volt_get(volt);
if (!condition || prev < 0 ||
(condition < 0 && ret < prev) ||
(condition > 0 && ret > prev)) {
- int min = nvkm_volt_map(volt, min_id);
+ int min = nvkm_volt_map(volt, min_id, max(temp, 0));
s/max(temp, 0)/temp/g
if (min >= 0)
ret = max(min, ret);
ret = nvkm_volt_set(volt, ret);
With the commit message and the max() duplication fixed, this is:
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 08/37] clk: export nvkm_volt_map
On 18/04/16 22:13, Karol Herbst wrote:
before clocking to a cstate, we have to check if the voltage is within the
allowed range.
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/volt.h | 1 +
drm/nouveau/nvkm/subdev/volt/base.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index ec9d87d..870d212 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -22,6 +22,7 @@ struct nvkm_volt {
u8 max2_id;
};
+int nvkm_volt_map(struct nvkm_volt *volt, u8 id);
int nvkm_volt_map_min(struct nvkm_volt *volt, u8 id);
int nvkm_volt_get(struct nvkm_volt *);
int nvkm_volt_set_id(struct nvkm_volt *, u8 id, u8 min_id, int condition);
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index 1690c1c..6fb9d2e 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -87,7 +87,7 @@ nvkm_volt_map_min(struct nvkm_volt *volt, u8 id)
return id ? id * 1 : -ENODEV;
}
-static int
+int
nvkm_volt_map(struct nvkm_volt *volt, u8 id)
{
struct nvkm_bios *bios = volt->subdev.device->bios;
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 06/37] volt: parse the max voltage map entries
On 18/04/16 22:13, Karol Herbst wrote:
There are at least three "max" entries, which specify the max voltage. Because
they are actually normal voltage map entries, they can also be affected by the
temperature.
Nvidia respects those entries and if they get changed, nvidia uses the lower
voltage from both.
both ;) I guess it is time to update this to: from the three of them.
We shouldn't exceed those voltages at any given time.
v2: state what those entries do in the source
v3: add the third max entry
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/bios/vmap.h | 3 +++
drm/nouveau/include/nvkm/subdev/volt.h | 5 +
drm/nouveau/nvkm/subdev/bios/vmap.c | 10 ++
drm/nouveau/nvkm/subdev/volt/base.c | 13 +
4 files changed, 31 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
index 6633c6d..ae2f27b 100644
--- a/drm/nouveau/include/nvkm/subdev/bios/vmap.h
+++ b/drm/nouveau/include/nvkm/subdev/bios/vmap.h
@@ -1,6 +1,9 @@
#ifndef __NVBIOS_VMAP_H__
#define __NVBIOS_VMAP_H__
struct nvbios_vmap {
+ u8 max0;
+ u8 max1;
+ u8 max2;
};
u16 nvbios_vmap_table(struct nvkm_bios *, u8 *ver, u8 *hdr, u8 *cnt, u8 *len);
diff --git a/drm/nouveau/include/nvkm/subdev/volt.h
b/drm/nouveau/include/nvkm/subdev/volt.h
index fc68825..285c6bf 100644
--- a/drm/nouveau/include/nvkm/subdev/volt.h
+++ b/drm/nouveau/include/nvkm/subdev/volt.h
@@ -15,6 +15,11 @@ struct nvkm_volt {
u32 max_uv;
u32 min_uv;
+
+ /* max voltage map entries, might be affected by temperature */
might be affected *differently* by temperature.
+ u8 max0_id;
+ u8 max1_id;
+ u8 max2_id;
};
int nvkm_volt_map_min(struct nvkm_volt *volt, u8 id);
diff --git a/drm/nouveau/nvkm/subdev/bios/vmap.c
b/drm/nouveau/nvkm/subdev/bios/vmap.c
index 2f13db7..f2295e1 100644
--- a/drm/nouveau/nvkm/subdev/bios/vmap.c
+++ b/drm/nouveau/nvkm/subdev/bios/vmap.c
@@ -61,7 +61,17 @@ nvbios_vmap_parse(struct nvkm_bios *bios, u8 *ver, u8 *hdr,
u8 *cnt, u8 *len,
memset(info, 0x00, sizeof(*info));
switch (!!vmap * *ver) {
case 0x10:
+ info->max0 = 0xff;
+ info->max1 = 0xff;
+ info->max2 = 0xff;
+ break;
case 0x20:
+ info->max0 = nvbios_rd08(bios, vmap + 0x7);
+ info->max1 = nvbios_rd08(bios, vmap + 0x8);
+ if (*len >= 0xc)
+ info->max2 = nvbios_rd08(bios, vmap + 0xc);
+ else
+ info->max2 = 0xff;
break;
}
return vmap;
diff --git a/drm/nouveau/nvkm/subdev/volt/base.c
b/drm/nouveau/nvkm/subdev/volt/base.c
index ecf4cb4..63fffb8 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -217,9 +217,22 @@ nvkm_volt_ctor(const struct nvkm_volt_func *func, struct
nvkm_device *device,
/* Assuming the non-bios device should build the voltage table later */
if (bios) {
+ u8 ver, hdr, cnt, len;
+ struct nvbios_vmap vmap;
+
nvkm_volt_parse_bios(bios, volt);
nvkm_debug(&volt->subdev, "min: %iuv max: %iuv\n",
volt->min_uv, volt->max_uv);
+
+ if (nvbios_vmap_parse(bios, &ver, &hdr, &cnt, &len, &vmap)) {
+ volt->max0_id = vmap.max0;
+ volt->max1_id = vmap.max1;
+ volt->max2_id = vmap.max2;
+ } else {
+ volt->max0_id = 0xff;
+ volt->max1_id = 0xff;
+ volt->max2_id = 0xff;
+ }
}
if (volt->vid_nr) {
With the comment and commit message fixed:
Reviewed-by: Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94990] Latest 4.6rc4 kernel, no booting on gtx970
https://bugs.freedesktop.org/show_bug.cgi?id=94990 --- Comment #10 from mirkorol...@googlemail.com --- Created attachment 123065 --> https://bugs.freedesktop.org/attachment.cgi?id=123065&action=edit Config File The .config File. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] more one question regarding gl and nouveau
Wow! Things go deep... :) Thank you very much. 2016-04-19 11:44 GMT-04:00 Ilia Mirkin : > On Tue, Apr 19, 2016 at 11:01 AM, Daniel Melo Jorge da Cunha > wrote: > > Hi Ilia, you were straight to the point for me in: > > > > "src/mesa/vbo will upload it to a vbo. The driver then points the > > hardware at the vbo and tells it to read from there." > > > > But where is it the function that implements this? Is it in > > nv30_draw_vbo(...)? Please, give me a function name or > > at least a file name? > > Before draw_vbo is called, the vbo will have been set up via > pipe->bind_vertex_elements_state and pipe->set_vertex_buffers. The > draw call will then validate those, by calling nv30_state_validate (or > something along those lines) which will look at all the dirtied state > and write that out to hw. > > There are also funny interactions with translate... for formats that > aren't directly supported. > > -ilia > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] more one question regarding gl and nouveau
On Tue, Apr 19, 2016 at 11:01 AM, Daniel Melo Jorge da Cunha wrote: > Hi Ilia, you were straight to the point for me in: > > "src/mesa/vbo will upload it to a vbo. The driver then points the > hardware at the vbo and tells it to read from there." > > But where is it the function that implements this? Is it in > nv30_draw_vbo(...)? Please, give me a function name or > at least a file name? Before draw_vbo is called, the vbo will have been set up via pipe->bind_vertex_elements_state and pipe->set_vertex_buffers. The draw call will then validate those, by calling nv30_state_validate (or something along those lines) which will look at all the dirtied state and write that out to hw. There are also funny interactions with translate... for formats that aren't directly supported. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] more one question regarding gl and nouveau
Hi Ilia, you were straight to the point for me in: "src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there." But where is it the function that implements this? Is it in nv30_draw_vbo(...)? Please, give me a function name or at least a file name? 2016-04-19 10:04 GMT-04:00 Ilia Mirkin : > On Tue, Apr 19, 2016 at 8:52 AM, Daniel Melo Jorge da Cunha > wrote: > > Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card > > processes > > these three floats? Does the card work with floats? Does (mesa? gallium? > > driver?) > > process these three input floats before it is sent to the card? Where is > the > > code > > for it? > > src/mesa/vbo will upload it to a vbo. The driver then points the > hardware at the vbo and tells it to read from there. (Under some > circumstances, the vbo data might have to be transformed on the cpu as > well if the driver can't handle the format.) > > > > > If you say the floats are memory mapped as in > > exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would > > say > > from what I learned that it has to pass through gallium and that means: > > st_draw_vbo(...) ending up in nv30_draw_vbo(..) but these functions don't > > make > > any reference to those (memory mapped) input floats. So where is the > piece > > of > > code that instructs the card to fetch those three (possibly processed) > input > > floats > > and send them to the card? > > > > Thanks in advance. > > The vbo module converts this to the equivalent of > > glGenBuffers(1, &buf) > glBindBuffer(GL_ARRAY_BUFFER, buf) > glBufferData(GL_ARRAY_BUFFER, ...) > foo = glMapBuffer(buf) > write vertex values to foo > glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, 0); > draw > > Hope that helps, > > -ilia > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] more one question regarding gl and nouveau
On Tue, Apr 19, 2016 at 8:52 AM, Daniel Melo Jorge da Cunha wrote: > Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card > processes > these three floats? Does the card work with floats? Does (mesa? gallium? > driver?) > process these three input floats before it is sent to the card? Where is the > code > for it? src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there. (Under some circumstances, the vbo data might have to be transformed on the cpu as well if the driver can't handle the format.) > > If you say the floats are memory mapped as in > exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would > say > from what I learned that it has to pass through gallium and that means: > st_draw_vbo(...) ending up in nv30_draw_vbo(..) but these functions don't > make > any reference to those (memory mapped) input floats. So where is the piece > of > code that instructs the card to fetch those three (possibly processed) input > floats > and send them to the card? > > Thanks in advance. The vbo module converts this to the equivalent of glGenBuffers(1, &buf) glBindBuffer(GL_ARRAY_BUFFER, buf) glBufferData(GL_ARRAY_BUFFER, ...) foo = glMapBuffer(buf) write vertex values to foo glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, 0); draw Hope that helps, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] more one question regarding gl and nouveau
Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card processes these three floats? Does the card work with floats? Does (mesa? gallium? driver?) process these three input floats before it is sent to the card? Where is the code for it? If you say the floats are memory mapped as in exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would say from what I learned that it has to pass through gallium and that means: st_draw_vbo(...) ending up in nv30_draw_vbo(..) but these functions don't make any reference to those (memory mapped) input floats. So where is the piece of code that instructs the card to fetch those three (possibly processed) input floats and send them to the card? Thanks in advance. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92126] [NVE4] GTX 760 Auto fan speed stays at 10% until temp hits 90C
https://bugs.freedesktop.org/show_bug.cgi?id=92126 --- Comment #7 from Karol Herbst --- (In reply to daemon32 from comment #6) > (In reply to Karol Herbst from comment #5) > > Is this bug fixed in recent kernels? (4.5 I think?) > > Well, sort of, the fan spins up, but it takes off like a jet engine at a > mere 50° C. (I'm using your out-of-tree module currently) ahh okay. Well there are some known fan issues left, we try to investigate it as soon as possible. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94990] Latest 4.6rc4 kernel, no booting on gtx970
https://bugs.freedesktop.org/show_bug.cgi?id=94990 --- Comment #9 from mirkorol...@googlemail.com --- (In reply to Alexandre Courbot from comment #8) > Ok, md5sums are correct, so your firmware is not corrupted. > > I will try to reproduce on the same setup as you (GTX970/4.6-rc4) - can you > confirm that you are using pure 4.6-rc4 without any extra patch? Also, can > you run > > $ cat /proc/config.gz >config.gz > > and attach the created config.gz file? > > Thanks! Yes, its a clean 4.6-rc4, from kernel.org. I Post the .config in 10h. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
