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: NBen 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: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Used on nv17-nv28, they contain memory clocks and timings, only one of
the table entries can actually be used, depending on the RAMCFG
straps, and it's usually higher than the frequency programmed on boot
by the BIOS.

The memory timings listed in table version 0x1x are used to init the
0x12xx range but they aren't required for reclocking to work.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Guarded by a module parameter for the moment, read the code for the
magic value which enables it.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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