linux-toradex.git/drivers/gpu/drm/vc4/vc4_render_cl.c, branch v6.10-rc2

drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}

2022-08-03T16:32:27+00:00

The field paddr of struct drm_gem_dma_object holds a DMA address, which
might actually be a physical address. However, depending on the platform,
it can also be a bus address or a virtual address managed by an IOMMU.

Hence, rename the field to dma_addr, which is more applicable.

In order to do this renaming the following coccinelle script was used:

```
	@@
	struct drm_gem_dma_object *gem;
	@@

	- gem->paddr
	+ gem->dma_addr

	@@
	struct drm_gem_dma_object gem;
	@@

	- gem.paddr
	+ gem.dma_addr

	@exists@
	typedef dma_addr_t;
	symbol paddr;
	@@

	dma_addr_t paddr;
	<...
	- paddr
	+ dma_addr
	...>

	@@
	symbol paddr;
	@@
	dma_addr_t
	- paddr
	+ dma_addr
	;

```

This patch is compile-time tested with:

```
	make ARCH={x86_64,arm,arm64} allyesconfig
	make ARCH={x86_64,arm,arm64} drivers/gpu/drm`
```

Acked-by: Sam Ravnborg 
Suggested-by: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-5-dakr@redhat.com

drm/gem: rename GEM CMA helpers to GEM DMA helpers

2022-08-03T16:31:49+00:00

Rename "GEM CMA" helpers to "GEM DMA" helpers - considering the
hierarchy of APIs (mm/cma -> dma -> gem dma) calling them "GEM
DMA" seems to be more applicable.

Besides that, commit e57924d4ae80 ("drm/doc: Task to rename CMA helpers")
requests to rename the CMA helpers and implies that people seem to be
confused about the naming.

In order to do this renaming the following script was used:

```
	#!/bin/bash

	DIRS="drivers/gpu include/drm Documentation/gpu"

	REGEX_SYM_UPPER="[0-9A-Z_\-]"
	REGEX_SYM_LOWER="[0-9a-z_\-]"

	REGEX_GREP_UPPER="(${REGEX_SYM_UPPER}*)(GEM)_CMA_(${REGEX_SYM_UPPER}*)"
	REGEX_GREP_LOWER="(${REGEX_SYM_LOWER}*)(gem)_cma_(${REGEX_SYM_LOWER}*)"

	REGEX_SED_UPPER="s/${REGEX_GREP_UPPER}/\1\2_DMA_\3/g"
	REGEX_SED_LOWER="s/${REGEX_GREP_LOWER}/\1\2_dma_\3/g"

	# Find all upper case 'CMA' symbols and replace them with 'DMA'.
	for ff in $(grep -REHl "${REGEX_GREP_UPPER}" $DIRS)
	do
	       sed -i -E "$REGEX_SED_UPPER" $ff
	done

	# Find all lower case 'cma' symbols and replace them with 'dma'.
	for ff in $(grep -REHl "${REGEX_GREP_LOWER}" $DIRS)
	do
	       sed -i -E "$REGEX_SED_LOWER" $ff
	done

	# Replace all occurrences of 'CMA' / 'cma' in comments and
	# documentation files with 'DMA' / 'dma'.
	for ff in $(grep -RiHl " cma " $DIRS)
	do
		sed -i -E "s/ cma / dma /g" $ff
		sed -i -E "s/ CMA / DMA /g" $ff
	done

	# Rename all 'cma_obj's to 'dma_obj'.
	for ff in $(grep -RiHl "cma_obj" $DIRS)
	do
		sed -i -E "s/cma_obj/dma_obj/g" $ff
	done
