Aradhya Bhatia [Thu, 5 Jun 2025 17:15:23 +0000 (22:45 +0530)]
drm/atomic-helper: Re-order bridge chain pre-enable and post-disable
Move the bridge pre_enable call before crtc enable, and the bridge
post_disable call after the crtc disable.
The sequence of enable after this patch will look like:
bridge[n]_pre_enable
...
bridge[1]_pre_enable
crtc_enable
encoder_enable
bridge[1]_enable
...
bridge[n]_enable
And, the disable sequence for the display pipeline will look like:
bridge[n]_disable
...
bridge[1]_disable
encoder_disable
crtc_disable
bridge[1]_post_disable
...
bridge[n]_post_disable
The definition of bridge pre_enable hook says that,
"The display pipe (i.e. clocks and timing signals) feeding this bridge
will not yet be running when this callback is called".
Since CRTC is also a source feeding the bridge, it should not be enabled
before the bridges in the pipeline are pre_enabled. Fix that by
re-ordering the sequence of bridge pre_enable and bridge post_disable.
While at it, update the drm bridge API documentation as well.
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-4-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
- and the disable sequence is exactly the reverse of this.
The crtc operations occur by looping over the old and new crtc states,
while the encoder and bridge operations occur together, by looping over
the connector states of the display pipelines.
Refactor these operations - crtc enable/disable, and encoder & bridge
(pre/post) enable/disable - into separate functions each, to make way
for the re-ordering of the enable/disable sequences.
This patch doesn't alter the sequence of crtc/encoder/bridge operations
in any way, but helps to cleanly pave the way for the next two patches,
by maintaining logical bisectability.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-2-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
Karunika Choo [Fri, 6 Jun 2025 10:18:35 +0000 (12:18 +0200)]
drm/panthor: Clean up 64-bit register definitions
With the introduction of 64-bit register accessors, the separate *_HI
definitions are no longer necessary. This change removes them and
renames the corresponding *_LO entries for cleaner and more consistent
register definitions.
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Boris Brezillon [Fri, 6 Jun 2025 08:09:32 +0000 (10:09 +0200)]
drm/panthor: Fix the user MMIO offset logic for emulators
Currently, we pick the MMIO offset based on the size of the pgoff_t
type seen by the process that manipulates the FD, such that a 32-bit
process can always map the user MMIO ranges. But this approach doesn't
work well for emulators like FEX, where the emulator is a 64-bit binary
which might be executing 32-bit code. In that case, the kernel thinks
it's the 64-bit process and assumes DRM_PANTHOR_USER_MMIO_OFFSET_64BIT
is in use, but the UMD library expects DRM_PANTHOR_USER_MMIO_OFFSET_32BIT,
because it can't mmap() anything above the pgoff_t size.
In order to solve that, we need a way to explicitly set the user MMIO
offset from the UMD, such that the kernel doesn't have to guess it
from the TIF_32BIT flag set on user thread. We keep the old behavior
if DRM_PANTHOR_SET_USER_MMIO_OFFSET is never called.
Changes in v2:
- Drop the lock/immutable fields and allow SET_USER_MMIO_OFFSET
requests to race with mmap() requests
- Don't do the is_user_mmio_offset test twice in panthor_mmap()
- Improve the uAPI docs
Changes in v3:
- Bump to version 1.5 instead of 1.4 after rebasing
- Add R-bs
- Fix/rephrase comment as suggested by Liviu
Boris Brezillon [Fri, 6 Jun 2025 08:09:31 +0000 (10:09 +0200)]
drm/panthor: Add missing explicit padding in drm_panthor_gpu_info
drm_panthor_gpu_info::shader_present is currently automatically offset
by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those
constraints don't stand on 32-bit x86 and cause a mismatch when running
an x86 binary in a user emulated environment like FEX. It's also
generally agreed that uAPIs should explicitly pad their struct fields,
which we originally intended to do, but a mistake slipped through during
the submission process, leading drm_panthor_gpu_info::shader_present to
be misaligned.
This uAPI change doesn't break any of the existing users of panthor
which are either arm32 or arm64 where the 64-bit alignment of
u64 fields is already enforced a the compiler level.
Changes in v2:
- Rename the garbage field into pad0 and adjust the comment accordingly
- Add Liviu's A-b
Douglas Anderson [Thu, 22 May 2025 00:32:05 +0000 (17:32 -0700)]
drm/panel-edp: Clarify the `prepare_to_enable` description in comments
It's unclear why I originally wrote in the description of
`prepare_to_enable` that "This is not specified in a standard way on
eDP timing diagrams" and then also wrote "It is effectively the time
from HPD going high till you can turn on the backlight." It seems
pretty clear that it's (T4+T5+T6+T8)-min. Either I was confused when I
wrote this or I was looking at some strange panel datasheet that I can
no longer find.
Update the description of the field so it's easier for people to fill
this in. Couch the description with "usually" in case there really was
some weird datasheet where things were specified in a different way.
Chris Morgan [Tue, 3 Jun 2025 19:39:29 +0000 (14:39 -0500)]
drm/panel: himax-hx8394: Add Support for Huiling hl055fhav028c
Add support for the Huiling hl055fhav028c panel as used on the
Gameforce Ace handheld gaming console. This panel uses a Himax HX8399C
display controller and requires a sparsely documented vendor provided
init sequence. The display resolution is 1080x1920 and is 70mm by 127mm
as stated in the manufacturer's documentation.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-2-macroalpha82@gmail.com
Add compatible string for the Huiling hl055fhav028c. This panel is
based on the Himax HX8399C display controller which is extremely
similar to the existing HX8394. Add a new constant for
himax,hx8399c for this new display controller as well.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-3-macroalpha82@gmail.com
Chris Morgan [Tue, 3 Jun 2025 19:39:27 +0000 (14:39 -0500)]
dt-bindings: vendor-prefixes: Add prefix for Huiling
Shenzhen Huiling Information Technology Co. Ltd. specializes in the
research and manufacturing of display and touch screens for industrial
usage. https://en.szhuiling.com/
Michael Walle [Tue, 20 May 2025 07:44:39 +0000 (09:44 +0200)]
drm/panel-simple: add AUO P238HAN01 panel entry
Timings taken from the datasheet and the display is working in DE mode,
thus the datasheet only specifies the blanking period. sync, back porch
and front porch are arbitrarily chosen.
The datasheet can be found at [1] but for reference these are the
relevant timings:
sym | | min | typ | max | unit |
------|--------------+------+------+------+------+
Tv | V period | 1094 | 1130 | 1836 | Th |
| V active | 1080 | 1080 | 1080 | Th |
| V blanking | 14 | 50 | 756 | Th |
Fv | V frequency | 49 | 60 | 76 | Hz |
Th | H period | 1000 | 1050 | 1678 | Tclk |
| H active | 960 | 960 | 960 | Tclk |
| H blanking | 40 | 90 | 718 | Tclk |
Fh | H frequency | 53.7 | 67.8 | 90.0 | kHz |
Tclk | LVDS clock | 53.7 | 71.2 | 90.0 | MHz |
Keep in mind that this is a dual link LVDS panel and the horizontal
timings are only for one half of the panel.
Lucas De Marchi [Tue, 3 Jun 2025 18:47:51 +0000 (11:47 -0700)]
drm/ttm: Fix build with CONFIG_DEBUG_FS=n
Move the define outside the ifdef for CONFIG_DEBUG_FS to fix the build.
This currently breaks drm kunit tests:
$ ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/ttm/tests/.kunitconfig
ERROR:root:../drivers/gpu/drm/ttm/ttm_pool.c: In function ‘ttm_pool_mgr_init’:
../drivers/gpu/drm/ttm/ttm_pool.c:1335:30: error: ‘TTM_SHRINKER_BATCH’ undeclared (first use in this function)
1335 | mm_shrinker->batch = TTM_SHRINKER_BATCH;
Fixes: 22b929b25293 ("drm/ttm: Increase pool shrinker batch target") Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603184750.3304647-2-lucas.demarchi@intel.com
Tvrtko Ursulin [Thu, 15 May 2025 09:49:58 +0000 (10:49 +0100)]
dma-fence: Add helpers for accessing driver and timeline name
Add some helpers in order to enable preventing dma-fence users accessing
the implementation details directly and make the implementation itself use
them.
This will also enable later adding some asserts to a consolidated
location.
Tvrtko Ursulin [Thu, 15 May 2025 09:49:57 +0000 (10:49 +0100)]
dma-fence: Use a flag for 64-bit seqnos
With the goal of reducing the need for drivers to touch (and dereference)
fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to
the fence->flags.
Drivers which were setting this flag are changed to use new
dma_fence_init64() instead of dma_fence_init().
v2:
* Streamlined init and added kerneldoc.
* Rebase for amdgpu userq which landed since.
Tvrtko Ursulin [Tue, 3 Jun 2025 11:27:50 +0000 (12:27 +0100)]
drm/ttm: Increase pool shrinker batch target
The default core shrink target of 128 pages (SHRINK_BATCH) is quite low
relative to how cheap TTM pool shrinking is, and how the free pages are
distributed in page order pools.
We can make the target a bit more aggressive by making it roughly the
average number of pages across all pools, freeing more of the cached
pages every time shrinker core invokes our callback.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603112750.34997-3-tvrtko.ursulin@igalia.com
Tvrtko Ursulin [Tue, 3 Jun 2025 11:27:49 +0000 (12:27 +0100)]
drm/ttm: Respect the shrinker core free target
Currently the TTM shrinker aborts shrinking as soon as it frees pages from
any of the page order pools and by doing so it can fail to respect the
freeing target which was configured by the shrinker core.
We use the wording "can fail" because the number of freed pages will
depend on the presence of pages in the pools and the order of the pools on
the LRU list. For example if there are no free pages in the high order
pools the shrinker core may require multiple passes over the TTM shrinker
before it will free the default target of 128 pages (assuming there are
free pages in the low order pools). This inefficiency can be compounded by
the pool LRU where multiple further calls into the TTM shrinker are
required to end up looking at the pool with pages.
Improve this by never freeing less than the shrinker core has requested.
At the same time we start reporting the number of scanned pages (freed in
this case), which prevents the core shrinker from giving up on the TTM
shrinker too soon and moving on.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603112750.34997-2-tvrtko.ursulin@igalia.com
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>
projects / thirdparty / kernel / stable.git / log
