aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/nvkm/falcon (follow)
AgeCommit message (Collapse)AuthorFilesLines
2017-08-22drm/nouveau/falcon: use a more reasonable msgqueue timeout valueBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-04-06drm/nouveau/msgqueue: support for GP10B PMU firmwareAlexandre Courbot3-0/+117
The GP10B firmware is very close to GM20B's. The only difference is that it supports booting multiple falcons. In order to avoid having too much functions and structures shared, implement its support in the same source file as GM20B firmware. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-04-06drm/nouveau/secboot: pass instance to LS firmware loadersAlexandre Courbot4-7/+12
Having access to the secboot instance loading a LS firmware can be useful to LS firmware handlers. At least more useful than just having an out-of-context subdev pointer. GP10B's firmware will also need to know the WPR address, which can be obtained from the secboot instance. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-04-06drm/nouveau/secboot: allow to boot multiple falconsAlexandre Courbot2-3/+24
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: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-17drm/nouveau/secboot: fix NULL pointer dereferenceAlexandre Courbot1-3/+2
The msgqueue pointer validity should be checked by its owner, not by the msgqueue code itself to avoid this situation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-03-07drm/nouveau/falcon: support for gp10x msgqueueAlexandre Courbot4-0/+268
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>
2017-03-07drm/nouveau/falcon/msgqueue: add SEC2 supportAlexandre Courbot1-0/+3
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>
2017-03-07drm/nouveau/falcon: support for EMEMAlexandre Courbot2-0/+64
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>
2017-03-07drm/nouveau/falcon: fix base address of FBIF registersAlexandre Courbot1-5/+20
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>
2017-03-07drm/nouveau/falcon: better detection of debug registerAlexandre Courbot1-2/+25
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>
2017-03-07drm/nouveau/falcon: delay construction of falcons to oneinit()Alexandre Courbot1-0/+3
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>
2017-03-07drm/nouveau/falcon: use NXTCTX register instead of NEW_INSTBLKAlexandre Courbot1-1/+4
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>
2017-03-07drm/nouveau/falcon: support for gm20b msgqueueAlexandre Courbot4-0/+329
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>
2017-03-07drm/nouveau/falcon: add msgqueue interfaceAlexandre Courbot3-0/+749
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>
2017-03-07drm/nouveau/falcon: fix IMEM port accessAlexandre Courbot1-5/+6
All IMEM registers are duplicated per port. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: fix port offset for DMEM registerAlexandre Courbot1-9/+10
DMEM registers are replicated with a stride of 8 bytes. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: protect against concurrent DMEM accessesAlexandre Courbot1-0/+9
The falcon library may be used concurrently, especially after the introduction of the msgqueue interface. Make it safe to use it that way. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: add missing context binding memory targetAlexandre Courbot1-0/+1
This is not used currently, but is added for the sake of completeness. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/core/memory: distinguish between coherent/non-coherent targetsBen Skeggs1-4/+7
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/core: add falcon library functionsAlexandre Courbot4-0/+464
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>