GK20A's initialization was based on GK104, but differences exist in the
way the initial context is built and the initialization process itself.

This patch follows the same initialization sequence as nvgpu performs
to avoid bad surprises. Since the register bundles initialization also
differ considerably from GK104, the register packs are now loaded from
firmware files, again similarly to what is done with nvgpu.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

After submitting a GO_IDLE bundle, one must wait for GR to effectively
be idle before submitting the next bundle. Failure to do so may result
in undefined behavior in some rare cases.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reported-by: NKary Jin <karyj@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Uncertain whether the GPC pack change is due to a newer driver version,
or a legitimate difference from GM204.  My GM204 has broken vram, so
can't currently try a newer binary driver on it to confirm.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK
can trigger a PRI fault and return an error code instead of a TPC mask,
unless PGOB has been disabled first.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver.  This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>