We never have any need for a double-linked list here, and as there's
generally a large number of these objects, replace it with a single-
linked list in order to save some memory.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We want a supervisor client of NVKM (such as the DRM) to be able to
allow sharing of resources (such as memory objects) between clients.
To allow this, the supervisor creates all its clients as children of
itself, and will use an upcoming ioctl to permit sharing.
Currently it's not possible for indirect clients to use subclients.
Supporting this will require an additional field in the main ioctl.
This isn't important currently, but will need to be fixed for virt.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The fields were already in struct nvkm_oclass for some reason (probably
as an accidental left-over).
Preparation for supporting subclients.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvkm_object::client refers to the client that created the object, which,
is currently always the same as the ioctl caller.
Upcoming patches introduce the concept of subclients, where a parent is
able to access the object trees of its children, making the above no
longer true.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It turns out we have a nice and convenient way of looking up a specific
object type already, by using the func pointer as a key.
This will be used to remove the separate object trees for each type we
need to be able to search for.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The halt interrupt must be cleared after ACR is run, otherwise the LS
PMU firmware will not be able to run.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the PMU firmware is present, the falcons it manages need to have
the lazy-bootstrap flag of their WPR header set so the ACR does not boot
them. Add support for this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Generate the WPR descriptor closer to what RM does. In particular, set
the expected masks, and only set the ucode members on Tegra.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Set a default error value in the mailbox 0 register so we can catch
cases where the secure boot binary fails early without being able to
report anything.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since DMEM was initialized to zero, these fields went unnoticed. Add
them for safety.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Perform the zeroing of BL descriptors in the caller function instead of
trusting each generator will do it. This could avoid a few pulled hairs.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The WPR and LSB headers, used to generate the LS blob, may have a
different layout and sizes depending on the driver version they come
from. Abstract them and confine their use to driver-specific code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This was used only locally to one function and can be replaced by ad-hoc
variables.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
ucode_header is not used anywhere, so just get rid of it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Make sure we are not disturbed by spurious interrupts, as we poll the
halt bit anyway.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Split the reset function into more meaningful and reusable ones.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a flag that can be set when declaring how a LS firmware should be
loaded. This allows us to remove falcon-specific code in the loader.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Split the act of building the ACR blob from firmware files from the rest
of the (chip-dependent) secure boot logic. ACR logic is moved into
acr_rxxx.c files, where rxxx corresponds to the compatible release of
the NVIDIA driver. At the moment r352 and r361 are supported since
firmwares have been released for these versions. Some abstractions are
added on top of r352 so r361 can easily be implemented on top of it by
just overriding a few hooks.
This split makes it possible and easy to reuse the same ACR version on
different chips. It also hopefully makes the code much more readable as
the different secure boot logics are separated. As more chips and
firmware versions will be supported, this is a necessity to not get lost
in code that is already quite complex.
This is a big commit, but it essentially moves things around (and split
the nvkm_secboot structure into two, nvkm_secboot and nvkm_acr). Code
semantics should not be affected.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the HS hook to completely generate the HS BL descriptor, similarly
to what is done in the LS hook, instead of (arbitrarily) using the
acr_v1 format as an intermediate.
This allows us to make the bootloader descriptor structures private to
each implementation, resulting in a cleaner an more consistent design.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Secure firmwares provided by NVIDIA will follow the same overall
principle, but may slightly differ in format, or not use the same
bootloader descriptor even on the same chip. In order to handle
this as gracefully as possible, turn the LS firmware functions into
hooks that can be overloaded as needed.
The current hooks cover the external firmware loading as well as the
bootloader descriptor generation.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This hook can be removed if the function writing the HS
descriptor is aware of WPR settings. Let's do that as it allows us to
make the ACR descriptor structure private and save some code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The init() hook is called by the subdev's oneinit(). Rename it
accordingly to avoid confusion about the lifetime of objects allocated
in it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since GR has moved to using the falcon library to start the falcons,
this function is not needed anymore.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Create instances for the FECS and GPCCS falcons and use the init() and
fini() hooks to reserve them for as long as GR controls them.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gf100_gr_init_ctxctl() is basically two different functions (one for
use of internal firmware, the other for use of external firmware), but
its current layout makes it look more complex than it is. Split it to
better reflect that fact.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a fini() hook to the GR engine. This will be used by gf100+ to
properly release the FECS and GPCCS falcons.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the falcon library functions in secure boot. This removes a lot of
code and makes the secure boot flow easier to understand as no register
is directly accessed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These functions should use the nvkm_secboot_falcon enum. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a dummy PMU device so the PMU falcon is instanciated and can be used
by secure boot.
We could reuse gk20a's implementation here, but it would fight with
secboot over PMU falcon's ownership and secboot will reset the PMU,
preventing it from operating afterwards. Proper handout between secboot
and pmu is coming along with the actual gm20b PMU implementation, so
use this as a temporary solution.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some functions always succeed - change their return type to void and
remove the error-handling code in their caller.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the PMU constructor so that all base members (in particular the
falcon instance) are initialized properly.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Have an instance of nvkm_falcon in the PMU structure, ready to be used
by other subdevs (i.e. secboot).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a PMU constructor so implementations that extend the nvkm_pmu
structure can have all base members properly initialized.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Falcon processors are used in various places of GPU chips. Although there
exist different versions of the falcon, and some variants exist, the
base set of actions performed on them is the same, which results in lots
of duplicated code.
This patch consolidates the current nvkm_falcon structure and extends it
with the following features:
* Ability for an engine to obtain and later release a given falcon,
* Abstractions for basic operations (IMEM/DMEM access, start, etc)
* Abstractions for secure operations if a falcon is secure
Abstractions make it easy to e.g. start a falcon, without having to care
about its details. For instance, falcons in secure mode need to be
started by writing to a different register.
Right now the abstractions variants only cover secure vs. non-secure
falcon, but more will come as e.g. SEC2 support is added.
This is still a WIP as other functions previously done by
engine/falcon.c need to be reimplemented. However this first step allows
to keep things simple and to discuss basic design.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a function that allows us to query whether a given subdev is
currently enabled or not.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
