* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next: (55 commits)
  drm/nouveau: make cursor_set implementation consistent with other drivers
  drm/nva3/clk: better pll calculation when no fractional fb div available
  drm/nouveau/pm: translate ramcfg strap through ram restrict table
  drm/nva3/pm: allow use of divisor 16
  drm/nvc0/pm: parse clock for pll 0x0a (0x137020) from perf table
  drm/nvc0/pm: correct core/mem/shader perflvl parsing
  drm/nouveau/pm: remove memtiming support check when assigning to perflvl
  drm/nva3: support for memory timing map table
  drm/nouveau: Associate memtimings with performance levels on cards <= nv98
  drm/nva3/pm: initial pass at set_clock() hook
  drm/nvc0/gr: calculate some more of our magic numbers
  drm/nv50: respect LVDS link count from EDID on SPWG panels
  drm/nouveau: recognise DCB connector type 0x41 as LVDS
  drm/nouveau: fix uninitialised variable warning
  drm/nouveau: Fix a crash at card takedown for NV40 and older cards
  drm/nouveau: Free nv04 instmem ramin heap at card takedown
  drm/nva3: somewhat improve clock reporting
  drm/nouveau: pull refclk from vbios on limits 0x40 boards
  drm/nv40/gr: oops, fix random bits getting set in engine obj
  drm/nv50: improve nv50_pm_get_clock()
  ...

When xorg state tracker wants to hide the cursor it calls set_cursor
with NULL buffer_handle and size=0x0, but nouveau refuses to hide it
because size is not 64x64... which is a bit odd. Both radeon and intel
check buffer_handle before validating size of cursor, so make nouveau
implementation consistent with them.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The core/mem/shader clocks don't support the fractional feedback divider,
causing our calculated clocks to be off by quite a lot in some cases.  To
solve this we will switch to a search-based algorithm when fN is NULL.

For my NVA8 at PL3, this actually generates identical cooefficients to
the binary driver.  Hopefully that's a good sign, and that does not
break VPLL calculation for someone..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Hopefully this is how we're supposed to correctly handle when the RAMCFG
strap is above the number of entries in timing-related tables.

It's rather difficult to confirm without finding a configuration where
the ram restrict table doesn't map 8-15 back onto 0-7 anyway.  There's
not a single vbios in the repo which is configured differently..

In any case, this is probably still better than potentially reading
outside of the bounds of various tables..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

We need to parse some of these other entries still, but I've yet to
determine exactly which PLLs the rest map to.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Really not necessary here, we want to be able to see if/how we managed to
match a timingset to a performance level, even if we can't currently
program it.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40
Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I still discourage anyone from actually doing this yet.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Again, doesn't quite match NVIDIA's, but not sure it really matters.  This
will however, match the same rules we use to calculate the other related
grctx magics.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

After looking at a number of different logs, it appears 0x41 likely
indicates the presense of an LVDS panel following the SPWG spec
(http://www.spwg.org/)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Looks like a false positive to me, but, anyways!
Reported-by: NJimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown.  The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: NJimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Add a missing nv04 instmem ramin heap shutdown call.
Signed-off-by: NJimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Definitely not 100% correct, but, for the configurations I've seen used
it'll read back the correct clocks now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Many of the nv50 cards have their shader and/or memory pll
disabled at some stage.
This patch addresses those cases, so that the function
returns the correct frequency.

When the shader pll is disabled, the blob reports 2*core clock
Whereas for memory, the data stored in the vbios. This action
is incorrect as some vbioses store a clock value that is less
than the refference clock of the pll.

Thus we are reporting the reff_clk as it is the frequency the
pll actually operates

v2 - Convert NV_INFO() messages to NV_DEBUG()
Provide more information in the actuall message
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Reported-by: NStratos Psomadakis <psomas@ece.ntua.gr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Contents will now be preserved across a suspend, unlike a pinned bo
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

PFIFO kickoff should have handled this for us.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Allows per-chipset firmware to be installed, and keeps a copy in memory
for suspend/resume purposes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

In preparation for adding 0x50 support.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

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

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

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

The nouveau_wait_for_idle() call should hopefully not have been actually
necessary, we *do* wait for the channel to go idle already.  If it's
an issue somehow, the chipset-specific hooks can wait for idle themselves
before taking the lock.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In the very least VPE (PMPEG and friends) also has this style of tile
region regs, lets make them just work if/when they get added.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like nv10-nv50, needs cleanup.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like nv20-nv50, needs cleanup.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A bit of cleanup done along the way, but, like nv40/nv50, needs more.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>