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>
drm/i915/display: Add i915 hook for format_mod_supported_async
Hook up the newly added plane function pointer
format_mod_supported_async to populate the modifiers/formats supported
by asynchronous flips.
v5: Correct the if condition for modifier support check (Chaitanya)
v6: Replace uint32_t/uint64_t with u32/u64 (Jani)
v7: Move plannar check from intel_async_flip_check_hw() to
intel_plane_format_mod_supported_async() (Ville)
v8: In case of error print format/modifier (Chaitanya)
v9: Exclude C8 format as its not supported by hardware
v10: filter only planar formats
move changes in can_async_flip to new patch (Ville)
drm/i915/display: Acomodate format check in intel_plane_can_async_flip()
The function intel_plane_can_async_flip() checks for async supported
modifier, add format support check also in the same function.
Note: on ADL the surface base addr is required to be 16k aligned and if
not might generate DMAR and GGTT faults leading to glitches. This patch
changes the 16k alignment to 4k for planar formats.
v11: Move filtering Indexed 8bit to a separate patch (Ville)
v12: correct the commit msg and remove unwanted debug print (Ville)
drm/plane: modify create_in_formats to acommodate async
create_in_formats creates the list of supported format/modifiers for
synchronous flips, modify the same function so as to take the
format_mod_supported as argument and create list of format/modifier for
async as well.
v5: create_in_formats can return -ve value in failure case, correct the
if condition to check the creation of blob <Chaitanya>
Dont add the modifier for which none of the formats is not supported.
v6: Remove the code for masking the unsupported modifiers as UMD can
leave with it. (Naveen/Chaitanya)
v7: Retain the unsupported modifiers, userspace should have no
impact, return pointer to blob instead of blob_id(Ville)
drm/plane: Add new plane property IN_FORMATS_ASYNC
There exists a property IN_FORMATS which exposes the plane supported
modifiers/formats to the user. In some platforms when asynchronous flip
are used all of modifiers/formats mentioned in IN_FORMATS are not
supported. This patch adds a new plane property IN_FORMATS_ASYNC to
expose the async flip supported modifiers/formats so that user can use
this information ahead and do flip with unsupported
formats/modifiers. This will save flip failures.
Add a new function pointer similar to format_mod_supported specifically
for asynchronous flip.
v2: Remove async variable from drm_plane (Ville)
v3: Add new function pointer for async (Ville)
v5: Typo corrected in commit message & some correction in the kernel
documentation. (Chaitanya)
v7: Place IN_FORMATS_ASYNC next to IN_FORMATS (Ville)
v8: replace uint32_t with u32 and uint64_t with u64 (Chaitanya)
Philipp Stanner [Thu, 17 Apr 2025 09:40:10 +0000 (11:40 +0200)]
drm/cirrus: Use non-hybrid PCI devres API
cirrus 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.
Replace the call to sometimes-managed pci_request_regions() with one to
the always-managed pcim_request_all_regions().
Lizhi Hou [Wed, 7 May 2025 16:15:00 +0000 (09:15 -0700)]
accel/amdxdna: Support submit commands without arguments
The latest userspace runtime allows generating commands which do not
have any argument. Remove the corresponding check in driver IOCTL to
enable this use case.
Add bindings for the Novatek NT37801 or NT37810 AMOLED DSI panel.
Sources, like downstream DTS, schematics and hardware manuals, use two
model names (NT37801 and NT37810), so choose one and hope it is correct.
Neil Armstrong [Wed, 7 May 2025 09:19:21 +0000 (11:19 +0200)]
dt-bindings: display: panel: convert truly,nt35597.txt to dt-schema
Convert the Truly NT35597 2K display panel bindings to dt-schema.
The vdispp-supply & vdispn-supply are not marked as required since
in practice they are not defined in sdm845-mtp.dts which is the
only used of these bindings.
sync_file_debug_add() and sync_file_debug_remove() have been unused
since 2016's
commit d4cab38e153d ("staging/android: prepare sync_file for de-staging")
Remove them.
Since sync_file_debug_add was the only thing to add to
sync_file_list_head, the code that dumps it in part of
sync_info_debugfs_show can be removed, and the declaration of
the list and it's associated lock can be removed.
(The 'fences:\n...' marker in that debugfs file is left in
so as not to change the output)
That leaves the sync_print_sync_file() helper unused, and
is thus removed.
Qiu-ji Chen [Wed, 6 Nov 2024 09:59:06 +0000 (17:59 +0800)]
drm/tegra: Fix a possible null pointer dereference
In tegra_crtc_reset(), new memory is allocated with kzalloc(), but
no check is performed. Before calling __drm_atomic_helper_crtc_reset,
state should be checked to prevent possible null pointer dereference.
Fixes: b7e0b04ae450 ("drm/tegra: Convert to using __drm_atomic_helper_crtc_reset() for reset.") Cc: stable@vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20241106095906.15247-1-chenqiuji666@gmail.com
projects / thirdparty / kernel / linux.git / log
