[Nouveau] [RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD S

[Nouveau] [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD S

Re: [Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 7 July 2016 at 18:59, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes,

Re: [Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 15 July 2016 at 07:52, Alexandre Courbot <gnu...@gmail.com> wrote: > On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: >> The 100c08 scratch page is mapped using dma_map_page() before the TTM >> layer has had a chance to s

Re: [Nouveau] [RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 21 June 2016 at 14:50, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes,

[Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD S

Re: [Nouveau] [PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

On 3 October 2016 at 06:39, Alexandre Courbot <gnu...@gmail.com> wrote: > On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: >> Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using >> dma_map_page() way before

[Nouveau] [PATCH v5 1/3] drm/nouveau: set streaming DMA mask early

RAM is above 4 GB). So set a preliminary DMA mask right after constructing the PCI device, and base it on the .dma_bits member of the MMU subdevice, which is what the TTM layer will base the DMA mask on as well. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/gpu/drm/n

[Nouveau] [PATCH v5 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit() hook

the dma_map_page() to the .oneinit hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 31 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/drivers/g

[Nouveau] [PATCH v5 0/3] drm/nouveau: set DMA mask before mapping scratch page

mask to probe hook (Alexander) v3: rework code to get rid of DMA_ERROR_CODE references, which is not defined on all architectures v2: replace incorrect comparison of dma_addr_t type var against NULL Ard Biesheuvel (3): drm/nouveau: set streaming DMA mask early drm/nouveau/fb/gf100: defe

[Nouveau] [PATCH v5 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit() hook

the dma_map_page() to the .oneinit hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 33 ++-- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/drivers/g

[Nouveau] [PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

RAM is above 4 GB). So set a preliminary DMA mask right after constructing the PCI device, and base it on the .dma_bits member of the MMU subdevice, which is what the TTM layer will base the DMA mask on as well. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/gpu/drm/n

[Nouveau] [PATCH v4 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook

the dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 30 +--- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/g

[Nouveau] [PATCH v4 0/3] drm/nouveau: set DMA mask before mapping scratch page

ct comparison of dma_addr_t type var against NULL Ard Biesheuvel (3): drm/nouveau: set streaming DMA mask early drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook drivers/gpu/drm/nouveau/nouveau_drm.c

[Nouveau] [PATCH v4 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook

the dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 26 ++-- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/g

Re: [Nouveau] [PATCH v5 0/3] drm/nouveau: set DMA mask before mapping scratch page

On 7 October 2016 at 09:12, Alexandre Courbot <gnu...@gmail.com> wrote: > On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: >> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that >> both GF 100 and NV50

[Nouveau] use-after-free bug with GT218 on arm64 machine

Hello all, I am trying to debug an elusive memory corruption bug on my arm64 machine which appears to be in the nouveau driver. I got the following splat from the refcount debugging code: """ refcount_t: underflow; use-after-free. [ cut here ] WARNING: CPU: 0 PID: 3366

Re: [Nouveau] NVAC - BUG: unable to handle kernel NULL pointer dereference

> On 25 Mar 2017, at 10:47, poma wrote: > > > With lightweight desktoping, > the atomic modesetting seems far from robust. > > BUG: unable to handle kernel NULL pointer dereference at 0021 > IP: dma_fence_wait_timeout+0x36/0xf0 > ... I am seeing

Re: [Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one par

Re: [Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

erre, Thanks for the reply. If a fix has been queued, I don't mind leaving it up to Ben to decide when it gets sent onwards. -- Ard. > [0]: > https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa > > On 2017-12-18 — 09:27, Ard Biesheuvel wrote: >>

[Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

refcount_inc(>maps); } i.e., it calls refcount_inc() to increment the refcount when it is known to be zero, which is explicitly forbidden by the API. Instead, use refcount_set() to set it to 1. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- Apologies if this was alre