Bug 66176

I'm sorry, but unfortunately reclocking is not implemented for this family of cards (NV4x) in nouveau. None of the developers has such a board capable of reclocking. I have marked this bug NEEDINFO because... well, we need a lot more info about the internals of this card to be able to implement reclocking. Given the amount of users actually still using NV49s (and the complete lack of developer manpower on reclocking) it will probably end up being a very-low-priority task though.

I am willing to give you a hand in the development and/or testing, if needed.

I know for a fact that re-clocking is possible on this card - I do that (quite regularly) on Windows and if I remember correctly I've also done this "manually" using the pathscale tools.

(In reply to comment #2)
> I am willing to give you a hand in the development and/or testing, if needed.
Glad to hear, there are a few notes further down that you can start with

> 
> I know for a fact that re-clocking is possible on this card - I do that
> (quite regularly) on Windows and if I remember correctly I've also done this
> "manually" using the pathscale tools.
Afaik Windows is another kettle of fish, although if it worked previously that's a good starting point

On the other from you can work from the current state and nitpick until it works

* The fanspeed set fails as the mode is not NOUVEAU_THERM_CTRL_MANUAL
Annoying but not crucial for the re-clocking to complete. Note I'm not entirely sure where it should be set

* pclk->pll_calc seems to return 0, causing nv40_calc_pll() to throw ERANGE
* Some of the functions called within nouveau_mem_timing_calc() may need tweaking depending on now well we generate the appropriate memory timings

Happy hacking :)

P.S.
Only one zero is required to change the perflvl - "0" rather than "0,0"

(In reply to comment #3)
> * The fanspeed set fails as the mode is not NOUVEAU_THERM_CTRL_MANUAL
> Annoying but not crucial for the re-clocking to complete. Note I'm not
> entirely sure where it should be set
So, the logical solution to this particular problem would be for that mode to be *forced* to MANUAL, regardless of its previous state (which I suspect is NONE) and then try and set the fan speed.

> * pclk->pll_calc seems to return 0, causing nv40_calc_pll() to throw ERANGE
> * Some of the functions called within nouveau_mem_timing_calc() may need
> tweaking depending on now well we generate the appropriate memory timings
You've lost me! I am no expert in Nouveau development, although I am a (willing) developer, so you need to explain the above a little bit.

> P.S.
> Only one zero is required to change the perflvl - "0" rather than "0,0"
Well, by looking at the code, the performance level consists of 2 parts - AC (power) and DC (battery) separated by a comma (","), so I used "0,0" for the sake of completeness.

(In reply to comment #4)
...
> to be *forced* to MANUAL, regardless of its previous state (which I suspect
> is NONE) and then try and set the fan speed.

I would call it "set", rather than "forced"

In the second part you'll need a "reference point" - which can be one of
* The kernel and/or "...I've also done this "manually" using the pathscale tools"
* Mmio dump of the blob reclocking the card

Initially I would recommend the former

> 
> > * pclk->pll_calc seems to return 0, causing nv40_calc_pll() to throw ERANGE

Confirm if the function nv40_calc_pll() is the one throwing ERANGE. Then dwell into the function, and analyse any differences with your "reff point".  There may be a typo/inverted logic, as this code moved around in nouveau quite a few times

> > * Some of the functions called within nouveau_mem_timing_calc() may need
> > tweaking depending on now well we generate the appropriate memory timings

nouveau_mem_timing_calc()
* parses the memory timing table stored in vbios - nouveau_perf_timing()
* generates the appropriate values based on the card generation - nv**_mem_timing_calc()
* and the memory type - nouveau_mem_*ddr*()
* On newer cards (iirc nvc0+) it maps the timings with memory frequency range. On previous generations the timings are related to the performance level rather than the memory frequency (range)

> 
> > P.S.
> > Only one zero is required to change the perflvl - "0" rather than "0,0"
> Well, by looking at the code, the performance level consists of 2 parts - AC
> (power) and DC (battery) separated by a comma (","), so I used "0,0" for the
> sake of completeness.

You got me there, I have no recollection when AC/DC got introduced ^_^

Although that seems too much as a start. Thus it would be nice to get the non-memory engine(s) reclock first and then deal with memory/timings/etc

This can be done by forcing current code to ignore the memory clock stored in vbios, i.e.

diff --git a/drm/nv40_pm.c b/drm/nv40_pm.c
index 3af5bcd..0be61db 100644
--- a/drm/nv40_pm.c
+++ b/drm/nv40_pm.c
@@ -191,7 +191,7 @@ nv40_pm_clocks_pre(struct drm_device *dev, struct nouveau_pm_level *perflvl)
 	}
 
 	/* memory clock */
-	if (!perflvl->memory) {
+	if (1) {
 		info->mpll_ctrl = 0x00000000;
 		goto out;
 	}

Note that a NV40 reclocking fix just went into the nouveau/linux-2.6 tree: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=dde3164f85035787ce7c63b791ce3c565ff3e3ff

Can you re-test with this fix in place?

No response to re-test request in a month. Closing as invalid.