GF108/GM107 implementations will want slightly different functions for
the upcoming RAM detection improvements.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

I'm not entirely sure NVKM needs to support this now, but I haven't
removed it as of yet just in case it's needed from DEVINIT scripts
where DRM isn't available.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This value represents the actual number of bytes recieved on the AUX
channel as the result of a read transaction.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Apparently sinks are allows to respond with ACK even if they didn't
fully complete a transaction...  It seems like a missed opportunity
for DEFER to me, but what do I know :)
Signed-off-by: Ben 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: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben 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: Ben Skeggs <bskeggs@redhat.com>

Add support for the msgqueue firmware used to process SEC2 commands
for gp10x chips.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

These gp10x chips are supporting using (roughly) the same firmware.
Compared to previous secure chips, ACR runs on SEC2 and so does the
low-secure msgqueue.

ACR for these chips is based on r367.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We will also need to load HS blobs outside of acr_r352 (for instance, to
run the NVDEC VPR scrubber), so make this code reusable.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

r375 ACR uses a unified bootloader descriptor for the GR and PMU
firmwares.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

r367 uses a different hsflcn_desc layout and LS firmware signature
format, requiring a rewrite of some functions.

It also makes use of the shadow region, and uses SEC as the boot falcon.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

r364 is similar to r361, but uses a different hsflcn_desc structure to
introduce the shadow region address (even though it is not yet used by
this version).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

For some unknown reason the LS SEC2 firmware needs to be started twice
to operate. Detect and address that condition.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

I had the brilliant idea to "improve" the binary format by removing
a useless indirection in the HS binary files. In the end it just
makes things more complicated than they ought to be as NVIDIA-provided
files need to be adapted. Since the format used can be identified by the
header, support both.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

If the load and unload falcons are different, then a different
bootloader must also be used. Support this case.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Since the HS blobs are provided and signed by NVIDIA, we cannot expect
always-consistent behavior. In this case, on GP10x the unload blob may
return 0x1d even though things have run perfectly well. This behavior
has been confirmed by NVIDIA.

So let the callers of the run_blob() hook receive the blob return's
value (a positive integer) and decide what it means. This allows us to
workaround the 0x1d code instead of issuing an error.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

On some secure boot instances (e.g. gp10x) the load and unload blobs do
not run on the same falcon. Support this case by introducing a new
member to the ACR structure and making related functions take the falcon
to use as an argument instead of assuming the boot falcon is to be used.

The rule is that the load blob can be run on either the SEC or PMU
falcons, but the unload blob must be always run on PMU.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Share elements of r361 that will be reused in other ACRs.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Support running a message queue firmware on SEC.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Add support for running the ACR binary on the SEC falcon.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The start address used for secure blobs is not unique to the ACR, but
rather blob-dependent. Remove the unique member stored in the ACR
structure and make the load function return the start address for the
current blob instead.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

ACR firmware from r364 on need a shadow region for the ACR to copy the
WPR region into. Add a flag to indicate that a shadow region is required
and manage memory allocations accordingly.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Add support for running a msgqueue on the SEC2 falcon.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

On SEC, DMEM is unaccessible by the CPU when the falcon is running in LS
mode. This makes communication with the firmware using DMEM impossible.

For this purpose, a new kind of memory (EMEM) has been added. It works
similarly to DMEM, with the difference that its address space starts at
0x1000000. For this reason, it makes sense to treat it like a special
case of DMEM.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

All falcons have their FBIF registers starting at offset 0x600, with the
exception of the PMU and NVENC engines.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Not all falcons have a debug register, and it is not always found at the
same offset.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben 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: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben 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: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben 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: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Both registers allow to bind a new context, but NXTCTX will work on all
falcons, while legacy NEW_INSTBLK is reserved to PMU.

After setting NXTCTX we trigger a context switch by writing 0x090 and
0x0a4.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Enable the PMU firmware in gm20b, managed by secure boot.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

gm20b PMU firmware is driven by a msgqueue, so connect relevant PMU
hooks to their msgqueue counterparts.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The ACR firmware may return no error but fail nonetheless. Such cases
can be detected by verifying that the WPR region has been properly set
in FB. If this is not the case, this is an error, but the unload
firmware should still not be run.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

PMU support has been enabled for r352 ACR, but it must remain optional
if we want to preserve existing user-space that do not include it. Allow
ACR to be instanciated with a list of optional LS falcons, that will not
produce a fatal error if their firmware is not loaded. Also change the
secure boot bootstrap logic to be able to fall back to legacy behavior
if it turns out the boot falcon's LS firmware cannot be loaded.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Add the PMU bootloader generator and PMU LS ops that will enable proper
PMU operation if the PMU falcon is designated as managed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Adapt secboot's behavior if a PMU firmware is present, in particular
the way LS falcons are reset. Without PMU firmware, secboot needs to be
performed again from scratch so all LS falcons are reset. With PMU
firmware, we can ask the PMU's ACR unit to reset a specific falcon
through a PMU message.

As we must preserve the old behavior to avoid breaking user-space, add a
few conditionals to the way falcons are reset.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Allow secboot to load a LS PMU firmware. LS PMU is one instance of
firmwares based on the message queue mechanism, which is also used for
other firmwares like SEC, so name its source file accordingly.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

NVIDIA-provided PMU firmware is controlled by a msgqueue. Add a member
to the PMU structure as well as the required cleanup code if this
feature is used.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Add support for the msgqueue firmware used to process PMU commands for
gm20b.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

A message queue firmware implements a specific protocol allowing the
host to send "commands" to a falcon, and the falcon to reply using
"messages". This patch implements the common part of this protocol and
defines the interface that the host can use.

Due to the way the firmware is developped internally at NVIDIA (where
kernel driver and firmware evolve in lockstep), firmwares taken at
different points in time can have frustratingly subtle differences that
must be taken into account. This code is architectured to make
implementing such differences as easy as possible.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>