search for: comptag

...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. Can GK20A take comptags with aperture set to system memory? For some reason I can recall, I was under the impression PTEs needed to be pointed at "vidmem" (despite them actually accessing system memory anyway) on Tegra parts for compression to work? I could be mistaken though. Ben. > > Signed-off-by:...

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 35e4909b6a2b4005ced3c4238da60d926b78fdea ] Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/core/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/core/memory.c

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 35e4909b6a2b4005ced3c4238da60d926b78fdea ] Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/core/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/core/memory.c

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 35e4909b6a2b4005ced3c4238da60d926b78fdea ] Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/core/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/core/memory.c

...ent 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. > Can GK20A take comptags with aperture set to system memory? For some > reason I can recall, I was under the impression PTEs needed to be > pointed at "vidmem" (despite them actually accessing system memory > anyway) on Tegra parts for compression to work? I could be mistaken > though. I don't...

...uot;drm/nouveau/mmu: automatically handle "un-bootstrapping" of vmm") 6359c982243e ("drm/nouveau/mmu/gp10b: fork from gf100") 698c1aa9f83b ("drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectors") 7f53d6dc9a72 ("drm/nouveau/core/memory: comptag allocation") 806a73356537 ("drm/nouveau/mmu: implement base for new vm management") 90df522912ac ("drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on newer chipsets") 997a89003c2d ("drm/nouveau/core/memory: add reference counting") b86a45...

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS

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