https://bugs.freedesktop.org/show_bug.cgi?id=94990
--- Comment #59 from Ilia Guterman ---
It increases the size of nv50_instobj objects that report the size of 0x3000.
Struct "nv50_instobj" has size of 0x3000 but it's parent structure
"nvkm_gpuobj" reports different size, a size of 0x97000.
All
https://bugs.freedesktop.org/show_bug.cgi?id=94990
--- Comment #58 from Florian Mickler ---
Created attachment 125833
--> https://bugs.freedesktop.org/attachment.cgi?id=125833&action=edit
dmesg with patch 125656 applied. everything else fedora stock...
--
You are receiving this mail because:
patches are on my reclocking_part_1 branch and I already fixed the
commit message of patch 3 there.
2016-08-16 22:46 GMT+02:00 Karol Herbst :
> I've splitted my big series between the part which actually fixes the
> engine reclocking bits and the part handling voltage/clock updates on
> temperatur
https://bugs.freedesktop.org/show_bug.cgi?id=94990
--- Comment #57 from Florian Mickler ---
(In reply to Ilia Guterman from comment #55)
> Created attachment 125656 [details] [review]
> 0001-nvkm_gpuobj-size-is-smaller-then-nvkm_gpuobj-size-ca.patch
>
> After some messing around i am able to boo
This enables memory reclocking on Maxwell. Sadly without a PMU firmware it
is useless for gm20x gpus.
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/fb/ram.h | 1 +
drm/nouveau/nvkm/subdev/fb/ramgk104.c | 8 +++-
drm/nouveau/nvkm/subdev/fb/ramgm107.c | 12 +---
3 file
Since gf100 we need a speedo value for calculating the voltage. The readout
will be added in a later patch.
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
This way other subdevs can notify the clk subdev about temperature changes
without the need of clk to poll that value.
Also make this function safe to be called from an interrupt handler.
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/clk.h | 4 ++--
drm/nouveau/nvkm/subdev/cl
This table contains three important clocks:
base clock: This is the non boosted max clock.
tdp clock: The clock at wich the vbios guarentees the TDP won't ever be
exceeded at max load (seems to be always the same as the base
clock, but behaves differently).
boost clock
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.
v5: Initialize best_err with volt->max_uv.
Signed-off-by: Karol Herbst
Reviewed-by: Martin Pere
I'm quite sure that those coefficients are real close, because while
testing the biggest error compared to nvidia was around -1.5% (biggest
error with right coefficients is 12.5mV / 600mV = 2%).
These coefficients were REed by modifing the voltage map entries and by
calculating the set voltage bac
Signed-off-by: Karol Herbst
Tested-by: Aidan Epstein
---
drm/nouveau/nvkm/subdev/fb/ramgk104.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/fb/ramgk104.c
b/drm/nouveau/nvkm/subdev/fb/ramgk104.c
index 1fa3ade..93b30d9 100644
--- a/
v5: Squashed speedo related commits.
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/volt.h | 2 ++
drm/nouveau/nvkm/subdev/volt/base.c| 24
drm/nouveau/nvkm/subdev/volt/gf100.c | 26 ++
drm/nouvea
Each pstate has its own voltage map entry like each cstate has.
The voltages of those entries act as a floor value for the currently
selected pstate and nvidia never sets a voltage below them.
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/include/nvkm/subdev/volt.h | 2
0: base clock from the vbios is max clock (default)
1: boost only to boost clock from the vbios
2: boost to max clock available
v2: Moved into nvkm_cstate_valid.
v4: Check the existence of the clocks before limiting.
v5: Default to boost level 0.
Signed-off-by: Karol Herbst
Reviewed-by: Martin P
Depending on the value a different formular is used to calculated the
voltage for this entry.
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 del
Signed-off-by: Karol Herbst
---
drm/nouveau/nvkm/subdev/clk/base.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/clk/base.c
b/drm/nouveau/nvkm/subdev/clk/base.c
index 7102c25..1defd32 100644
--- a/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drm/nou
Now the cstatei parameter can be used of the nvkm_cstate_prog function to
select a specific cstate.
v5: Make a constant for the magic value.
Use list_last_entry.
Add nvkm_cstate_get here instead of in the next commit.
Signed-off-by: Karol Herbst
---
drm/nouveau/include/nvkm/subdev/clk.h
I've splitted my big series between the part which actually fixes the
engine reclocking bits and the part handling voltage/clock updates on
temperature change, so that the more reviewed parts can be merged in
faster.
This series fixes a lot of Engine reclocking issues found on Fermi, Kepler
and al
The voltage entries actually may map to a different voltage depending on
the current temperature.
v2: Only read the temperature when actually needed.
v5: Be smarter about using max().
Don't read the temperature anymore.
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/
It is better to read out the id out of the cstate struct directly instead
of iterating over the list of cstates over and over again. Especially when
we start saving pointers to a nvkm_cstate struct, it makes things easier.
v5: Rename field to id.
Signed-off-by: Karol Herbst
---
drm/nouveau/incl
nvkm_volt_map_min is a copy of nvkm_volt_map, which always returns the
lowest possible voltage for a cstate.
nvkm_volt_map will get a temperature parameter there later and also fix
the voltage calculation, so that this functions will be completly
different later.
Signed-off-by: Karol Herbst
Revi
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 all three.
We shouldn't exceed those
Some Fermi+ GPUs specify VID information via voltage table entries, rather
than describing them as a range in the header.
The mask may be bigger than 0x1f, but this value is already >2V, so it
will be fine for now.
This patch fixes volting issues on those cards enabling them to switch
cstates
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.
v3: Use find_best for all cstates before actually trying.
Add nvkm_cstate_get function to get cs
There is a field in the voltage table which tells us if the VIDs are taken
from the entries or calculated through the header.
v2: Don't break older versions.
v5: Reverse flag name.
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
Tested-by: Pierre Moreau
---
drm/nouveau/include/nvkm/subd
https://bugs.freedesktop.org/show_bug.cgi?id=97367
--- Comment #3 from Mathieu Maret ---
With another try having modeset=2 does not produce a normal amount of IRQ.
Sorry for the error, it should be due to the randomness of the issue :/
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=97367
--- Comment #2 from Mathieu Maret ---
Created attachment 125821
--> https://bugs.freedesktop.org/attachment.cgi?id=125821&action=edit
dmesg with debug (nouveau.debug=debug drm.debug=0xe)
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=97367
--- Comment #1 from Mathieu Maret ---
Created attachment 125819
--> https://bugs.freedesktop.org/attachment.cgi?id=125819&action=edit
vbios ROM
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=97367
Bug ID: 97367
Summary: k520 card produce high volume of IRQ
Product: xorg
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=31122
A. Chaud changed:
What|Removed |Added
Attachment #125547|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=93887
--- Comment #48 from Pierre Moreau ---
That looks way better, thanks! I’ll have a look at it this evening.
--
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing
31 matches
Mail list logo
