similar to: [PATCH] drm/nouveau: gr/gk20a: Use firmware version 0

From: Thierry Reding <treding at nvidia.com> [ Upstream commit 21454fe697fde188ad6fb541f94b9838fa73ab38 ] Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on available FW")

smatch reports drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: symbol 'tu102_gr_load' was not declared. Should it be static? This function is not used so remove it. Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: ?tu102_gr_load? defined but not used [-Wunused-function] Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at ffwll.ch>

On Wed, 3 Jun 2020 at 15:20, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > Tegra firmware doesn't actually use any version numbers and passing -1 > causes the existing firmware binaries not to be found. Use version 0 to > find the correct files. > > Signed-off-by: Thierry Reding <treding at

On Fri, Mar 17, 2023 at 9:23?AM Lee Jones <lee at kernel.org> wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: ?tu102_gr_load? defined but not used [-Wunused-function] > mhh, this looks a little fishy and might be a mistake not using this function. Ben, is it safe to remove it? The code seems to

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for ?tu102_gr_load? [-Wmissing-prototypes] Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at

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

On 08/12/2023 10:46, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not > preserved across suspend") uses container_of() to cast from struct > nvkm_memory to struct nvkm_instobj, assuming that all instance objects > are derived from struct nvkm_instobj. For the gk20a family

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

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

From: Thierry Reding <treding at nvidia.com> Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not preserved across suspend") uses container_of() to cast from struct nvkm_memory to struct nvkm_instobj, assuming that all instance objects are derived from struct nvkm_instobj. For the gk20a family that's not the case and they are derived from struct nvkm_memory instead.

This patch series is the final (?) step towards the initial support of GK20A, allowing it to be probed and used (currently at a very slow speed, and for offscreen rendering only) on the Jetson TK1 and Venice 2 boards. The main piece if the first patch which adds platform devices probing support to Nouveau. There are probably lots of things that need to be discussed about it, e.g.: * The way the

Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") introduced add a teardown helper function for BAR1. During initialisation of the Nouveau, initially all the teardown helpers are called once, before calling their init counterparts. For gk20a, after the BAR1 teardown function is called, the device is hanging during the initialisation of the FB sub-device. At this point it

From: Arnd Bergmann <arnd at arndb.de> tu102_gr_load() is completely unused and can be removed to address this warning: drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype for 'nv50_display_create' Another patch was sent in the meantime to mark the function static but that would just cause a different warning about an unused function. Fixes: 1cd97b5490c8

If a memory allocation fails when using the DMA allocator, gk20a_instobj_dtor_dma() will be called on the failed instmem object. At this time, node->handle might not be NULL despite the call to dma_alloc_attrs() having failed. node->cpuaddr is the right member to check for such a failure, so use it instead. Reported-by: Vince Hsu <vinceh at nvidia.com> Signed-off-by: Alexandre Courbot

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v2: - change subject prefix to "iommu: virtio: " for virtio-iommu.c driver Thierry Thierry Reding (5):

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v3: - add Reviewed-by from Jean-Philippe Brucker on virtio patch - add Acked-by from Will Deacon on ARM SMMU patch

Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c index 4ca8ed1..de8b806 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by: