ADV75xx hardware supports sending SPD InfoFrame over the HDMI link. Also
it provides support for two generic (Spare) InfoFrames. Use those
capabilities to be able to send SPD and HDMI Vendor-Specific Infoframes.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250827-adv7511-infoframes-v1-1-f89b9690f89c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Handle LVDS pixel clock.
The LTDC operates with multiple clock domains for register access,
requiring all clocks to be provided during read/write operations. This
imposes a dependency between the LVDS and LTDC to access correctly all
LTDC registers. And because both IPs' pixel rates must be synchronized,
the LTDC has to handle the LVDS clock.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-8-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
STM32MP25 SoC features a new version of the LTDC IP. Add its compatible
to the list of device to probe and implement its quirks.
This hardware supports a pad frequency of 150MHz and a peripheral bus
clock.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-7-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
On STM32MP25 SoC, the syscfg peripheral provides a clock to the display
subsystem through a multiplexer. Since it only provides a single clock,
the cell value is 0.
Doing so allows the clock consumers to reach the peripheral and gate the
clock accordingly.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Christophe Roullier <christophe.roullier@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-6-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
STM32 LVDS peripheral may be in a power domain. Allow an optional
single 'power-domains' entry for STM32 LVDS devices.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-5-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
This property is added when the peripheral is under the STM32 firewall
controller. It allows an accurate representation of the hardware, where
the peripheral is connected to a firewall bus. The firewall can then
check the peripheral accesses before allowing its device to probe.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-4-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Update the compatible to accept both "st,stm32mp255-lvds" and
st,stm32mp25-lvds" respectively. Default will fall back to
"st,stm32mp25-lvds".
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-3-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
This property is added when the peripheral is under the STM32 firewall
controller. It allows an accurate representation of the hardware, where
the peripheral is connected to a firewall bus. The firewall can then check
the peripheral accesses before allowing its device to probe.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-2-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
The new STMicroelectronics SoC features a display controller similar to
the one used in previous SoCs. Because there is additional registers,
and different mandatory clocks it is incompatible with existing IPs. On
STM32MP251, the device only needs two clocks while on STM32MP255 it
needs four.
Add the new names to the list of compatible string and handle each
quirks accordingly.
Acked-by: Philippe Cornu <philippe.cornu@foss.st.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-1-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Add driver extension for Synopsys DesignWare DPTX IP used
on Rockchip RK3588 SoC.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Acked-by: Dmitry Baryshkov <lumag@kernel.org>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250822063959.692098-4-andyshrk@163.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The DW DP TX Controller is compliant with the DisplayPort Specification
Version 1.4 with the following features:
* DisplayPort 1.4a
* Main Link: 1/2/4 lanes
* Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps
* AUX channel 1Mbps
* Single Stream Transport(SST)
* Multistream Transport (MST)
* Type-C support (alternate mode)
* HDCP 2.2, HDCP 1.3
* Supports up to 8/10 bits per color component
* Supports RBG, YCbCr4:4:4, YCbCr4:2:2, YCbCr4:2:0
* Pixel clock up to 594MHz
* I2S, SPDIF audio interface
Add library with common helpers to make it can be shared with
other SoC.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20250822063959.692098-3-andyshrk@163.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The Rockchip RK3588 SoC integrates the Synopsys DesignWare DPTX
controller. And this DPTX controller need share a USBDP PHY with
the USB 3.0 OTG controller during operation.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250822063959.692098-2-andyshrk@163.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. This means the code paths
after that are dead. Removing those paths means the
mmu_hw_do_flush_on_gpu_ctrl() function might has well be inlined.
Simplify everything by having a switch statement for the type of 'op'
(warning if we get an unexpected value) and removing the dead cases.
Suggested-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Steven Price <steven.price@arm.com>
Reviewed-by: Karunika Choo <karunika.choo@arm.com>
Link: https://lore.kernel.org/r/20250815134226.57703-1-steven.price@arm.com
Since all users of gem.gpuva.lock_dep_map now rely on the mutex directly
in gpuva, we may remove it. Whether the mutex is used is now tracked by
a flag in gpuvm rather than by whether lock_dep_map is null.
Note that a GEM object may not be pushed to multiple gpuvms that
disagree on the value of this new flag. But that's okay because a single
driver should use the same locking scheme everywhere, and a GEM object
is driver specific (when a GEM is exported with prime, a new GEM object
instance is created from the backing dma-buf).
The flag is present even with CONFIG_LOCKDEP=n because the intent is
that the flag will also cause vm_bo cleanup to become deferred. However,
that will happen in a follow-up patch.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-3-bd89f5a82c0d@google.com
[ Use lockdep_is_held() instead of lock_is_held(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Now that drm_gem_object has a dedicated mutex for the gpuva list that is
intended to be used in cases that must be fence signalling safe, use it
in Panthor.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-2-bd89f5a82c0d@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
There are two main ways that GPUVM might be used:
* staged mode, where VM_BIND ioctls update the GPUVM immediately so that
the GPUVM reflects the state of the VM *including* staged changes that
are not yet applied to the GPU's virtual address space.
* immediate mode, where the GPUVM state is updated during run_job(),
i.e., in the DMA fence signalling critical path, to ensure that the
GPUVM and the GPU's virtual address space has the same state at all
times.
Currently, only Panthor uses GPUVM in immediate mode, but the Rust
drivers Tyr and Nova will also use GPUVM in immediate mode, so it is
worth to support both staged and immediate mode well in GPUVM. To use
immediate mode, the GEMs gpuva list must be modified during the fence
signalling path, which means that it must be protected by a lock that is
fence signalling safe.
For this reason, a mutex is added to struct drm_gem_object that is
intended to achieve this purpose. Adding it directly in the GEM object
both makes it easier to use GPUVM in immediate mode, but also makes it
possible to take the gpuva lock from core drm code.
As a follow-up, another change that should probably be made to support
immediate mode is a mechanism to postpone cleanup of vm_bo objects, as
dropping a vm_bo object in the fence signalling path is problematic for
two reasons:
* When using DRM_GPUVM_RESV_PROTECTED, you cannot remove the vm_bo from
the extobj/evicted lists during the fence signalling path.
* Dropping a vm_bo could lead to the GEM object getting destroyed.
The requirement that GEM object cleanup is fence signalling safe is
dubious and likely to be violated in practice.
Panthor already has its own custom implementation of postponing vm_bo
cleanup.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-1-bd89f5a82c0d@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250828085708.3383760-1-nichen@iscas.ac.cn
In drm_sched_fini() all entities are marked as stopped - without taking
the appropriate lock, because that would deadlock. That means that
drm_sched_fini() and drm_sched_entity_push_job() can race against each
other.
This should most likely be fixed by establishing the rule that all
entities associated with a scheduler must be torn down first. Then,
however, the locking should be removed from drm_sched_fini() alltogether
with an appropriate comment.
Reported-by: James Flowers <bold.zone2373@fastmail.com>
Link: https://lore.kernel.org/dri-devel/20250720235748.2798-1-bold.zone2373@fastmail.com/
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250813085654.102504-2-phasta@kernel.org
The header file <linux/atomic.h> is already included on line 8. Remove the
redundant include.
Fixes: 5a99350794 ("drm/sched: Add scheduler unit testing infrastructure and some basic tests")
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250819142630.368796-1-liaoyuanhong@vivo.com
Indirect buffers are an AMD term describing essentialy a job submitted to
the scheduler, just a lower level one. Since scheduler was promoted to be
generic long ago, lets replace those references with jobs.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250814133627.2550-1-tvrtko.ursulin@igalia.com
Bitwise AND was intended instead of OR. With the current code the
condition is always true.
Fixes: cbdd16b818 ("HID: i2c-hid: Make elan touch controllers power on after panel is enabled")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Pin-yen Lin <treapking@chromium.org>
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/aK8Au3CgZSTvfEJ6@stanley.mountain
Add support for DRM_FORMAT_C8 to vesadrm. The new pixel-format
description PIXEL_FORMAT_C8 describes the layout. Vesadrm's helpers
vesadrm_fill_palette_lut() and vesadrm_load_palette_lut() set the
hardware palette according to the CRTC's output format.
The driver emulates XRGB8888 by converting the source buffer to
RGB332 and using the resulting 256 colors as index into the hardware
palette. The hardware palette converts back to RGB during scanout.
This has no overhead compared to other format conversion, but allows
common userspace, such as Wayland compositors, to operate on the
display.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-10-tzimmermann@suse.de
Distiguish between component-based formats and 'the rest' in vesadrm's
color management. Scanout buffers with component-based format allow
for gamma correction. Palette-based formats (i.e., 'the rest') require
palette setup.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-9-tzimmermann@suse.de
Rename vesadrm's gamma helpers in preparation of the upcoming support
for color palettes. Gamma correction and color palettes share the same
hardware features, but the driver's old naming only indicated support
for gamma LUTs.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-8-tzimmermann@suse.de
List the conversion from XRGB8888-to-RGB332 in drm_fb_blit(), so that
drivers based on sysfb-helpers can use it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-7-tzimmermann@suse.de
Add helper drm_crtc_fill_palette_332(), which fills palettes with
RGB332 color data. Each color in RGB332 format serves as an index
into an 8-bit palette that stores the corresponding component-based
colors.
Vesadrm will use the new helper to emulate RGB formats on top of
framebuffers in C8 format.
v2:
- add comments on bit operations (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-6-tzimmermann@suse.de
Use the color format stored in struct drm_sysfb_crtc_state for
color-format conversion instead of the scanout-buffer format
announced by firmware. Currently, both values are identical.
This will allow drivers to modify the CRTC's input format to a
certain extend. Specifically, vesadrm will be able to display RGB
framebuffers when the scanout buffer is of C8 format. With color-
format conversion to RGB332 and correct setup of the C8 palette,
displaying XRGB8888-based buffers under C8 can be achieved.
v2:
- refer to RGB332 as CRTC input format
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-5-tzimmermann@suse.de
Convert drm_sysfb_get_format_si() to lookup the screen_info color
format as struct pixel_format with screen_info_pixel_format(). Then
search the list of given formats for the screen_info format with
pixel_format_equal().
Replaces custom code with helpers. The pixel-compare helper
pixel_format_equal() also handles indexed color formats. Prepares
for sysfb drivers to support color palettes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-4-tzimmermann@suse.de
Add screen_info_pixel_format(), which converts a screen_info's
information about the color format to struct pixel_format. The encoding
within the screen_info structure is complex and therefore prone to
errors. Later patches will convert callers to use the pixel format.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20250714151513.309475-3-tzimmermann@suse.de
Introduce a new HID quirk to indicate that this device has to be enabled
after the panel's backlight is enabled, and update the driver data for
the elan devices to enable this quirk. This cannot be a I2C HID quirk
because the kernel needs to acknowledge this before powering up the
device and read the VID/PID. When this quirk is enabled, register
.panel_enabled()/.panel_disabling() instead for the panel follower.
Also rename the *panel_prepare* functions into *panel_follower* because
they could be called in other situations now.
Fixes: bd3cba00dc ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens")
Fixes: d06651bebf ("HID: i2c-hid: elan: Add elan-ekth6a12nay timing")
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250818115015.2909525-2-treapking@chromium.org
Some touch controllers have to be powered on after the panel's backlight
is enabled. To support these controllers, introduce .panel_enabled() and
.panel_disabling() to panel_follower_funcs and use them to power on the
device after the panel and its backlight are enabled.
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250818115015.2909525-1-treapking@chromium.org
Since commit 3309323241 ("drm/gpuvm: Kill drm_gpuva_init()") MSM
driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not
allocate memptrs: -22" errors. The mentioned commit reworked the
function, but didn't take into account that op_map is initialized at the
top of the function, while ranges might change if GPUVM is managed by
the kernel.
Move op_mode initialization after finalizing all addresses and right
before the drm_gpuva_init_from_op() call.
Reported-by: Danct12 <danct12@disroot.org>
Fixes: 3309323241 ("drm/gpuvm: Kill drm_gpuva_init()")
Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Rob Clark <robin.clark@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250823-msm-fix-gpuvm-init-v1-1-e199cd5b1983@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Add the necessary specific bits to support the rk3576-variant of the
DW-DSI2 controller.
Signed-off-by: Guochun Huang <hero.huang@rock-chips.com>
[adapted from the vendor-kernel for mainline]
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-10-heiko@sntech.de
The rk3576 controller is based on the same newer Synopsis IP as the one
found in the rk3588.
Its external setting bits in the GRF are different though, so it needs
its own distinct compatible.
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-9-heiko@sntech.de
Document the compatible value for Bestar BSD1218-A101KL68 LCD panels
that are based around the ili9881c controller.
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-6-heiko@sntech.de
Add the prefix for Bestar, named in full both on Panelook.com and their
display datasheets as
Shenzhen Bestar Electronic Technology Co., Ltd.
which produces at least DSI displays and maybe more.
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-5-heiko@sntech.de
This saves some lines for error handling.
For the address mode change, that value is always an u8, so switching
to dcs_write_buffer function should be appropriate.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-4-heiko@sntech.de
At least for panel-bridges, the atomic_enable call is defined as being
called right after the preceding element in the display pipe is enabled.
It is also stated that "The bridge can assume that the display pipe (i.e.
clocks and timing signals) feeding it is running when this callback is
called"
This means the DSI controller driving this display would have already
switched over to video-mode from command mode and thus dcs functions
should not be called anymore at this point.
This caused a non-working display for me, when trying to enable
the rk3576 dsi controller using a display using this controller.
Therefore move the display_on/off calls the more appropriate
prepare/unprepare callbacks.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-3-heiko@sntech.de
The prepare function turns on the power-supply regulator first, when
preparing the display. But in an error case, just returns the error
code, but does not power off the regulator again, fix that.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250707164906.1445288-2-heiko@sntech.de
The RA620 is an active DP to HDMI converter chip, basically
no software is involved to drive it.
Add it to simple bridge to make it can be find by the drm bridge chain.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250822063959.692098-7-andyshrk@163.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
RA620 is a DP to HDMI bridge converter from RADXA, which first
found be used on ROCK 5 ITX.
This chip can be used without involving software.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250822063959.692098-6-andyshrk@163.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Commit fd40a63c63 ("drm/atomic: Let drivers decide which planes to
async flip") unintentionally disallowed no-op changes on non-primary
planes that the driver doesn't allow async flips on. This broke async
flips for compositors that disable the cursor plane in every async
atomic commit. To fix that, change drm_atomic_set_property to again
only run atomic_async_check if the plane would actually be changed by
the atomic commit.
Fixes: fd40a63c63 ("drm/atomic: Let drivers decide which planes to async flip")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Reviewed-by: André Almeida <andrealmeid@igalia.com>
Link: https://lore.kernel.org/r/20250822152849.87843-1-xaver.hugl@kde.org
[andrealmeid: fix checkpatch warning]
Signed-off-by: André Almeida <andrealmeid@igalia.com>
The compiler information is outdated. Update it to the latest.
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://lore.kernel.org/r/20250820233817.4050006-1-lizhi.hou@amd.com
