From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will.deacon@arm.com>,
David Zhou <David1.Zhou@amd.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
David Airlie <airlied@linux.ie>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Michel Daenzer <michel.daenzer@amd.com>,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Junwei Zhang <Jerry.Zhang@amd.com>, Huang Rui <ray.huang@amd.com>,
dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
Michael Ellerman <mpe@ellerman.id.au>,
Alex Deucher <alexander.deucher@amd.com>,
Sean Paul <sean@poorly.run>,
Christian Koenig <christian.koenig@amd.com>
Subject: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
Date: Mon, 21 Jan 2019 11:06:17 +0100 [thread overview]
Message-ID: <20190121100617.2311-1-ard.biesheuvel@linaro.org> (raw)
Currently, the DRM code assumes that PCI devices are always cache
coherent for DMA, and that this can be selectively overridden for
some buffers using non-cached mappings on the CPU side and PCIe
NoSnoop transactions on the bus side.
Whether the NoSnoop part is implemented correctly is highly platform
specific. Whether it /matters/ if NoSnoop is implemented correctly or
not is architecture specific: on x86, such transactions are coherent
with the CPU whether the NoSnoop attribute is honored or not. On other
architectures, it depends on whether such transactions may allocate in
caches that are non-coherent with the CPU's uncached mappings.
Bottom line is that we should not rely on this optimization to work
correctly for cache coherent devices in the general case. On the
other hand, disabling this optimization for non-coherent devices
is likely to cause breakage as well, since the driver will assume
cache coherent PCIe if this optimization is turned off.
So rename drm_arch_can_wc_memory() to drm_device_can_wc_memory(), and
pass the drm_device pointer into it so we can base the return value
on whether the device is cache coherent or not if not running on
X86.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Zhou <David1.Zhou@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Michel Daenzer <michel.daenzer@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Will Deacon <will.deacon@arm.com>
Reported-by: Carsten Haitzler <Carsten.Haitzler@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
This is a followup to '[RFC PATCH] drm/ttm: force cached mappings for system
RAM on ARM'
https://lore.kernel.org/linux-arm-kernel/20190110072841.3283-1-ard.biesheuvel@linaro.org/
Without t
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
include/drm/drm_cache.h | 19 +++++++++++--------
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 728e15e5d68a..777fa251838f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -480,7 +480,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
/* For architectures that don't support WC memory,
* mask out the WC flag from the BO
*/
- if (!drm_arch_can_wc_memory())
+ if (!drm_device_can_wc_memory(adev->ddev))
bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
#endif
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index 833e909706a9..610889bf6ab5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -249,7 +249,7 @@ int radeon_bo_create(struct radeon_device *rdev,
/* For architectures that don't support WC memory,
* mask out the WC flag from the BO
*/
- if (!drm_arch_can_wc_memory())
+ if (!drm_device_can_wc_memory(rdev->ddev))
bo->flags &= ~RADEON_GEM_GTT_WC;
#endif
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index bfe1639df02d..ced63b1207a3 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -33,6 +33,8 @@
#ifndef _DRM_CACHE_H_
#define _DRM_CACHE_H_
+#include <drm/drm_device.h>
+#include <linux/dma-noncoherent.h>
#include <linux/scatterlist.h>
void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
@@ -41,15 +43,16 @@ void drm_clflush_virt_range(void *addr, unsigned long length);
u64 drm_get_max_iomem(void);
-static inline bool drm_arch_can_wc_memory(void)
+static inline bool drm_device_can_wc_memory(struct drm_device *ddev)
{
-#if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
- return false;
-#elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
- return false;
-#else
- return true;
-#endif
+ if (IS_ENABLED(CONFIG_PPC))
+ return IS_ENABLED(CONFIG_NOT_COHERENT_CACHE);
+ else if (IS_ENABLED(CONFIG_MIPS))
+ return !IS_ENABLED(CONFIG_CPU_LOONGSON3);
+ else if (IS_ENABLED(CONFIG_X86))
+ return true;
+
+ return !dev_is_dma_coherent(ddev->dev);
}
#endif
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-01-21 10:06 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 10:06 Ard Biesheuvel [this message]
2019-01-21 10:11 ` [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86 Koenig, Christian
2019-01-21 15:07 ` Christoph Hellwig
2019-01-21 15:33 ` Ard Biesheuvel
2019-01-21 15:59 ` Christoph Hellwig
2019-01-21 16:14 ` Ard Biesheuvel
2019-01-21 16:22 ` Christoph Hellwig
2019-01-21 16:30 ` Ard Biesheuvel
2019-01-21 16:35 ` Christoph Hellwig
2019-01-21 16:50 ` Ard Biesheuvel
2019-01-21 17:55 ` Michel Dänzer
2019-01-21 17:59 ` Ard Biesheuvel
2019-01-21 18:04 ` Michel Dänzer
2019-01-21 18:20 ` Ard Biesheuvel
2019-01-21 18:23 ` Michel Dänzer
2019-01-21 18:28 ` Ard Biesheuvel
2019-01-21 19:04 ` Michel Dänzer
2019-01-21 19:18 ` Ard Biesheuvel
2019-01-22 8:38 ` Ard Biesheuvel
2019-01-22 20:56 ` Alex Deucher
2019-01-22 21:07 ` Ard Biesheuvel
2019-01-23 7:15 ` Christoph Hellwig
2019-01-23 9:08 ` Ard Biesheuvel
2019-01-23 16:44 ` Christoph Hellwig
2019-01-23 16:52 ` Ard Biesheuvel
2019-01-24 9:13 ` Christoph Hellwig
2019-01-24 9:25 ` Koenig, Christian
2019-01-24 9:28 ` Ard Biesheuvel
2019-01-24 9:45 ` Koenig, Christian
2019-01-24 9:59 ` Ard Biesheuvel
2019-01-24 11:23 ` Koenig, Christian
2019-01-24 11:26 ` Ard Biesheuvel
2019-01-24 11:37 ` Koenig, Christian
2019-01-24 11:45 ` Ard Biesheuvel
2019-01-24 13:54 ` Alex Deucher
2019-01-24 13:57 ` Ard Biesheuvel
2019-01-24 14:00 ` Alex Deucher
2019-01-24 16:04 ` Michel Dänzer
2019-01-24 9:31 ` Michel Dänzer
2019-01-24 9:37 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190121100617.2311-1-ard.biesheuvel@linaro.org \
--to=ard.biesheuvel@linaro.org \
--cc=David1.Zhou@amd.com \
--cc=Jerry.Zhang@amd.com \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=benh@kernel.crashing.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime.ripard@bootlin.com \
--cc=michel.daenzer@amd.com \
--cc=mpe@ellerman.id.au \
--cc=ray.huang@amd.com \
--cc=sean@poorly.run \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox