similar to: GP10B regression

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,

Bisection status report: The latest commit I have gotten to work is 10842ba074e9 drm/nouveau: remove unused nouveau_fence_work() i.e. the first bad commit is d7722134b825 drm/nouveau: switch over to new memory and vmm interfaces Even with the first one some patches/hacks are needed: - in mmu/gp10b.c, in the constructor we need to select the GM200 path - the GP100 path seems to not to work

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

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 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

This allows to have the related MODULE_FIRMWARE tag only on relevant arch (arm64). This will saves about 400k on initramfs when not relevant Signed-off-by: Nicolas Chauvet <kwizart at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp10b.c | 2 ++ 2 files changed, 4 insertions(+) diff --git

2018-06-11 10:33 GMT+02:00 Thierry Reding <thierry.reding at gmail.com>: > On Sun, Jun 10, 2018 at 01:01:31PM +0200, Nicolas Chauvet wrote: >> This allows to have the related MODULE_FIRMWARE tag only >> on relevant arch (arm64). >> This will saves about 400k on initramfs when not relevant >> >> Signed-off-by: Nicolas Chauvet <kwizart at gmail.com>

GP10B uses the same 3D class as GP100. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 3e4c4f44ba92..c9042fc00447 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++

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 Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote: > On 16/09/2019 16:04, Thierry Reding wrote: > > From: Thierry Reding <treding at nvidia.com> > > > > There are extra registers that need to be programmed to make the level 2 > > cache work on GP10B, such as the stream ID register that is used when an > > SMMU is used to translate memory addresses.

On Mon, Sep 16, 2019 at 05:49:46PM +0200, Thierry Reding wrote: > On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote: > > On 16/09/2019 16:04, Thierry Reding wrote: > > > From: Thierry Reding <treding at nvidia.com> > > > > > > There are extra registers that need to be programmed to make the level 2 > > > cache work on GP10B, such as the

I applied the changes manually. This time, Xorg is actually starting... [ 16.862744] WARNING: CPU: 3 PID: 381 at drivers/gpu/drm/nouveau/nouveau_bo.c:280 nouveau_bo_new+0x450/0x4d0 [nouveau] [ 16.873333] Modules linked in: nouveau i2c_algo_bit ttm tegra_drm gpio_keys drm_kms_helper drm drm_panel_orientation_quirks(P) host1x dwmac_dwc_qos_eth stmmac_platform stmmac ptp pps_core syscopyarea

Hi Thierry, Thanks for the patch. I applied on top of linux-next-2017-12-14. Different output this time. [ 11.862495] WARNING: CPU: 1 PID: 254 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:391 gf100_vmm_new_+0x60/0x128 [nouveau] [ 11.863458] tegra-dpaux 155c0000.dpaux: 155c0000.dpaux supply vdd not found, using dummy regulator [ 11.866197] tegra-sor 15580000.sor: failed to probe

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

On Sun, Jun 10, 2018 at 01:01:31PM +0200, Nicolas Chauvet wrote: > This allows to have the related MODULE_FIRMWARE tag only > on relevant arch (arm64). > This will saves about 400k on initramfs when not relevant > > Signed-off-by: Nicolas Chauvet <kwizart at gmail.com> > --- > drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 2 ++ >

On Mon, 9 Dec 2019 at 22:00, Thierry Reding <thierry.reding at gmail.com> wrote: > > 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

From: Thierry Reding <treding at nvidia.com> gp10b doesn't have all the registers that gp102_gr_zbc wants to access, which causes IBUS MMIO faults to occur. Avoid this by using the gp100 variants of grctx and gr_zbc. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gp100.c | 2

From: Thierry Reding <treding at nvidia.com> The low-level Falcon bootstrapping callbacks are expected to return 0 on success or a negative error code on failure. However, the implementation on Tegra returns the ID or mask of the Falcons that were bootstrapped on success, thus breaking the calling code, which treats this as failure. Fix this by making sure we only return 0 or a negative

GP10B's FB is largely compatible with the GP100 implementation, and only requires a few additional register inits. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/fb.h | 1 + drm/nouveau/nvkm/subdev/fb/Kbuild | 1 + drm/nouveau/nvkm/subdev/fb/gp10b.c | 38 ++++++++++++++++++++++++++++++++++++ 3 files changed, 40 insertions(+) create