```

Only a few more manual modifications were needed, e.g. reverting the
following modifications in some DRM Kconfig files

    -       select CMA if HAVE_DMA_CONTIGUOUS
    +       select DMA if HAVE_DMA_CONTIGUOUS

as well as manually picking the occurrences of 'CMA'/'cma' in comments and
documentation which relate to "GEM CMA", but not "FB CMA".

Also drivers/gpu/drm/Makefile was fixed up manually after renaming
drm_gem_cma_helper.c to drm_gem_dma_helper.c.

This patch is compile-time tested building a x86_64 kernel with
`make allyesconfig && make drivers/gpu/drm`.

Acked-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Danilo Krummrich 
Reviewed-by: Liviu Dudau  #drivers/gpu/drm/arm
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-4-dakr@redhat.com

drm/vc4: Warn if some v3d code is run on BCM2711

2022-06-16T09:07:52+00:00

The BCM2711 has a separate driver for the v3d, and thus we can't call
into any of the driver entrypoints that rely on the v3d being there.

Let's add a bunch of checks and complain loudly if that ever happen.

Reviewed-by: Melissa Wen 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20220610115149.964394-15-maxime@cerno.tech

drm/vc4: Make sure to emit a tile coordinates between two MSAA loads.

2019-04-01T16:33:38+00:00

The HW only executes a load once the tile coordinates packet happens,
and only tracks one at a time, so by emitting our two MSAA loads back
to back we would end up with an undefined color or Z buffer.

Fixes dEQP-EGL.functional.render.multi_context.gles2.rgb888_window

Signed-off-by: Eric Anholt 
Reviewed-by: Paul Kocialkowski 
Cc: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20190206232550.12012-1-eric@anholt.net

drm/vc4: Add exec flags to allow forcing a specific X/Y tile walk order.

2017-08-08T20:26:44+00:00

This is useful to allow GL to provide defined results for overlapping
glBlitFramebuffer, which X11 in turn uses to accelerate uncomposited
window movement without first blitting to a temporary.  x11perf
-copywinwin100 goes from 1850/sec to 4850/sec.

v2: Default to the same behavior as before when the flags aren't
    passed. (suggested by Boris)

Signed-off-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20170725162733.28007-2-eric@anholt.net
Reviewed-by: Boris Brezillon

drm/vc4: Demote user-accessible DRM_ERROR paths to DRM_DEBUG.

2017-08-08T20:20:11+00:00

Userspace shouldn't be able to spam dmesg by passing bad arguments.
This has particularly become an issues since we started using a bad
argument to set_tiling to detect if set_tiling was supported.

Signed-off-by: Eric Anholt 
Fixes: 83753117f1de ("drm/vc4: Add get/set tiling ioctls.")
Link: https://patchwork.freedesktop.org/patch/msgid/20170725162733.28007-1-eric@anholt.net
Reviewed-by: Boris Brezillon

drm/vc4: Add an ioctl for labeling GEM BOs for summary stats

2017-07-28T23:04:53+00:00

This has proven immensely useful for debugging memory leaks and
overallocation (which is a rather serious concern on the platform,
given that we typically run at about 256MB of CMA out of up to 1GB
total memory, with framebuffers that are about 8MB ecah).

The state of the art without this is to dump debug logs from every GL
application, guess as to kernel allocations based on bo_stats, and try
to merge that all together into a global picture of memory allocation
state.  With this, you can add a couple of calls to the debug build of
the 3D driver and get a pretty detailed view of GPU memory usage from
/debug/dri/0/bo_stats (or when we debug print to dmesg on allocation
failure).

The Mesa side currently labels at the gallium resource level (so you
see that a 1920x20 pixmap has been created, presumably for the window
system panel), but we could extend that to be even more useful with
glObjectLabel() names being sent all the way down to the kernel.

(partial) example of sorted debugfs output with Mesa labeling all
resources:

               kernel BO cache:  16392kb BOs (3)
       tiling shadow 1920x1080:   8160kb BOs (1)
       resource 1920x1080@32/0:   8160kb BOs (1)
scanout resource 1920x1080@32/0:   8100kb BOs (1)
                        kernel:   8100kb BOs (1)

v2: Use strndup_user(), use lockdep assertion instead of just a
    comment, fix an array[-1] reference, extend comment about name
    freeing.

Signed-off-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20170725182718.31468-2-eric@anholt.net
Reviewed-by: Chris Wilson

drm/vc4: Allow using more than 256MB of CMA memory.

2017-04-18T21:32:20+00:00

Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to
keep from triggering the hardware addressing bug between the tile
binner and the tile alloc memory (where the top 4 bits come from the
tile state data array's address).

To work around that and allow more memory to be reserved for graphics,
allocate a single BO to store tile state data arrays and tile
alloc/overflow memory while the GPU is active, and make sure that that
one BO doesn't happen to cross a 256MB boundary.  With that in place,
we can allocate textures and shaders anywhere in system memory (still
contiguous, of course).

Signed-off-by: Eric Anholt 
Link: http://patchwork.freedesktop.org/patch/msgid/20170327231025.19391-1-eric@anholt.net
Reviewed-by: Boris Brezillon

drm/vc4: Extend and edit documentation for output from the RST

2017-02-28T20:51:49+00:00

I had written most of my comments as if I was describing the
individual code files the way I used to for doxygen, while for RST we
want to describe things in a more chapter/section way where there's no
obvious relation to .c files.

Additionally, several of the files had stub descriptions that I've
taken this opportunity to extend.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170227201144.10970-4-eric@anholt.net

drm/vc4: fix a bounds check

2017-01-17T10:12:59+00:00

We accidentally return success even if vc4_full_res_bounds_check() fails.

Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Dan Carpenter 
Reviewed-by: Eric Engestrom 
Reviewed-by: Eric Anholt