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]
Its only purpose was for trace events, but jobs can already be
uniquely identified using their fence.
The downside of using the fence is that it's only available
after 'drm_sched_job_arm' was called which is true for all trace
events that used job.id so they can safely switch to using it.
Suggested-by: Tvrtko Ursulin <tursulin@igalia.com> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Arvind Yadav <arvind.yadav@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250526125505.2360-9-pierre-eric.pelloux-prayer@amd.com
All events now start with the same prefix (drm_sched_job_).
drm_sched_job_wait_dep was misleading because it wasn't waiting
at all. It's now replaced by trace_drm_sched_job_unschedulable,
which is only traced if the job cannot be scheduled.
For moot dependencies, nothing is traced.
We can't trace dependencies from drm_sched_job_add_dependency
because when it's called the job's fence is not available yet.
So instead each dependency is traced individually when
drm_sched_entity_push_job is used.
Tracing the dependencies allows tools to analyze the dependencies
between the jobs (previously it was only possible for fences
traced by drm_sched_job_wait_dep).
drm/sched: Add device name to the drm_sched_process_job event
Since switching the scheduler from using kthreads to workqueues in
commit a6149f039369 ("drm/sched: Convert drm scheduler to use a work
queue rather than kthread") userspace applications cannot determine
the device from the PID of the threads sending the trace events
anymore.
Each queue had its own kthread which had a given PID for the whole
time. So, at least for amdgpu, it was possible to associate a PID
to the hardware queues of each GPU in the system. Then, when a
drm_run_job trace event was received by userspace, the source PID
allowed to associate it back to the correct GPU.
With workqueues this is not possible anymore, so the event needs to
contain the dev_name() to identify the device.
drm/sched: Store the drm client_id in drm_sched_fence
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
This requires changing all the users of drm_sched_job_init to
add an extra parameter.
The newly added drm_client_id field in the drm_sched_fence is a bit
of a duplicate of the owner one. One suggestion I received was to
merge those 2 fields - this can't be done right now as amdgpu uses
some special values (AMDGPU_FENCE_OWNER_*) that can't really be
translated into a client id. Christian is working on getting rid of
those; when it's done we should be able to squash owner/drm_client_id
together.
drm/debugfs: Output client_id in in drm_clients_info
client_id is a unique id used by fdinfo. Having it listed in 'clients'
output means a userspace application can correlate the fields, eg:
given a fdinfo id get the fdinfo name.
Geiven that client_id is a uint64_t, we use a %20llu printf format to
keep the output aligned (20 = digit count of the biggest uint64_t).
projects / thirdparty / linux.git / log
