Upcoming commits make supervisor handling share code between the NV50
and GF119 implementations.  Because of this, and a few other cleanups,
we need to allow some additional customisation.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In order to properly support the SOR -> SOR + pad macro separation
that occurred with GM20x GPUs, we need to separate OR handling out
of the output path code.

This will be used as the base to support ORs (DAC, SOR, PIOR).
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Primarily intended as a way to pass per-head state around during
supervisor handling, and share logic between NV50/GF119.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is to allow hw-specific code to instantiate output resources first,
so we can cull unsupported output paths based on them.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Not all users of nvkm_output_dp have been changed here.  The remaining
ones belong to code that's disappearing in upcoming commits.

This also modifies the debug level of some messages.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This isn't technically "output", but, "display/output path".

Not all users of nvkm_output have been changed here.  The remaining
ones belong to code that's disappearing in upcoming commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Upcoming changes to split OR from output path drastically change the
placement of various operations.

In order to make the real changes clearer, do the moving around part
ahead of time.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.

Also don't enable any InfoFrame that is not provided, and disable
the Vendor InfoFrame when disabling the output.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.

Also don't enable any InfoFrame that is not provided, and disable
the Vendor InfoFrame when disabling the output.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic") InfoFrame.

Also don't enable any AVI or Vendor InfoFrame that is not provided,
and disable the Vendor InfoFrame when disabling the output.

Ignore the Audio InfoFrame: We don't supply it, and altering HDMI
audio semantics (for better or worse) on this hardware is out of
scope for me at this time.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.

While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.

Also don't enable any AVI or Vendor InfoFrame that is not provided,
and disable the Vendor InfoFrame when disabling the output.

Ignore the Audio InfoFrame: We don't supply it, and altering HDMI
audio semantics (for better or worse) on this hardware is out of
scope for me at this time.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

HDMI InfoFrames are passed to NVKM as bags of bytes, but the
hardware needs them to be packed into words.  Rather than having
four (or more) copies of the packing logic introduce a single copy
now, in a central place.

We currently need these for AVI and Vendor InfoFrames, but we may
also expect to need them for Audio InfoFrames at some point.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The nouveau driver, in the Linux 3.7 days, used to try and set the
AVI InfoFrame based on the selected display mode.  These days, it
uses a fixed set of InfoFrames.  Start to correct that, by
providing a mechanism whereby InfoFrame data may be passed to the
NVKM functions that do the actual configuration.

At this point, only establish the new parameters and their parsing,
don't actually use the data anywhere yet (since it's not supplied
anywhere).
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Presumably we can never actually hit this return, but static checkers
complain that we should unlock before we return.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>

Forked from GP106 implementation.

Differences:
- 1 PPC/GPC
- Slightly different grctx magics
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GP10B's power is managed by generic PM domains, so it does not require a
VDD regulator. Add this option into the chip function structure.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GR is similar to GP100, with a few unavailable registers.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GP10B's FIFO is similar to GP100's, but only allows 512 channels.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Change the secboot and msgqueue interfaces to take a mask of falcons to
reset instead of a single falcon. The GP10B firmware interface requires
FECS and GPCCS to be booted in a single firmware command.

For firmwares that only support single falcon boot, it is trivial to
loop over the mask and boot each falcons individually.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Forked from GP106 implementation.

Split out from commit enabling secboot/gr support so that it can be
added to earlier kernels.

Cc: stable@vger.kernel.org	[4.10+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
and PCI varieties, rather than a core PCIE chip with a bridge for
AGP/PCI as necessary. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.

Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Fixes: 590801c1 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup")
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Forked from GP106 implementation.

Split out from commit enabling secboot/gr support so that it can be
added to earlier kernels.

Cc: stable@vger.kernel.org	[4.10+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
and PCI varieties, rather than a core PCIE chip with a bridge for
AGP/PCI as necessary. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.

Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Fixes: 590801c1 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup")
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The msgqueue pointer validity should be checked by its owner, not by the
msgqueue code itself to avoid this situation.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reported-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

All the bricks are in place for secure boot to be enabled. This in turn
makes GR usable so enable them all.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Differences from GP100:
- 3 PPCs/GPC.
- Another random reg to calculate/write.
- Attrib CB setup a little different.
- PascalB
- PascalComputeB
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

SEC2 is the name given by NVIDIA to the SEC engine post-Fermi (reasons
unknown). Even though it shares the same address range as SEC, its usage
is quite different and this justifies a new engine. Add this engine and
make TOP use it all post-TOP devices should use this implementation and
not the older SEC.

Also quickly add the short gp102 implementation which will be used for
falcon booting purposes.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gp10x' secure boot requires a blob to be run on NVDEC. Expose the falcon
through a dummy device.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reading registers at device construction time can be harmful, as there
is no guarantee the underlying engine will be up, or in its runtime
configuration. Defer register reading to the oneinit() hook and update
users accordingly.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

704a6c008b7942bb7f30bb43d2a6bcad7f543662 broke pci msi rearm for g92 GPUs.

g92 needs the nv46_pci_msi_rearm, where g94+ gpus used nv40_pci_msi_rearm.
Reported-by: NAndrew Randrianasulu <randrianasulu@gmail.com>
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

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

Greatly improves the chances of recovering the GPU from a CTXSW_TIMEOUT.

Tested with piglit's arb_shader_image_load_store-atomicity, which causes
GR to hang in such a way that recovery failed (CTXSW_TIMEOUT continually
re-triggers).
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>