On Fri, 13 Sep 2019 at 21:33, Karol Herbst wrote:
>
> v2: fixed compilation error
Is there any need for this patch at all now, if you're forcing 8_0
rather than the pre-DEVINIT speed?
>
> Signed-off-by: Karol Herbst
> Reviewed-by: Lyude Paul
> ---
> drm/nouveau/include/nvkm/subdev/pci.h | 1 +
On Fri, 13 Sep 2019 at 05:00, Karol Herbst wrote:
>
> taken from nvgpu
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/nvkm/subdev/pci/g84.c | 9 +
> drm/nouveau/nvkm/subdev/pci/g92.c | 1 +
> drm/nouveau/nvkm/subdev/pci/g94.c | 1 +
> drm/nouveau/nvkm/subdev/pci/gf100.c |
On Tue, 17 Sep 2019 at 01:04, Thierry Reding wrote:
>
> From: Thierry Reding
>
> 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.
>
>
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> From: Thierry Reding
>
> 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
> ---
>
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> From: Thierry Reding
>
> 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?
>
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> From: Thierry Reding
>
> 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
On 16/09/2019 16:57, Thierry Reding wrote:
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
> Hi Thierry,
>
> On 16/09/2019 16:04, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > If the GPU is already attached to an IOMMU, don't detach it and setup an
> > explicit IOMMU domain. Since Nouveau can now properly handle
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
> > >
> > > There are extra registers that need to be programmed to make the level 2
> > > cache
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
> >
> > 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
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
From: Thierry Reding
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
From: Thierry Reding
Some registers and instance block entries need the aperture to be
programmed correctly. This is important on recent Tegra GPUs where
the GPU actually checks the value of this field and faults if an
invalid aperture is programmed.
For example GV11B no longer supports VRAM
From: Thierry Reding
These implementations are now all unused. Remove them.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c | 14 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c
From: Thierry Reding
The aperture of a buffer is always specific to where its memory was
allocated from. Furthermore, the encoding of the aperture is always
the same, regardless of GPU generation.
Implement the memory target to aperture conversion in one central
place and make the aperture
From: Thierry Reding
The fault information register contains data about the aperture that
caused the failure. This can be useful in debugging aperture related
programming bugs.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 +
From: Thierry Reding
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
From: Thierry Reding
The engine field in the FIFO fault information registers is actually 9
bits wide.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Thierry Reding
The GPU has a connection to the ARM SMMU found on Tegra186, which can be
used to support large pages. Make sure the GPU is attached to the SMMU
to take advantage of its capabilities.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
1 file
From: Alexandre Courbot
Enable the GPU node for the Jetson TX2 board.
Signed-off-by: Alexandre Courbot
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts | 4
1 file changed, 4 insertions(+)
diff --git
From: Thierry Reding
The GPU integrated in NVIDIA Tegra SoCs is connected to system memory
via two paths: one direct path to the memory controller and another path
that goes through a system MMU first. It's not typically necessary to go
through the system MMU because the GPU's MMU can already
From: Thierry Reding
The GPU can usually address more than 32-bit, even without being
attached to an IOMMU. However, if the GPU is not attached to an IOMMU,
it's likely that there is no IOMMU in the system, in which case any
buffers allocated by Nouveau will likely end up in a region of memory
From: Thierry Reding
gp10b uses the new engine enumeration mechanism introduced in the Pascal
architecture. As a result, the copy engine, which used to be at index 2
for prior Tegra GPU instantiations, has now moved to index 0. Fix up the
index and also use the gp100 variant of the copy engine
From: Thierry Reding
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.
Signed-off-by: Thierry Reding
---
.../gpu/drm/nouveau/include/nvkm/subdev/ltc.h |
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Detect if the DMA API is backed by an IOMMU and set the IOMMU bit if so.
This is needed to make sure IOMMU addresses are properly translated even
the explicit IOMMU API is not used.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 35
From: Thierry Reding
If the GPU clock has not had a rate set, initialize it to the maximum
clock rate to make sure it does run.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 12
1 file changed, 12 insertions(+)
diff --git
From: Thierry Reding
When the GPU powergate is controlled by a generic power domain provider,
the reset will automatically be asserted and deasserted as part of the
power-ungating procedure.
On some Jetson TX2 boards, doing an additional assert and deassert of
the GPU outside of the
From: Thierry Reding
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.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
When Nouveau is instantiated on top of a platform device, the dev->pdev
field will be NULL and calling pci_disable_device() will crash. Move the
PCI disabling code to the PCI specific driver removal code.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Fill in BAR2 callbacks for instance memory. There's no BAR2 on Tegra
GPUs, but buffers are all in system memory anyway, so just return the
plain address.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 30 +++
1 file
From: Thierry Reding
Hi Ben,
I messed up the ordering of patches in my tree a bit, so these two fixes
got separated from the others. I don't consider these particularily
urgent because the crash that the first one fixes only happens on gp10b
which we don't enable by default yet and the second
From: Thierry Reding
Hi Ben,
these are fixes for a couple of issues that I've been running into when
testing on various Tegra boards. The first two patches fix up issues in
the fix that I had sent out earlier to fix the regression introduced in
drm-misc-next. The first one is critical because
From: Thierry Reding
Prior to commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before
TTM object"), the reservation object was locked across all of the buffer
object creation.
After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and
nouveau_bo_init() functions, the
From: Thierry Reding
When the last reference to a TTM BO is dropped, ttm_bo_release() will
acquire the DMA reservation object's wound/wait mutex while trying to
clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is
therefore essential that drm_gem_object_release() be called after
From: Thierry Reding
Writing the 0x1704 (BUS_BAR1_BLOCK) register causes the GPU to probe the
memory region at the programmed address. The result is an address decode
error in the external memory controller because address 0, which is what
is written to the register, is not designated as
From: Thierry Reding
Commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM
object") introduced a subtle change in how the buffer allocation size is
handled. Prior to that change, the size would get aligned to at least a
page, whereas after that change a non-page-aligned size would
https://bugs.freedesktop.org/show_bug.cgi?id=103217
--- Comment #10 from sarataylor ---
After years of not sleeping well and not finding the right guide for natural
products online, she decided to do the research so others don’t suffer when
buying a new mattress as she did. For the past 3 years,
On 9/13/19 6:28 PM, José Roberto de Souza wrote:
> Currently we restrict the number of encoders that can be linked to
> a connector to 3, increase it to match the maximum number of encoders
> that can be initialized(32).
>
> To more effiently do that lets switch from an array of encoder ids to
>
https://bugs.freedesktop.org/show_bug.cgi?id=108857
--- Comment #10 from Vasili Pupkin ---
I am experiencing a similar behaviour and a crash with a similar callstack on a
much older hardware, see bug 111642
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107016
--- Comment #25 from atirage21 ---
Created attachment 145371
--> https://bugs.freedesktop.org/attachment.cgi?id=145371=edit
Valgrind-mmt log from glxgears with driver nvidia 390.116ubuntu0.18.04.1
--
You are receiving this mail because:
You
41 matches
Mail list logo
