summaryrefslogtreecommitdiff
path: root/include/drm
AgeCommit message (Collapse)AuthorFilesLines
2026-06-24drm/dp: Add DP_DSC_MAX_BPP_DELTA registerNemesa Garg1-1/+3
The dsc max bpp delta masks were incorrectly placed under the DP_DSC_BITS_PER_PIXEL_INC(0x06F) register. Move these under correct DP_DSC_MAX_BPP_DELTA(0x06E) register. v2: Separate patch for correcting register. [Ankit] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260623094236.1586318-2-nemesa.garg@intel.com
2026-06-23drm/{i915, xe}/panic: drop dependency on struct intel_framebufferJani Nikula1-1/+2
Store tiling function pointer in struct intel_panic instead of struct intel_framebuffer, and store struct intel_panic pointer instead of struct intel_framebuffer pointer in struct drm_scanout_buffer private member. To make this happen, pass the tiling function pointer to panic setup hook, and initialize sb->private in the hook for clarity. This allows us to drop the dependency on struct intel_framebuffer from i915 and xe panic code. Note: It would be less verbose to have a typedef for the tiling function pointer. However, there isn't a nice location for it that wouldn't also increase header interdependencies. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/d97abae79db3437c617cd4cb6193ba017b3a8d78.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/{i915,xe}/panic: pass obj to panic setupJani Nikula1-1/+2
Start reducing i915 and xe core dependency on struct intel_framebuffer by passing the fb obj from display. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/840c4ccaced5f1c82277285938287776c8cdf513.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-22drm/bridge: Remove atomic_reset supportMaxime Ripard1-29/+1
There are no remaining users of the atomic_reset hook. Remove it from the core. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-78-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-06-22drm/atomic-state-helper: Remove drm_atomic_helper_bridge_reset()Maxime Ripard1-2/+0
All drivers have been converted to the atomic_create_state callback and its drm_atomic_helper_bridge_create_state() helper. Remove the deprecated drm_atomic_helper_bridge_reset(). Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-74-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-06-22drm/atomic-state-helper: Add drm_atomic_helper_bridge_create_state()Maxime Ripard1-0/+2
The drm_atomic_helper_bridge_reset() helper is deprecated in favour of the new atomic_create_state callback. Add drm_atomic_helper_bridge_create_state() as the counterpart helper for this new callback, and make drm_atomic_helper_bridge_reset() call this new helper. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-7-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-06-22drm/bridge: Add new atomic_create_state callbackMaxime Ripard1-1/+18
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states: atomic_create_state, a dedicated hook that allocates and initializes a pristine state without any side effect. The bridge atomic_reset callback is already fallible and in practice only allocates and initializes state without touching hardware. However, the reset name does not make this contract clear: callers and implementers cannot tell from the name alone whether the hardware will be affected or when the hook is safe to call. Add an atomic_create_state callback to drm_bridge_funcs to make the contract explicit: allocate a pristine state, initialize it, no side effects. The core calls it when available, falling back to atomic_reset otherwise. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-6-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-06-22drm/atomic-state-helper: Reorder __drm_atomic_helper_bridge_state_init() ↵Maxime Ripard1-2/+2
arguments The convention for state init helpers is to pass the state pointer as the first argument and the object pointer second. __drm_atomic_helper_bridge_state_init() has them in the opposite order. Swap the arguments to follow the convention, and update the cdns-mhdp8546 caller. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-4-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-06-22drm/atomic-state-helper: Rename __drm_atomic_helper_bridge_reset()Maxime Ripard1-1/+1
__drm_atomic_helper_bridge_reset() is used to initialize a newly allocated drm_bridge_state, and is being typically called by the drm_bridge_funcs.atomic_reset implementation. Since we want to consolidate DRM objects state allocation around the atomic_create_state callback that will only allocate and initialize a new drm_bridge_state instance, we will need to call __drm_atomic_helper_bridge_reset() from both the atomic_reset and atomic_create_state hooks. To avoid any confusion, we can thus rename __drm_atomic_helper_bridge_reset() to __drm_atomic_helper_bridge_state_init(). Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-3-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-06-17Merge tag 'drm-next-2026-06-17' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds43-351/+1090
Pull drm updates from Dave Airlie: "Highlights: - xe: add initial CRI platform support - amdgpu: initial HDMI 2.1 FRL support - rust: add some new type concepts for device lifetimes - scheduler: moves to a fair algorithm and lots of cleanups But it's mostly the usual mountain of changes across the board. core: - add docbook for DRM_IOCTL_SYNCOBJ_EVENTFD - change signature of drm_connector_attach_hdr_output_metadata_property - dedup counter and timestamp retrieval in vblank code - parse AMD VSDB v3 in CTA extension blocks - add P230, Y7, XYYY2101010, T430, XVUY210101010 formats - don't call drop master on file close if not master - use drm_printf_indent in atomic / bridge - fix 32b format descriptions - docs: fix toctree - hdmi: add common TMDS character rates - fix drm_syncobj_find_fence leak rust: - introduce Higher-Ranked lifetime types - replace drvdata with scoped registration data - add GPUVM immediate mode abstraction for rust GPU drivers - introduce DeviceContext type state for drm::Device bridge: - clarify drm_bridge_get/put - create drm_get_bridge_by_endpoint and use it - analogix_dp: add panel probing - ite-it6211 - use drm audio hdmi helpers buddy: - add lockdep annotations dp: - add PR and VRR updates - mst: fix buffer overflows - add Adaptive Sync SDP decoding support - fix OOB reads in dp-mst ttm: - bump fpfn/lpfn to 64-bit scheduler: - change default to fair scheduler - map runqueue 1:1 with scheduler dma-buf: - port selftests to kunit - convert dma-buf system/heap allocators to module - add separate DMABUF_HEAPS_SYSTEM_CC_SHARED Kconfig udmabuf: - revert hugetlb support - fix error with CONFIG_DMA_API_DEBUG dma-fence: - fix tracepoints lifetime - remove unused signal on any support ras: - add clear error counter netlink command to drm ras gpusvm: - reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges - use IOVA allocations pagemap: - use IOVA allocations panels: - update to use ref counts - add support for CSW PNB601LS1-2, LGD LP116WHA-SPB1 - add support for waveshare panels - CMN N116BCN-EA1, CMN N140HCA-EEK, IVO M140NWFQ R5, - IVO, R140NWFW R0, BOE NT140*, BOE NV133FHM-N4F, - AUO B140*, AUO B133HAN06.6 and AUO B116XTN02.3 eDP panels - Surface Pro 12 Panel xe: - add CRI PCI-IDs - debugfs add multi-lrc info - engine init cleanup - PF fair scheduling auto provisioning - system controller support for CRI/Xe3p - PXP state machine fixes - Reset/wedge/unload corner case fixes - Wedge path memory allocation fixes - PAT type cleanups - Reject unsafe PAT for CPU cached memory - OA improvements for CRI device memory - kernel doc syntax in xe headers - xe_drm.h documentation fixes - include guard cleanups - VF CCS memory pool - i915/xe step unification - Xe3p GT tuning fixes - forcewake cleanup in GT and GuC - admin-only PF mode - enable hwmon energy attributes for CRI - enable GT_MI_USER_INTERRUPT - refactor emit functions - oa workarounds - multi_queue: allow QUEUE_TIMESTAMP register - convert stolen memory to ttm range manager - use xe2 style blitter as a feature flag - make drm_driver const - add/use IRQ page to HW engine definition - fix oops when display disabled i915: - enable PIPEDMC_ERROR interrupt - more common display code refactoring - restructure DP/HDMI sink format handling - eliminate FB usage from lowlevel pinning code - panel replay bw optimization - integrate sharpness filter into the scaler - new fb_pin abstraction for xe/i915 fb transparent handling - skip inactive MST connectors on HDCP - start switching to display specific registers - use polling when irq unavailable - Adaptive-sync SDP prep amdgpu: - use drm_display_info for AMD VSDB data - Initial HDMI 2.1 FRL support - Initial DCN 4.2.1 support - GART fixes for non-4k pages - GC 11.5.6/SDMA 6.4.0/and other new IPs - GFX9/DCE6/Hawaii/SDMA4/GART/Userq fixes - Finish support for using multiple SDMA queues for TTM operations - SWSMU updates - GC 12.1 updates - SMU 15.0.8 updates - DCN 4.2 updates - DC type conversion fixes - Enable DC power module - Replay/PSR updates - SMU 13.x updates - Compute queue quantum MQD updates - ASPM fix - Align VKMS with common implementation - DC analog support fixes - UVD 3 fixes - TCC harvesting fixes for SI - GC 11 APU module reload fix - NBIO 6.3.2 support - IH 7.1 updates - DC cursor fixes - VCN/JPEG user fence fixes - DC support for connectors without DDC - Prefer ROM BAR for default VGA device - DC bandwidth fixes - Add PTL support for profiler - Introduce dc_plane_cm and migrate surface update color path - Add FRL registers for HDMI 2.1 - Restructure VM state machine - Auxless ALPM support - GEM_OP locking/warning fixes - switch to system_dfl_wq amdkfd: - GPUVM TLB flush fix - Hotplug fix - Boundary check fixes - SVM fixes - CRIU fixes - add profiler API - MES 12.1 updates msm: - core: - fix shrinker documentation - IFPC enabled for gen8 - PERFCNTR_CONFIG ioctl support - GPU: - reworked UBWC handling - a810 support - MDSS: - add support for Milos platform - reworked UBWC handling - DisplayPort: - reworked HPD handling as prep for MST - DPU: - Milos platform support - reworked UBWC handling - DSI: - Milos platform support nova: - Hopper/Blackwell enablement (GH100/GB100/GB202) - FSP support - 32-bit firmware support - HAL functions - refactor GSP boot/unload - GA100 support - VBIOS hardening/refactoring - Adopt higher order lifetime types tyr: - define register blocks - add shmem backed GEM objects - adopt higher order lifetime types - move clock cleanup into Drop radeon: - Hawaii SMU fixes - CS parser fix - use struct drm_edid instead of edid amdxdna: - export per-client BO memory via fdinfo - AIE4 device support - support medium/lower power modes - expandable device heap support - revert read-only user-pointer BO mappings ivpu: - support frequency limiting panthor: - enable GEM shrinker support - add eviction and reclaim info to fdinfo v3d: - enable runtime PM mgag200: - support XRGB1555 + C8 ast: - support XRGB1555 + C8 - use constants for lots of registers - fix register handling imagination: - fence handling refactoring nouveau: - fix sched double call - expose VBIOS on GSP-RM systems - add GA100 support virtio: - add VIRTIO_GPU_F_BLOB_ALIGNMENT flag - add deferred mapping support gud: - add RCade Display Adapter hibmc: - fix no connectors usage mediatek: - hdmi: convert error handling - simplify mtk_crtc allocation exynos: - move fbdev emulation to drm client buffers - use drm format helpers for geometry/size - adopt core DMA tracking - fix framebuffer offset handling renesas: - add RZ/T2H SOC support versilicon: - add cursor plane support tegra: - use drm client for framebuffer" * tag 'drm-next-2026-06-17' of https://gitlab.freedesktop.org/drm/kernel: (1731 commits) dma-buf: move system_cc_shared heap under separate Kconfig accel/amdxdna: Clear sva pointer after unbind agp/amd64: Fix broken error propagation in agp_amd64_probe() accel/amdxdna: Require carveout when PASID and force_iova are disabled drm/amdkfd: always resume_all after suspend_all drm/amdgpu/gfx: move fault and EOP IRQ get/put to hw_init/hw_fini drm/amd/display: Consult MCCS FreeSync cap only if requested & supported drm/amd/pm: Use strscpy in profile mode parsing drm/amdkfd: Fix infinite loop parsing CRAT with zero subtype length drm/amdkfd: fix sysfs topology prop length on buffer truncation drm/amdgpu: drop retry loop in amdgpu_hmm_range_get_pages drm/amd/pm: bound OD parameter parsing to stack array size drm/amd/pm: Stop pp_od_clk_voltage emit at PAGE_SIZE drm/amdkfd: Unwind debug trap enable on copy_to_user failure drm/amdgpu: validate the mes firmware version for gfx12.1 drm/amdgpu: validate the mes firmware version for gfx12 drm/amdgpu: compare MES firmware version ucode for gfx11 drm/amdkfd: Add bounds check for AMDKFD_IOC_WAIT_EVENTS drm/amdgpu: restart the CS if some parts of the VM are still invalidated drm/amd/display: use unsigned types for local pipe and REG_GET counters ...
2026-06-16drm/intel: drop driver include from mchbar_regs.hJani Nikula1-2/+0
Headers under include/ aren't supposed to try to include headers from driver directories, such as i915_reg_defs.h. Remove it. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260615152837.1898991-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-15drm/displayid: fix Tiled Display Topology ID sizeJani Nikula1-3/+3
The Tiled Display Topology ID of a DisplayID Tiled Display Topology Data Block consists of three fields: - Tiled Display Manufacturer/Vendor ID Field (3 bytes) - Tiled Display Product ID Code Field (2 bytes) - Tiled Display Serial Number Field (4 bytes) i.e. a total of 9 bytes, not 8. The DisplayID Tiled Display Topology ID is used as the tile group identifier. Update both struct displayid_tiled_block topology_id member and struct drm_tile_group group_data member to full 9 bytes. The group data was missing the last byte of the serial number. I don't know whether there are known bug reports that might be linked to this, but it's plausible the last byte could be the differentiating part for the tile groups, and fewer tile groups might have been created than intended. Fixes: b49b55bd4fba ("drm/displayid: add displayid defines and edid extension (v2)") Fixes: 138f9ebb9755 ("drm: add tile_group support. (v3)") Cc: Dave Airlie <airlied@redhat.com> Cc: stable@vger.kernel.org # v3.19+ Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260610141549.555605-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-13Merge tag 'drm-misc-fixes-2026-06-12' of ↵Dave Airlie2-19/+19
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: amd: - track colorop changes correctly amdxdna: - fix possible leak of mm_struct colorop: - make lut interpolation mutable - track colorop updates correctly ivpu: - fix integer truncation vc4: - fix leak in krealloc() error handling virtio: - fix dma_fence ref-count leak Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260612081418.GA17001@2a02-2455-9062-2500-e496-5a17-62ba-545e.dyn6.pyur.net
2026-06-10drm/atomic: track individual colorop updatesMelissa Wen1-1/+3
As we do for CRTC color mgmt properties, use color_mgmt_changed flag to track any value changes in the color pipeline of a given plane, so that drivers can update color blocks as soon as plane color pipeline or individual colorop values change. Since we're here, only announce and track changes to plane COLOR_PIPELINE prop if its value is actually changing. Fixes: 8c5ea1745f4c ("drm/colorop: Add BYPASS property") Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation") Fixes: 41651f9d42eb ("drm/colorop: Add 1D Curve subtype") Fixes: 3410108037d5 ("drm/colorop: Add multiplier type") Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline") Fixes: e5719e7f1900 ("drm/colorop: Add 3x4 CTM type") Fixes: 99a4e4f08abe ("drm/colorop: Add 1D Curve Custom LUT type") Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property") Reviewed-by: Harry Wentland <harry.wentland@amd.com> #v1 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-4-mwen@igalia.com
2026-06-10drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutableMelissa Wen1-14/+14
As interpolation props are actually mutable props, any changes should be handled by drm_colorop_state. Move their enum and make it correctly behaves as mutable. Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation") Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline") Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-3-mwen@igalia.com
2026-06-10drm/colorop: Remove read-only comments from interpolation fieldsAlex Hung1-4/+2
The lut1d_interpolation and lut3d_interpolation fields and their associated properties were marked as read-only, but userspace can set them via drm_atomic_colorop_set_property(). Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation") Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline") Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-2-mwen@igalia.com
2026-06-09drm/atomic-helper: Add HDMI bridge output bus formats helperNicolas Frattaroli1-0/+7
The drm_bridge_funcs atomic_get_output_bus_fmts operation should be the same for likely every HDMI connector bridge, unless such an HDMI connector bridge has some special hardware restrictions that I cannot envision yet. To avoid code duplication and standardize on a set of media bus formats that the HDMI output color formats translate to, add a common helper function that implements this operation to the drm bridge helpers. The function returns a list of output bus formats based on the HDMI bridge's current output bits-per-component, and its bitmask of supported color formats. To guard against future expansion of DRM_OUTPUT_COLOR_FORMAT outgrowing the hweight8 call, add a BUILD_BUG_ON statement where it's used that checks for DRM_OUTPUT_COLOR_FORMAT_COUNT. The justification for not using hweight32 in all cases is that not all ISAs have a popcount instruction, and will benefit from a smaller/faster software implementation that doesn't have to operate across all bits. The justification for not defining an hweight_color depending on the value of DRM_OUTPUT_COLOR_FORMAT_COUNT is that this count enum value is only known at compile time, not at preprocessor time. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20260609-color-format-v17-7-35739b5782cc@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-06-09drm/connector: Let connectors have a say in their color formatNicolas Frattaroli1-0/+12
Add a function to get the connector color format from a connector state, and a new function pointer in drm_connector_funcs to allow connectors to override what connector color format it returns. This is useful for the bridge chain recursive bus format selection code, which does not wish to implement connector implementation specific checks like whether it involves HDMI. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20260609-color-format-v17-4-35739b5782cc@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-06-09drm: Add new general DRM property "color format"Nicolas Frattaroli1-0/+84
Add a new general DRM property named "color format" which can be used by userspace to request the display driver to output a particular color format. Possible string values for the new enum property are: - "AUTO" (setup by default, driver internally picks the color format) - "RGB" - "YUV 4:4:4" - "YUV 4:2:2" - "YUV 4:2:0" Drivers should advertise from this list the formats they support in an optimistic best-case scenario. EDID data from the sink can then be used in the kernel's atomic check phase to restrict this set of formats, as well as by userspace to make a correct choice in the first place. Co-developed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Co-developed-by: Andri Yngvason <andri@yngvason.is> Signed-off-by: Andri Yngvason <andri@yngvason.is> Signed-off-by: Marius Vlad <marius.vlad@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20260609-color-format-v17-3-35739b5782cc@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-06-09drm/xe/nvls: Update PCI IDsGustavo Sousa1-2/+3
Bspec has been updated with respect to NVL-S PCI IDs. Update INTEL_NVLS_IDS() accordingly. Bspec: 74201 Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260521-nvl-s-update-pci-ids-v1-1-ec59e5d6bf12@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-06-08drm/bridge: split hpd_mutex into two mutexesDmitry Baryshkov1-0/+4
Currently almost all bridge drivers which implement hpd_enable / hpd_disable callbacks simply toggle the hardware registers generating the interrupt. However, as pointed out by Jonas Karlman and Sashiko bot, using those callbacks for enable_irq() / disable_irq() calls or scheduling and cancelling the work can cause a AB-BA deadlock (between hpd_mutex lock and the corresponding lock). Split the hpd_mutex into two locks: one simply making sure that hpd_cb / hpd_data are consistent and another one, hpd_state_mutex, making sure that concurrent drm_bridge_hpd_enable() / drm_bridge_hpd_disable() calls can't end up with inconsistency between hpd_cb/_data and bridge's internal state. Link: https://lore.kernel.org/dri-devel/9aa4bd35-bff6-4009-a959-ce31010c7b35@kwiboo.se Link: https://sashiko.dev/#/patchset/20260513-dp-connector-hpd-v2-0-42f757bfcbf9%40oss.qualcomm.com Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patch.msgid.link/20260528-dp-connector-hpd-v3-1-d656eb1079b7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-06-07drm/mipi-dsi: add flag for sending all DSC slices in one packetAlexander Koskovich1-0/+2
The MIPI DSI v1.3 spec defines two modes for transporting compressed pixel data: one slice per packet or multiple slice widths in a single packet (Section 8.8.24 Figure 40). Add a MIPI_DSI_MODE_DSC_ALL_SLICES_IN_PKT flag that panel drivers can set to indicate that all DSC slices for a line should be packed into a single packet. When unset should default to 1 slice per packet. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Tested-by: Junjie Cao <junjie.cao@linux.dev> Acked-by: Maxime Ripard <mripard@kernel.org> # from v1 Link: https://patch.msgid.link/20260318-dsi-dsc-slice-per-pkt-v2-1-0a1b316f8250@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-06-05Merge tag 'drm-rust-next-2026-06-04' of ↵Dave Airlie1-0/+1
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.2-rc1 - Driver Core (shared via signed tag dd-lifetimes-7.2-rc1): - Introduce Higher-Ranked Lifetime Types (HRT) for Rust device drivers, allowing driver structs to hold device resources like pci::Bar and IoMem directly with a lifetime tied to the binding scope, removing the need for Devres indirection and ARef<Device>. - Replace drvdata() with scoped registration data on the auxiliary bus, using the new ForLt trait to thread lifetimes through registrations. Remove drvdata() and driver_type. - DRM: - Add GPUVM immediate mode abstraction for Rust GPU drivers: - In immediate mode, GPU virtual address space state is updated during job execution (in the DMA fence signalling critical path), keeping the GPUVM and the GPU's address space always in sync. - Provide GpuVm, GpuVa, and GpuVmBo types for managing address spaces, virtual mappings, and GEM object backing respectively. - Provide split-merge map/unmap operations that handle partial overlaps with existing mappings. - drm_exec integration for dma_resv locking and GEM object validation based on the external/evicted object lists are not yet covered and planned as follow-up work. - Introduce DeviceContext type state for drm::Device, allowing drivers to restrict operations to contexts where the device is guaranteed to be registered (or not yet registered) with userspace. - Add FEAT_RENDER flag to the Driver trait for render node support. - Nova: - Hopper/Blackwell enablement: - Add GPU identification and architecture-based HAL selection for Hopper (GH100) and Blackwell (GB100, GB202). - Implement the FSP (Foundation Security Processor) boot path used by Hopper and Blackwell, including FSP falcon engine support, EMEM operations, MCTP/NVDM message infrastructure, and FSP Chain of Trust boot with GSP lockdown release. - Add support for 32-bit firmware images and auto-detection of firmware image format. - Add architecture-specific framebuffer, sysmem flush, PCI config mirror, DMA mask, and WPR/non-WPR heap sizing. - GSP boot and unload: - Refactor the GSP boot process into a chipset-specific HAL, keeping the SEC2 and FSP boot paths separated cleanly. - Implement proper driver unload: send UNLOADING_GUEST_DRIVER command, run Booter Unloader and FWSEC-SB upon unbinding, and run the unload bundle on Gsp::boot() failure. This removes the need for a manual GPU reset between driver unbind and re-probe. - GA100 support: - Add support for the GA100 GPU, including IFR header detection and skipping, correct fwsignature selection, conditional FRTS boot, and documentation of the IFR header layout. - VBIOS hardening and refactoring: - Harden VBIOS parsing with checked arithmetic, bounds-checked accesses, and FromBytes-based structure reads throughout the FWSEC and Falcon data paths. Simplify the overall VBIOS module structure. - HRT adoption: - Use lifetime-parameterized pci::Bar directly, replacing the Arc<Devres<Bar0>> indirection. Replace ARef<Device> with &'bound Device in SysmemFlush and the GSP sequencer. Separate the driver type from driver data. - Misc: - Rename module names to kebab-case (nova-drm, nova-core). - Require little-endian in Kconfig, making the existing assumption explicit. - Tyr: - Define comprehensive typed register blocks for GPU_CONTROL, JOB_CONTROL, MMU_CONTROL (including per-address-space registers), and DOORBELL_BLOCK using the kernel register!() macro. This replaces manual bit manipulation with typed register and field accessors. - Add shmem-backed GEM objects and set DMA mask based on GPU physical address width. - Adopt HRT: separate driver type from driver data, and use IoMem directly instead of Devres for register access during probe. - Move clock cleanup into a Drop implementation. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DJ0IF39U9ETK.PCCUO7ZEQ4S0@kernel.org
2026-06-03drm/managed: fix drmm_add_action() kernel-docMichał Grzelak1-1/+1
Kernel-doc of drmm_add_action() references @releases which is not on argument list. Swap '@' between 'releases' and 'action' words to fix the documentation. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260522135520.1862848-3-michal.grzelak@intel.com
2026-06-03drm/print: describe 6th & 9th bit of drm.debugMichał Grzelak1-1/+1
Setting 6th or 9th bit of drm.debug change debug logging. Meanwhile `modinfo drm` does not inform about it at all. Add info to MODULE_PARAM_DESC(debug, ...) about setting 6th and 9th bit basing on DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, ...). Match description of corresponding bits with enum drm_debug_category. Include 9th bit in the example with enabling all possible logging provided at comment at include/drm/drm_print.h. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260522135520.1862848-2-michal.grzelak@intel.com
2026-06-02drm/bridge: analogix_dp: Add support for RK3576Damon Ding1-0/+2
Add RK3576_EDP device type entry and extend Rockchip check to match existing hardware capabilities shared with RK3588. Set identical maximum link rate and lane count parameters for RK3576 eDP controller to reuse existing RK3588 config. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260601065100.1103873-11-damon.ding@rock-chips.com
2026-06-02drm/bridge: analogix_dp: Rename and simplify is_rockchip()Damon Ding1-2/+9
Rename inline helper is_rockchip() to analogix_dp_is_rockchip() to follow driver namespace convention consistently across code. Replace chained equality comparisons with switch-case layout to improve readability and simplify adding new SoC entries later. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Suggested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260601065100.1103873-10-damon.ding@rock-chips.com
2026-06-02drm/bridge: synopsys: dw-dp: Support unregistering the AUX channelCristian Ciocaltea1-0/+1
The DisplayPort AUX channel gets initialized and registered during dw_dp_bind(), but it is never unregistered, which may lead to resource leaks and/or use-after-free. Add the missing dw_dp_unbind() function to allow the users of the library to handle the required cleanup, i.e. unregister the AUX adapter. Fixes: 86eecc3a9c2e ("drm/bridge: synopsys: Add DW DPTX Controller support library") Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-1-c3f3f123e1da@collabora.com
2026-06-02drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked()Lyude Paul1-0/+1
One of the complications of trying to use the shmem helpers to create a scatterlist for shmem objects is that we need to be able to provide a guarantee that the driver cannot be unbound for the lifetime of the scatterlist. The easiest way of handling this seems to be just hooking up an unmap operation to devres the first time we create a scatterlist, which allows us to still take advantage of gem shmem facilities without breaking that guarantee. To allow for this, we extract __drm_gem_shmem_free_sgt_locked() - which allows a caller (e.g. the rust bindings) to manually unmap the sgt for a gem object as needed. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260529183702.677677-6-lyude@redhat.com
2026-05-29drm: Remove DRIVER_GEM_GPUVA feature flagLaura Nao3-10/+1
The DRIVER_GEM_GPUVA feature flag is currently only used to control two behaviors within the DRM core: - calling drm_gem_gpuva_init() during GEM object initialization - creating the "gpuvas" debugfs entry drm_gem_gpuva_init() is a plain INIT_LIST_HEAD() and therefore is cheap to run for every GEM object. The DRM_DEBUGFS_GPUVA_INFO macro is only referenced by GPU-VA capable drivers, so clearing the feature bit does not cause any unrelated drivers to get the "gpuvas" debugfs node. The flag doesn't have any relevant purpose (e.g. gating ioctl handlers or MM logic) and doesn't provide any practical benefit. Remove the flag definition and drop it from all drivers that use it, call drm_gem_gpuva_init() unconditionally and clear the driver features bit in DRM_DEBUGFS_GPUVA_INFO. Signed-off-by: Laura Nao <laura.nao@collabora.com> Acked-by: Rob Clark <rob.clark@oss.qualcomm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260421084701.24227-1-laura.nao@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-05-29drm/mode-config: Create drm_mode_config_create_initial_state()Maxime Ripard1-0/+1
drm_mode_config_reset() can be used to create the initial state, but also to return to the initial state, when doing a suspend/resume cycle for example. It also affects both the software and the hardware, and drivers can choose to reset the hardware as well. Most will just create an empty state and the synchronisation between hardware and software states will effectively be done when the first commit is done. That dual role can be harmful, since some objects do need to be initialized but also need to be preserved across a suspend/resume cycle. drm_private_obj are such objects for example. Thus, create another helper for drivers to call to initialize their state when the driver is loaded, so we can make drm_mode_config_reset() only about handling suspend/resume and similar. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-16-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/connector: Add new atomic_create_state callbackMaxime Ripard2-0/+18
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states. Instead of relying on the reset() callback, it created a new atomic_create_state hook. This is helpful because reset is a bit overloaded: it's used to create the initial software state, reset it, but also reset the hardware. It can also be used either at probe time, to create the initial state and possibly reset the hardware to an expected default, but also during suspend/resume. Both these cases come with different expectations too: during the initialization, we want to initialize all states, but during suspend/resume, drm_private_states for example are expected to be kept around. reset() also isn't fallible, which makes it harder to handle initialization errors properly. This is only really relevant for some drivers though, since all the helpers for reset only create a new state, and don't touch the hardware at all. It was thus decided to create a new hook that would allocate and initialize a pristine state without any side effect: atomic_create_state to untangle a bit some of it, and to separate the initialization with the actual reset one might need during a suspend/resume. Continue the transition to the new pattern with connectors. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-15-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()Maxime Ripard1-2/+2
__drm_atomic_helper_connector_hdmi_reset() is typically used to initialize a newly allocated drm_connector_state when the connector is using the HDMI helpers, and is being called by the drm_connector_funcs.reset implementation. Since we want to consolidate DRM objects state allocation around the atomic_create_state callback that will only allocate and initialize a new drm_connector_state instance, we will need to call __drm_atomic_helper_connector_hdmi_reset() from both the reset and atomic_create hooks. To avoid any confusion, we can thus rename __drm_atomic_helper_connector_hdmi_reset() to __drm_atomic_helper_connector_hdmi_state_init(). Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-14-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()Maxime Ripard1-1/+1
__drm_atomic_helper_connector_state_reset() is used to initialize a newly allocated drm_connector_state, and is being typically called by the drm_connector_funcs.reset implementation. Since we want to consolidate DRM objects state allocation around the atomic_create_state callback that will only allocate and initialize a new drm_connector_state instance, we will need to call __drm_atomic_helper_connector_state_reset() from both the reset and atomic_create hooks. To avoid any confusion, we can thus rename __drm_atomic_helper_connector_state_reset() to __drm_atomic_helper_connector_state_init(). Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-13-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/crtc: Add new atomic_create_state callbackMaxime Ripard2-0/+18
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states. Instead of relying on the reset() callback, it created a new atomic_create_state hook. This is helpful because reset is a bit overloaded: it's used to create the initial software state, reset it, but also reset the hardware. It can also be used either at probe time, to create the initial state and possibly reset the hardware to an expected default, but also during suspend/resume. Both these cases come with different expectations too: during the initialization, we want to initialize all states, but during suspend/resume, drm_private_states for example are expected to be kept around. reset() also isn't fallible, which makes it harder to handle initialization errors properly. This is only really relevant for some drivers though, since all the helpers for reset only create a new state, and don't touch the hardware at all. It was thus decided to create a new hook that would allocate and initialize a pristine state without any side effect: atomic_create_state to untangle a bit some of it, and to separate the initialization with the actual reset one might need during a suspend/resume. Continue the transition to the new pattern with CRTCs. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-12-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()Maxime Ripard1-1/+1
__drm_atomic_helper_crtc_state_reset() is used to initialize a newly allocated drm_crtc_state, and is being typically called by the drm_crtc_funcs.reset implementation. Since we want to consolidate DRM objects state allocation around the atomic_create_state callback that will only allocate and initialize a new drm_crtc_state instance, we will need to call __drm_atomic_helper_crtc_state_reset() from both the reset and atomic_create hooks. To avoid any confusion, we can thus rename __drm_atomic_helper_crtc_state_reset() to __drm_atomic_helper_crtc_state_init(). Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-11-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/plane: Add new atomic_create_state callbackMaxime Ripard2-0/+18
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states. Instead of relying on the reset() callback, it created a new atomic_create_state hook. This is helpful because reset is a bit overloaded: it's used to create the initial software state, reset it, but also reset the hardware. It can also be used either at probe time, to create the initial state and possibly reset the hardware to an expected default, but also during suspend/resume. Both these cases come with different expectations too: during the initialization, we want to initialize all states, but during suspend/resume, drm_private_states for example are expected to be kept around. reset() also isn't fallible, which makes it harder to handle initialization errors properly. This is only really relevant for some drivers though, since all the helpers for reset only create a new state, and don't touch the hardware at all. It was thus decided to create a new hook that would allocate and initialize a pristine state without any side effect: atomic_create_state to untangle a bit some of it, and to separate the initialization with the actual reset one might need during a suspend/resume. Continue the transition to the new pattern with planes. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-10-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/atomic-state-helper: Rename __drm_atomic_helper_plane_state_reset()Maxime Ripard1-1/+1
__drm_atomic_helper_plane_state_reset() is used to initialize a newly allocated drm_plane_state, and is being typically called by the drm_plane_funcs.reset implementation. Since we want to consolidate DRM objects state allocation around the atomic_create_state callback that will only allocate and initialize a new drm_plane_state instance, we will need to call __drm_atomic_helper_plane_state_reset() from both the reset and atomic_create hooks. To avoid any confusion, we can thus rename __drm_atomic_helper_plane_state_reset() to __drm_atomic_helper_plane_state_init(). Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-9-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/colorop: Create drm_atomic_helper_colorop_create_state()Maxime Ripard1-0/+2
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states. Instead of relying on the reset() callback, it created a new atomic_create_state hook. This is helpful because reset is a bit overloaded: it's used to create the initial software state, reset it, but also reset the hardware. It can also be used either at probe time, to create the initial state and possibly reset the hardware to an expected default, but also during suspend/resume. Both these cases come with different expectations too: during the initialization, we want to initialize all states, but during suspend/resume, drm_private_states for example are expected to be kept around. reset() also isn't fallible, which makes it harder to handle initialization errors properly. This is only really relevant for some drivers though, since all the helpers for reset only create a new state, and don't touch the hardware at all. It was thus decided to create a new hook that would allocate and initialize a pristine state without any side effect: atomic_create_state to untangle a bit some of it, and to separate the initialization with the actual reset one might need during a suspend/resume. Continue the transition to the new pattern with drm_colorop. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-7-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-29drm/atomic: Expand atomic_create_state expectations for drm_private_objMaxime Ripard1-1/+4
The atomic_create_state callback documentation for planes, CRTCs, and connectors explicitly states the expected behaviour: the returned state must not be assigned to the object's state pointer, and hardware must not be touched. The drm_private_state_funcs.atomic_create_state documentation is missing this clarification. Add it for consistency. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-4-852346394200@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-28Merge drm/drm-next into drm-misc-nextThomas Zimmermann5-12/+65
Backmerging to get GEM LRU fixes from commit 379e8f1c ("drm/gem: Make the GEM LRU lock part of drm_device") and other updates from v7.1-rc5. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-05-28Merge v7.1-rc5 into drm-nextSimona Vetter3-11/+18
Boris Brezillion needs the gem lru fixes 379e8f1ca5e9 ("drm/gem: Make the GEM LRU lock part of drm_device") backmerged for drm-misc-next. That also means we need to sort out the rename conflict in panthor with the fixup patch from Boris from drm-tip. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2026-05-26Merge tag 'drm-misc-next-2026-05-21' of ↵Dave Airlie1-0/+7
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.2-rc1: UAPI Changes: - Add VIRTIO_GPU_F_BLOB_ALIGNMENT flag. Cross-subsystem Changes: - Add common TMDS character rate constants to video/hdmi and use those in bridge drivers. Core Changes: - Fix leak in drm_syncobj_find_fence. - Fix OOB reads related to DP-MST. - Create drm_get_bridge_by_endpoint and convert drivers to use it in preparation of hotplug. Driver Changes: - Assorted bugfixes and cleanups to accel/ethosu, imagination, virtio, rockchip. - Expandable device heap support to amdxdna, bridge/chipone-icn6211. - Add Surface Pro 12 panels. - Convert ite-it6211 to use drm hdmi audio helpers. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/f4034e3c-8290-49e1-9410-dc1f449265f4@linux.intel.com
2026-05-25drm/exec, drm/xe, drm/amdgpu: Add an accessor for struct drm_exec::ticketThomas Hellström1-0/+11
Drivers were accessing this drm_exec member directly. While that may seem harmless, it will require action if the drm_exec utility is made a subclass of a dma-resv transaction utility as outlined in the cover-letter. Provide an accessor, drm_exec_ticket() to avoid that. v2: - Fix amdgpu compile error (Intel CI) - Update the commit message. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-5-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec, drm/xe: Avoid abusing the drm_exec retry pointerThomas Hellström1-0/+19
The xe driver was using the drm_exec retry pointer directly to restart the locking loop after out-of-memory errors. This is relying on undocumented behaviour. Instead add a drm_exec_retry() macro that can be used in this situation, and that also warns if the struct drm_exec is not newly (re-)initialized. Use that macro in xe. v2: - Only allow if the drm_exec context is newly initialized. (Christian) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-4-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec: Make the drm_exec_until_all_locked() macro more readableThomas Hellström1-9/+12
Use __UNIQUE_ID as done elsewhere in the kernel rather than a hand-rolled __PASTE to craft a unique id. Also use __maybe_unused rather than (void) to signify that a variable, althrough written to, may not actually be used. v2: - Move assignment to declaration (Christian) - Declare the retry pointer as void *const. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-3-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse]Thomas Hellström1-8/+12
Nobody makes any use of it. Possible internal future users can instead use the _index variable. External users shouldn't use it since the array it's pointing into is internal drm_exec state. v2: - Use a unique id for the loop variable (Christian) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-2-thomas.hellstrom@linux.intel.com
2026-05-22Merge tag 'drm-misc-fixes-2026-05-21' of ↵Dave Airlie2-11/+16
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: amdxdna: - remove mmap and export for ubuf bridge: - chipone-icn6211: managed bridge cleanup - lt66121: acquire reset GPIO - megachips: fix clean up on failed IRQ requests gem: - clean up LRU locking v3d: - fix UAF in error code paths - release GEM-object ref on free'd jobs virtio: - use uninterruptible resv locking in plane updates Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260521071456.GA14644@localhost.localdomain
2026-05-19drm/bridge: add of_drm_get_bridge_by_endpoint()Luca Ceresoli1-0/+7
drm_of_find_panel_or_bridge() is widely used, but many callers pass NULL into the @panel or the @bridge arguments, thus making a very partial usage of this rather complex function. Besides, the bridge returned in @bridge is not refcounted, thus making this API unsafe when DRM bridge hotplug will be introduced. Solve both issues for the cases of calls to drm_of_find_panel_or_bridge() with a NULL @panel pointer by adding a new function that only looks for bridges (and is thus much simpler) and increments the refcount of the returned bridge. The new function is identical to drm_of_find_panel_or_bridge() except it: - handles bridge refcounting: uses of_drm_find_and_get_bridge() instead of of_drm_find_bridge() internally to return a refcounted bridge - is simpler to use: just takes no @panel parameter, returns the pointer in the return value instead of a double pointer argument - has a simpler implementation: it is equal to drm_of_find_panel_or_bridge() after removing the code that becomes dead when @panel == NULL Also add this function to drm_bridge.c and not drm_of.c because it returns bridges only. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-2-f61c9e498b3f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-05-18drm/gem: Make the GEM LRU lock part of drm_deviceBoris Brezillon2-11/+16
Recently, a few races have been discovered in the GEM LRU logic, all of them caused by the fact the LRU lock is accessed through gem->lru->lock, and that very same lock also protects changes to gem->lru, leading to situations where gem->lru needs to first be accessed without the lock held, to then get the lru to access the lock through and finally take the lock and do the expected operation. Currently, the only driver making use of this API (MSM) declares a device-wide lock, and the user we're about to add (panthor) will do the same. There's no evidence that we will ever have a driver that wants different pools of LRUs protected by different locks under the same drm_device. So we're better off moving this lock to drm_device and always locking it through obj->dev->gem_lru_mutex, or directly through dev->gem_lru_mutex. If anyone ever needs more fine-grained locking, this can be revisited to pass some drm_gem_lru_pool object representing the pool of LRUs under a specific lock, but for now, the per-device lock seems to be enough. Fixes: e7c2af13f811 ("drm/gem: Add LRU/shrinker helper") Reported-by: Chia-I Wu <olvaffe@gmail.com> Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/86 Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20260518-panthor-shrinker-fixes-v4-1-1920234470d5@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-22 15:04:23 +0000