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

This v4 is now a 3 piece series, after Alexandre pointed out that both GF 100 and NV50 are affected by the same issue, and that a related issue has been solved already for Tegra in commit 9d0394c6bed5 ("drm/nouveau/instmem/gk20a: set DMA mask early"). The issue that this series addresses is the fact that the Nouveau driver invokes the DMA API before setting the DMA mask. In both cases

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, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before

On 7 October 2016 at 09:12, Alexandre Courbot <gnurou at gmail.com> wrote: > On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel > <ard.biesheuvel at linaro.org> wrote: >> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that >> both GF 100 and NV50 are affected by the same issue, and that a related issue >> has been solved already for Tegra

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, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: > Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using > dma_map_page() way before the TTM layer has had a chance to set the DMA > mask. This may prevent the driver from loading at all on platforms whose > system memory is not covered by the default DMA mask of 32-bit (i.e.,

On 15 July 2016 at 07:52, Alexandre Courbot <gnurou at gmail.com> wrote: > On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel > <ard.biesheuvel at 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,

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, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before

The DMA API is the recommended way to map pages no matter what the underlying bus is. Use the DMA functions for page mapping and remove currently existing wrappers. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> Cc: Daniel Vetter <daniel at ffwll.ch> --- Changes since v4: - Patch against the Nouveau tree instead of the kernel - Separated this patch from the rest of the

Ard Biesheuvel <ard.biesheuvel at linaro.org> writes: > 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, and this causes > problems for platforms with no memory below 4 GB (such as AMD Seattle) > > So move the dma_map_page()

Hi Ard, the official nouveau tree is here: https://github.com/skeggsb/nouveau But ben usually takes care of everything if you post the patches on the ML. No idea what you discussed internally though, but alex also posts his suff here. On 16 Oct 2016 22:12, "Ard Biesheuvel" <ard.biesheuvel at linaro.org> wrote: On 7 October 2016 at 09:12, Alexandre Courbot <gnurou at

On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: > This v4 is now a 3 piece series (since v4), after Alexandre pointed out that > both GF 100 and NV50 are affected by the same issue, and that a related issue > has been solved already for Tegra in commit 9d0394c6bed5 > ("drm/nouveau/instmem/gk20a: set DMA mask early"). > > The

After observing random crashes on Tegra devices when patch "fb/gf100: defer DMA mapping of scratch page to oneinit() hook" was applied, I noticed that moving the 100c10 page allocation to the oneinit() hook resulted in that page being now allocated for Tegra as well, and accesses be made to members of gf100_fb which were not accessible because gk20a_fb_new() called nvkm_fb_new_()

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 particular instance, it does the following: if (!refcount_inc_not_zero(&iobj->maps)) { ... refcount_inc(&iobj->maps); } i.e., it calls refcount_inc() to increment the

https://bugs.freedesktop.org/show_bug.cgi?id=100431 Bug ID: 100431 Summary: nv50: memory corruption due to use-after-free of dma_fence Product: xorg Version: unspecified Hardware: ARM OS: Linux (All) Status: NEW Severity: major Priority: medium Component:

Hey Ard, It seems that Ben already committed a similar patch to his tree (see [0]). I do not know whether he is planning to have it part of a pull request of fixes for 4.15. Best regards, Pierre [0]: https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa On 2017-12-18 — 09:27, Ard Biesheuvel wrote: > On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheuvel

The 100c10 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, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard

On Thu, Jan 25, 2018 at 10:35 PM, Lyude Paul <lyude at redhat.com> wrote: > Same as the previous patch, but for Kepler2 now > > Signed-off-by: Lyude Paul <lyude at redhat.com> > --- > drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + > drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +-- > drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 62

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ Some minor changes: - Clarified that SLCG stands for 'secondary level clockgating', thanks for the small tip nvidia! - Removed the concept of levels, this was more useful for debugging then

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ One small change: - Set therm->clkgate_enabled to false until the last patch, where we introduce the NvPmEnableGating option Lyude Paul (5): drm/nouveau: Add support for basic clockgating on

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ One small change: - Add Martin's R-B, whoops Lyude Paul (5): drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau: Add support for BLCG on Kepler1 drm/nouveau: Add support for