Luca Ceresoli [Fri, 9 May 2025 13:53:44 +0000 (15:53 +0200)]
drm/bridge: imx8qxp-pixel-combiner: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
This driver embeds an array of channels in the main struct, and each
channel embeds a drm_bridge. This prevents dynamic, refcount-based
deallocation of the bridges.
To make the new, dynamic bridge allocation possible:
* change the array of channels into an array of channel pointers
* allocate each channel using devm_drm_bridge_alloc()
* adapt the code wherever using the channels
* remove the is_available flag, now "ch != NULL" is equivalent
When moving the Sitronix DRM drivers and renaming their Kconfig symbols,
the old symbols were kept, aiming to provide a seamless migration path
when running "make olddefconfig" or "make oldconfig".
However, the old compatibility symbols are not visible. Hence unless
they are selected by another symbol (which they are not), they can never
be enabled, and no backwards compatibility is provided.
drm/vesadrm: Use helpers for programming gamma ramps
Replace vesadrm's code for programming the hardware gamma LUT with
DRM helpers. Either load a provided gamma ramp or program a default.
Set the individual entries with a callback.
Each gamma value is given as 3 individual 16-bit values for red,
green and blue. The driver reduces them to 8 bit to make them fit
into hardware registers.
drm/ofdrm: Use helpers for programming gamma ramps
Replace ofdrm's code for programming the hardware gamma LUT with
DRM helpers. Either load a provided gamma ramp or program a default.
Set the individual entries with a callback.
Each gamma value is given as 3 individual 16-bit values for red,
green and blue. The driver reduces them to 8 bit to make them fit
into hardware registers.
drm/mgag200: Use helpers for programming gamma ramps
Replace mgag200's code for programming the hardware gamma LUT with
DRM helpers. Either load a provided gamma ramp or program a default.
Set the individual entries with a callback.
Each gamma value is given as 3 individual 16-bit values for red,
green and blue. The driver reduces them to 8 bit to make them fit
into hardware registers.
drm/ast: Use helpers for programming gamma ramps and palettes
Replace ast's code for programming the hardware gamma/palette LUT
with DRM helpers. Either load provided data or program a default.
Set the individual entries with a callback.
Each gamma/palette value is given as 3 individual 16-bit values
for red, green and blue. The driver reduces them to 8 bit to make
them fit into hardware registers.
drm: Add helpers for programming hardware gamma LUTs
Provide helpers that program hardware gamma LUTs. Tha gamma ramp is
either provided by the driver or generated by the helper.
The DRM driver exports the GAMMA_LUT property with a fixed number of
entries per color component, such as 256 on 8-bit-wide components. The
entries describe the gamma ramp of each individual component. The new
helper drm_crtc_load_gamma_888() loads such gamma ramp to hardware. The
hardware uses each displayed pixel's individial components as indices
into the hardware gamma table.
For color modes with less than 8 bits per color component, the helpers
drm_crtc_load_gamma_565_from() and drm_crtc_load_gamma_555_from_888()
interpolate the provided gamma ramp to reduce it to the correct number
of entries; 5/6/5 for RGB565-like formats and 5/5/5 for XRGB1555-like
formats.
If no gamma ramp has been provided, drivers can use the new helper
drm_crtc_fill_gamma_888() to load a default gamma ramp with 256 entries
per color component. For color modes with less bits, the new helpers
drm_crtc_fill_gamma_565() and drm_crtc_fill_gamma_555() are available.
The default gamma ramp uses a gamma factor of 1.
For color modes with palette, drm_crtc_load_palette_8() load an 8-bit
palette into the hardware. If no palette has been specified,
drm_crtc_fill_palette_8() load a system-specific default palette. This
is currently only a grey-scale palette with increasing luminance, but
later patches can change this. For PCs, a VGA default palette could
be used.
v2:
- drop comment on gamma factor of 2.2 (Michel, Pekka)
- fix typos in commit description (Javier)
Lad Prabhakar [Mon, 12 May 2025 18:23:20 +0000 (19:23 +0100)]
drm: renesas: rz-du: Add support for RZ/V2H(P) SoC
The LCD controller (LCDC) on the RZ/V2H(P) SoC is composed of Frame
Compression Processor (FCPVD), Video Signal Processor (VSPD), and
Display Unit (DU).
There is one LCDC unit available on the RZ/V2H(P) SoC which is connected
to the DSI.
Lad Prabhakar [Mon, 12 May 2025 18:23:19 +0000 (19:23 +0100)]
dt-bindings: display: renesas,rzg2l-du: Add support for RZ/V2H(P) SoC
The DU block on the RZ/V2H(P) SoC is identical to the one found on the
RZ/G2L SoC. However, it only supports the DSI interface, whereas the
RZ/G2L supports both DSI and DPI interfaces.
Due to this difference, a SoC-specific compatible string
'renesas,r9a09g057-du' is added for the RZ/V2H(P) SoC.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250512182330.238259-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Chris Brandt [Wed, 21 May 2025 21:03:35 +0000 (17:03 -0400)]
drm: renesas: rz-du: Add atomic_pre_enable
When drm_panel.prepare_prev_first is set to true in a panel driver, the
panel expects the MIPI DSI hardware to be already configured before the
panel's prepare function is called because it might need to send DCS
commands.
Luca Ceresoli [Fri, 9 May 2025 13:53:48 +0000 (15:53 +0200)]
drm/todo: add entry to remove devm_drm_put_bridge()
devm_drm_put_bridge() is a temporary workaround waiting for the panel
bridge lifetime rework. Add a TODO entry to not forget it must be removed
after such rework.
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().
projects / thirdparty / kernel / linux.git / log
