Displaying 20 results from an estimated 5000 matches similar to: "[PATCH v4 0/6] drm: nouveau: memory coherency on ARM"
2014 Oct 27
4
[PATCH v5 0/4] drm: nouveau: memory coherency on ARM
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
2014 Jul 10
2
[PATCH v4 4/6] drm/nouveau: synchronize BOs when required
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.
>
2014 Jul 11
1
[PATCH v4 4/6] drm/nouveau: synchronize BOs when required
On Fri, Jul 11, 2014 at 11:40:27AM +0900, Alexandre Courbot wrote:
> On 07/10/2014 10:04 PM, Daniel Vetter wrote:
> >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.
>
2014 May 19
8
[PATCH 0/4] drm/ttm: nouveau: memory coherency fixes for ARM
This small series introduces TTM helper functions as well as Nouveau hooks that
are needed to ensure buffer coherency on ARM. Most of this series is a
forward-port of some patches Lucas Stach sent last year and that are also
needed for Nouveau GK20A support:
http://lists.freedesktop.org/archives/nouveau/2013-August/014026.html
Another patch takes care of flushing the CPU write-buffer when
2014 Jun 24
4
[PATCH v2 0/3] drm/ttm: nouveau: memory coherency for ARM
For this v2 I have fixed the patches that are non-controversial (all Lucas' :))
and am resubmitting them in the hope that they will get merged. This will
just leave the issue of Nouveau system-memory buffers mapping to be solved.
This issue is quite complex, so let me summarize the situation and the data
I have at hand. ARM caching is like a quantum world where Murphy's law
constantly
2013 Aug 28
11
[PATCH 0/6] Nouveau on ARM fixes
This is the first set of patches to make Nouveau work
on Tegra. Those are only the obvious correctness fixes,
a lot of optimization work remains to be done, but at least
it's enough to get accel working and let the machine survive
a piglit run.
A new BO flag is introduced to allow userspace to hint the
kernel about possible optimizations.
Lucas Stach (6):
drm/ttm: recognize ARM arch in
2016 Jul 13
1
[PATCH 1/2] ttm: remove special handling of coherent objects
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
2018 Feb 27
4
[PATCH 4/5] drm/ttm: add ttm_sg_tt_init
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
2014 Jul 31
2
[PATCH v5] drm/nouveau: map pages using DMA API
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
2014 Feb 12
2
[PATCH v2] drm/nouveau: support for platform devices
On 12/02/14 05:38, Alexandre Courbot wrote:
> 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()
2014 Feb 11
2
[PATCH] drm/nouveau: support for platform devices
On Mon, Feb 10, 2014 at 8:50 PM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c
> [...]
>> +resource_size_t
>> +nv_device_resource_start(struct nouveau_device *device,
2013 Jul 12
2
[PATCH] drm/nouveau: kill nouveau_ttm_fault_reserve_notify handler to prevent useless buffer moves
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
2014 Jul 08
0
[PATCH v4 4/6] drm/nouveau: synchronize BOs when required
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
2013 Aug 28
2
[PATCH 3/6] drm/nouveau: hook up cache sync functions
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> Signed-off-by: Lucas Stach <dev at lynxeye.de>
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++
> drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index
2020 Jan 24
4
TTM/Nouveau cleanups
Hi guys,
I've already send this out in September last year, but only got a response from Daniel.
Could you guys please test this and tell me what you think about it?
Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework.
Thanks,
Christian.
2014 May 19
2
[PATCH 3/4] drm/nouveau: hook up cache sync functions
On Mon, May 19, 2014 at 04:10:57PM +0900, Alexandre Courbot wrote:
> From: Lucas Stach <dev at lynxeye.de>
>
> Signed-off-by: Lucas Stach <dev at lynxeye.de>
> [acourbot at nvidia.com: make conditional and platform-friendly]
> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
Perhaps having a propery commit message here would be good.
> diff --git
2020 Nov 06
4
[PATCH 0/3] drm/nouveau: extend the lifetime of nouveau_drm
Hi folks,
Currently, when the device is removed (or the driver is unbound) the
nouveau_drm structure de-allocated. However, it's still accessible from
and used by some DRM layer callbacks. For example, file handles can be
closed after the device has been removed (physically or otherwise). This
series converts the Nouveau device structure to be allocated and
de-allocated with the
2020 Aug 21
5
Moving LRU handling into Nouveau v3
Hi guys,
so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine.
Could you give it more testing?
Thanks in advance,
Christian
2019 Nov 20
2
Move io_reserve_lru handling into the driver
Just a gentle ping on this.
Already got the Acked-by from Daniel, but I need some of the
nouveau guys to test this since I can only compile test it.
Regards,
Christian.
2016 Sep 18
5
[PATCH 1/2] Revert "bus: remove cpu_coherent flag"
This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
The commit caused fence timeouts within nvc0_screen_destroy and most likely
other places as well.
The most obvious effect is, that userspace processes take minutes to actually
quit.
Signed-off-by: Karol Herbst <karolherbst at gmail.com>
---
drm/nouveau/include/nvkm/core/device.h | 1 +
drm/nouveau/nouveau_bo.c |