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 |
|
#
d306788b |
| 01-Feb-2023 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: allocate unique ID per drm_file
Allows to easily track if several fd are pointing to the same execution context due to being dup'ed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
drm/etnaviv: allocate unique ID per drm_file
Allows to easily track if several fd are pointing to the same execution context due to being dup'ed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
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 |
|
#
764be123 |
| 01-Dec-2022 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: convert user fence tracking to XArray
This simplifies the driver code a bit, as XArray already provides internal locking. IDRs are implemented using XArrays anyways, so this drops one l
drm/etnaviv: convert user fence tracking to XArray
This simplifies the driver code a bit, as XArray already provides internal locking. IDRs are implemented using XArrays anyways, so this drops one level of unneeded abstraction.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
show more ...
|
Revision tags: v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
45b64fd9 |
| 03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove unnecessary include statements
Remove include statements for <drm/drm_fb_helper.h> where it is not required (i.e., most of them). In a few places include other header files tha
drm/fb-helper: Remove unnecessary include statements
Remove include statements for <drm/drm_fb_helper.h> where it is not required (i.e., most of them). In a few places include other header files that are required by the source code.
v3: * fix amdgpu include statements * fix rockchip include statements
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-23-tzimmermann@suse.de
show more ...
|
Revision tags: 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, 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, v5.15.49, v5.15.48, v5.15.47, 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 |
|
#
7938f421 |
| 04-Feb-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
dma-buf-map: Rename to iosys-map
Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's
dma-buf-map: Rename to iosys-map
Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed via arch helpers.
The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory.
The conversion was mostly done with the following semantic patch:
@r1@ @@ - struct dma_buf_map + struct iosys_map
@r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr )
@@ @@ - #include <linux/dma-buf-map.h> + #include <linux/iosys-map.h>
Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map.
Since this is not specific to dma-buf anymore, move the documentation to the "Bus-Independent Device Accesses" section.
v2: - Squash patches
v3: - Fix wrong removal of dma-buf.h from MAINTAINERS - Move documentation from dma-buf.rst to device-io.rst
v4: - Change documentation title and level
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com
show more ...
|
Revision tags: 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 |
|
#
81fd23e2 |
| 24-Jun-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/etnaviv: Implement mmap as GEM object function
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks.
The respective etnaviv fu
drm/etnaviv: Implement mmap as GEM object function
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks.
The respective etnaviv functions are being removed. The file_operations structure fops is now being created by the helper macro DEFINE_DRM_GEM_FOPS().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|
Revision tags: 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 |
|
#
49a3f51d |
| 03-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM b
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks.
v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de
show more ...
|
#
1fc90559 |
| 03-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
The function etnaviv_gem_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimme
drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
The function etnaviv_gem_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-4-tzimmermann@suse.de
show more ...
|
Revision tags: 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 |
|
#
3136fed4 |
| 03-Sep-2020 |
Robin Murphy <robin.murphy@arm.com> |
drm/etnaviv: Drop local dma_parms
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices"), struct platform_device already provides a dma_parms structure, so we
drm/etnaviv: Drop local dma_parms
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices"), struct platform_device already provides a dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|
#
a7730627 |
| 23-Sep-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/etnaviv: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance ca
drm/etnaviv: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in etnaviv. The only exception is gem_prime_mmap, which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-4-tzimmermann@suse.de
show more ...
|
Revision tags: 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 |
|
#
b72af445 |
| 27-Feb-2020 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: request pages from DMA32 zone when needed
Some Vivante GPUs are found in systems that have interconnects restricted to 32 address bits, but may have system memory mapped above the 4GB m
drm/etnaviv: request pages from DMA32 zone when needed
Some Vivante GPUs are found in systems that have interconnects restricted to 32 address bits, but may have system memory mapped above the 4GB mark. As this region isn't accessible to the GPU via DMA any GPU memory allocated in the upper part needs to go through SWIOTLB bounce buffering. This kills performance if it happens too often, as well as overrunning the available bounce buffer space, as the GPU buffer may stay mapped for a long time.
Avoid bounce buffering by checking the addressing restrictions. If the GPU is unable to access memory above the 4GB mark, request our SHM buffers to be located in the DMA32 zone.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|
Revision tags: 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, v4.15, v4.13.16, v4.14 |
|
#
38c4a4cf |
| 06-Nov-2017 |
Arnd Bergmann <arnd@arndb.de> |
drm/etnaviv: avoid deprecated timespec
struct timespec is being removed from the kernel because it often leads to code that is not y2038-safe.
In the etnaviv driver, monotonic timestamps are used,
drm/etnaviv: avoid deprecated timespec
struct timespec is being removed from the kernel because it often leads to code that is not y2038-safe.
In the etnaviv driver, monotonic timestamps are used, which do not suffer from overflow, but the usage of timespec here gets in the way of removing the interface completely.
Pass down the user-supplied 64-bit value here rather than converting it to an intermediate timespec to avoid the conversion.
The conversion is transparent for all regular CLOCK_MONOTONIC values, but is a small change in behavior for excessively large values: the existing code would treat e.g. tv_sec=0x100000000 the same as tv_sec=0 and not block, while the new code it would block for up to 2^31 seconds. The new behavior is more logical here, but if it causes problems, the truncation can be put back.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
088880dd |
| 02-Aug-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: implement softpin
With softpin we allow the userspace to take control over the GPU virtual address space. The new capability is relected by a bump of the minor DRM version. There are a
drm/etnaviv: implement softpin
With softpin we allow the userspace to take control over the GPU virtual address space. The new capability is relected by a bump of the minor DRM version. There are a few restrictions for userspace to take into account:
1. The kernel reserves a bit of the address space to implement zero page faulting and mapping of the kernel internal ring buffer. Userspace can query the kernel for the first usable GPU VM address via ETNAVIV_PARAM_SOFTPIN_START_ADDR.
2. We only allow softpin on GPUs, which implement proper process separation via PPAS. If softpin is not available the softpin start address will be set to ~0.
3. Softpin is all or nothing. A submit using softpin must not use any address fixups via relocs.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
show more ...
|
#
17e4660a |
| 05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: implement per-process address spaces on MMUv2
This builds on top of the MMU contexts introduced earlier. Instead of having one context per GPU core, each GPU client receives its own con
drm/etnaviv: implement per-process address spaces on MMUv2
This builds on top of the MMU contexts introduced earlier. Instead of having one context per GPU core, each GPU client receives its own context.
On MMUv1 this still means a single shared pagetable set is used by all clients, but on MMUv2 there is now a distinct set of pagetables for each client. As the command fetch is also translated via the MMU on MMUv2 the kernel command ringbuffer is mapped into each of the client pagetables.
As the MMU context switch is a bit of a heavy operation, due to the needed cache and TLB flushing, this patch implements a lazy way of switching the MMU context. The kernel does not have its own MMU context, but reuses the last client context for all of its operations. This has some visible impact, as the GPU can now only be started once a client has submitted some work and we got the client MMU context assigned. Also the MMU context has a different lifetime than the general client context, as the GPU might still execute the kernel command buffer in the context of a client even after the client has completed all GPU work and has been terminated. Only when the GPU is runtime suspended or switches to another clients MMU context is the old context freed up.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
show more ...
|
#
27b67278 |
| 05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: rework MMU handling
This reworks the MMU handling to make it possible to have multiple MMU contexts. A context is basically one instance of GPU page tables. Currently we have one set of
drm/etnaviv: rework MMU handling
This reworks the MMU handling to make it possible to have multiple MMU contexts. A context is basically one instance of GPU page tables. Currently we have one set of page tables per GPU, which isn't all that clever, as it has the following two consequences:
1. All GPU clients (aka processes) are sharing the same pagetables, which means there is no isolation between clients, but only between GPU assigned memory spaces and the rest of the system. Better than nothing, but also not great.
2. Clients operating on the same set of buffers with different etnaviv GPU cores, e.g. a workload using both the 2D and 3D GPU, need to map the used buffers into the pagetable sets of each used GPU.
This patch reworks all the MMU handling to introduce the abstraction of the MMU context. A context can be shared across different GPU cores, as long as they have compatible MMU implementations, which is the case for all systems with Vivante GPUs seen in the wild.
As MMUv1 is not able to change pagetables on the fly, without a "stop the world" operation, which stops GPU, changes pagetables via CPU interaction, restarts GPU, the implementation introduces a shared context on MMUv1, which is returned whenever there is a request for a new context.
This patch assigns a MMU context to each GPU, so on MMUv2 systems there is still one set of pagetables per GPU, but due to the shared context MMUv1 systems see a change in behavior as now a single pagetable set is used across all GPU cores.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
show more ...
|
#
bffe5db8 |
| 05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: share a single cmdbuf suballoc region across all GPUs
There is no need for each GPU to have it's own cmdbuf suballocation region. Only allocate a single one for the the etnaviv virtual
drm/etnaviv: share a single cmdbuf suballoc region across all GPUs
There is no need for each GPU to have it's own cmdbuf suballocation region. Only allocate a single one for the the etnaviv virtual device and share it across all GPUs.
As the suballoc space is now potentially shared by more hardware jobs running in parallel, double its size to 512KB to avoid contention.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
show more ...
|
#
2e737e52 |
| 04-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: clean up includes
Drop unused includes, move more includes from the generic etnaviv_drv.h to the units where they are actually used, sort includes.
Signed-off-by: Lucas Stach <l.stach@
drm/etnaviv: clean up includes
Drop unused includes, move more includes from the generic etnaviv_drv.h to the units where they are actually used, sort includes.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Sam Ravnborg <sam@ravnborg.org>
show more ...
|
#
6eae41fe |
| 30-Jun-2019 |
Sam Ravnborg <sam@ravnborg.org> |
drm/etnaviv: drop use of drmP.h
Drop use of the deprecated drmP.h header file. Fix fallout in all .c files.
The etnaviv_drv.h header file was made self-contained, and missing includes was then adde
drm/etnaviv: drop use of drmP.h
Drop use of the deprecated drmP.h header file. Fix fallout in all .c files.
The etnaviv_drv.h header file was made self-contained, and missing includes was then added to the .c files that needed them. In a few cases the list of include files was sorted.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: etnaviv@lists.freedesktop.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|
#
1262cc88 |
| 25-Feb-2019 |
Russell King <rmk+kernel@armlinux.org.uk> |
drm: etnaviv: avoid DMA API warning when importing buffers
During boot, I get this kernel warning:
WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301 debug_dma_map_sg+0x284/0x3dc etnaviv etnaviv
drm: etnaviv: avoid DMA API warning when importing buffers
During boot, I get this kernel warning:
WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301 debug_dma_map_sg+0x284/0x3dc etnaviv etnaviv: DMA-API: mapping sg segment longer than device claims to support [len=3145728] [max=65536] Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_broute ebtable_nat ip6table_raw ip6table_nat nf_nat_ipv6 ip6table_mangle iptable_raw iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6 libcrc32c iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter caam_jr error snd_soc_imx_spdif imx_thermal snd_soc_imx_audmux nvmem_imx_ocotp snd_soc_sgtl5000 caam imx_sdma virt_dma coda rc_cec v4l2_mem2mem snd_soc_fsl_ssi snd_soc_fsl_spdif imx_vdoa imx_pcm_dma videobuf2_dma_contig etnaviv dw_hdmi_cec gpu_sched dw_hdmi_ahb_audio imx6q_cpufreq nfsd sch_fq_codel ip_tables x_tables CPU: 0 PID: 19001 Comm: Xorg Not tainted 4.20.0+ #307 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [<c0019658>] (unwind_backtrace) from [<c001489c>] (show_stack+0x10/0x14) [<c001489c>] (show_stack) from [<c07fb420>] (dump_stack+0x9c/0xd4) [<c07fb420>] (dump_stack) from [<c00312dc>] (__warn+0xf8/0x124) [<c00312dc>] (__warn) from [<c00313d0>] (warn_slowpath_fmt+0x38/0x48) [<c00313d0>] (warn_slowpath_fmt) from [<c00b14e8>] (debug_dma_map_sg+0x284/0x3dc) [<c00b14e8>] (debug_dma_map_sg) from [<c046eb40>] (drm_gem_map_dma_buf+0xc4/0x13c) [<c046eb40>] (drm_gem_map_dma_buf) from [<c04c3314>] (dma_buf_map_attachment+0x38/0x5c) [<c04c3314>] (dma_buf_map_attachment) from [<c046e728>] (drm_gem_prime_import_dev+0x74/0x104) [<c046e728>] (drm_gem_prime_import_dev) from [<c046e5bc>] (drm_gem_prime_fd_to_handle+0x84/0x17c) [<c046e5bc>] (drm_gem_prime_fd_to_handle) from [<c046edd0>] (drm_prime_fd_to_handle_ioctl+0x38/0x4c) [<c046edd0>] (drm_prime_fd_to_handle_ioctl) from [<c0460efc>] (drm_ioctl_kernel+0x90/0xc8) [<c0460efc>] (drm_ioctl_kernel) from [<c0461114>] (drm_ioctl+0x1e0/0x3b0) [<c0461114>] (drm_ioctl) from [<c01cae20>] (do_vfs_ioctl+0x90/0xa48) [<c01cae20>] (do_vfs_ioctl) from [<c01cb80c>] (ksys_ioctl+0x34/0x60) [<c01cb80c>] (ksys_ioctl) from [<c0009000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xd81a9fa8 to 0xd81a9ff0) 9fa0: b6c69c88 bec613f8 00000009 c00c642e bec613f8 b86c4600 9fc0: b6c69c88 bec613f8 c00c642e 00000036 012762e0 01276348 00000300 012d91f8 9fe0: b6989f18 bec613dc b697185c b667be5c irq event stamp: 47905 hardirqs last enabled at (47913): [<c0098824>] console_unlock+0x46c/0x680 hardirqs last disabled at (47922): [<c0098470>] console_unlock+0xb8/0x680 softirqs last enabled at (47754): [<c000a484>] __do_softirq+0x344/0x540 softirqs last disabled at (47701): [<c0038700>] irq_exit+0x124/0x144 ---[ end trace af477747acbcc642 ]---
The reason is the contiguous buffer exceeds the default maximum segment size of 64K as specified by dma_get_max_seg_size() in linux/dma-mapping.h. Fix this by providing our own segment size, which is set to 2GiB to cover the window found in MMUv1 GPUs.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|
#
fa238ea1 |
| 02-Feb-2019 |
Rob Herring <robh@kernel.org> |
drm: etnaviv: Switch to use drm_gem_object reservation_object
Now that the base struct drm_gem_object has a reservation_object, use it and remove the private BO one.
Cc: Lucas Stach <l.stach@pengut
drm: etnaviv: Switch to use drm_gem_object reservation_object
Now that the base struct drm_gem_object has a reservation_object, use it and remove the private BO one.
Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: etnaviv@lists.freedesktop.org Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190202154158.10443-3-robh@kernel.org Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
show more ...
|
#
fcd70cd3 |
| 17-Jan-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Split out drm_probe_helper.h
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out
drm: Split out drm_probe_helper.h
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out.
To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes.
v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1.
v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over.
This will also conflict with ongoing drmP.h cleanup by others I expect.
v3: Rebase on top of atomic bochs.
v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically
v5: Actually try to sort them, and while at it, sort all the ones I touch.
v6: Rebase onto i915 changes.
v7: Rebase once more.
Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: CK Hu <ck.hu@mediatek.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etnaviv@lists.freedesktop.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-tegra@vger.kernel.org Cc: xen-devel@lists.xen.org Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
show more ...
|
#
3283ee77 |
| 05-Nov-2018 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
This is the only place in the driver that should have to deal with the raw hardware fences. To avoid any further confusion, consolidat
drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
This is the only place in the driver that should have to deal with the raw hardware fences. To avoid any further confusion, consolidate the fence handling in this file and remove any traces of this from the header files.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
show more ...
|
#
cfad05a2 |
| 29-May-2018 |
Souptick Joarder <jrdr.linux@gmail.com> |
drm/etnaviv: change return type to vm_fault_t
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Onc
drm/etnaviv: change return type to vm_fault_t
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type.
Ref- commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_page() returns err which driver mapped into VM_FAULT_* type. The new function vmf_insert_page() will replace this inefficiency by returning VM_FAULT_* type.
vmf_error() is the newly introduce inline function in 4.17-rc6.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|
#
f6ffbd4f |
| 08-May-2018 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: replace license text with SPDX tags
This replaces the repetitive GPL-2.0 license text in code and header files with the SPDX tags. Generated hardware headers aren't changed, as any chan
drm/etnaviv: replace license text with SPDX tags
This replaces the repetitive GPL-2.0 license text in code and header files with the SPDX tags. Generated hardware headers aren't changed, as any changes there need to be done in the upstream rnndb repository.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
show more ...
|
#
a98b1e78 |
| 19-Apr-2018 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: remove register logging
I'm not aware of any case where tracing GPU register manipulation at the kernel level would have been useful. It only adds more indirections and adds to the code
drm/etnaviv: remove register logging
I'm not aware of any case where tracing GPU register manipulation at the kernel level would have been useful. It only adds more indirections and adds to the code size.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
show more ...
|
#
d066b246 |
| 20-Feb-2018 |
Russell King <rmk+kernel@armlinux.org.uk> |
drm/etnaviv: correct timeout calculation
The old way did clamp the jiffy conversion and thus caused the timeouts to become negative after some time. Also it didn't work with userspace which actually
drm/etnaviv: correct timeout calculation
The old way did clamp the jiffy conversion and thus caused the timeouts to become negative after some time. Also it didn't work with userspace which actually fills the upper 32bits of the 64bit timestamp value.
clock_gettime() is 32-bit on 32-bit architectures. Using 64-bit timespec math, like we do in this commit, means that when a wrap occurs, the specified timeout goes into the past and we can't request a timeout in the future. As the Linux implementation of CLOCK_MONOTONIC is reasonable and starts at 0, the first such timer wrap will occur after approx. 68 years of system uptime.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
show more ...
|