summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/nvkm
Commit message (Collapse)AuthorAgeFilesLines
* drm/nouveau/secboot: fix NULL pointer dereferenceAlexandre Courbot2017-03-173-3/+15
| | | | | | | | | 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>
* drm/nouveau/secboot: fix inconsistent pointer checkingAlexandre Courbot2017-03-171-1/+2
| | | | | | | | | | We were returning PTR_ERR() on a NULL pointer, which obviously won't work. nvkm_engine_ref() will return an error in case something went wrong. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-nextDave Airlie2017-03-0867-556/+4358
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Re-architecture of the code to handle proprietary fw, more abstracted to support the multitude of differences that NVIDIA introduce - Support in the said code for GP10x ACR and GR fw, giving acceleration support \o/ - Fix for GTX 970 GPUs that are in an odd MMU configuration * 'linux-4.12' of git://github.com/skeggsb/linux: (60 commits) drm/nouveau/fb/gf100-: rework ram detection drm/nouveau/fb/gm200: split ram implementation from gm107 drm/nouveau/fb/gf108: split implementation from gf100 drm/nouveau/fb/gf100-: modify constructors to allow more customisation drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm drm/nouveau/i2c/g94-: return REPLY_M value on reads drm/nouveau/i2c: modify aux interface to return length actually transferred drm/nouveau/gp10x: enable secboot and GR drm/nouveau/gr/gp102: initial support drm/nouveau/falcon: support for gp10x msgqueue drm/nouveau/secboot: add gp102/gp104/gp106/gp107 support drm/nouveau/secboot: put HS code loading code into own file drm/nouveau/secboot: support for r375 ACR drm/nouveau/secboot: support for r367 ACR drm/nouveau/secboot: support for r364 ACR drm/nouveau/secboot: workaround bug when starting SEC2 firmware drm/nouveau/secboot: support standard NVIDIA HS binaries drm/nouveau/secboot: support for unload blob bootloader drm/nouveau/secboot: let callers interpret return value of blobs drm/nouveau/secboot: support for different load and unload falcons ...
| * drm/nouveau/fb/gf100-: rework ram detectionBen Skeggs2017-03-077-101/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit reworks the RAM detection algorithm, using RAM-per-LTC to determine whether a board has a mixed-memory configuration instead of using RAM-per-FBPA. I'm not certain the algorithm is perfect, but it should handle all currently known configurations in the very least. This should fix GTX 970 boards with 4GiB of RAM where the last 512MiB isn't fully accessible, as well as only detecting half the VRAM on GF108 boards. As a nice side-effect, GP10x memory detection now reuses the majority of the code from earlier chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb/gm200: split ram implementation from gm107Ben Skeggs2017-03-074-1/+44
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb/gf108: split implementation from gf100Ben Skeggs2017-03-075-1/+86
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb/gf100-: modify constructors to allow more customisationBen Skeggs2017-03-074-52/+81
| | | | | | | | | | | | | | GF108/GM107 implementations will want slightly different functions for the upcoming RAM detection improvements. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/i2c/g94-: return REPLY_M value on readsBen Skeggs2017-03-072-0/+2
| | | | | | | | | | | | | | 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>
| * drm/nouveau/i2c: modify aux interface to return length actually transferredBen Skeggs2017-03-075-21/+21
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/gp10x: enable secboot and GRAlexandre Courbot2017-03-071-0/+15
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/gr/gp102: initial supportBen Skeggs2017-03-077-4/+180
| | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/falcon: support for gp10x msgqueueAlexandre Courbot2017-03-074-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>
| * drm/nouveau/secboot: add gp102/gp104/gp106/gp107 supportAlexandre Courbot2017-03-072-0/+252
| | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: put HS code loading code into own fileAlexandre Courbot2017-03-075-124/+182
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support for r375 ACRAlexandre Courbot2017-03-073-0/+167
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support for r367 ACRAlexandre Courbot2017-03-074-0/+425
| | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support for r364 ACRAlexandre Courbot2017-03-073-0/+119
| | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: workaround bug when starting SEC2 firmwareAlexandre Courbot2017-03-071-0/+33
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support standard NVIDIA HS binariesAlexandre Courbot2017-03-071-8/+52
| | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support for unload blob bootloaderAlexandre Courbot2017-03-072-30/+37
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: let callers interpret return value of blobsAlexandre Courbot2017-03-072-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support for different load and unload falconsAlexandre Courbot2017-03-076-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: share r361 BL structures and functionsAlexandre Courbot2017-03-072-39/+74
| | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: add support for SEC LS firmwareAlexandre Courbot2017-03-073-0/+76
| | | | | | | | | | | | | | Support running a message queue firmware on SEC. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: support running ACR on SECAlexandre Courbot2017-03-072-3/+23
| | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: get start address of blob from ACRAlexandre Courbot2017-03-073-10/+9
| | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: add shadow blob argumentAlexandre Courbot2017-03-072-2/+15
| | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/falcon/msgqueue: add SEC2 supportAlexandre Courbot2017-03-071-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>
| * drm/nouveau/falcon: support for EMEMAlexandre Courbot2017-03-072-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>
| * drm/nouveau/falcon: fix base address of FBIF registersAlexandre Courbot2017-03-071-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>
| * drm/nouveau/falcon: better detection of debug registerAlexandre Courbot2017-03-071-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>
| * drm/nouveau/core: add SEC2 engineAlexandre Courbot2017-03-079-1/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/nvdec: add gp102 supportAlexandre Courbot2017-03-075-2/+98
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/falcon: delay construction of falcons to oneinit()Alexandre Courbot2017-03-073-16/+26
| | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/falcon: use NXTCTX register instead of NEW_INSTBLKAlexandre Courbot2017-03-071-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>
| * drm/nouveau/secboot/gm20b: enable PMU firmwareAlexandre Courbot2017-03-071-1/+7
| | | | | | | | | | | | | | 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>
| * drm/nouveau/pmu/gm20b: add msgqueue supportAlexandre Courbot2017-03-071-2/+17
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: check that WPR region is properly setAlexandre Courbot2017-03-071-2/+39
| | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support optional falconsAlexandre Courbot2017-03-072-25/+39
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support PMU LS firmwareAlexandre Courbot2017-03-072-0/+134
| | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: base support for PMU falconAlexandre Courbot2017-03-071-16/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/secboot: support for loading LS PMU firmwareAlexandre Courbot2017-03-073-1/+121
| | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/pmu: add msgqueue memberAlexandre Courbot2017-03-071-0/+2
| | | | | | | | | | | | | | | | | | 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>
| * drm/nouveau/falcon: support for gm20b msgqueueAlexandre Courbot2017-03-074-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>
| * drm/nouveau/falcon: add msgqueue interfaceAlexandre Courbot2017-03-073-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>
| * drm/nouveau/secboot: add LS firmware post-run hooksAlexandre Courbot2017-03-072-0/+13
| | | | | | | | | | | | | | | | | | Add the ability for LS firmwares to declare a post-run hook that is invoked right after the HS firmware is executed. This allows them to e.g. write some initialization data into the falcon's DMEM. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: abstract fixup_hs_desc functionAlexandre Courbot2017-03-073-3/+9
| | | | | | | | | | | | | | | | As different firmare versions use different HS descriptor formats, we need to abstract this part as well. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: make specialized ls_ucode_img struct privateAlexandre Courbot2017-03-072-96/+90
| | | | | | | | | | | | | | This structure does not need to be shared anymore. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: store ucode offset in base image structureAlexandre Courbot2017-03-073-9/+9
| | | | | | | | | | | | | | | | | | This allows the bootloader descriptor generation code to not rely on specialized ls_ucode_img structures, making it reusable in other instances. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: fix usage of hsf_load_headerAlexandre Courbot2017-03-073-13/+30
| | | | | | | | | | | | | | | | Offsets were not properly computed. This went unnoticed because we are only using one app for now. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
OpenPOWER on IntegriCloud