The tilcdc_panel driver was removed by commit 8f1e1ab9c7 ("drm/tilcdc:
Remove tilcdc panel driver"), but was inadvertently reintroduced by the
merge commit 8b85987d3c ("Merge drm/drm-next into drm-misc-next").
The regression went unnoticed because standard git commands such as
'git show' do not expose the change. It was only spotted via
'git show --stat':
git show --stat 8b85987d3c | grep tilcdc
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 408 +
git show 8b85987d3c | grep tilcdc
(no output)
Remove tilcdc_panel.c again to restore the previously intended state.
Fixes: 8b85987d3c ("Merge drm/drm-next into drm-misc-next")
Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260305155921.659550-1-kory.maincent@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
When drm_atomic_add_affected_planes() adds a plane to the atomic
state, the associated colorops are not guaranteed to be included.
This can leave colorop state out of the transaction when planes
are pulled in implicitly (eg. during modeset or internal commits).
Also add affected colorops when adding affected planes to keep
plane and color pipeline state consistent within the atomic
transaction.
v2: Add affected colorops only when a pipeline is enabled
Fixes: 2afc3184f3 ("drm/plane: Add COLOR PIPELINE property")
Cc: <stable@vger.kernel.org> #v6.19+
Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260310113238.3495981-3-chaitanya.kumar.borah@intel.com
__drm_atomic_helper_colorop_duplicate_state() unconditionally
sets state->bypass = true after copying the existing state.
This override causes the new atomic state to no longer reflect
the currently committed hardware state. Since the bypass property
directly controls whether the colorop is active in hardware,
resetting it to true can inadvertently disable an active colorop
during a subsequent commit, particularly for internal driver commits
where userspace does not touch the property.
Drop the unconditional assignment and preserve the duplicated
bypass value.
Fixes: 8c5ea1745f ("drm/colorop: Add BYPASS property")
Cc: <stable@vger.kernel.org> #v6.19+
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260310113238.3495981-2-chaitanya.kumar.borah@intel.com
Commit 4636ce93d5 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.
This patch uses this helper to replace our own open coded version of the
same function.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20260309165635.1138413-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Commit adefb2ccea ("drm/v3d: create a dedicated lock for dma fence")
split `fence_lock` from `queue_lock` because v3d_job_update_stats() was
taking `queue_lock` to protect `job->file_priv` during stats collection
in the IRQ handler. Using the same lock for both DMA fence signaling and
stats protection in a IRQ context caused issues on PREEMPT_RT.
Since then, the stats infrastructure has been reworked: v3d_stats is now
refcounted and jobs hold their own references to stats objects, so
v3d_job_update_stats() no longer takes `queue_lock` at all.
With the original reason for the split gone, merge `fence_lock` back
into `queue_lock` to simplify the locking scheme.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patch.msgid.link/20260306-v3d-reset-locking-improv-v3-6-49864fe00692@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
To remove the file_priv NULL-ing dance needed to check if the file
descriptor is open, move the per-fd reset counter into v3d_stats, which
is heap-allocated and refcounted, outliving the fd as long as jobs
reference it.
This change allows the removal of the last `queue_lock` usage to protect
`job->file_priv` and avoids possible NULL ptr dereference issues due to
lifetime mismatches.
Also, to simplify locking, replace both the global and per-fd locked
reset counters with atomics.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patch.msgid.link/20260306-v3d-reset-locking-improv-v3-5-49864fe00692@igalia.com
Co-developed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
The `v3d_stats` sequence counter uses regular seqcount helpers, which
carry lockdep annotations that expect a consistent IRQ context between
all writers. However, lockdep is unable to detect that v3d's readers
are never in IRQ or softirq context, and that for CPU job queues, even
the write side never is. This led to false positive that were previously
worked around by conditionally disabling local IRQs under
IS_ENABLED(CONFIG_LOCKDEP).
Switch to the raw seqcount helpers which skip lockdep tracking entirely.
This is safe because jobs are fully serialized per queue: the next job
can only be queued after the previous one has been signaled, so there is
no scope for the start and update paths to race on the same seqcount.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patch.msgid.link/20260306-v3d-reset-locking-improv-v3-2-49864fe00692@igalia.com
Co-developed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
The colorop state blob property handling had memory leaks during state
duplication, destruction, and reset operations. The implementation
failed to follow the established pattern from drm_crtc's handling of
DEGAMMA/GAMMA blob properties.
Issues fixed:
- drm_colorop_atomic_destroy_state() was freeing state memory without
releasing the blob reference, causing a leak
- drm_colorop_reset() was directly freeing old state with kfree()
instead of properly destroying it, leaking blob references
- drm_colorop_cleanup() had duplicate blob cleanup code
Changes:
- Add __drm_atomic_helper_colorop_destroy_state() helper to properly
release blob references before freeing state memory
- Update drm_colorop_atomic_destroy_state() to call the helper
- Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()
for proper cleanup of old state
- Simplify drm_colorop_cleanup() to use the common destruction path
This matches the well-tested pattern used by drm_crtc since 2016 and
ensures proper reference counting throughout the state lifecycle.
Co-developed by Claude Sonnet 4.5.
Fixes: cfc27680ee ("drm/colorop: Introduce new drm_colorop mode object")
Cc: Simon Ser <contact@emersion.fr>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Melissa Wen <mwen@igalia.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: <stable@vger.kernel.org> #v6.19+
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Link: https://patch.msgid.link/20260312204145.829714-1-harry.wentland@amd.com
Convert the driver to use the non-deprecated mipi_dsi_*_multi() helpers and
mipi_dsi_msleep().
Switch DCS command sequences to the multi context API and
accumulate errors via struct mipi_dsi_multi_context. Replace
open-coded error handling with the multi helpers and convert
nt36672a_send_cmds() and power sequencing accordingly.
This patch is intended to functionally be a no-op, though there is one
slight change. Previously a failure in regulator_bulk_disable() would
have caused nt36672a_panel_unprepare() to return an error. Now it
won't. No other errors in nt36672a_panel_unprepare() were propagated,
so this makes things consistent.
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260305044921.10942-1-chintanlike@gmail.com
The IPUv3 overlay plane may be placed over or under the primary plane.
Set the zpos of the primary to an immutable position of 1 to have the
possibility to place the other plane underneath it.
Set the zpos of other planes (the overlay plane) to a mutable value
between 0 (the lowest possible value of a zpos) and directly above the
primary plane with the latter being the default.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patch.msgid.link/20260219-drm-imx-underlay-plane-v2-2-26ef829c5483@pengutronix.de
Prefer bus format set via legacy "interface-pix-fmt" DT property
over panel bus format. This is necessary to retain support for
DTs which configure the IPUv3 parallel output as 24bit DPI, but
connect 18bit DPI panels to it with hardware swizzling.
This used to work up to Linux 6.12, but stopped working in 6.13,
reinstate the behavior to support old DTs.
Cc: stable@vger.kernel.org
Fixes: 5f6e56d331 ("drm/imx: parallel-display: switch to drm_panel_bridge")
Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patch.msgid.link/20260110171510.692666-1-marex@nabladev.com
Currently, ttm_bo_swapout is not exercised by the TTM KUnit tests.
It used to be exercised until commit 76689eb526 ("drm/ttm: remove
ttm_bo_validate_swapout test"), but that test was removed as it was
unreliable due to requiring to allocate half of the system memory.
Calling ttm_bo_swapout directly with a single allocated BO, however, does
not suffer from that problem, and was able to detect a UAF introduced by
commit c06da4b357 ("drm/ttm: Tidy usage of local variables a little
bit"), when built with KASAN.
When applying a fix to that UAF, the test passed without any issues.
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: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260309-ttm_bo_swapout_test-v2-1-219f64046cfe@igalia.com
Requested by Maxime Ripard for drm-misc-next because renesas people need
fb797a7010 ("drm: renesas: rz-du: mipi_dsi: Set DSI divider").
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
On successful vmap, set the page_mark_accessed_on_put and _dirty_on_put
flags in the gem-shmem object. Signals that the contained pages require
LRU and dirty tracking when they are being released back to SHMEM. Clear
these flags on put, so that the buffer remains quiet until the next call
to vmap. There's no means of handling dirty status in vmap as there's no
write-only mapping available.
Both flags, _accessed_on_put and _dirty_on_put, have always been part of
the gem-shmem object, but never used much. So most drivers did not track
the page status correctly.
Only the v3d and imagination drivers make limited use of _dirty_on_put. In
the case of imagination, move the flag setting from init to cleanup. This
ensures writeback of modified pages but does not interfere with the
internal vmap/vunmap calls. V3d already implements this behaviour.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> # gem-shmem
Acked-by: Frank Binns <frank.binns@imgtec.com> # imagination
Tested-by: Frank Binns <frank.binns@imgtec.com> # imagination
Link: https://patch.msgid.link/20260227114509.165572-7-tzimmermann@suse.de
Invoke folio_mark_accessed() in mmap page faults to add the folio to
the memory manager's LRU list. Userspace invokes mmap to get the memory
for software rendering. Compositors do the same when creating the final
on-screen image, so keeping the pages in LRU makes sense. Avoids paging
out graphics buffers when under memory pressure.
In pfn_mkwrite, further invoke the folio_mark_dirty() to add the folio
for writeback should the underlying file be paged out from system memory.
This rarely happens in practice, yet it would corrupt the buffer content.
This has little effect on a system's hardware-accelerated rendering, which
only mmaps for an initial setup of textures, meshes, shaders, etc.
v4:
- test for VM_FAULT_NOPAGE before marking folio as accessed (Boris)
- test page-array bounds in mkwrite handler (Boris)
v3:
- rewrite for VM_PFNMAP
v2:
- adapt to changes in drm_gem_shmem_try_mmap_pmd()
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-6-tzimmermann@suse.de
The current mmap page-fault handler requires some changes before it
can track folio access.
Call to folio_test_pmd_mappable() into the mmap page-fault handler
before calling drm_gem_shmem_try_map_pmd(). The folio will become
useful for tracking the access status.
Also rename drm_gem_shmem_try_map_pmd() to _try_insert_pfn_pmd()
and only pass the page fault and page-frame number. The new name and
parameters make it similar to vmf_insert_pfn_pmd().
No functional changes. If PMD mapping fails or is not supported,
insert a regular PFN as before.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-5-tzimmermann@suse.de
Return the exact VM_FAULT_ mask from drm_gem_shmem_try_map_pmd(). Gives
the caller better insight into the result. Return 0 if nothing was done.
If the caller sees VM_FAULT_NOPAGE, drm_gem_shmem_try_map_pmd() added a
PMD entry to the page table. As before, return early from the page-fault
handler in that case.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-4-tzimmermann@suse.de
During initial checks the ANX7625 bridge can be powered on before
setting up the Type-C port. At this point, when
anx7625_ocm_loading_check() checks if it can disable PD or not, it will
notice that typec_port is not set and disable PD, breaking orientation
and HPD handling. Unify the check between anx7625_ocm_loading_check()
anx7625_i2c_probe() and anx7625_typec_register() and check for the
presence of the "connector" node.
Fixes: 8ad0f7d2e6 ("drm: bridge: anx7625: implement message sending")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Xin Ji <xji@analogixsemi.com>
Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260211-anx7625-fix-pd-v1-1-1dd31451b06f@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The typec_set_*() functions do not tolerate being passed the NULL
typec_port instance. However, if CONFIG_TYPEC is enabled, but anx7625
DT node doesn't have the usb-c connector fwnode, then typec_port remains
NULL, crashing the kernel. Prevent calling typec_set_foo() functions by
checking that ctx->typec_port is not NULL in anx7625_typec_set_status().
Call trace:
typec_set_orientation+0x18/0x68 (P)
anx7625_typec_set_status+0x108/0x13c
anx7625_work_func+0x124/0x438
process_one_work+0x214/0x648
worker_thread+0x1b4/0x358
kthread+0x14c/0x214
ret_from_fork+0x10/0x20
Code: 910003fd a90153f3 aa0003f3 2a0103f4 (f9431400)
Fixes: f81455b2d3 ("drm: bridge: anx7625: implement minimal Type-C support")
Reported-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
[db: dropped chunk anx7625_typec_unregister(), wrote commit message]
Cc: Amit Kucheria <akucheri@qti.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260215-anx-fix-no-typec-v1-1-75172a5ca88b@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
When CONFIG_TYPEC is enabled, but USB_ROLE_SWITCH=m, the anx7625 driver
fails to link as built-in:
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_remove':
anx7625.c:(.text+0x6ec): undefined reference to `usb_role_switch_put'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_typec_set_status':
anx7625.c:(.text+0x3080): undefined reference to `usb_role_switch_set_role'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_probe':
anx7625.c:(.text+0x5368): undefined reference to `fwnode_usb_role_switch_get'
The problem is that both dependencies are optional in the sense of allowing
the anx7625 driver to call the exported interfaces to be used from a loadable
module, but cannot work for built-in drivers. It would be possible to handle
all nine combinations of the CONFIG_TYPEC and CONFIG_USB_ROLE_SWITCH tristate
options, but that does add a lot of complexity that seems unnecessary when
in reality any user of this driver would have both enabled anyway.
Turn both dependencies into hard 'depends on' here to only allow configurations
where it's possible to actually use them, and remove the misguided IS_REACHABLE()
check that did nothing here.
Fixes: f81455b2d3 ("drm: bridge: anx7625: implement minimal Type-C support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260304083604.724519-1-arnd@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
