[PATCH 1/2] mm: cma: export functions to get CMA base and size

[PATCH 1/2] mm: cma: export functions to get CMA base and size

[Lucas Stach]

Make them usable in modules. Some drivers want to know where their
device CMA area is located to make better decisions about the DMA
programming.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 mm/cma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/cma.c b/mm/cma.c
index 3340ef34c154..191c89bf038d 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -44,11 +44,13 @@ phys_addr_t cma_get_base(const struct cma *cma)
 {
 	return PFN_PHYS(cma->base_pfn);
 }
+EXPORT_SYMBOL_GPL(cma_get_base);
 
 unsigned long cma_get_size(const struct cma *cma)
 {
 	return cma->count << PAGE_SHIFT;
 }
+EXPORT_SYMBOL_GPL(cma_get_size);
 
 const char *cma_get_name(const struct cma *cma)
 {
-- 
2.20.1

[PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset if possible

[Lucas Stach]

The dma_required_mask might overestimate the memory size, or might not match
up with the CMA area placement for other reasons. Get the information about
CMA area placement directly from CMA where it is available, but keep the
dma_required_mask as an approximate fallback for architectures where CMA is
not available.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 72d01e873160..b144f1bbbb3c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -4,7 +4,9 @@
  */
 
 #include <linux/clk.h>
+#include <linux/cma.h>
 #include <linux/component.h>
+#include <linux/dma-contiguous.h>
 #include <linux/dma-fence.h>
 #include <linux/moduleparam.h>
 #include <linux/of_device.h>
@@ -724,11 +726,18 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
 	 */
 	if (!(gpu->identity.features & chipFeatures_PIPE_3D) ||
 	    (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) {
-		u32 dma_mask = (u32)dma_get_required_mask(gpu->dev);
-		if (dma_mask < PHYS_OFFSET + SZ_2G)
+		struct cma *cma = dev_get_cma_area(gpu->dev);
+		phys_addr_t end_mask;
+
+		if (cma)
+			end_mask = cma_get_base(cma) - 1 + cma_get_size(cma);
+		else
+			end_mask = dma_get_required_mask(gpu->dev);
+
+		if (end_mask < PHYS_OFFSET + SZ_2G)
 			gpu->memory_base = PHYS_OFFSET;
 		else
-			gpu->memory_base = dma_mask - SZ_2G + 1;
+			gpu->memory_base = end_mask - SZ_2G + 1;
 	} else if (PHYS_OFFSET >= SZ_2G) {
 		dev_info(gpu->dev, "Need to move linear window on MC1.0, disabling TS\n");
 		gpu->memory_base = PHYS_OFFSET;
-- 
2.20.1

Re: [PATCH 1/2] mm: cma: export functions to get CMA base and size

[Christoph Hellwig]

On Wed, May 29, 2019 at 12:43:11PM +0200, Lucas Stach wrote:
> Make them usable in modules. Some drivers want to know where their
> device CMA area is located to make better decisions about the DMA
> programming.

NAK.  This is very much a layering violation.  At very least you'd
need to wire this up through the DMA API and deal with dma_addr_t
addresses instead of physical addresses, which are opaque to DMA
using drivers.  But even for that we'd need a really good rationale.

Re: [PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset if possible

[Primoz Fiser]

Hi,

what happened to these patches? In thread "[REGRESSION] drm/etnaviv: command
buffer outside valid memory window" [1] it was mentioned these got "shot
down" due to layering violations, but no official correspondence has been
found? Is is due to exporting symbols from mm/cma.c in [1/2] and why is this
an issue?

We are still affected by issue these patches tried to address and we are
interested in getting the solution into mainline.

Patches were integrated (small fix required due to renamed include file header)
and tested on latest master with PHYTEC's 2GiB phyCORE SoM and cma=256M kernel
cmdline parameter.

Without patches:

[    7.892954] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[    7.901286] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[    7.909809] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
[    7.915775] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[    7.924000] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[    7.930615] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[    7.936934] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[    7.948600] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1
[   16.656092] etnaviv etnaviv: command buffer outside valid memory window
[   16.695777] etnaviv etnaviv: command buffer outside valid memory window
[   16.765654] etnaviv etnaviv: command buffer outside valid memory window
[   16.800111] etnaviv etnaviv: command buffer outside valid memory window

NOTE: See "command buffer outside valid memory window" errors when trying to
use GPU.

With patches:

[    7.708159] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[    7.716095] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[    7.724257] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
[    7.730205] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[    7.738407] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[    7.745039] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[    7.751365] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[    7.762876] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1

NOTE: No errors, GPU fully functional!

In the end, it looks like we are not the only ones with the same issues as
patch "drm/etnaviv: optionally set gpu linear window to cma area"  that
addresses the same issue was submitted by Sven Van Asbroeck (see [2]). 
Unfortunately, his solution was also not accepted.

Please advise what would be the best solution implementation and how to
proceed in this case?

BR,
Primoz

[1] https://lists.freedesktop.org/archives/dri-devel/2019-June/223516.html

[2] https://lore.kernel.org/dri-devel/20190619183856.467-1-TheSven73@gmail.com/