similar to: [PATCH 0/6] drm/nouveau: Preparatory work for GV11B support

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > in fact use the same apertures as regular GPUs. Prior to gv11b there are > no checks in hardware for the aperture, so we get away with setting VRAM > as the

From: Thierry Reding <treding at nvidia.com> Hi, the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why exactly is not clear, but there are slight differences between the SKUs that were tested. It turns out that the biggest issue is that on some devices (e.g. the one that I have), pulsing the GPU reset twice as is done in the current code (once as part of the power-ungate

From: Thierry Reding <treding at nvidia.com> The gk20a (as well as all subsequent Tegra instantiations of the GPU) do in fact use the same apertures as regular GPUs. Prior to gv11b there are no checks in hardware for the aperture, so we get away with setting VRAM as the aperture for buffers that are actually in system memory. Signed-off-by: Thierry Reding <treding at nvidia.com> ---

On Tue, Sep 17, 2019 at 01:43:13PM +1000, Ben Skeggs wrote: > On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > > > From: Thierry Reding <treding at nvidia.com> > > > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > > in fact use the same apertures as regular GPUs. Prior to gv11b there are

These are based on 5.8.0-rc2 and intended for Ben Skeggs' nouveau tree. I believe the changes can be queued for 5.8-rcX after being reviewed. These were part of a larger series but I'm resending them separately as suggested by Jason Gunthorpe. https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell at nvidia.com/ Note that in order to exercise/test patch 2 here, you will need a

hmm_range_fault() returns an array of page frame numbers and flags for how the pages are mapped in the requested process' page tables. The PFN can be used to get the struct page with hmm_pfn_to_page() and the page size order can be determined with compound_order(page) but if the page is larger than order 0 (PAGE_SIZE), there is no indication that the page is mapped using a larger page size. 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

Thanks to Thierry for finding this - applying index e14643615698..00eeaaffeae5 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c @@ -2369,7 +2369,7 @@ nv13b_chipset = { .imem = gk20a_instmem_new, .ltc = gp100_ltc_new, .mc = gp10b_mc_new, - .mmu = gf100_mmu_new, + .mmu = gp10b_mmu_new,

These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM self tests. Patch 7-8 prepare nouveau for the meat of this series which adds support and testing for compound page mapping of system memory (patches 9-11) and compound page migration to device private memory (patches 12-16). Since these changes are split

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One

I just built a linux-4.18.7 kernel from kernel.org for opensuse linux 42.3. When I issued the command "sudo make modules_install install" I received a series of error messages: dracut: Possible missing firmware "nvidia/gv100/sec2/sig.bin" for kernel module "nouveau.ko" dracut: Possible missing firmware "nvidia/gv100/sec2/image.bin" for kernel module

The symbol is not used outside of the file, so mark it static. Fixes the following warning: ./drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c:591:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? Signed-off-by: ruanjinjie <ruanjinjie at huawei.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c | 2 +- 1 file changed, 1 insertion(+), 1

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The engine field in the FIFO fault information registers is actually 9 > bits wide. Looks like this is true for fault buffer parsing too. > > Signed-off-by: Thierry Reding <treding at nvidia.com> > --- >

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

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The fault information register contains data about the aperture that > caused the failure. This can be useful in debugging aperture related > programming bugs. Should this be parsed for fault buffer entries too? > >

The functions nvkm_vmm_ctor() and nvkm_mmu_ptp_get() are not called outside of the file defining them so make them static. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 --- 3 files changed, 2 insertions(+), 5

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not 100% sure that this is needed, but BSP/MPEG are in the mask. drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c b/drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c index 0cb322a..f25fc5f 100644 ---

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

From: Thierry Reding <treding at nvidia.com> The purpose of BAR1 is primarily to make memory accesses coherent. However, some GPUs do not have BAR1 functionality. For example, the GV11B found on the Xavier SoC is DMA coherent and therefore doesn't need BAR1. Implement a variant of FIFO channels that work without a mapping of instance memory through BAR1. XXX ensure memory barriers are

The goal for this series is to introduce the hmm_pfn_to_map_order() function. This allows a device driver to know that a given 4K PFN is actually mapped by the CPU using a larger sized CPU page table entry and therefore the device driver can safely map system memory using larger device MMU PTEs. The series is based on 5.8.0-rc3 and is intended for Jason Gunthorpe's hmm tree. These were