There's cards out there with completely messed up PCIROM images that have
a perfectly valid signature.. Sigh!
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Theoretically handles CRTC2/CRTC3, should any GF119 out there actually
have them enabled.  The room is there for the regs etc, so why not :)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch fixes two small issues in timing generation as spotted on
several NVCx cards.

In addition, the header of the file is updated to also contain (some of)
the current developers of this code.
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes reclocking failure on some chips where we attempted to set PDAEMON
to PLL mode.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The comparison (lpre == DP_TRAIN_PRE_EMPHASIS_9_5) is always false:
lpre is initialized as (lane & 0x0c) >> 2, which is at most 3, while
DP_TRAIN_PRE_EMPHASIS_9_5 is defined as (3 << 3).
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's a HP laptop out there where the MXM version in the VBIOS doesn't
match what the ACPI implementation is expecting.  These tables will accept
0x00 to MXMS to return latest version, but *only* if MXMI has been called
first..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch fixes an oops cause by pm_trigger accessing the (uninitialised)
crtc list.
Reported-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v2 (Emil Velikov <emil.l.velikov@gmail.com>):
- Fixed a regression on certain nv50 IGP due to not passing the correct
  target type to nv50_vm_addr()
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Tested-by: NJohannes Obermayr <johannesobermayr@gmx.de>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Fixes minor flickering on NVS295 when at perflvl 0.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Goes a long way to correcting NVS295 memory reclocking issues.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

There's some "extended" GDDR3 chipsets out there with EMRS2 settings that
change the layout of MRS/EMRS1 bitmaps.. Sigh.. Still need to track down
how exactly we're supposed to handle this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Idea from Martin Peres, different implementation by me.

v2: Martin Peres:
- fix mast calculation
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

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: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin 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: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

We might want/need the boot data to generate the other perflevels.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Roy Spliet:
- Implement according to specs
- Simplify
- Make array for mc latency registers

Martin Peres:
- squash and split all the commits from Roy
- rework following Ben Skeggs comments
- add a form of timings validation
- store the initial timings for later use

Ben Skeggs
- merge slightly modified tidy-up patch with this one
- remove perflvl-dropping logic for the moment
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It turns out we need access to some additional information in various VBIOS
tables to handle PFB memory timings correctly.

Rather than hack in parsing of the new stuff in some kludgy way, I've
restructured the VBIOS parsing to be more primitive, so we can use them in
more flexible ways in the future.

The perflvl->timing association code is disabled for the moment until it can
be reworked.  We don't use this stuff yet anyway, so no harm done.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Module parameter descriptions don't take a trailing \n, otherwise it
breaks formatting of modinfo's output. Also remove trailing space.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

- Rename several VBIOS entries to closer match the real world
- Add the missing 0x100238 and 0x100240 register values
- Parse bit 14 of the VBIOS timing table
- "Magic value" -> tCWL, fixing some minor bugs in the process
- Also name a few more by their name rather than their number.
- Some values seem to be dependent on the memory type. Fix

Edits by Martin Peres <martin.peres@labri.fr>:
- this is a squash commit
- reworked for fixing some style issues
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Uses only the VBIOS tables, from what I can tell this is what NVIDIA do
too, I was able to change the detected memory type by modifying this table
on a NVC1 chipset.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

M version 2 appears to have a table with some form of memory type info
available.

NVIDIA appear to ignore the table information except for this DDR2/DDR3
case (which has the same value in 0x100714).  My guess is this is due to
some of the supported memory types not being represented in the table.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>