Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10 |
|
#
47c07e46 |
| 02-Feb-2023 |
Maíra Canal <mcanal@igalia.com> |
drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_info
The array of BOs that are lookup at the start of exec doesn't need to be instantiated as drm_gem_dma_object, as it doesn't ben
drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_info
The array of BOs that are lookup at the start of exec doesn't need to be instantiated as drm_gem_dma_object, as it doesn't benefit from its attributes. So, simplify the code by replacing the array of drm_gem_dma_object for an array of drm_gem_object in the struct vc4_exec_info.
Suggested-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230202111943.111757-2-mcanal@igalia.com
show more ...
|
Revision tags: v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59 |
|
#
8c30eecc |
| 01-Aug-2022 |
Danilo Krummrich <dakr@redhat.com> |
drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}
The field paddr of struct drm_gem_dma_object holds a DMA address, which might actually be a physical address. However, depending on the
drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}
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 <sam@ravnborg.org> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-5-dakr@redhat.com
show more ...
|
#
4a83c26a |
| 01-Aug-2022 |
Danilo Krummrich <dakr@redhat.com> |
drm/gem: rename GEM CMA helpers to GEM DMA helpers
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 mor
drm/gem: rename GEM CMA helpers to GEM DMA helpers
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 <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> #drivers/gpu/drm/arm Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-4-dakr@redhat.com
show more ...
|
Revision tags: v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50 |
|
#
3026b5ca |
| 22-Jun-2022 |
Dan Carpenter <dan.carpenter@oracle.com> |
drm/vc4: fix error code in vc4_check_tex_size()
The vc4_check_tex_size() function is supposed to return false on error but this error path accidentally returns -ENODEV (which means true).
Fixes: 30
drm/vc4: fix error code in vc4_check_tex_size()
The vc4_check_tex_size() function is supposed to return false on error but this error path accidentally returns -ENODEV (which means true).
Fixes: 30f8c74ca9b7 ("drm/vc4: Warn if some v3d code is run on BCM2711") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/YrMKK89/viQiaiAg@kili
show more ...
|
Revision tags: v5.15.49, v5.15.48, v5.15.47 |
|
#
30f8c74c |
| 10-Jun-2022 |
Maxime Ripard <maxime@cerno.tech> |
drm/vc4: Warn if some v3d code is run on BCM2711
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
drm/vc4: Warn if some v3d code is run on BCM2711
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 <mwen@igalia.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220610115149.964394-15-maxime@cerno.tech
show more ...
|
Revision tags: v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16 |
|
#
0126b23c |
| 13-Mar-2018 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
drm/vc4_validate: Remove VLA usage
In preparation to enabling -Wvla, remove VLA. In this particular case use macro ARRAY_SIZE so the length of array _bo_ can be computed at preprocessing time.
The
drm/vc4_validate: Remove VLA usage
In preparation to enabling -Wvla, remove VLA. In this particular case use macro ARRAY_SIZE so the length of array _bo_ can be computed at preprocessing time.
The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug.
Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180313143151.GA27486@embeddedgus
show more ...
|
Revision tags: v4.15, v4.13.16, v4.14, v4.13.5, v4.13 |
|
#
fb95992a |
| 25-Jul-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Demote user-accessible DRM_ERROR paths to DRM_DEBUG.
Userspace shouldn't be able to spam dmesg by passing bad arguments. This has particularly become an issues since we started using a bad
drm/vc4: Demote user-accessible DRM_ERROR paths to DRM_DEBUG.
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 <eric@anholt.net> 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 <boris.brezillon@free-electrons.com>
show more ...
|
Revision tags: v4.12, v4.10.17 |
|
#
fdb888de |
| 14-May-2017 |
Colin Ian King <colin.king@canonical.com> |
drm/vc4: fix spelling mistake: "dimesions" -> "dimensions"
Trivial fix to spelling mistake in DRM_ERROR message and split over two lines to clean up a "line over 80 characters" checkpatch warning.
drm/vc4: fix spelling mistake: "dimesions" -> "dimensions"
Trivial fix to spelling mistake in DRM_ERROR message and split over two lines to clean up a "line over 80 characters" checkpatch warning.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170514170016.6802-1-colin.king@canonical.com
show more ...
|
Revision tags: v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7 |
|
#
553c942f |
| 27-Mar-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Allow using more than 256MB of CMA memory.
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
drm/vc4: Allow using more than 256MB of CMA memory.
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 <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170327231025.19391-1-eric@anholt.net Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
show more ...
|
Revision tags: v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2 |
|
#
f6c01530 |
| 27-Feb-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Extend and edit documentation for output from the RST
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
drm/vc4: Extend and edit documentation for output from the RST
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 <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170227201144.10970-4-eric@anholt.net
show more ...
|
#
72f793f1 |
| 27-Feb-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Convert existing documentation to actual kerneldoc.
I'm going to hook vc4 up to the sphinx build, so clean up its comments to not generate warnings when we do.
Signed-off-by: Eric Anholt <
drm/vc4: Convert existing documentation to actual kerneldoc.
I'm going to hook vc4 up to the sphinx build, so clean up its comments to not generate warnings when we do.
Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170227201144.10970-2-eric@anholt.net
show more ...
|
Revision tags: v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31 |
|
#
c778cc5d |
| 07-Nov-2016 |
Jonas Pfeil <pfeiljonas@gmx.de> |
drm/vc4: Add fragment shader threading support
FS threading brings performance improvements of 0-20% in glmark2.
The validation code checks for thread switch signals and ensures that the registers
drm/vc4: Add fragment shader threading support
FS threading brings performance improvements of 0-20% in glmark2.
The validation code checks for thread switch signals and ensures that the registers of the other thread are not touched, and that our clamps are not live across thread switches. It also checks that the threading and branching instructions do not interfere.
(Original patch by Jonas, changes by anholt for style cleanup, removing validation the kernel doesn't need to do, and adding the flag for userspace).
v2: Minor style fixes from checkpatch.
Signed-off-by: Jonas Pfeil <pfeiljonas@gmx.de> Signed-off-by: Eric Anholt <eric@anholt.net>
show more ...
|
#
7154d76f |
| 03-Nov-2016 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Add support for rendering with ETC1 textures.
The validation for it ends up being quite simple, but I hadn't got around to it before merging the driver. For backwards compatibility, we als
drm/vc4: Add support for rendering with ETC1 textures.
The validation for it ends up being quite simple, but I hadn't got around to it before merging the driver. For backwards compatibility, we also need to add a flag so that the userspace GL driver can easily tell if the kernel will allow ETC1 textures (on an old kernel, it will continue to convert to RGBA8)
Signed-off-by: Eric Anholt <eric@anholt.net>
show more ...
|
Revision tags: v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6 |
|
#
7edabee0 |
| 27-Sep-2016 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Fix races when the CS reads from render targets.
With the introduction of bin/render pipelining, the previous job may not be completed when we start binning the next one. If the previous j
drm/vc4: Fix races when the CS reads from render targets.
With the introduction of bin/render pipelining, the previous job may not be completed when we start binning the next one. If the previous job wrote our VBO, IB, or CS textures, then the binning stage might get stale or uninitialized results.
Fixes the major rendering failure in glmark2 -b terrain.
Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Cc: stable@vger.kernel.org
show more ...
|
Revision tags: v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4 |
|
#
6d45c81d |
| 02-Jul-2016 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Add support for branching in shader validation.
We're already checking that branch instructions are between the start of the shader and the proper PROG_END sequence. The other thing we nee
drm/vc4: Add support for branching in shader validation.
We're already checking that branch instructions are between the start of the shader and the proper PROG_END sequence. The other thing we need to make branching safe is to verify that the shader doesn't read past the end of the uniforms stream.
To do that, we require that at any basic block reading uniforms have the following instructions:
load_imm temp, <next offset within uniform stream> add unif_addr, temp, unif
The instructions are generated by userspace, and the kernel verifies that the load_imm is of the expected offset, and that the add adds it to a uniform. We track which uniform in the stream that is, and at draw call time fix up the uniform stream to have the address of the start of the shader's uniforms at that location.
Signed-off-by: Eric Anholt <eric@anholt.net>
show more ...
|
Revision tags: v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1 |
|
#
2c68f1fc |
| 25-Jan-2016 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Return an ERR_PTR from BO creation instead of NULL.
Fixes igt vc4_create_bo/create-bo-0 by returning -EINVAL from the ioctl instead of -ENOMEM.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
Revision tags: openbmc-20160120-1 |
|
#
c671e1e3 |
| 17-Jan-2016 |
Dave Airlie <airlied@redhat.com> |
drm/vc4: fix warning in validate printf.
This just fixes a warning on 64-bit builds:
drivers/gpu/drm/vc4/vc4_validate.c: In function ‘validate_gl_shader_rec’: drivers/gpu/drm/vc4/vc4_validate.c
drm/vc4: fix warning in validate printf.
This just fixes a warning on 64-bit builds:
drivers/gpu/drm/vc4/vc4_validate.c: In function ‘validate_gl_shader_rec’: drivers/gpu/drm/vc4/vc4_validate.c:864:12: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1 |
|
#
d5b1a78a |
| 30-Nov-2015 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Add support for drawing 3D frames.
The user submission is basically a pointer to a command list and a pointer to uniforms. We copy those in to the kernel, validate and relocate them, and s
drm/vc4: Add support for drawing 3D frames.
The user submission is basically a pointer to a command list and a pointer to uniforms. We copy those in to the kernel, validate and relocate them, and store the result in a GPU BO which we queue for execution.
v2: Drop support for NV shader recs (not necessary for GL), simplify vc4_use_bo(), improve bin flush/semaphore checks, use __u32 style types.
Signed-off-by: Eric Anholt <eric@anholt.net>
show more ...
|
Revision tags: v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16 |
|
#
0126b23c |
| 13-Mar-2018 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
drm/vc4_validate: Remove VLA usage In preparation to enabling -Wvla, remove VLA. In this particular case use macro ARRAY_SIZE so the length of array _bo_ can be computed at preproces
drm/vc4_validate: Remove VLA usage In preparation to enabling -Wvla, remove VLA. In this particular case use macro ARRAY_SIZE so the length of array _bo_ can be computed at preprocessing time. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180313143151.GA27486@embeddedgus
show more ...
|
Revision tags: v4.15, v4.13.16, v4.14, v4.13.5, v4.13 |
|
#
fb95992a |
| 25-Jul-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Demote user-accessible DRM_ERROR paths to DRM_DEBUG. Userspace shouldn't be able to spam dmesg by passing bad arguments. This has particularly become an issues since we started
drm/vc4: Demote user-accessible DRM_ERROR paths to DRM_DEBUG. 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 <eric@anholt.net> 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 <boris.brezillon@free-electrons.com>
show more ...
|
Revision tags: v4.12, v4.10.17 |
|
#
fdb888de |
| 14-May-2017 |
Colin Ian King <colin.king@canonical.com> |
drm/vc4: fix spelling mistake: "dimesions" -> "dimensions" Trivial fix to spelling mistake in DRM_ERROR message and split over two lines to clean up a "line over 80 characters" checkpatc
drm/vc4: fix spelling mistake: "dimesions" -> "dimensions" Trivial fix to spelling mistake in DRM_ERROR message and split over two lines to clean up a "line over 80 characters" checkpatch warning. Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170514170016.6802-1-colin.king@canonical.com
show more ...
|
Revision tags: v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7 |
|
#
553c942f |
| 27-Mar-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Allow using more than 256MB of CMA memory. 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
drm/vc4: Allow using more than 256MB of CMA memory. 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 <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170327231025.19391-1-eric@anholt.net Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
show more ...
|
Revision tags: v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2 |
|
#
f6c01530 |
| 27-Feb-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Extend and edit documentation for output from the RST 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
drm/vc4: Extend and edit documentation for output from the RST 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 <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170227201144.10970-4-eric@anholt.net
show more ...
|
#
72f793f1 |
| 27-Feb-2017 |
Eric Anholt <eric@anholt.net> |
drm/vc4: Convert existing documentation to actual kerneldoc. I'm going to hook vc4 up to the sphinx build, so clean up its comments to not generate warnings when we do. Signed-o
drm/vc4: Convert existing documentation to actual kerneldoc. I'm going to hook vc4 up to the sphinx build, so clean up its comments to not generate warnings when we do. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170227201144.10970-2-eric@anholt.net
show more ...
|
Revision tags: v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31 |
|
#
c778cc5d |
| 07-Nov-2016 |
Jonas Pfeil <pfeiljonas@gmx.de> |
drm/vc4: Add fragment shader threading support FS threading brings performance improvements of 0-20% in glmark2. The validation code checks for thread switch signals and ensures tha
drm/vc4: Add fragment shader threading support FS threading brings performance improvements of 0-20% in glmark2. The validation code checks for thread switch signals and ensures that the registers of the other thread are not touched, and that our clamps are not live across thread switches. It also checks that the threading and branching instructions do not interfere. (Original patch by Jonas, changes by anholt for style cleanup, removing validation the kernel doesn't need to do, and adding the flag for userspace). v2: Minor style fixes from checkpatch. Signed-off-by: Jonas Pfeil <pfeiljonas@gmx.de> Signed-off-by: Eric Anholt <eric@anholt.net>
show more ...
|