similar to: [PATCH 00/11] drm/nouveau: Enable GP10B by default

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for its base engines after reworking secboot a bit to accomodate its calling convention better. This patchset has been tested rendering simple off-screen buffers using Mesa and yielded the expected result. Alexandre Courbot (15): secboot: allow to boot multiple falcons secboot: pass instance to LS firmware loaders secboot:

On Tue, 17 Sep 2019 at 01:04, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The GPUs found on Tegra SoCs have registers that can be used to read the > WPR configuration. Use these registers instead of reaching into the > memory controller's register space to read the same information. > >

Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") tried to be smart while using the DMA-API by managing the CPU mappings of buffers allocated with the DMA-API by itself. In doing so, it relied on dma_to_phys() which is an architecture-private function not available everywhere. This broke the build on several architectures. Since there is no reliable and portable

From: Thierry Reding <treding at nvidia.com> The gk20a implementation of instance memory uses vmap()/vunmap() to map memory regions into the kernel's virtual address space. These functions may sleep, so protecting them by a spin lock is not safe. This triggers a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this by using a mutex instead. Signed-off-by: Thierry Reding

Although I would not have expected this to happen, we seem to run into race conditions if instobjs are accessed concurrently. Use a global lock for safety. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c

On 02/24/2017 01:20 AM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote: >> From: Thierry Reding <treding at nvidia.com> >> >> The gk20a implementation of instance memory uses vmap()/vunmap() to map >> memory regions into the kernel's virtual address space. These functions >>

Due to the lack of implicit synchronization between CPU and GPU on Tegra systems (like what PCI provides for dGPUs), the instmem implementation of GK20A/GM20B relied on the slow, legacy PRAMIN so that CPU accesses used the same path as GPU, making sure we see the same data on both ends. The recent Nouveau refactoring introduced acquire/release functions on instmem that help us understand the

On 3 September 2015 at 16:42, Alexandre Courbot <acourbot at nvidia.com> wrote: > Allow clients to manually flush and invalidate L2. This will be useful > for Tegra systems for which we want to write instmem using the CPU. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau/include/nvkm/subdev/ltc.h | 1 + >

On 3 September 2015 at 17:13, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, Sep 3, 2015 at 4:09 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 3 September 2015 at 16:42, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Allow clients to manually flush and invalidate L2. This will be useful >>> for Tegra systems for which we want to

Hello everyone, it seems that GP10B support has regressed recently. With linux-next, I need to modify device/base.c to set .mmu = gp10b_mmu_new for GP10B (makes sense - I guess this was left as gf100_mmu_new as a typo) to probe. After that, running a trivial testcase (running a NOP method in 3D class) fails with [ 110.084649] nouveau 17000000.gpu: fifo: read fault at 0000011000 engine 06

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

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

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

The INA3221 is usually found on mid and high end kepler+ gpus Marins Patch implements the new iccsense subdev and all needed bits for the INA3221 power sensor. My Patch implements the hwmon power1 interface to expose the current power consumption through hwmon (and can be read out via sysfs or the sensors tool) Please test these patches for Fermi+ GPUs, that nothing gets messed up and works as

This is a complete rework from the first version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards. The power consumption is also exported via

This is a complete rework from the last version I sent out. Now the implementation is more centered around the power_rails we find in the SENSE table instead of extdev centered. This makes the implementation a lot easier and straightforward. I've added support for the INA219, INA209 and INA3221 sensors found on multiple Fermi and Kepler cards, but only the INA3221 bits are tested so far.

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,