search for: nvkm_wo32

...4 deletions(-) diff --git a/drm/nouveau/nvkm/engine/gr/nv30.c b/drm/nouveau/nvkm/engine/gr/nv30.c index 69de8c6..f1e15a4 100644 --- a/drm/nouveau/nvkm/engine/gr/nv30.c +++ b/drm/nouveau/nvkm/engine/gr/nv30.c @@ -76,8 +76,8 @@ nv30_gr_chan_new(struct nvkm_gr *base, struct nvkm_fifo_chan *fifoch, nvkm_wo32(chan->inst, i, 0x00040004); for (i = 0x1f18; i <= 0x3088 ; i += 16) { nvkm_wo32(chan->inst, i + 0, 0x10700ff9); - nvkm_wo32(chan->inst, i + 1, 0x0436086c); - nvkm_wo32(chan->inst, i + 2, 0x000c001b); + nvkm_wo32(chan->inst, i + 4, 0x0436086c); + nvkm_wo32(chan->inst, i...

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

.../nvkm/engine/fifo/gv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c index 6ee1bb32a071..1f6ddf880179 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c @@ -52,7 +52,7 @@ gv100_fifo_runlist_cgrp(struct nvkm_fifo_cgrp *cgrp, nvkm_wo32(memory, offset + 0xc, 0x00000000); } -const struct gk104_fifo_runlist_func +static const struct gk104_fifo_runlist_func gv100_fifo_runlist = { .size = 16, .cgrp = gv100_fifo_runlist_cgrp, -- 2.23.0

...pr_blob, + img->lsb_header.bl_data_off, + &desc, gsb->func->bl_desc_size); + } + + /* Copy ucode */ + nvkm_gpuobj_memcpy_to(wpr_blob, img->lsb_header.ucode_off, + img->ucode_data, img->ucode_size); + + pos += sizeof(img->wpr_header); + } + + nvkm_wo32(wpr_blob, pos, NVKM_SECBOOT_FALCON_INVALID); + + nvkm_done(wpr_blob); + + return 0; +} + +/* Both size and address of WPR need to be 128K-aligned */ +#define WPR_ALIGNMENT 0x20000 +/** + * gm200_secboot_prepare_ls_blob() - prepare the LS blob + * + * For each securely managed falcon, load the FW, s...

The following functions are not declared outside of the file they are in, so make them static to avoid these warnings: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:745:1: warning: symbol 'gf100_gr_fecs_start_ctxsw' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:760:1: warning: symbol 'gf100_gr_fecs_stop_ctxsw' was not declared. Should it be

This is a highly changed revision of the first patch series that adds secure boot support to Nouveau. This code still depends on NVIDIA releasing official firmware files, but the files released with SHIELD TV and Pixel C can already be used on a Jetson TX1. As you know we are working hard to release the official firmware files, however in the meantime it doesn't hurt to review the code so it

..._fifo_chan_mem_wr32(struct nvkm_object *object, u64 addr, u32 data) +{ + struct nvkm_fifo_chan *chan = nvkm_fifo_chan(object); + + pr_info("> %s(object=%px, addr=%016llx, data=%08x)\n", __func__, object, addr, data); + + if (unlikely(addr + 4 > chan->size)) + return -EINVAL; + + nvkm_wo32(chan->mem, addr, data); + + /* XXX add barrier */ + + pr_info("< %s()\n", __func__); + return 0; +} + +static const struct nvkm_object_func +nvkm_fifo_chan_mem_func = { + .dtor = nvkm_fifo_chan_mem_dtor, + .init = nvkm_fifo_chan_init, + .fini = nvkm_fifo_chan_fini, + .ntfy = nvkm_fi...

New version of the secure boot code that works with the blobs just merged into linux-firmware. Since the required Mesa patches are also merged, this set is the last piece of the puzzle to get out-of-the-box accelerated Maxwell 2. The basic code remains the same, with a few improvements with respect to how secure falcons are started. Hopefully the patchset is better split too. I have a

This patchset centralizes the firmware-loading procedure to one set of functions instead of having each engine load its firmware as it pleases. This helps ensure that all firmware comes from the same place, namely nvidia/<chip>/. This changes where the firmware is fetched from for falcon/xtensa/bios, but these locations never seemed to have been official anyway. Also for most (all?) chips

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

Hi everyone, Apologies for the big patchset. This is a rework of the secure boot code that moves the building of the blob into its own set of source files (and own hooks), making the code more flexible and (hopefully) easier to understand as well. This rework is needed to support more signed firmware for existing and new chips. Since the firmwares in question are not available yet I cannot send

This is a rework of the secure boot code that moves the building of the blob into its own set of source files (and own hooks), making the code more flexible and (hopefully) easier to understand as well. This rework is needed to support more signed firmware for existing and new chips. Since the firmwares in question are not available yet I cannot send the code to manage then, but hopefully the

This is a rework of the secure boot code that moves the building of the blob into its own set of source files (and own hooks), making the code more flexible and (hopefully) easier to understand as well. This rework is needed to support more signed firmware for existing and new chips. Since the firmwares in question are not available yet I cannot send the code to manage then, but hopefully the

This revision includes initial signed PMU firmware support for GM20B (Tegra X1). This PMU code will also be used as a basis for dGPU signed PMU firmware support. With the PMU code, the refactoring of secure boot should also make more sense. ACR (secure boot) support is now separated by the driver version it originates from. This separation allows to run any version of the ACR on any chip,

Sending things in a smaller chunks since it makes their reviewing easier. This part part 2/3 of the secboot refactoring/PMU command support patch series. Part 1 was the new falcon library which should be merged soon now. This series is mainly a refactoring/sanitization of the existing secure boot code. It does not add new features (part 3 will). Secure boot handling is now separated by NVIDIA

From: Jérôme Glisse <jglisse at redhat.com> (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)). git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00