FP8006P datasheet mentions:
> It is necessary to wait 15msec after releasing RESX before sending
> commands. Also Sleep Out command cannot be sent for 120 msec.
This hasn't been respected by the driver so far, which could interfere
with the LCD init code sequence performed by the controller. In some cases
this leads to VCOM voltage being set to a wrong value, causing "halo"
effects, temporary burn-in around the edges of the screen and degraded
image contrast.
T3 and T4 are counted from when VDDI is enabled. There's no need to add
them when we've already waited more than that in T2 and T2d.
While FT8006P datasheet does not mention a delay between exiting sleep
mode and turning the display on, code provided by the vendor uses 120ms
there and it happens to be the same value as required in newer datasheets
for newer controllers from the same family, so it seems appropriate to
use it here as well.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-2-1ebc9b195a34@puri.sm
This improves reliability of sending DSI commands.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-1-1ebc9b195a34@puri.sm
In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it
may be NULL:
if (!jdi)
mipi_dsi_detach(dsi);
However, when jdi is NULL, the function does not return and continues by
calling jdi_panel_disable():
err = jdi_panel_disable(&jdi->base);
Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can
lead to a NULL-pointer dereference:
struct jdi_panel *jdi = to_panel_jdi(panel);
backlight_disable(jdi->backlight);
To prevent such a potential NULL-pointer dereference, return early from
jdi_panel_dsi_remove() when jdi is NULL.
Signed-off-by: Tuo Li <islituo@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251218120955.11185-1-islituo@gmail.com
Add support for the Innolux G150XGE-L05 15.0" TFT 1024x768 LVDS panel.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260102141706.36842-2-festevam@gmail.com
Migrate the TL121BVMS07 panel from non-DSC 60 Hz to DSC-enabled 120 Hz,
including updated init sequence, DSC configuration, and display timings.
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251216075530.1966327-1-yelangyan@huaqin.corp-partner.google.com
Add support for the dw-hdmi-qp driver to handle devices with missing
HPD pins.
Since in this situation we are now polling for the EDID data via i2c
change the error message to a rate limited debug message when we are
unable to complete an i2c read, as a disconnected device would
otherwise fill dmesg with i2c read errors.
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-3-macroalpha82@gmail.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251031104846.119503-3-marco.crivellari@suse.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251031104846.119503-2-marco.crivellari@suse.com
drm_gem_put_pages(), which we rely on for returning BO pages to shmem,
assume per-folio refcounting and not per-page. If we call
shmem_read_mapping_page() per-page, we break this assumption and leak
pages every time we get a huge page allocated.
v2:
- Rework the logic for() loop to better match the folio-granular
allocation scheme
Cc: Loïc Molinari <loic.molinari@collabora.com>
Fixes: c12e9fcb5a ("drm/panfrost: Introduce huge tmpfs mountpoint option")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260108123325.1088195-1-boris.brezillon@collabora.com
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
drm_gem_object_lookup_at_offset() can return a valid object with
filp or filp->f_op->get_unmapped_area set to NULL. Make sure we still
release the ref we acquired on such objects.
Cc: Loïc Molinari <loic.molinari@collabora.com>
Fixes: 99bda20d6d ("drm/gem: Introduce drm_gem_get_unmapped_area() fop")
Reviewed-by: Loïc Molinari <loic.molinari@collabora.com>
Link: https://patch.msgid.link/20260106164935.409765-1-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
On the RK3506 platform, there is no iommu hardware. And even on
platform that have iommu hardware, it should be possible to use
VOP without enabling iommu. In this case, a contiguous memory
space like CMA should be used.
So this patch removes the dependency on ROCKCHIP_IOMMU
with an 'optional-dependency'.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
[added reference to optional-dependies description]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-9-kernel@airkyi.com
The help text of CONFIG_DRM_PANIC_SCREEN_QR_CODE documents the expected
value to CONFIG_DRM_PANIC_SCREEN as "qr_code" but drm_panic_type_map
checks for "qr". Adjust drm_panic_type_map and the module description to
match so that existing configurations do not stop working.
Fixes: e85e9ccf3f ("drm/panic: Report invalid or unsupported panic modes")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260105-drm_panic-handle-invalid-drm_panic_screen-v1-2-55228bd4b0f8@kernel.org
If a user has set an invalid CONFIG_DRM_PANIC_SCREEN value (such as
"qr_code" without CONFIG_DRM_PANIC_SCREEN_QR_CODE=y due to missing or
incorrect Rust dependencies), there is a panic when accessing
/sys/module/drm/parameters/panic_screen:
[ 12.218375] BUG: unable to handle page fault for address: 0000000796dd8818
[ 12.219737] #PF: supervisor read access in kernel mode
...
[ 12.227167] RIP: 0010:drm_panic_type_get+0x1b/0x30
If drm_panic_type_set() does not find a valid drm_panic_type enumeration
in drm_panic_type_map based on the provided value, it does not change
drm_panic_type from the default -1 value, which is not a valid index for
accessing drm_panic_type_map in drm_panic_type_get(), resulting in the
crash.
Validate the value of CONFIG_DRM_PANIC_SCREEN at boot time via the
return value of drm_panic_type_set() in drm_panic_init() and explicitly
fall back to the default of "user" with a message to the user so that
they can adjust their configuration or fix missing dependencies.
[ 0.800697] Unsupported value for CONFIG_DRM_PANIC_SCREEN ('qr_code'), falling back to 'user'...
Fixes: e85e9ccf3f ("drm/panic: Report invalid or unsupported panic modes")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260105-drm_panic-handle-invalid-drm_panic_screen-v1-1-55228bd4b0f8@kernel.org
The VOP on rk3506:
- Support 2 lane MIPI DSI interface, 1.5Gbps/lane.
- Support RGB interface.
- Max output resolution is 1280x1280@60fps.
- WIN1 layer support RGB888/ARGB8888/RGB565.
- Support Gamma LUT.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-10-kernel@airkyi.com
The dsi controller found on RK3506 supports up to 2 lanes.
Signed-off-by: Hongming Zou <hongming.zou@rock-chips.com>
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-8-kernel@airkyi.com
Make it a little less convoluted, and just directly check if the
combination of plane + format + modifier is supported.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-8-83463c075a8d@collabora.com
We don't need to do a long open-coded walk here; we can simply check the
modifier value.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-7-83463c075a8d@collabora.com
Make sure we can't break the hardware by requesting an unsupported
configuration.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-6-83463c075a8d@collabora.com
Planes can only source AFBC framebuffers at multiples of 4px wide on
RK3566/RK3568. Instead of clipping on all SoCs when the user asks for an
unaligned source rectangle, reject the configuration in the plane's
atomic check on RK3566/RK3568 only.
Signed-off-by: Daniel Stone <daniels@collabora.com>
[Make RK3566/RK3568 specific, reword message, s/byte/pixel/]
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-5-83463c075a8d@collabora.com
It seems only cluster windows are capable of applying downscaling when
the source region has an odd width. Instead of applying a workaround
inside atomic_update, fail the plane check if this is requested.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-4-83463c075a8d@collabora.com
If we want to find out if a window is Esmart or not, test for not being
a cluster window, rather than AFBDC presence.
No functional effect as only cluster windows support AFBC decode.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-3-83463c075a8d@collabora.com
We already clip the plane to the display bounds in atomic_check, and
ensure that it is sufficiently sized. Instead of trying to catch this
and adjust for it in atomic_update, just assert that atomic_check has
done its job.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-2-83463c075a8d@collabora.com
We should never be able to create a framebuffer with an unsupported
format, so throw a warning if this ever happens.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-1-83463c075a8d@collabora.com
These methods just read the values stored in the op pointers without
modifying them, so it is appropriate to use const ptrs here.
This allows us to avoid const -> mut pointer casts in Rust.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-3-dbd014005a0b@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In commit 9ce4aef9a5 ("drm/gpuvm: take GEM lock inside
drm_gpuvm_bo_obtain_prealloc()") we update
drm_gpuvm_bo_obtain_prealloc() to take locks internally, which means
that it's only usable in immediate mode.
In this commit, we notice that drm_gpuvm_bo_obtain() requires you to use
staged mode. This means that we now have one variant of obtain for each
mode you might use gpuvm in.
To reflect this information, we add a warning about using it in
immediate mode, and to make the distinction clearer we rename the method
with a _locked() suffix so that it's clear that it requires the caller
to take the locks.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-2-dbd014005a0b@google.com
[ Slightly reword commit message to refer to commit 9ce4aef9a5
("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()").
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
v2: Check for feature PIPE_3D when forcing PPU flop reset (Lucas)
v3: - drop use of ppu_flop_reset enum (Christian Gmeiner)
- don't initialize module parameter to zero (checkpatch)
- avoid multi-line string in warning message (checkpatch)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marek.vasut@mailbox.org> # STM32MP255C DHCOS DHSBC
Link: https://patch.msgid.link/20251119164624.9297-6-gert.wollny@collabora.com
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
The PPU flop reset is required on some hardware to clear the
temporary registers. This code follows the implementation
of the PPU flop reset as found in the public galcore kernel
module. Compared to that code some superfluous parts were
removed and only the code path for SoC chip_model = 0x8000
and revision = 0x6205 is implemented and tested.
v2: - Move flop reset data to etnaviv_drm_private and initialize it
from etnaviv_gpu_bind (Lucas)
- Prepare code for more chip IDs and other flop reset types
- Do some cleanups and rename some functions
v3: - Move initialization of flop reset data to etnaviv_gpu_init (Lucas)
- Free PPU data suballocation (Lucas)
v4: As suggested by
- replace "asm-generic/int-ll64.h" with "linux/types.h"
- drop flop reset type enum since we only support one type here
- move function return parameters on same line with function name
- replace open coded for loop with memset32
- add cnost to local static values
- add a return value to etnaviv_flop_reset_ppu_init; handle and
pass errors on to the caller
- handle etnaviv_flop_reset_ppu_init return value
- use dev_err for flop reset error message
- fix include guard to be consistent with the other driver code
- fix license header and formatting
v5: As suggested by Christian Gmeiner:
- add required header that is no longer pulled in by etnaviv_buffer.h
- fix include style of linux headers
- free flop_reset_data_ppu when command buffer initialization fails
- fix typo in error message
[cgmeiner: fix SPDX comment style, fix line end with a '(' and fix typo]
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marek.vasut@mailbox.org> # STM32MP255C DHCOS DHSBC
Link: https://patch.msgid.link/20251119164624.9297-5-gert.wollny@collabora.com
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
v2: move some defines that resided in etnaviv_flop_reset.c
into the header as well
v3: fix spacing/tab stops
[cgmeiner: remove use of multiple blank lines]
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marek.vasut@mailbox.org> # STM32MP255C DHCOS DHSBC
Link: https://patch.msgid.link/20251119164624.9297-2-gert.wollny@collabora.com
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Commit 5d0bfe4484 ("drm/meson: Add HDMI 1.4 4k modes") added support
for HDMI 1.4 4k modes, which is what TVs need. For computer monitors
the code is using the DMT code-path, which ends up in
meson_venc_hdmi_supported_mode(), which does not allow the 4k modes yet.
The datasheet for all supported SoCs mentions "4Kx2K@60". It's not
clear whether "4K" here means 3840 or 4096 pixels.
Allow resolutions up to 3840x2160 pixels (including middle steps, such
as WQHD at 2560x1440 pixels) so they can be used with computer monitors
(using the DMT code-path in the driver).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251108134236.1299630-1-martin.blumenstingl@googlemail.com
Add kunit tests for drm_panic.
They check that drawing the panic screen doesn't crash, but they
don't check the correctness of the resulting image.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216082524.115980-3-jfalempe@redhat.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
I called them "static" because the panic screen is drawn only once,
but this can be confused with the static meaning in C.
Also remove some unnecessary braces in draw_panic_dispatch().
No functionnal change.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20251216082524.115980-2-jfalempe@redhat.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
The drm_info() function requires the drm/drm_print.h header to be included
first:
In file included from drivers/gpu/drm/pl111/pl111_nomadik.c:7:
drivers/gpu/drm/pl111/pl111_nomadik.h:11:32: error: 'struct drm_device' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
11 | void pl111_nomadik_init(struct drm_device *dev);
| ^~~~~~~~~~
drivers/gpu/drm/pl111/pl111_nomadik.c: In function 'pl111_nomadik_init':
drivers/gpu/drm/pl111/pl111_nomadik.c:34:9: error: implicit declaration of function 'drm_info'; did you mean 'pr_info'? [-Wimplicit-function-declaration]
34 | drm_info(dev, "set Nomadik PMU mux to CLCD mode\n");
| ^~~~~~~~
| pr_info
Fixes: a1542b8ca6 ("drm: pl111: replace dev_* print functions with drm_* variants")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Eslam Khafagy <eslam.medhat1993@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20251223214915.503913-1-arnd@kernel.org
imx8qxp_pixel_link_find_next_bridge() already emits a DRM_DEV_ERROR() on
error except for -EPROBE_DEFER. The caller emits another one, which is
redundant. Remove the message in the caller and keep the one in
imx8qxp_pixel_link_find_next_bridge() as it is more informative about the
error cause.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-20-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use the destroy hook to put the reference on deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-17-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-16-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
In preparation for using bridge->next_bridge, we need to ensure that it
will never contain anything but NULL or a valid bridge pointer. Current
code stores an ERR_PTR when imx8qxp_pxl2dpi_find_next_bridge() errors
out. Instead of fixing that after the facts in the caller, change the
function to internally set the next_pointer and just return an int error
value.
No functional changes.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-15-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
imx8qxp_pxl2dpi_find_next_bridge() already emits a DRM_DEV_ERROR() for
every error except -EPROBE_DEFER. The caller emits another one, which is
redundant. Remove the message in the caller and keep the two in
imx8qxp_pxl2dpi_find_next_bridge() as they are more informative about the
error cause.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-14-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-12-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-11-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-10-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-9-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-8-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-7-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Many bridge drivers store a next_bridge pointer in their private data and
use it for attach and sometimes other purposes. This is going to be risky
when bridge hot-unplug is used.
Considering this example scenario:
1. pipeline: encoder --> bridge A --> bridge B --> bridge C
2. encoder takes a reference to bridge B
3. bridge B takes a next_bridge reference to bridge C
4. encoder calls (bridge B)->b_foo(), which in turns references
next_bridge, e.g.:
b_foo() {
bar(b->next_bridge);
}
If bridges B and C are removed, bridge C can be freed but B is still
allocated because the encoder holds a reference to B. So when step 4
happens, 'b->next-bridge' would be a use-after-free.
Calling drm_bridge_put() in the B bridge .remove function does not solve
the problem as it leaves a (potentially long) risk window between B removal
and the final deallocation of B. A safe moment to put the B reference is in
__drm_bridge_free(), when the last reference has been put. This can be done
by drivers in the .destroy func. However to avoid the need for so many
drivers to implement a .destroy func, just offer a next_bridge pointer to
all bridges that is automatically put it in __drm_bridge_free(), exactly
when the .destroy func is called.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
