Luca Ceresoli [Fri, 9 May 2025 13:53:28 +0000 (15:53 +0200)]
drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
For many drivers having a simple code flow in the probe function, this
commit does a mass conversion automatically with the following semantic
patch. The changes have been reviewed manually for correctness as well as
to find any false positives.
The patch has been applied with the explicit exclusion of bridge/panel.c,
handled by a separate patch.
After applying the semantic patch, manually fixed these issues:
- 4 drivers need ERR_CAST() instead of PTR_ERR() as the function calling
devm_drm_bridge_alloc() returns a pointer
- re-added empty lines and comments that the script had removed but that
should stay
Luca Ceresoli [Fri, 9 May 2025 13:53:47 +0000 (15:53 +0200)]
drm/bridge: panel: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
The devm lifetime management of this driver is peculiar. The underlying
device for the panel_bridge is the panel, and the devm lifetime is tied the
panel device (panel->dev). However the panel_bridge allocation is not
performed by the panel driver, but rather by a separate entity (typically
the previous bridge in the encoder chain).
Thus when that separate entity is destroyed, the panel_bridge is not
removed automatically by devm, so it is rather done explicitly by calling
drm_panel_bridge_remove(). This is the function that does devm_kfree() the
panel_bridge in current code, so update it as well to put the bridge
reference instead.
This is a temporary solution until the panel lifetime is reworked, which
should make this workaround unnecessary, so add a comment to clarify that.
Luca Ceresoli [Fri, 9 May 2025 13:53:46 +0000 (15:53 +0200)]
drm/bridge: add devm_drm_put_bridge()
Bridges obtained via devm_drm_bridge_alloc(dev, ...) will be put when the
requesting device (@dev) is removed.
However drivers which obtained them may need to put the obtained reference
explicitly. One such case is if they bind the devm removal action to a
different device than the one implemented by the driver itself and which
might be removed at a different time, such as bridge/panel.c.
Add devm_drm_put_bridge() to manually release a devm-obtained bridge in
such cases.
This function is considered only a temporary workaround until the panel
bridge is reworked and should be removed afterwards.
Luca Ceresoli [Fri, 9 May 2025 13:53:43 +0000 (15:53 +0200)]
drm: zynqmp_dp: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
This driver has a peculiar structure. zynqmp_dpsub.c is the actual driver,
which delegates to a submodule (zynqmp_dp.c) the allocation of a
sub-structure embedding the drm_bridge and its initialization, however it
does not delegate the drm_bridge_add(). Hence, following carefully the code
flow, it is correct to change the allocation function and .funcs assignment
in the submodule, while the drm_bridge_add() is not in that submodule.
Luca Ceresoli [Fri, 9 May 2025 13:53:42 +0000 (15:53 +0200)]
drm/sti: dvo: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
This driver allocates the DRM bridge separately from the main driver
private struct, which prevents using the new devm_drm_bridge_alloc()
API. Simplify the code by replacing the struct drm_bridge pointer with an
embedded struct drm_bridge inside the private struct, to make use of the
new API with the same code flow.
Luca Ceresoli [Fri, 9 May 2025 13:53:39 +0000 (15:53 +0200)]
drm/omap: dss: venc: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
Switching from a non-devm to a devm allocation allows removing the kfree()
in the remove function and in the probe error management code, and as a
consequence to simplify the code flow by removing now unnecessary gotos.
Luca Ceresoli [Fri, 9 May 2025 13:53:38 +0000 (15:53 +0200)]
drm/omap: dss: sdi: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
Switching from a non-devm to a devm allocation allows removing the kfree()
in the remove function and in the probe error management code, and as a
consequence to simplify the code flow by removing now unnecessary gotos.
Luca Ceresoli [Fri, 9 May 2025 13:53:37 +0000 (15:53 +0200)]
drm/omap: dss: hdmi5: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
Switching from a non-devm to a devm allocation allows removing the kfree()
in the remove function and in the probe error management code, and as a
consequence to simplify the code flow by removing now unnecessary gotos.
Luca Ceresoli [Fri, 9 May 2025 13:53:36 +0000 (15:53 +0200)]
drm/omap: dss: hdmi4: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
Switching from a non-devm to a devm allocation allows removing the kfree()
in the remove function and in the probe error management code, and as a
consequence to simplify the code flow by removing now unnecessary gotos.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:46 +0000 (04:59 +0300)]
drm/bridge: adv7511: switch to the HDMI connector helpers
Rewrite the ADV7511 driver to use implementation provided by the DRM
HDMI connector framework, including the Audio and CEC bits. Drop the
in-bridge connector support and use drm_bridge_connector if the host
requires the connector to be provided by the bridge.
Note: currently only AVI InfoFrames are supported. Existing driver
doesn't support programming any other InfoFrames directly and Audio
InfoFrame seems to be programmed using individual bits and pieces rather
than programming it directly.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:44 +0000 (04:59 +0300)]
drm/display: bridge-connector: hook in CEC notifier support
Allow HDMI DRM bridges to create CEC notifier. Physical address is
handled automatically by drm_atomic_helper_connector_hdmi_hotplug()
being called from .detect() path.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:41 +0000 (04:59 +0300)]
drm/display: add CEC helpers code
Add generic CEC helpers to be used by HDMI drivers. Both notifier and
and adapter are supported for registration. Once registered, the driver
can call common set of functions to update physical address, to
invalidate it or to unregister CEC data. Unlike drm_connector_cec_funcs
(which provides interface common to all implementations, including, but
not limited to the CEC adapter, CEC notifier, CEC pin-based adapter,
etc) the struct drm_connector_hdmi_cec_adapter_ops provides callbacks
specific to the CEC adapter implementations.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:40 +0000 (04:59 +0300)]
drm/display: move CEC_CORE selection to DRM_DISPLAY_HELPER
THe Kconfig symbol DRM_DISPLAY_DP_AUX_CEC is a boolean which simply
toggles whether DP_AUX_CEC support should be built into the
drm_display_helper (which can be eithera module or built-in into the
kernel). If DRM_DISPLAY_DP_AUX_CEC is selected, then CEC_CORE is
selected to be built-in into the kernel even if DRM_DISPLAY_HELPER is
selected to be built as a module. Move CEC_CORE selection to the latter
symbol in order to allow it to be built as a module.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:39 +0000 (04:59 +0300)]
drm/connector: add CEC-related fields
As a preparation to adding HDMI CEC helper code, add CEC-related fields
to the struct drm_connector. The callbacks abstract CEC infrastructure
in order to support CEC adapters and CEC notifiers in a universal way.
CEC data is a void pointer as it allows us to make CEC data
helper-specific. For example, currently it will be either cec_notifier
or cec_adapter + drm_connector_hdmi_cec_funcs. Later cec-pin might store
platform callbacks here. DP CEC might need to store AUX pointer, etc.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:38 +0000 (04:59 +0300)]
drm/bridge: allow limiting I2S formats
By default HDMI codec registers all formats supported on the I2S bus.
Allow bridges (and connectors) to limit the list of the PCM formats
supported by the HDMI codec.
Dmitry Baryshkov [Sat, 17 May 2025 01:59:37 +0000 (04:59 +0300)]
drm/bridge: move private data to the end of the struct
WHen adding HDMI fields I didn't notice the private: declaration for HPD
fields. Move private fields to the end of the struct drm_bride to have
clear distinction between private and public fields.
Devarsh Thakkar [Wed, 7 May 2025 18:06:31 +0000 (23:36 +0530)]
drm/tidss: Add support for AM62L display subsystem
Enable display for AM62L DSS [1] which supports only a single display
pipeline using a single overlay manager, single video port and a single
video lite pipeline which does not support scaling.
The output of video port is routed to SoC boundary via DPI interface and
the DPI signals from the video port are also routed to DSI Tx controller
present within the SoC.
[1]: Section 11.7 (Display Subsystem and Peripherals)
Link : https://www.ti.com/lit/pdf/sprujb4
Devarsh Thakkar [Wed, 7 May 2025 18:06:30 +0000 (23:36 +0530)]
drm/tidss: Update infrastructure to support K3 DSS cut-down versions
SoCs like AM62Lx support cut-down version of K3 DSS where although same
register space is supported as in other K3 DSS supported SoCs such as
AM65x, AM62x, AM62Ax but some of the resources such as planes and
corresponding register spaces are truncated.
For e.g. AM62Lx has only single VIDL pipeline supported, so corresponding
register spaces for other video pipelines need to be skipped.
To add a generic support for future SoCs where one or more video pipelines
can get truncated from the parent register space, move the video plane
related information to vid_info struct which will also have a field to
indicate hardware index of each of the available video planes, so that
driver only maps and programs those video pipes and skips the unavailable
ones.
While at it, also change the num_planes field in the features structure to
num_vid so that all places in code which use vid_info structure are
highlighted in the code.
Devarsh Thakkar [Wed, 7 May 2025 18:06:29 +0000 (23:36 +0530)]
dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS
The DSS controller on TI's AM62L SoC is an update from that on TI's
AM625/AM65x/AM62A7 SoC. The AM62L DSS [1] only supports a single display
pipeline using a single overlay manager, single video port and a single
video lite pipeline which does not support scaling.
The output of video port is routed to SoC boundary via DPI interface and
the DPI signals from the video port are also routed to DSI Tx controller
present within the SoC.
[1]: Section 11.7 (Display Subsystem and Peripherals)
Link : https://www.ti.com/lit/pdf/sprujb4
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250507180631.874930-2-devarsht@ti.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Dan Carpenter [Wed, 30 Apr 2025 08:06:32 +0000 (11:06 +0300)]
drm/nouveau/fifo: small cleanup in nvkm_chan_cctx_get()
"&chan->cgrp->mutex" and "&cgrp->mutex" are the same thing. Use
"&cgrp->mutex" consistently. It looks nicer and it silences a
Smatch static checker warning.
Philipp Stanner [Thu, 24 Apr 2025 13:02:54 +0000 (15:02 +0200)]
drm/nouveau: Check dma_fence in canonical way
In nouveau_fence_done(), a fence is checked for being signaled by
manually evaluating the base fence's bits. This can be done in a
canonical manner through dma_fence_is_signaled().
Replace the bit-check with dma_fence_is_signaled().
Philipp Stanner [Thu, 24 Apr 2025 13:02:53 +0000 (15:02 +0200)]
drm/nouveau: Simplify nouveau_fence_done()
nouveau_fence_done() contains an if branch that checks whether a
nouveau_fence has either of the two existing nouveau_fence backend ops,
which will always evaluate to true.
Philipp Stanner [Thu, 24 Apr 2025 13:02:51 +0000 (15:02 +0200)]
drm/nouveau: nouveau_fence: Standardize list iterations
nouveau_fence.c iterates over lists in a non-canonical way. Since the
operations done are just basic for-each-loops and list-empty checks,
they should be written in the standard form.
We cannot use vmap_pfn() in vmap_udmabuf() as it would fail the pfn_valid()
check in vmap_pfn_apply(). This is because vmap_pfn() is intended to be
used for mapping non-struct-page memory such as PCIe BARs. Since, udmabuf
mostly works with pages/folios backed by shmem/hugetlbfs/THP, vmap_pfn()
is not the right tool or API to invoke for implementing vmap.
Tvrtko Ursulin [Thu, 15 May 2025 09:49:56 +0000 (10:49 +0100)]
dma-fence: Change signature of __dma_fence_is_later
With the goal of reducing the need for drivers to touch (and dereference)
fence->ops, we change the prototype of __dma_fence_is_later() to take
fence instead of fence->ops.
drm/hyperv: Replace simple-KMS with regular atomic helpers
Drop simple-KMS in favor of regular atomic helpers to make the code more
modular. The simple-KMS helper mix up plane and CRTC state, so it is
obsolete and should go away [1]. Since it just split the simple-pipe
functions into per-plane and per-CRTC, no functional changes is
expected.
Philipp Stanner [Wed, 14 May 2025 07:31:27 +0000 (09:31 +0200)]
drm/vmwgfx: Use non-hybrid PCI devres API
vmwgfx enables its PCI device with pcim_enable_device(). This,
implicitly, switches the function pci_request_regions() into managed
mode, where it becomes a devres function.
The PCI subsystem wants to remove this hybrid nature from its
interfaces. To do so, users of the aforementioned combination of
functions must be ported to non-hybrid functions.
Moreover, since both functions are already managed in this driver, the
calls to pci_release_regions() are unnecessary.
Remove the calls to pci_release_regions().
Replace the call to sometimes-managed pci_request_regions() with one to
always-managed pcim_request_all_regions().
Liu Ying [Mon, 14 Apr 2025 03:50:21 +0000 (11:50 +0800)]
drm/imx: Add i.MX8qxp Display Controller KMS
i.MX8qxp Display Controller(DC) is comprised of three main components that
include a blit engine for 2D graphics accelerations, display controller for
display output processing, as well as a command sequencer. Add kernel
mode setting support for the display controller part with two CRTCs and
two primary planes(backed by FetchLayer and FetchWarp respectively). The
registers of the display controller are accessed without command sequencer
involved, instead just by using CPU. The command sequencer is supposed to
be used by the blit engine.
i.MX8qxp Display Controller pixel engine consists of all processing
units that operate in the AXI bus clock domain. Add drivers for
ConstFrame, ExtDst, FetchLayer, FetchWarp and LayerBlend units, as
well as a pixel engine driver, so that two displays with primary
planes can be supported. The pixel engine driver and those unit
drivers are components to be aggregated by a master registered in
the upcoming DRM driver.
i.MX8qxp Display Controller display engine consists of all processing
units that operate in a display clock domain. Add minimal feature
support with FrameGen and TCon so that the engine can output display
timings. The FrameGen driver, TCon driver and display engine driver
are components to be aggregated by a master registered in the upcoming
DRM driver.
i.MX8qxp Display Controller(DC) is comprised of three main components that
include a blit engine for 2D graphics accelerations, display controller for
display output processing, as well as a command sequencer.
i.MX8qxp Display Controller pixel engine consists of all processing units
that operate in the AXI bus clock domain. Command sequencer and interrupt
controller of the Display Controller work with AXI bus clock, but they are
not in pixel engine.
i.MX8qxp Display Controller contains a blit engine for raster graphics.
It may read up to 3 source images from memory and computes one destination
image from it, which is written back to memory.
Liu Ying [Mon, 14 Apr 2025 03:50:10 +0000 (11:50 +0800)]
dt-bindings: display: imx: Add i.MX8qxp Display Controller processing units
Freescale i.MX8qxp Display Controller is implemented as construction set of
building blocks with unified concept and standardized interfaces. Document
all existing processing units.
hienhuynh [Thu, 8 May 2025 09:50:35 +0000 (10:50 +0100)]
drm: rz-du: Support panels connected directly to the DPAD output
This patch is based on the commit 73eb5476df72 ("drm: rcar-du: Support
panels connected directly to the DPAD outputs").
The RZ DU driver assumes that a bridge is always connected to the DU
output. This is valid for the HDMI output, but the DPAD output can be
connected directly to a panel, in which case no bridge is available.
To support this use case, detect whether the entities connected to the DU
DPAD output is encoders or panels based on the number of ports of their DT
node, and retrieve the corresponding type of DRM objects. For panels,
additionally create panel bridge instances.
Asahi Lina [Tue, 18 Mar 2025 19:22:35 +0000 (16:22 -0300)]
drm/shmem-helper: Add lockdep asserts to vmap/vunmap
Since commit 21aa27ddc582 ("drm/shmem-helper: Switch to reservation
lock"), the drm_gem_shmem_vmap and drm_gem_shmem_vunmap functions
require that the caller holds the DMA reservation lock for the object.
Add lockdep assertions to help validate this.
Philipp Stanner [Fri, 14 Mar 2025 10:10:24 +0000 (11:10 +0100)]
drm/sched: Remove kthread header
The kthread header doesn't need to be included anymore. It's a relict
from commit a6149f039369 ("drm/sched: Convert drm scheduler to use a
work queue rather than kthread").
The GPU scheduler's comments refer to a "thread" at various places.
Those are leftovers from commit a6149f039369 ("drm/sched: Convert drm
scheduler to use a work queue rather than kthread").
Vivek Kasireddy [Thu, 1 May 2025 23:24:19 +0000 (16:24 -0700)]
drm/virtio: Fix NULL pointer deref in virtgpu_dma_buf_free_obj()
There is a chance that obj->dma_buf would be NULL by the time
virtgpu_dma_buf_free_obj() is called. This can happen for imported
prime objects, when drm_gem_object_exported_dma_buf_free() gets
called on them before drm_gem_object_free(). This is because
drm_gem_object_exported_dma_buf_free() explicitly sets
obj->dma_buf to NULL.
Therefore, fix this issue by storing the dma_buf pointer in the
virtio_gpu_object instance and using it in virtgpu_dma_buf_free_obj.
This stored pointer is guaranteed to be valid until the object is
freed as we took a reference on it in virtgpu_gem_prime_import().
Marcus Folkesson [Mon, 12 May 2025 07:15:11 +0000 (09:15 +0200)]
drm/sitronix: move tiny Sitronix drivers to their own subdir
We start to have support many Sitronix displays in the tiny directory,
and we expect more to come.
Move them to their own subdirectory.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250512-sitronix-v3-1-bbf6cc413698@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
projects / thirdparty / kernel / linux.git / log
