Signed-off-by: Martin Peres martin.pe...@free.fr
Tested-by: SaveTheRobots john.rowle...@gmail.com
---
drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c
b/drivers/gpu/drm/nouveau/core/subdev/therm
From: Martin Peres martin.pe...@labri.fr
I spent some time this weekend trying to find in the vbios the number of
pulses per revolutions in the vbios but couldn't find it. It would seem
all my cards have 2 pulses per revolution so let's stick to that until
further notice.
Thermal table's id 0x48
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Martin Peres martin.pe...@free.fr
---
nvkm/subdev/bios/base.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/nvkm/subdev/bios/base.c b/nvkm/subdev/bios/base.c
index 3de7d81..5f8643d 100644
--- a/nvkm
Le 24/03/2014 02:03, Martin Peres a écrit :
From: Martin Peres martin.pe...@labri.fr
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would
rewrite.
Suggested-by: Christian Zander czan...@nvidia.com
Signed-off-by: Martin Peres martin.pe...@free.fr
---
nvkm/subdev/bios/base.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/nvkm/subdev/bios/base.c b/nvkm/subdev/bios/base.c
index
On 25/03/2014 23:24, Ilia Mirkin wrote:
On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres martin.pe...@free.fr wrote:
Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA,
Maxwell or Kepler?
Damn, I meant Kepler.
I updated the patch in my git tree:
http
On 25/03/2014 17:17, Christian Zander wrote:
On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote:
Hello,
One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM
at boot time but, if I blacklist the module and load it myself later on,
it always succeeds. To make things
Hello,
One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM
at boot time but, if I blacklist the module and load it myself later on,
it always succeeds. To make things weirder, the same card works great on
another computer.
Here is the relevant code in Nouveau to fetch the
From: Martin Peres martin.pe...@labri.fr
This should fix automatic fan management on fermi cards who do not have
0x46 entries in the thermal table.
On my nve6, the blob sets the default linear range from 40°C to 100°C
but my nvcf's default values are 40°C to 85°C. Let's keep 85 as a default
From: Martin Peres martin.pe...@labri.fr
This should fix fan management on many nvd7+ chipsets.
Signed-off-by: Martin Peres martin.pe...@labri.fr
Tested-by: Timothée Ravier t...@siosm.fr
---
nvkm/include/subdev/therm.h | 2 +-
nvkm/subdev/therm/fan.c | 3 ++-
nvkm/subdev/therm/fanpwm.c
At boot time, on one of my desktop PC and one of my card, Nouveau fails to
boot because the vbios is corrupted. If I blacklist the module and load it
after, it works fine. Also, this card on another computer works fine and other
cars on this desktop work directly (I would need to check more cards
From: Martin Peres martin.pe...@labri.fr
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update
Le 14/03/2014 00:48, Martin Peres a écrit :
From: Martin Peres martin.pe...@labri.fr
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would
Le 13/03/2014 14:38, Ilia Mirkin a écrit :
On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
[ 326.168487] ==
[ 326.168491] [ INFO: possible circular locking dependency detected ]
[ 326.168496] 3.13.6 #1270 Not
From: Martin Peres martin.pe...@labri.fr
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update
Hi, fellow graphics stack developers,
Now that FOSDEM is over, it is time to think about the
Google Summer of Code 2014!
If you would like to propose a project for the GSoC 2014, please
write your proposals at [1], before the 14th of February, in order
to increase our chances of being an
Le 12/12/2013 08:58, Matthias Nagel a écrit :
Hi Martin,
if you refer to my kernel version. 3.10.17 is the latest, stable
version in the official gentoo repository for the amd64 architeture.
See here
...
[4] https://packages.gentoo.org/package/sys-kernel/gentoo-sources?full_cat
As long as I
,
Martin Peres
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
From: Martin Peres martin.pe...@labri.fr
This patch is a follow-up from Ilia Mirkin's enable H.264 patch which
solves the problem that prevented MPEG-4 videos to play correctly.
Tested on an nva3.
Signed-off-by: Martin Peres martin.pe...@labri.fr
Tested-by: Martin Peres martin.pe...@labri.fr
Cc
On 07/12/2013 17:09, Ilia Mirkin wrote:
On Sat, Dec 7, 2013 at 8:11 AM, Martin Peres martin.pe...@free.fr wrote:
From: Martin Peres martin.pe...@labri.fr
This patch is a follow-up from Ilia Mirkin's enable H.264 patch which
solves the problem that prevented MPEG-4 videos to play correctly
On 23/09/2013 17:42, Moritz Meiser wrote:
Hi,
I would like to donate my GT630 card (which is actually Fermi/NVC0 family
based) to support Nouveau's further development for this hardware generation.
It's this model: http://www.inno3d.com/product/gt630_4gb_dual.html
Anyone interested?
Regards,
From: Martin Peres martin.pe...@labri.fr
This should enable automatic fan management for all cards by default, at
boot time. However, this commit actually affects only nv40-c0 as nvc0+
cards already have vbios's PDAEMON fw already taking care of fan management.
Signed-off-by: Martin Peres
From: Martin Peres martin.pe...@labri.fr
This is safe because ptherm hasn't been configured yet and will be a
little further down the initialization path. Ptherm should be safe
regarding to runtime reconfiguration.
v2:
- do not limit this patch to nv84-a3 and make it nv84+
v3:
- move
On 04/09/2013 03:52, Ben Skeggs wrote:
On Sat, Aug 31, 2013 at 10:06 AM, Martin Peres martin.pe...@free.fr wrote:
From: Martin Peres martin.pe...@labri.fr
This is safe because ptherm hasn't been configured yet and will be a
little further down the initialization path. Ptherm should be safe
On 04/09/2013 03:55, Ben Skeggs wrote:
On Sat, Aug 31, 2013 at 9:58 AM, Martin Peres martin.pe...@free.fr wrote:
From: Martin Peres martin.pe...@labri.fr
Some vbioses have extra useless entries after the end of the table. This is
problematic since all of the vbios I found with this issue
From: Martin Peres martin.pe...@labri.fr
Some vbioses have extra useless entries after the end of the table. This is
problematic since all of the vbios I found with this issue redefine the
pwm freq divider to insane levels (52750 Hz instead of 2500), thus breaking
fan management.
The first
From: Martin Peres martin.pe...@labri.fr
This is safe because ptherm hasn't been configured yet and will be a
little further down the initialization path. Ptherm should be safe
regarding to runtime reconfiguration.
Signed-off-by: Martin Peres martin.pe...@labri.fr
---
drivers/gpu/drm/nouveau
From: Martin Peres martin.pe...@labri.fr
This is safe because ptherm hasn't been configured yet and will be a
little further down the initialization path. Ptherm should be safe
regarding to runtime reconfiguration.
v2:
- do not limit this patch to nv84-a3 and make it nv84+
Signed-off-by: Martin
There are still some rendering issues on my nvc4, but the framerate is
much smoother than it was before this patch.
Tested-by: Martin Peres martin.pe...@labri.fr
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index d506da5..762bfcd 100644
On 03/02/2013 21:07, Marcin Slusarz wrote:
+ the same for shutdown threshold - seems impossible, but shutdown can fail.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Looks good. Please add my signed-off-by
Signed-off-by: Martin Peres martin.pe...@labri.fr
---
drivers/gpu/drm
On 03/02/2013 21:07, Marcin Slusarz wrote:
Current uninitialized sensor detection does not work for me on nv4b and
sensor returns crazy values (190°C). It stabilises later, but it's too
late - therm code shutdowns the machine...
Let's just reset it on init.
Signed-off-by: Marcin Slusarz
On 03/02/2013 21:07, Marcin Slusarz wrote:
orderly_poweroff cannot be called from atomic context.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Oops, my bad. Please add my signed-off-by.
___
Nouveau mailing list
From: Martin Peres martin.pe...@labri.fr
This fixes a bug where, when temperature is outside of the linear range, fan
pwm would be outside of the allowed range ([0, 100]) and could get negative in
some cases.
It seems like a regression that happened when we re-worked the fan management
logic
Hi Nouveau enthusiasts,
One week ago was merged the thermal/fan management code for most nvidia
cards.
So far, no major issue arose but we would like to have more testing as
soon as possible to deliver a nice and solid support when Linux 3.8 is
released.
Thermal management is split into
From: Martin Peres martin.pe...@labri.fr
This should avoid the situation where a user gets its kernel logs flooded when
temperature oscillates around a threshold with 0°C hysteresis.
This patch is just meant to fix broken vbios (as reported on a nv4e on
sysfs hwmon interface.
Signed-off
On 10/17/12 22:11, Nilton Teixeira wrote:
Please, I tried to install xserver-xorg-video-nouveau and Xterm (Linux
Ubuntu) returned this information: /xserver-xorg-video-nouveau
configurado para instalar manualmente/ (xserver-xorg-video-nouveau
set to install manually. How should I proceed?
On 26/08/2012 23:05, Mark Carey wrote:
v2 spaces to tabs as per RSpliets feedback on IRC
Hi Mark,
Thanks for the patch, it is indeed needed :)
However, I don't like the wording. Instead of telling that it isn't
normal, we don't tell what should be done neither what it will impact.
I guess
On 02/05/2012 13:28, Ben Skeggs wrote:
Right, again, I don't disagree :) I think we can improve a lot on the
big-hammer-suspend-the-gpu solution though, and instead reset only the
faulting engine. It's (in theory) almost possible for us to do now, but
I have a couple of reworks to areas
On 02/05/2012 15:48, Ben Skeggs wrote:
On Wed, 2012-05-02 at 15:33 +0200, Martin Peres wrote:
On 02/05/2012 13:28, Ben Skeggs wrote:
Right, again, I don't disagree :) I think we can improve a lot on the
big-hammer-suspend-the-gpu solution though, and instead reset only the
faulting engine
Le 28/04/2012 16:56, Marcin Slusarz a écrit :
On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote:
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing
Le 24/04/2012 20:14, Maarten Maathuis a écrit :
Do you get rendering errors also when using a nv50 class gpu? I seem
to get them in firefox.
I also noticed a huge amount of failures when running rendercheck -t
gradients, which i find odd, because they are not supposed to be
accelerated.
Hi,
Le 24/04/2012 20:49, Maarten Maathuis a écrit :
On Tue, Apr 24, 2012 at 8:36 PM, Martin Peresmartin.pe...@free.fr wrote:
Le 24/04/2012 20:14, Maarten Maathuis a écrit :
Do you get rendering errors also when using a nv50 class gpu? I seem
to get them in firefox.
I also noticed a huge amount
Le 23/04/2012 18:32, Marcin Slusarz a écrit :
Just run piglit. Even quick tests can cause ~5 lockups (it eventually messes
up DDX channel, but this patchset can't fix this case).
You can run fs-discard-exit-2 test first - for me it causes instant GPU lockup.
Marcin
Great, Thanks.
Did you
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
Signed-off-by: Marcin Slusarzmarcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
Le 03/04/2012 11:03, Meelis Roos a écrit :
This time, memory timing table is not unknown, but voltage tabele
still is, and only 0 available performance levels instead of 8 empty
ones. Also, monitor is not attached at the moment, used somewhere else.
Looks better, indeed.
Could you send us
Le 17/01/2012 21:55, Lucas Stach a écrit :
Isn't it possible that the performance regression seen with xfer
disabled by default is caused by slow memory clock speed? Martin, you
saw only a 1% performance drop on your 8600 which is running with full
speed by default. Marcins nv92 is likely
on
the actual results!
By the mean time, I'll plug it to a PM brain so as it would switch back
and forth between the two modes according to the load or the perflvl.
Take care,
Martin
From 8e6667c87074b1b519fef0946083d46d01dfe8a0 Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@labri.fr
Date
On 28/12/2011 22:39, Marcin Slusarz wrote:
Heh, with page flipping enabled, regression is still there, only smaller
(61-54, instead of 49 FPS).
I want my Nouveau performance back ;)
---
From: Marcin Slusarzmarcin.slus...@gmail.com
Subject: [PATCH] drm/nv50/gr: make xfers only in ctxprog
Le 01/11/2011 11:41, Martin Peres a écrit :
Signed-off-by: Martin Peresmartin.pe...@labri.fr
---
drivers/gpu/drm/nouveau/nv50_pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index e7ff5ac
Le 09/11/2011 23:10, Marcin Slusarz a écrit :
For anyone who don't read IRC logs - it turns out it regressed only on
my box, because I have page flipping disabled (due to page flipping
being very buggy here, see
https://bugs.freedesktop.org/show_bug.cgi?id=42398), which forces gpu
context
Signed-off-by: Martin Peres martin.pe...@labri.fr
---
drivers/gpu/drm/nouveau/nv50_pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index e7ff5ac..e025cae 100644
--- a/drivers/gpu/drm/nouveau
Le 31/08/2011 13:48, Mr Dash Four a écrit :
The implemented fan management support
---
Current fan management should only work on what we call PWM fans.
This work should be usable up to (not including) nva3 chipset
generation.
This is
Hi Nouveau users,
Just saw the bitching on Phoronix about lack of fan management in
nouveau (no offence Michael, it was justified ;) ).
Since it has been working flawlessly for more than a week on my desktop,
I decided to let you guys know about it and ask for testing.
Here is the code:
Le 04/07/2011 08:42, Ben Skeggs a écrit :
Apologies for top-posting.
Martin,
As per our convo on irc earlier, pushed code achieving this functionality.
Let me know if there's issues :)
Ben.
Ack, I'll test that tonight but as I said in our conversation, it looks
good to me.
Martin
Le 11/06/2011 14:30, Emil Velikov a écrit :
+ if (entries NOUVEAU_PM_MAX_LEVEL) {
+ NV_DEBUG(dev, perf table has too many entries - buggy
vbios?\n);
+ entries = NOUVEAU_PM_MAX_LEVEL;
+ }
+
I would suggest using NV_ERROR or INFO. How will we get buggy
Le 07/05/2011 01:42, Emil Velikov a écrit :
On Sat, 30 Apr 2011 01:17:13 +0100, Martin Peres
martin.pe...@free.fr wrote:
From: Martin Peres martin.pe...@ensi-bourges.fr
v2: Reclock memory after reclocking the other engines
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
Le 29/04/2011 02:56, Nigel Cunningham a écrit :
Hi.
On 29/04/11 04:35, Martin Peres wrote:
Le 28/04/2011 20:29, Maxim Levitsky a écrit :
On Thu, 2011-04-28 at 20:24 +0200, Martin Peres wrote:
Le 28/04/2011 18:58, Maxim Levitsky a écrit :
Interesting fact is that GPU temperatures rise
Sorry, forgot to add nouveau_pms.h
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
From: Martin Peres martin.pe...@ensi-bourges.fr
v2: Reclock memory after reclocking the other engines
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_pm.c | 11 +--
drivers/gpu/drm/nouveau/nouveau_pms.h | 98 +
drivers/gpu
From: Martin Peres martin.pe...@ensi-bourges.fr
With this patch, cards without internal memory (IONs and other IGPs)
and cards with no memory reclock (a lot of nv40) should support
safe reclocking while gaming.
This should work on all hardware( nva3), report bugs if it doesn't.
v2: Fix missing
Le 28/04/2011 12:32, Maxim Levitsky a écrit :
On Thu, 2011-04-28 at 01:58 +0200, Martin Peres wrote:
Hi everyone,
I would like everyone to test this set of patch as we'll need them quite soon
for timing management on nv50.
Please report success/failure by answering to this email.
Thanks
Le 28/04/2011 13:43, Maxim Levitsky a écrit :
Martin, one more thing, this is my observations regarding clocks I
finished today:
clock = (ref * N / M) (P 0x7)
first line is blob, second nouveau
level0:
P NNMM
0x4008 - memory - 0018e200 2505 = 1
Le 28/04/2011 14:32, Maxim Levitsky a écrit :
On Thu, 2011-04-28 at 14:11 +0200, Martin Peres wrote:
Good work Maxim!
Can you please tell us what card you use? For what range of card is this
true? I can give you access to the vbios repo so as you can contact some
people for further testing
Le 28/04/2011 18:58, Maxim Levitsky a écrit :
Interesting fact is that GPU temperatures rise to very high levels
(~75C) even while doing CPU only work (like compiling kernel for
example).
Let me guess, you're on a laptop? The temperature of the case goes up
when the processor is working and so,
From: Martin Peres martin.pe...@ensi-bourges.fr
v2: Reclock memory after reclocking the other engines
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_pm.c | 11 +--
drivers/gpu/drm/nouveau/nv50_pm.c| 153 +++---
2
Hi everyone,
This new version of the previous patchset features some memory reclocking and
voltage management improvements.
Memory: Reclock it after all the other engines so as we don't need to reclock
it back again if pausing didn't work.
Voltage: Bump the voltage before reclocking or lower
From: Martin Peres martin.pe...@ensi-bourges.fr
With this patch, cards without internal memory (IONs and other IGPs)
and cards with no memory reclock (a lot of nv40) should support
safe reclocking while gaming.
This should work on all hardware( nva3), report bugs if it doesn't.
v2: Fix missing
Le 28/04/2011 20:29, Maxim Levitsky a écrit :
On Thu, 2011-04-28 at 20:24 +0200, Martin Peres wrote:
Le 28/04/2011 18:58, Maxim Levitsky a écrit :
Interesting fact is that GPU temperatures rise to very high levels
(~75C) even while doing CPU only work (like compiling kernel for
example).
Let
From: Martin Peres martin.pe...@ensi-bourges.fr
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_pm.c |7 +-
drivers/gpu/drm/nouveau/nouveau_pms.h | 98 +
drivers/gpu/drm/nouveau/nv50_pm.c | 153
Le 20/04/2011 02:11, Hanno Böck a écrit :
Am Wed, 20 Apr 2011 01:28:30 +0200
schrieb Lucas Stachd...@lynxeye.de:
No, sorry. Tegras are significantly different from normal nvidia
chipsets. Some knowledge can be applied, but it's likely easier to
write a new driver for tegras than adapting
Le 19/04/2011 04:45, Maxim Levitsky a écrit :
On Sat, 2011-03-19 at 23:14 +0100, Martin Peres wrote:
This version corrects the missing symbol linking error you could get by
compiling on a x86_32 kernel:
ERROR: __udivdi3 [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
Again, please test
---
drivers/gpu/drm/nouveau/nouveau_perf.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_perf.c
b/drivers/gpu/drm/nouveau/nouveau_perf.c
index 950caba..d64a98a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_perf.c
+++
Le 18/04/2011 00:32, Ben Skeggs a écrit :
On Sun, 2011-04-17 at 17:10 +0200, Martin Peres wrote:
---
drivers/gpu/drm/nouveau/nouveau_perf.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_perf.c
b/drivers/gpu/drm/nouveau
Le 18/04/2011 00:56, Ben Skeggs a écrit :
On Mon, 2011-04-18 at 00:54 +0200, Martin Peres wrote:
Le 18/04/2011 00:32, Ben Skeggs a écrit :
On Sun, 2011-04-17 at 17:10 +0200, Martin Peres wrote:
---
drivers/gpu/drm/nouveau/nouveau_perf.c |6 +++---
1 files changed, 3 insertions(+), 3
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
drivers/gpu/drm/nouveau/nouveau_perf.c | 25 +
drivers/gpu/drm/nouveau/nouveau_pm.c
Le 13/04/2011 09:35, Martin Peres a écrit :
Signed-off-by: Martin Peresmartin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
drivers/gpu/drm/nouveau/nouveau_perf.c | 25
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
drivers/gpu/drm/nouveau/nouveau_perf.c | 25 +
drivers/gpu/drm/nouveau/nouveau_pm.c
Le 11/04/2011 15:22, Stratos Psomadakis a écrit :
In nouveau_pm.c, in the function nouveau_pm_acpi_event(), there's no
check for CONFIG_POWER_SUPPLY.
If CONFIG_POWER_SUPPLY is set to either n or m, the
power_supply_is_system_supplied() is 'missing' and there's a build error.
One solution is to
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
Reported-by: Stratos Psomadakis pso...@ece.ntua.gr
---
drivers/gpu/drm/nouveau/nouveau_pm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c
b/drivers/gpu/drm/nouveau
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
drivers/gpu/drm/nouveau/nouveau_perf.c | 25 +
drivers/gpu/drm/nouveau/nouveau_pm.c
The first patch should allow the generation of correct memtimings (r100240 put
aside) on the nv40-nv98.a1 interval.
The second one is associating the memtimings with the performance levels.
Please comment on it or push it
___
Nouveau mailing list
From: Roy Spliet r.spl...@student.tudelft.nl
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_mem.c | 42 +-
drivers/gpu/drm/nouveau/nouveau_state.c |2 +
3 files changed, 33 insertions(+), 13 deletions(-)
diff --git
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |1 +
drivers/gpu/drm/nouveau/nouveau_perf.c | 25 +
drivers/gpu/drm/nouveau/nouveau_pm.c
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_pm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index 4399e2f..0b1caeb 100644
--- a/drivers/gpu
From: Martin Peres martin.pe...@ensi-bourges.fr
With this patch, cards without internal memory (IONs and other IGPs)
and cards with no memory reclock (a lot of nv40) should support
safe reclocking while gaming.
This should work on all hardware( nva3), report bugs if it doesn't.
v2: Fix missing
Hi everyone,
This is another update following to Ben's feedback.
Looking forward to some testing on your side (nv30 - nva0).
Martin
From 84fd9da1e34c1bc863d0274b3928333e4db39a20 Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@ensi-bourges.fr
Date: Wed, 19 Jan 2011 10:03:08 +0100
Le 04/03/2011 01:59, Guenter Roeck a écrit :
On Thu, Mar 03, 2011 at 06:53:12PM -0500, Martin Peres wrote:
[ ... ]
Guenter
This is a bigger change than we initially aimed for and I didn't dare to
ask for such a heavy modification, but I'm very happy with this solution
if you prefer and support
Dave,
The answers are inlined.
Le 03/03/2011 10:36, Dave Airlie a écrit :
Martin,
you probably should have cc'ed Matthew since it was his patch you based this on,
and I think he can provide a good explaination.
I knew he was monitoring the nouveau ML. He provided a good explanation
but
Le 03/03/2011 16:22, Guenter Roeck a écrit :
On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote:
On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvarekh...@linux-fr.org wrote:
On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote:
On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres
Le 03/03/2011 23:03, Guenter Roeck a écrit :
On Thu, 2011-03-03 at 16:56 -0500, Lucas Stach wrote:
Am Donnerstag, den 03.03.2011, 13:19 -0800 schrieb Guenter Roeck:
On Thu, 2011-03-03 at 15:48 -0500, Lucas Stach wrote:
Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres:
Le 03/03
Le 23/01/2011 15:14, Martin Peres a écrit :
Hi everyone,
I would like devs to test this patch on all their cards(nvc0) and
report bugs/instability. It shouldn't ever crash (but it may not
always work and return -EAGAIN).
I've attached a little bash script that you need to modify according
isn't needed (as far as I can tell, the critical ressource is
fifo_reassign).
Martin
PS: I'll be out in an hour for a week so I may be slower to answer messages.
From 1fd18aa03020f64567bc2a711babb190b49a1520 Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@ensi-bourges.fr
Date: Wed, 19
theories and got proper support on other cards than the nv86
ones.
From f7ad98f4a857dd4b1892712d15f93c13eb0669e3 Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@ensi-bourges.fr
Date: Mon, 10 Jan 2011 00:44:05 +0100
Subject: [PATCH] Pause PFIFO and PGRAPH before reclocking
Signed-off-by: Martin
: Martin Peres mu...@mupuf.org
Date: Mon, 22 Nov 2010 09:59:16 +0100
Subject: [PATCH] Add a way to list the available voltages through sysfs
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_pm.c | 32
1 files changed, 32
Le 21/11/2010 03:47, Martin Peres a écrit :
Hi everyone,
Please comment on this patch allowing you to set all the PM-related
clocks on the card. The patch is described in length in the commit log.
There is something some of you will like and some won't. The custom_*
files will always
1df2984f21ba0bf034684b1b1287fb86a255a15c Mon Sep 17 00:00:00 2001
From: Martin Peres mu...@mupuf.org
Date: Sat, 20 Nov 2010 18:29:45 +0100
Subject: [PATCH] Add a custom power management perflvl
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is to allow people to tweak their clocks
Le 06/11/2010 01:34, Delan Azabani a écrit :
The sensors implementation of nouveau has a bug where the name file is
not in hwmonX/device, but in the root of the hwmonX directory. Normally,
the name file (contains driver name) of a sensor is placed:
/sys/class/hwmon/hwmonint/device/name
This
61a256a6fa171c7c310a5abedd7cf178c8403f8b Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@ensi-bourges.fr
Date: Wed, 3 Nov 2010 02:49:52 +0100
Subject: [PATCH] Pause the card before reclocking and use PMS to reclock the memory clocks.
This is a very experimental patch. Please test with caution. This should
Hi,
Please merge this patch, it helps a lot when it comes to safe
re-clocking. It isn't perfect yet but it will satisfy most users.
Cheers,
Martin
From 58605d78ec7a576502a8f46953f6e2f0092eb180 Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@ensi-bourges.fr
Date: Thu, 28 Oct 2010 20
Le 07/10/2010 03:33, Martin Peres a écrit :
Hi,
Here is an updated version, all in one patch. When we agree on the
code, I'll split it into 3 patches.
Sorry, I forgot to attach it. Here it is.
From 86e7dd89810b37a12ae189633de41aacf07355cb Mon Sep 17 00:00:00 2001
From: Martin Peres
201 - 300 of 313 matches
Mail list logo
