This will probably result in more lines of code, however, we're going to
have at least 3 slightly different implementations of this very soon and
I'd rather keep the ram reclocking logic separate from the hw specifics.
DDR2/DDR3/GDDR3 implemented thus far, others will be added as necessary.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Statically generating the PFB register and MR values for each timing set
turns out to be insufficient. There's at least one (so far) known piece
of information which effects MR values which is stored in the perflvl
entry on some chipsets (and in another table on later ones), which is
disconnected from the timing table entries.
After this change we will generate a timing set based on an input clock
frequency instead, and have this data stored in the performance level
data.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
We don't need more than the line id to determine the PWM controller, and
the GPIO interfaces are about to change somewhat.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This area is horrifically complicated on these chipsets, and it's likely we
will need at least a few more tweaks yet.
Oh yes, and it's completely disabled on IGPs for the moment. From traces,
things look potentially different there yet again. Sigh...
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reporting an error is better than silently refusing to reclock.
V2: Use the same logic on nv40
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A NV49 appeared a while back that was using the "nv41 style" pwm registers,
rather than the "nv40 style" ones my board is using. This disproves the
previous theory that the pwm controller choice is chipset-specific.
So, after looking at a bunch of vbios images it appears that the next viable
theory is that we should select the pwm controller to use based on the gpio
line the fan is tied to, just like we do on nv50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not 100% perfect yet, but a good start towards what it'll look like in the
end.
Actually seems stable on a NV44 I have here, as much as running around OA
for a fair amount of time constantly switching between performance levels
can prove..
My NV49 isn't quite so happy, and semaphores mess up somehow (sometimes) as
a result of the memory reclocking.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On certain boards, there's BIOS scripts and memory timings that need to
be modified with the memclk. Just pass in the entire perflvl struct and
let the chipset-specific code decide what to do.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This isn't correct everywhere yet, but since we don't use the data yet
it's perfectly safe to push in, and the information we gain from logs
will help to fix the remaining issues.
v2 (Ben Skeggs <bskeggs@redhat.com>):
- fixed up formatting
- free parsed timing info on takedown
- switched timing table printout to debug loglevel
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Currently just hooked up to the already-existing nouveau_hw, which should
handle all relevant chipsets as well as we currently can.
This will likely be eventually split out and improved into chipset specific
code at a later point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This will make nouveau_pm attempt to report the card's current performance
level both during bootup, and through sysfs.
This is a very initial implementation, and can be improved a *lot*
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
