CMA-allocated memory must be freed by an exact mirror call to
dma_release_from_contiguous(). It cannot be freed page-by-page as was
previously believed without severe memory leakage.
This page records the address and size of every allocated memory chunk
so they can be properly freed when needed.
Fix a very shameful memory leak and a compilation error due to the use of
non-exported CMA functions. The workaround for the latter is not really elegant
(replace the CMA functions by a runtime failure if we are compiled as a
module), but is temporary and still an improvement over the current
CMA functions are not available to kernel modules, but the GK20A FB
driver currently (and temporarily) relies on them.
This patch replaces the calls to CMA functions in problematic cases (CMA
enabled and Nouveau compiled as a module) with dummy stubs that will
make this particular driver fail,
From: Lucas Stach d...@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 d...@lynxeye.de
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Some architectures (e.g. ARM) need the CPU buffers to be explicitely
flushed for a memory write to take effect. Not doing so results in
synchronization issues, especially after writing to BOs.
This patch introduces a macro that flushes the caches on ARM and
translates to a no-op on other
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
[acour...@nvidia.com: make conditional and platform-friendly]
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 32
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014
On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote:
From: Lucas Stach d...@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
On Mon, May 19, 2014 at 04:10:57PM +0900, Alexandre Courbot wrote:
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
[acour...@nvidia.com: make conditional and platform-friendly]
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Perhaps having a propery commit
On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
Some architectures (e.g. ARM) need the CPU buffers to be explicitely
flushed for a memory write to take effect. Not doing so results in
synchronization issues, especially after writing to BOs.
It seems to me that the above is
Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
Some architectures (e.g. ARM) need the CPU buffers to be explicitely
flushed for a memory write to take effect. Not doing so results in
synchronization issues,
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
Add a platform driver for Nouveau devices declared using the device tree
or platform data. This driver currently supports GK20A on Tegra
platforms and is only compiled for these platforms if Nouveau is
enabled.
Nouveau will probe the chip type itself using the BOOT0 register, so all
this driver
Add the device tree binding documentation for the GK20A GPU used in
Tegra K1 SoCs.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644
From: Thierry Reding tred...@nvidia.com
Signed-off-by: Thierry Reding tred...@nvidia.com
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra124-venice2.dts | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
Am Montag, den 19.05.2014, 16:10 +0900 schrieb Alexandre Courbot:
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
[acour...@nvidia.com: make conditional and platform-friendly]
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Am Montag, den 19.05.2014, 10:46 +0200 schrieb Thierry Reding:
On Mon, May 19, 2014 at 04:10:57PM +0900, Alexandre Courbot wrote:
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
[acour...@nvidia.com: make conditional and platform-friendly]
Signed-off-by:
This patch is not meant to be merged, but rather to try and understand
why this is needed and what a more suitable solution could be.
Allowing BOs to be write-cached results in the following happening when
trying to run any program on Tegra/GK20A:
Unhandled fault: external abort on non-linefetch
Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
This patch is not meant to be merged, but rather to try and understand
why this is needed and what a more suitable solution could be.
Allowing BOs to be write-cached results in the following happening when
trying to run any
On Mon, May 19, 2014 at 11:22:11AM +0200, Lucas Stach wrote:
Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
Some architectures (e.g. ARM) need the CPU buffers to be explicitely
flushed for a memory write to
Am Montag, den 19.05.2014, 18:24 +0900 schrieb Alexandre Courbot:
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.
This seem
On 05/19/2014 06:57 PM, Lucas Stach wrote:
Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
This patch is not meant to be merged, but rather to try and understand
why this is needed and what a more suitable solution could be.
Allowing BOs to be write-cached results in the
On Mon, May 19, 2014 at 12:04:28PM +0200, Lucas Stach wrote:
Am Montag, den 19.05.2014, 18:24 +0900 schrieb Alexandre Courbot:
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
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14
Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot:
On 05/19/2014 06:57 PM, Lucas Stach wrote:
Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
This patch is not meant to be merged, but rather to try and understand
why this is needed and what a more suitable
On Mon, May 19, 2014 at 12:03:17PM +0200, Thierry Reding wrote:
On Mon, May 19, 2014 at 11:22:11AM +0200, Lucas Stach wrote:
Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
Some architectures (e.g. ARM)
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides with the way we
do reset handling from a conceptual point of view. Every IOCTL or
other call
op 19-05-14 14:30, Christian König schreef:
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides with the way we do reset
handling from a
Am 19.05.2014 15:35, schrieb Maarten Lankhorst:
op 19-05-14 14:30, Christian König schreef:
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
Add the device tree binding documentation for the GK20A GPU used in
Tegra K1 SoCs.
A few minor nits, but otherwise,
Acked-by: Stephen Warren swar...@nvidia.com
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
From: Thierry Reding tred...@nvidia.com
Add the GK20A device node to Tegra124's device tree.
At a quick glance, patches 3-5 look fine too. I'll hold off on applying
them until patches 1-2 have been applied to the DRM/... tree.
33 matches
Mail list logo
