similar to: [PATCH] drm/nouveau: use new TTM populate/DMA map function

On Thu, Jul 31, 2014 at 06:09:42PM +0900, Alexandre Courbot wrote: > 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

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

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Commonly-used PCI functions include resource range query and page mapping. These functions are

Ping? Am 27.02.2018 um 13:07 schrieb Christian König: > Hi guys, > > at least on amdgpu and radeon the page array allocated by > ttm_dma_tt_init is completely unused in the case of DMA-buf sharing. > So I'm trying to get rid of that by only allocating the DMA address > array. > > Now the only other user of DMA-buf together with ttm_dma_tt_init is > Nouveau. So

Hi guys, at least on amdgpu and radeon the page array allocated by ttm_dma_tt_init is completely unused in the case of DMA-buf sharing. So I'm trying to get rid of that by only allocating the DMA address array. Now the only other user of DMA-buf together with ttm_dma_tt_init is Nouveau. So my question is are you guys using the page array anywhere in your kernel driver in case of a

Fix variables set but not used compilation warnings: ./nouveau_bo.c:1313:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] struct device *dev; ^~~ ./nouveau_bo.c:1337:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] struct device *dev; ^~~ Reported-by: Hulk Robot <hulkci at huawei.com> Signed-off-by: Zou

fixed the following warnings drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 -- 1 file changed, 2 deletions(-)

Am 20.11.20 um 07:49 schrieb Tian Tao: > fixed the following warnings > drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ?dev? > set but not used [-Wunused-but-set-variable] > drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ?dev? > set but not used [-Wunused-but-set-variable] > > Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> The

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

On architectures for which access to GPU memory is non-coherent, caches need to be flushed and invalidated explicitly when BO control changes between CPU and GPU. This patch adds buffer synchronization functions which invokes the correct API (PCI or DMA) to ensure synchronization is effective. Based on the TTM DMA cache helper patches by Lucas Stach. Signed-off-by: Lucas Stach <dev at

On Tue, Jul 08, 2014 at 05:25:59PM +0900, Alexandre Courbot wrote: > On architectures for which access to GPU memory is non-coherent, > caches need to be flushed and invalidated explicitly when BO control > changes between CPU and GPU. > > This patch adds buffer synchronization functions which invokes the > correct API (PCI or DMA) to ensure synchronization is effective. >

From: Lucas Stach <dev at lynxeye.de> On arches with non-coherent PCI, we need to flush caches ourselfes at the appropriate places. Introduce two small helpers to make things easy for TTM based drivers. Signed-off-by: Lucas Stach <dev at lynxeye.de> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/ttm/ttm_tt.c | 25 +++++++++++++++++++++++++

From: Lucas Stach <dev at lynxeye.de> On architectures for which access to GPU memory is non-coherent, caches need to be flushed and invalidated explicitly at the appropriate places. Introduce two small helpers to make things easy for TTM-based drivers. Signed-off-by: Lucas Stach <dev at lynxeye.de> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---

It has been a couple of months since v4 - apologies for this. v4 has not received many comments, but this version addresses them and makes a new attempt at pushing the critical bit for GK20A and Nouveau on ARM in general. As a reminder, this series addresses the memory coherency issue that we are seeing on ARM platforms. Contrary to x86 which invalidates the PCI caches whenever a write is made by

TTM-allocated coherent objects were populated using the DMA API and accessed using the mapping it returned to workaround coherency issues. These issues seem to have been solved, thus remove this extra case to handle and use the regular kernel mapping functions. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nouveau_bo.c | 61

On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p > VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to > get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. It's not bogus, and is

I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c

On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote: > From: Lucas Stach <dev at lynxeye.de> > > On arches with non-coherent PCI, I guess since this applies to gk20a > we need to flush caches ourselfes at "ourselves". Or perhaps even reword to something like: "..., caches need to be flushed and invalidated explicitly", since

On Mon, May 19, 2014 at 5:33 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote: >> From: Lucas Stach <dev at lynxeye.de> >> >> On arches with non-coherent PCI, > > I guess since this applies to gk20a > >> we need to flush caches ourselfes at > > "ourselves". Or