drm/nv84+: fix fence context seqno's

This fixes a regression introduced by "drm/nouveau: rework to new fence interface"
(commit 29ba89b2371d466).

The fence sequence should not be reset after creation, the old value is used instead.
On destruction the final value is written, to prevent another source of accidental
wraparound in case of a channel being destroyed after a hang, and unblocking any other
channel that may wait on the about-to-be-deleted channel to signal.

I'm nothing if not optimistic about any hope of recovery from that. ;-)

Reported-by: Ted Percival <ted@tedp.id.au>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
fb/gddr3: Generate MR values
clock/nva3: Allow user reclocking
fb/ramnva3: Link training for DDR3
fb/ramnva3: Ressurect timing calculation code
fb/ramnva3: Reclocking script for DDR3

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
fb/ramnva3: Reclocking script for DDR2

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
fb/ramnva3: Reclocking script for GDDR3

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
fb/ramnva3: Initialise PART_PM_SEL
pwr/fuc: WIP mimic blob by adding read before waiting status

This could be a workaround for stale values... see if it helps stability
clock/nva3: Stop CTXPROG
DROP: regenerate microcode