Shixiong Ou [Thu, 22 May 2025 07:07:14 +0000 (15:07 +0800)]
drm/udl: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT
Import dmabuf without mapping its sg_table to avoid issues likes:
udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536 (slots), used 1 (slots)
Shixiong Ou [Thu, 22 May 2025 07:07:13 +0000 (15:07 +0800)]
drm/ast: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT
Import dmabuf without mapping its sg_table to avoid issues likes:
ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots)
Shixiong Ou [Thu, 22 May 2025 07:07:12 +0000 (15:07 +0800)]
drm/shmem-helper: Import dmabuf without mapping its sg_table
[WHY]
1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and
DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require
sg_table import.
They only need dma_buf_vmap() to access the shared buffer's
kernel virtual address.
2. On certain Aspeed-based boards, a dma_mask of 0xffff_ffff may
trigger SWIOTLB during dmabuf import. However, IO_TLB_SEGSIZE
restricts the maximum DMA streaming mapping memory, resulting in
errors like:
ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots)
[HOW]
Provide a gem_prime_import implementation without sg_table mapping
to avoid issues (e.g., "swiotlb buffer is full"). Drivers that do not
require sg_table can adopt this.
Adrián Larumbe [Tue, 20 May 2025 17:44:01 +0000 (18:44 +0100)]
drm/panfrost: show device-wide list of DRM GEM objects over DebugFS
This change is essentially a Panfrost port of commit a3707f53eb3f
("drm/panthor: show device-wide list of DRM GEM objects over DebugFS").
The DebugFS file is almost the same as in Panthor, minus the GEM object
usage flags, since Panfrost has no kernel-only BO's.
Two additional GEM state flags which are displayed but aren't relevant
to Panthor are 'Purged' and 'Purgeable', since Panfrost implements an
explicit shrinker and a madvise ioctl to flag objects as reclaimable.
Adrián Larumbe [Tue, 20 May 2025 17:43:59 +0000 (18:43 +0100)]
drm/panfrost: Internally label some BOs
Perfcnt samples buffer is not exposed to UM, but we would like to keep
a tag on it as a potential debug aid.
PRIME imported GEM buffers are UM exposed, but since the usual Panfrost
UM driver code path is not followed in their creation, they might remain
unlabelled for their entire lifetime, so a generic tag was deemed
preferable. The tag is assigned before a UM handle is created so it
doesn't contradict the logic about labelling internal BOs.
Add new inference_timeout_ms parameter that allows specifying
maximum allowed duration in milliseconds that inference can take before
triggering a recovery.
Calculate maximum number of heartbeat retries based on ratio between
inference timeout and tdr timeout.
Philipp Stanner [Tue, 27 May 2025 10:10:30 +0000 (12:10 +0200)]
drm/sched/tests: Use one lock for fence context
There is no need for separate locks for single jobs and the entire
scheduler. The dma_fence context can be protected by the scheduler lock,
allowing for removing the jobs' locks. This simplifies things and
reduces the likelyhood of deadlocks etc.
Replace the jobs' locks with the mock scheduler lock.
drm/tests: hdmi: Rename max TMDS rate fallback tests
In preparation to extend the max TMDS rate fallback tests for covering
YUV420 output, update the rather generic function names
drm_test_check_max_tmds_rate_{bpc|format}_fallback() to properly
indicate the intended test cases.
drm/tests: hdmi: Add limited range tests for YUV420 mode
Provide tests to verify that drm_atomic_helper_connector_hdmi_check()
helper behaviour when using YUV420 output format is to always set the
limited RGB quantization range to 'limited', no matter what the value of
Broadcast RGB property is.
drm/tests: hdmi: Switch to drm_atomic_get_new_connector_state() where possible
Replace the calls to drm_atomic_get_connector_state() with
drm_atomic_get_new_connector_state() for cases which do not require
allocating the connector state, e.g. after drm_atomic_check_only() when
the intent is to only read the new connector state.
The rational is to avoid the need to handle the potential EDEADLK error
returned by the former helper, which would require restarting the entire
atomic sequence.
drm/tests: hdmi: Setup ycbcr_420_allowed before initializing connector
Initializing HDMI connector via drmm_connector_hdmi_init() requires its
->ycbcr_420_allowed flag to be adjusted according to the supported
formats passed as function argument, prior to the actual invocation.
In order to allow providing test coverage for YUV420 modes, ensure the
flag is properly setup.
Make use of the recently introduced macros to reduce boilerplate code
around EDID setup. This also helps dropping the redundant calls to
set_connector_edid().
Factor out the HDMI connector initialization from
drm_kunit_helper_connector_hdmi_init_funcs() into a common
__connector_hdmi_init() function, while extending its functionality to
allow setting custom (i.e. non-default) EDID data.
Introduce a macro as a wrapper over the new helper to allow dropping the
open coded EDID setup from all test cases.
The actual conversion will be handled separately; for now just apply it
to drm_kunit_helper_connector_hdmi_init() helper.
drm/tests: hdmi: Switch to 'void *' type for EDID data
Replace 'const char *' with 'const void *' type for current_edid member
in struct drm_atomic_helper_connector_hdmi_priv, as well as for the edid
parameter of set_connector_edid() function.
drm/connector: hdmi: Factor out bpc and format computation logic
In preparation to support fallback to an alternative output format, e.g.
YUV420, when RGB cannot be used for any of the available color depths,
move the bpc try loop out of hdmi_compute_config() and, instead, make it
part of hdmi_compute_format(), while adding a new parameter to the
latter holding the output format to be checked and eventually set.
Since this helper now also changes hdmi.output_bpc in addition to
hdmi.output_format, highlight the extended functionality by renaming it
to hdmi_compute_format_bpc().
This improves code reusability and further extensibility, without
introducing any functional changes.
drm/connector: hdmi: Evaluate limited range after computing format
Evaluating the requirement to use a limited RGB quantization range
involves a verification of the output format, among others, but this is
currently performed before actually computing the format, hence relying
on the old connector state.
Move the call to hdmi_is_limited_range() after hdmi_compute_config() to
ensure the verification is done on the updated output format.
Fixes: 027d43590649 ("drm/connector: hdmi: Add RGB Quantization Range to the connector state") Reviewed-by: Dmitry Baryshkov <lumag@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-1-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Jernej Skrabec [Wed, 28 May 2025 09:22:11 +0000 (21:22 +1200)]
drm: sun4i: de33: mixer: add Display Engine 3.3 (DE33) support
The DE33 is a newer version of the Allwinner Display Engine IP block,
found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
supported by the mainline driver.
Notable features (from the H616 datasheet and implemented):
- 4096 x 2048 (4K) output support
Other features (implemented but not in this patchset):
- AFBC ARM Frame Buffer Compression support
- YUV pipeline support
The DE2 and DE3 engines have a blender register range within the
mixer engine register map, whereas the DE33 separates this out into
a separate display group, and adds a top register map.
The DE33 also appears to remove the global double buffer control
register, present in the DE2 and DE3.
Extend the mixer to support the DE33.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250528092431.28825-7-ryan@testtoast.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
The Allwinner H616 and variants have a new display engine revision
(DE33).
The mixer configuration registers are significantly different to the DE3
and DE2 revisions, being split into separate top and display blocks,
therefore a fallback for the mixer compatible is not provided.
Note that the DE33 mixer requires 3 register blocks instead of 1. To
keep things simple the maxItems value for registers is conditionally
removed for the H616 and replaced with the block names from the vendor
BSP kernel.
Add a display engine mixer binding for the DE33.
Signed-off-by: Ryan Walklin <ryan@testtoast.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20250528092431.28825-6-ryan@testtoast.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Jernej Skrabec [Wed, 28 May 2025 09:22:08 +0000 (21:22 +1200)]
drm: sun4i: de2/de3: add generic blender register reference function
The DE2 and DE3 engines have a blender register range within the
mixer engine register map, whereas the DE33 separates this out into
a separate display group.
Prepare for this by adding a function to look the blender reference up,
with a subsequent patch to add a conditional based on the DE type.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Ryan Walklin <ryan@testtoast.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250528092431.28825-4-ryan@testtoast.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Jernej Skrabec [Wed, 28 May 2025 09:22:06 +0000 (21:22 +1200)]
drm: sun4i: de2/de3: add mixer version enum
The Allwinner DE2 and DE3 display engine mixers are currently identified
by a simple boolean flag. This will not scale to support additional DE
variants.
Convert the boolean flag to an enum.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Ryan Walklin <ryan@testtoast.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250528092431.28825-2-ryan@testtoast.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
AIC100 devices generates Reliability, Availability, Serviceability events
via MHI QAIC_STATUS channel. Support such events and print a structured
log with details of the events, and if the event describes an uncorrected
error, reset the device to put it back into service. As these events may
not all be reported via other mechanisms like AER, maintain counts of
the number of errors observed for each type.
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Troy Hanson <quic_thanson@quicinc.com> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Link: https://lore.kernel.org/r/20250516160634.1408309-1-jeff.hugo@oss.qualcomm.com
Inline drm_gem_pin() into its only caller drm_gem_map_attach()
and update the documentation in the callback's purpose. Do the
equivalent for drm_gem_unpin(). Also add stricter error checking
on the involved locking.
The pin operation in the GEM object functions is a helper for
PRIME-exported buffer objects. Having drm_gem_pin() gives the
impression of a general-purpose interface, which is not the case.
Removing it makes the pin callback a bit harder to misuse.
Gem-vram helpers do not support PRIME dma-buf sharing. So nothing
will ever call pin/unpin on its buffer objects. Do not set these
callbacks in struct drm_gem_object_funcs.
drm/client: Do not pin in drm_client_buffer_vmap()
Pin and vmap are two distict operations. Do not mix them.
The helper drm_client_buffer_vmap() maps the pages for fbdev-dma
and fbdev-shmem. In both cases, the vmap operation ensures that
the pages are available until the vunmap happens. And as the pages
in DMA or SHMEM areas cannot be moved, there is no reason to call
pin. Hence remove the pin call.
Update drm_client_buffer_vunmap() accordingly.
v2:
- call 'locked' variants of GEM helpers (Dmitry)
This adds FOURCCs for 3-plane 10/12/16bit YCbCr formats used by software
decoders like ffmpeg, dav1d and libvpx. The intended use-case is buffer
sharing between decoders and GPUs by allocating buffers with e.g. udmabuf
or dma-heaps, avoiding unnecessary copies and format conversions in
various scenarios.
Unlike formats typically used by hardware decoders the 10/12bit formats
use a LSB alignment. In order to allow fast implementations in GL
and Vulkan the padding must contain only zeros, so the float
representation can be calculated by multiplying with 2^6=64 or 2^4=16
respectively.
MRs or branches for Mesa, Vulkan, Gstreamer, Weston and Mutter can be found at:
- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34303
- https://github.com/rmader/Vulkan-Docs/commits/ycbcr-16bit-lsb-formats/
- https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8540
- https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1753
- https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4348
The naming scheme follows the 'P' and 'Q' formats. The 'S' stands for
'software' and was selected in order to make remembering easy.
The 'Sx16' formats could as well be 'Qx16'. We stick with 'S' as 16bit software
decoders are likely much more common than hardware ones for the foreseeable
future. Note that these formats already have Vulkan equivalents:
- VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM
- VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM
- VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM
Since drm_file starts with 1 for the unique id, just use 0 for the
in-kernel jobs.
Fixes: 2956554823ce ("drm/sched: Store the drm client_id in drm_sched_fence") Cc: Christian König <christian.koenig@amd.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250528-fix-sched-v1-1-c042ef23ff8b@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Arthur Grillo [Tue, 15 Apr 2025 13:55:38 +0000 (15:55 +0200)]
drm/vkms: Add how to run the Kunit tests
Now that we have KUnit tests, add instructions on how to run them.
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250415-yuv-v18-7-f2918f71ec4b@bootlin.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Arthur Grillo [Tue, 15 Apr 2025 13:55:37 +0000 (15:55 +0200)]
drm/vkms: Create KUnit tests for YUV conversions
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
The code used to compute the expected result can be found in comment.
[Louis Chauvet:
- fix minor formating issues (whitespace, double line)
- change expected alpha from 0x0000 to 0xffff
- adapt to the new get_conversion_matrix usage
- apply the changes from Arthur
- move struct pixel_yuv_u8 to the test itself]
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250415-yuv-v18-6-f2918f71ec4b@bootlin.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Louis Chauvet [Tue, 15 Apr 2025 13:55:36 +0000 (15:55 +0200)]
drm: Export symbols to use in tests
The functions drm_get_color_encoding_name and drm_get_color_range_name
are useful for clarifying test results. Therefore, export them so they
can be used in tests built as modules.
Arthur Grillo [Tue, 15 Apr 2025 13:55:35 +0000 (15:55 +0200)]
drm/vkms: Drop YUV formats TODO
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250415-yuv-v18-4-f2918f71ec4b@bootlin.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Arthur Grillo [Tue, 15 Apr 2025 13:55:34 +0000 (15:55 +0200)]
drm/vkms: Add range and encoding properties to the plane
Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them.
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
[Louis Chauvet: retained only relevant parts, updated the commit message] Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250415-yuv-v18-3-f2918f71ec4b@bootlin.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The conversion from yuv to rgb is done with fixed-point arithmetic, using
32.32 fixed-point numbers and the drm_fixed helpers.
To do the conversion, a specific matrix must be used for each color range
(DRM_COLOR_*_RANGE) and encoding (DRM_COLOR_*). This matrix is stored in
the `conversion_matrix` struct, along with the specific y_offset needed.
This matrix is queried only once, in `vkms_plane_atomic_update` and
stored in a `vkms_plane_state`. Those conversion matrices of each
encoding and range were obtained by rounding the values of the original
conversion matrices multiplied by 2^32. This is done to avoid the use of
floating point operations.
The same reading function is used for YUV and YVU formats. As the only
difference between those two category of formats is the order of field, a
simple swap in conversion matrix columns allows using the same function.
[Louis Chauvet:
- Adapted Arthur's work
- Implemented the read_line_t callbacks for yuv
- add struct conversion_matrix
- store the whole conversion_matrix in the plane state
- remove struct pixel_yuv_u8
- update the commit message
- Merge the modifications from Arthur]
projects / thirdparty / linux.git / log
