- 17 Oct, 2022 20 commits
-
-
Dmitry Osipenko authored
All drivers that use dma-bufs have been moved to the updated locking specification and now dma-buf reservation is guaranteed to be locked by importers during the mapping operations. There is no need to take the internal dma-buf lock anymore. Remove locking from the videobuf2 memory allocators. Acked-by:
Tomasz Figa <tfiga@chromium.org> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221017172229.42269-21-dmitry.osipenko@collabora.com
-
Dmitry Osipenko authored
Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by:
-
Dmitry Osipenko authored
Move dma_buf_mmap() function to the dynamic locking specification by taking the reservation lock. Neither of the today's drivers take the reservation lock within the mmap() callback, hence it's safe to enforce the locking. Acked-by:
-
Dmitry Osipenko authored
Move dma-buf attachment mapping functions to the dynamic locking specification by asserting that the reservation lock is held. Acked-by:
-
Dmitry Osipenko authored
Move dma-buf attachment API functions to the dynamic locking specification by taking the reservation lock around the mapping operations. The strict locking convention prevents deadlock situations for dma-buf importers and exporters. Acked-by:
-
Dmitry Osipenko authored
Move dma_buf_vmap/vunmap() functions to the dynamic locking specification by asserting that the reservation lock is held. Acked-by:
-
Dmitry Osipenko authored
Prepare Tegra video decoder driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
-
Dmitry Osipenko authored
Prepare V4L2 memory allocators to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
-
Dmitry Osipenko authored
Prepare gntdev driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
Juergen Gross <jgross@suse.com> Acked-by:
-
Dmitry Osipenko authored
Prepare fastrpc to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Dmitry Osipenko authored
Prepare InfiniBand drivers to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
Jason Gunthorpe <jgg@nvidia.com> Acked-by:
-
Dmitry Osipenko authored
Prepare Etnaviv driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
-
Dmitry Osipenko authored
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
-
Dmitry Osipenko authored
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
-
Dmitry Osipenko authored
Prepare i915 driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions and handling cases where importer now holds the reservation lock. Acked-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
-
Dmitry Osipenko authored
Prepare Armada driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by:
-
Dmitry Osipenko authored
Prepare DRM prime core to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Reviewed-by:
-
Dmitry Osipenko authored
The new common dma-buf locking convention will require buffer importers to hold the reservation lock around mapping operations. Make DRM GEM core to take the lock around the vmapping operations and update DRM drivers to use the locked functions for the case where DRM core now holds the lock. This patch prepares DRM core and drivers to the common dynamic dma-buf locking convention. Acked-by:
-
Dmitry Osipenko authored
Add unlocked variant of dma_buf_map/unmap_attachment() that will be used by drivers that don't take the reservation lock explicitly. Acked-by:
-
Dmitry Osipenko authored
Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized by drivers that don't take the reservation lock explicitly. Acked-by:
-
- 16 Oct, 2022 11 commits
-
-
Zeng Heng authored
Remove unnecessary `drm_mm_clean` calling in `ttm_range_man_fini_nocheck`, due to effective check is already included in the following `drm_mm_takedown`. Signed-off-by:
Zeng Heng <zengheng4@huawei.com> Reviewed-by:
-
Maíra Canal authored
The drm_test_dp_mst_sideband_msg_req_decode repeats the same test structure with different parameters. This could be better represented by parameterized tests, provided by KUnit. In addition to the parameterization of the tests, the test case for the client ID was changed: instead of using get_random_bytes to generate the client ID, the client ID is now hardcoded in the test case. This doesn't affect the assertively of the tests, as this test case only compare the data going in with the data going out and it doesn't transform the data itself in any way. So, convert drm_test_dp_mst_sideband_msg_req_decode into parameterized tests and make the tests' allocations and prints completely managed by KUnit. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20221001223422.857505-2-mcanal@igalia.com
-
Maíra Canal authored
The drm_test_dp_mst_calc_pbn_mode is based on a loop that executes tests for a couple of test cases. This could be better represented by parameterized tests, provided by KUnit. So, convert the drm_test_dp_mst_calc_pbn_mode into parameterized tests. Signed-off-by:
-
Thomas Zimmermann authored
Some AST-based BMCs stop display output for up to 5 seconds after reprogramming the scanout address. As the address is fixed, avoid re-setting the address' value. v2: * only update offset if it changed (Jocelyn) Reported-by:
Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
Replace GEM VRAM helpers with GEM SHMEM helpers in ast. Avoids OOM errors when allocating video memory. Also adds support for dma-buf functionality. Aspeed display hardware supports display resolutions of FullHD and higher at 32-bit pixel depth. But the amount of video memory is in the range of 8 MiB to 32 MiB, which adds constraints to the actually available resolutions. As atomic modesetting with VRAM helpers requires double buffering in video memory, ast fails to pageflip in some configurations. For example, FullHD with an active cursor plane does not work on devices with 16 MiB of video memory. Resolve this problem by converting the ast driver to GEM SHMEM helpers. Keep the buffer objects in system memory and copy to video memory on pageflips via shadow-plane helpers. Userspace used to require shadow planes for decent performance, but that's now provided by the driver. To replace the memory management, the patch also implements damage handling for the primary plane. With GEM SHMEM helpers, dma-buf import and export is now supported by ast. This allows easier screen mirroring across devices or with an Aspeed-based BMC. A corresponding feature request is available at [1]. v2: * fix typos in commit message (Jocelyn) Signed-off-by:
-
Thomas Zimmermann authored
Rename some of the variables in the plane code to better reflect the old and new state during checks and updates. Change some indention as well. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Rename the plane structure struct ast_cursor_plane to struct ast_plane as it will be used for the primary plane as well. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Update the cursor image via damage handling in-place. The cursor's double buffering has no visible effect on the output, so remove it. Done in preparation of switching ast to GEM SHMEM helpers. Removing double buffering will allow us to use the same data structure for primary and cursor plane. Signed-off-by:
-
Thomas Zimmermann authored
There's no need to add planes to the atomic state. Remove the call to drm_atomic_add_affected_planes() from ast. On full modesets, the DRM helpers already add a CRTC's planes to the atomic state; see drm_atomic_helper_check_modeset(). There's no reason to call drm_atomic_add_affected_planes() unconditionally in the CRTC's atomic_check() in ast. It's also too late, as the atomic_check() of the added planes will not be called before the commit. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Thomas Zimmermann authored
Always call drm_atomic_helper_check_plane_state() in each plane's atomic_check function. At the minimum, it needs to set or clear the plane state's 'visible' field. Otherwise the plane-state handling is bogus and would keep updating planes that have been disabled. While at it, also warn if the primary plane has been enabled, but is not visible. This cannot legally happen as the plane always covers the entire screen. Signed-off-by:
-
Thomas Zimmermann authored
Hold I/O-register lock in atomic_commit_tail to protect all pipeline updates at once. Protects modesetting against concurrent EDID reads. Complex modesetting operations involve mode changes and plane updates. These steps used to be protected individually against concurrent I/O. Make all this atomic wrt to reading display modes via EDID. The EDID code in the connector's get_modes helper already acquires the necessary lock. A similar issue was fixed in commit 2d70b9a1 ("drm/mgag200: Acquire I/O-register lock in atomic_commit_tail function") for mgag200. v2: * fix typo in commit message (Jocelyn) Signed-off-by:
-
- 15 Oct, 2022 4 commits
-
-
Kieran Bingham authored
The LCDIF includes a color space converter that supports YUV input. Use it to support YUV planes, either through the converter if the output format is RGB, or in conversion bypass mode otherwise. Signed-off-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
-
Laurent Pinchart authored
Up to and including v1.3, HDMI supported limited quantization range only for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this feature isn't supported in the dw-hdmi driver that is used in conjunction with the LCDIF in the i.MX8MP. The HDMI YCbCr output is thus always advertised in the AVI infoframe as limited range. The LCDIF driver, on the other hand, configures the CSC to produce full range YCbCr. This mismatch results in loss of details and incorrect colours. Fix it by switching to limited range YCbCr. The coefficients are copied from drivers/media/platforms/nxp/imx-pxp.c for coherency, as the hardware is most likely identical. Fixes: 9db35bb3 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by:
-
Laurent Pinchart authored
The BIT() macro is meant to represent a single bit. Don't use it for values of register fields that span multiple bits. Signed-off-by:
-
Laurent Pinchart authored
A couple of the register macro values are incorrectly indented. Fix them. Signed-off-by:
-
- 14 Oct, 2022 5 commits
-
-
Thomas Zimmermann authored
All DRM formats assume little-endian byte order. On big-endian systems, it is likely that the scanout buffer is in big endian as well. Update the format accordingly and add endianness conversion to the format-helper library. Also opt-in to allocated buffers in host format by default. Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Thomas Zimmermann authored
Support the CRTC's color-management property and implement each model's palette support. The OF hardware has different methods of setting the palette. The respective code has been taken from fbdev's offb and refactored into per-model device functions. The device functions integrate this functionality into the overall modesetting. As palette handling is a CRTC property that depends on the primary plane's color format, the plane's atomic_check helper now updates the format field in ofdrm's custom CRTC state. The CRTC's atomic_flush helper updates the palette for the format as needed. v4: * use cpu_to_be32() (Geert) v3: * lookup CRTC state with drm_atomic_get_new_crtc_state() * access HW palette with writeb(), writel(), and readl() (Ben) * declare register values as u32 Signed-off-by:
-
Thomas Zimmermann authored
Add a per-model device-function structure in preparation of adding color-management support. Detection of the individual models has been taken from fbdev's offb. v3: * define constants for PCI ids (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Add a dedicated CRTC state to ofdrm to later store information for palette updates. v3: * rework CRTC state helpers (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Open Firmware provides basic display output via the 'display' node. DT platform code already provides a device that represents the node's framebuffer. Add a DRM driver for the device. The display mode and color format is pre-initialized by the system's firmware. Runtime modesetting via DRM is not possible. The display is useful during early boot stages or as error fallback. Similar functionality is already provided by fbdev's offb driver, which is insufficient for modern userspace. The old driver includes support for BootX device tree, which can be found on old 32-bit PowerPC Macintosh systems. If these are still in use, the functionality can be added to ofdrm or implemented in a new driver. As with simpledrm, the fbdev driver cannot be selected if ofdrm is already enabled. Two notable points about the driver: * Reading the framebuffer aperture from the device tree is not reliable on all systems. Ofdrm takes the heuristics and a comment from offb to pick the correct range. * No resource management may be tied to the underlying PCI device. Otherwise the handover to the native driver will fail with a resource conflict. PCI management is therefore done as part of the platform device's cleanup. The driver has been tested on qemu's ppc64le emulation. The device hand-over has been tested with bochs. v5: * use drm_atomic_helper_check_crtc_primary_plane() v4: * set preferred depth to the correct value * set bpp value for console emulation * output scanout-buffer parameters with drm_dbg() v3: * reintegrate FWFB helpers into ofdrm * use damage iterator * sync GEM BOs with drm_gem_fb_{begin,end}_cpu_access() * fix various atomic_check helpers * remove CRTC atomic_{enable,disable} (Javier) * compute stride with drm_format_info_min_pitch() (Daniel) v2: * removed simple-pipe helpers * built driver on top of FWFB helpers * merged all init code into single function * make PCI support optional (Michal) * support COMPILE_TEST (Javier) Signed-off-by:
-
