summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-11drm/tilcdc: Convert to drm_device-based logging helpersKory Maincent (TI.com)
Replace dev_* logging calls with their DRM equivalents. This aligns with the DRM subsystem's logging infrastructure and provides better integration with DRM debugging mechanisms. The drm_* helpers automatically include device information and integrate with DRM's debug category filtering. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-19-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Convert to DRM managed resourcesKory Maincent (TI.com)
Convert the tilcdc driver to use DRM managed resources (drmm_* APIs) to eliminate resource lifetime issues, particularly in probe deferral scenarios. This conversion addresses potential use-after-free bugs by ensuring proper cleanup ordering through the DRM managed resource framework. The changes include: - Replace drm_crtc_init_with_planes() with drmm_crtc_alloc_with_planes() - Replace drm_universal_plane_init() with drmm_universal_plane_alloc() - Replace drm_simple_encoder_init() with drmm_simple_encoder_alloc() - Remove manual cleanup in tilcdc_crtc_destroy() and error paths - Remove drm_encoder_cleanup() from encoder error handling paths - Use drmm_add_action_or_reset() for remaining cleanup operations This approach is recommended by the DRM subsystem for improved resource lifetime management and is particularly important for drivers that may experience probe deferral. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-18-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove the use of drm_device private_dataKory Maincent (TI.com)
The DRM core documentation recommends against using dev_private: "Instead of using this pointer it is recommended that drivers use embed the struct &drm_device in their larger per-device structure." This patch refactors the tilcdc driver to follow this recommendation by embedding struct drm_device within struct tilcdc_drm_private and replacing all dev->dev_private accesses with the ddev_to_tilcdc_priv() helper macro that uses container_of(). This change aligns the driver with modern DRM best practices. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-17-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Modernize driver initialization and cleanup pathsKory Maincent (TI.com)
Refactor the driver initialization to use modern DRM managed resource APIs, simplifying the code. The tilcdc_init and tilcdc_fini wrapper functions are removed since they served no purpose after the component framework was eliminated. Their logic is integrated directly into probe and remove. Key changes: - Use devm_drm_dev_alloc() instead of drm_dev_alloc(). - Use drmm_mode_config_init() instead of drm_mode_config_init(). - Align the remove path with the probe error path to ensure consistent cleanup ordering in both success and failure cases. - Adjust platform_set_drvdata() to store the private structure instead of the drm_device, matching the new allocation pattern. These changes reduce error-prone code while maintaining the same functional behavior. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-16-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Move tilcdc_init/fini closer to probe/removeKory Maincent (TI.com)
Move tilcdc_init/fini functions adjacent to the probe and remove functions in preparation for cleanup and modernization. This improves readability for subsequent commits that will refactor these functions. No functional changes, only code reorganization. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-15-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Use drm_module_platform_driver() helperKory Maincent (TI.com)
Use the drm_module_platform_driver() helper macro to simplify driver registration. This macro handles both the platform driver registration and the drm_firmware_drivers_only() check, making the custom init/exit functions unnecessary. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-14-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove the useless module list supportKory Maincent (TI.com)
The tilcdc driver previously supported a sub-module system where external display drivers (panels, encoders) could register themselves through tilcdc_module_init() and be automatically initialized through a module list. This infrastructure became unused after the component framework support and panel driver was removed. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-13-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Rename tilcdc_external to tilcdc_encoderKory Maincent (TI.com)
The tilcdc_external module describes the encoder part of the tilcdc driver. Rename it to tilcdc_encoder for better clarity and to make the naming more consistent with DRM subsystem conventions, where encoder-related files typically use "encoder" in their names. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-12-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Rename external_encoder and external_connector to encoder and ↵Kory Maincent (TI.com)
connector Remove the "external_" prefix from encoder and connector members in the tilcdc driver. These are internal driver structures and the "external" naming is misleading. The simpler names better reflect that these are the primary encoder and connector managed by this driver. Also rename tilcdc_attach_external_device() to tilcdc_encoder_create() for consistency and to better describe the function's purpose. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-11-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove unused encoder and connector tracking arraysKory Maincent (TI.com)
The num_encoders/encoders and num_connectors/connectors arrays in tilcdc_drm_private are never populated or used by the driver. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-10-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove redundant #endif/#ifdef in debugfs codeKory Maincent (TI.com)
Remove the unnecessary #endif/#ifdef CONFIG_DEBUG_FS pair that splits the debugfs code section. This keeps all debugfs-related code within a single preprocessor conditional block, improving code readability. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-9-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove tilcdc_panel_info structureKory Maincent (TI.com)
Remove the tilcdc_panel_info structure and its associated helper function as the structure contains only redundant or unused parameters. Most panel configuration parameters in tilcdc_panel_info are either: - Already represented by existing DRM mode flags (invert_pxl_clk, sync_edge via DRM_BUS_FLAG_*), or - Set to identical values across all instances (panel_info_default), making them effectively constants The removed fifo_th field is already handled by priv->fifo_th when set. Other removed fields (tft_alt_mode, raster_order) were always set to 0 in the only instance (panel_info_default) and thus had no effect. This simplifies the code by eliminating unnecessary abstraction while preserving all functional behavior. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-8-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove component framework supportKory Maincent (TI.com)
The tilcdc driver previously used the component framework to bind external encoder subdrivers (specifically the TDA998x HDMI encoder). With the removal of these subdrivers in previous commits, the component framework is no longer needed. This commit removes all component framework infrastructure including: - Component master operations and bind/unbind callbacks - The is_componentized flag and conditional code paths - tilcdc_get_external_components() and tilcdc_add_component_encoder() - TDA998x-specific panel configuration The driver now uses a simplified initialization path that directly attaches external devices via the DRM bridge API, eliminating the complexity of dual code paths for componentized vs non-componentized configurations. This cleanup removes approximately 140 lines of code and makes the driver initialization flow more straightforward. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-7-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove tilcdc panel driverKory Maincent (TI.com)
The tilcdc panel subdriver is a legacy, non-standard driver that has been replaced by the standard panel-dpi driver and panel-simple infrastructure. With the device tree bindings removed and all in-tree users migrated to use panel-dpi, this driver no longer has any associated device tree bindings or users. The panel-dpi driver combined with DRM bus flags provides equivalent functionality in a standard way that is compatible with the broader DRM panel ecosystem. This removal eliminates 400+ lines of redundant code and completes the migration to standard panel handling. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-6-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Convert legacy panel binding via DT overlay at boot timeKory Maincent (TI.com)
To maintain backward compatibility while removing the deprecated tilcdc_panel driver, add a tilcdc_panel_legacy subdriver that converts the legacy "ti,tilcdc,panel" devicetree binding to the standard panel-dpi binding at early boot. The conversion uses an embedded device tree overlay that is applied and modified during subsys_initcall. The process: - Apply embedded overlay to create a tilcdc-panel-dpi node with port/endpoint connections to the LCDC - Copy all properties from the legacy panel node to the new tilcdc-panel-dpi node - Copy display-timings from the legacy panel - Convert legacy panel-info properties (invert-pxl-clk, sync-edge) to standard display timing properties (pixelclk-active, syncclk-active) - Disable the legacy panel by removing its compatible property to prevent the deprecated driver from binding The result is a standard tilcdc-panel-dpi node with proper endpoints and timing properties, allowing the DRM panel infrastructure to work with legacy devicetrees without modification. Other legacy panel-info properties are not migrated as they consistently use default values across all mainline devicetrees and can be hardcoded in the tilcdc driver. This feature is optional via CONFIG_DRM_TILCDC_PANEL_LEGACY and should only be enabled for systems with legacy devicetrees containing "ti,tilcdc,panel" nodes. Suggested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/all/1d9a9269-bfda-4d43-938b-2df6b82b9369@ideasonboard.com/ Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-5-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Add support for DRM bus flags and simplify panel configKory Maincent (TI.com)
Migrate CRTC mode configuration to use standard DRM bus flags in preparation for removing the tilcdc_panel driver and its custom tilcdc_panel_info structure. Add support for DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE and DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE flags to control pixel clock and sync signal edge polarity, while maintaining backward compatibility with the existing tilcdc panel info structure. Simplify several hardware parameters by setting them to fixed defaults based on common usage across existing device trees: - DMA burst size: 16 (previously configurable via switch statement) - AC bias frequency: 255 (previously panel-specific) - FIFO DMA request delay: 128 (previously panel-specific) These parameters show no variation in real-world usage, so hardcoding them simplifies the driver without losing functionality. Preserve FIFO threshold configurability by detecting the SoC type, as this parameter varies between AM33xx (8) and DA850 (16) platforms. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-4-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-11drm/tilcdc: Remove simulate_vesa_sync flagKory Maincent (TI.com)
The tilcdc hardware does not generate VESA-compliant sync signals. It aligns the vertical sync (VS) on the second edge of the horizontal sync (HS) instead of the first edge. To compensate for this hardware behavior, the driver applies a timing adjustment in mode_fixup(). Previously, this adjustment was conditional based on the simulate_vesa_sync flag, which was only set when using external encoders. This appears problematic because: 1. The timing adjustment seems needed for the hardware behavior regardless of whether an external encoder is used 2. The external encoder infrastructure is driver-specific and being removed due to design issues 3. Boards using tilcdc without bridges (e.g., am335x-evm, am335x-evmsk) may not be getting the necessary timing adjustments Remove the simulate_vesa_sync flag and apply the VESA sync timing adjustment unconditionally, ensuring consistent behavior across all configurations. While it's unclear if the previous conditional behavior was causing actual issues, the unconditional adjustment better reflects the hardware's characteristics. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260123-feature_tilcdc-v5-3-5a44d2aa3f6f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-10Merge tag 'irq-msi-2026-02-09' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull MSI updates from Thomas Gleixner: "Updates for the [PCI] MSI subsystem: - Add interrupt redirection infrastructure Some PCI controllers use a single demultiplexing interrupt for the MSI interrupts of subordinate devices. This prevents setting the interrupt affinity of device interrupts, which causes device interrupts to be delivered to a single CPU. That obviously is counterproductive for multi-queue devices and interrupt balancing. To work around this limitation the new infrastructure installs a dummy irq_set_affinity() callback which captures the affinity mask and picks a redirection target CPU out of the mask. When the PCI controller demultiplexes the interrupts it invokes a new handling function in the core, which either runs the interrupt handler in the context of the target CPU or delegates it to irq_work on the target CPU. - Utilize the interrupt redirection mechanism in the PCI DWC host controller driver. This allows affinity control for the subordinate device MSI interrupts instead of being randomly executed on the CPU which runs the demultiplex handler. - Replace the binary 64-bit MSI flag with a DMA mask Some PCI devices have PCI_MSI_FLAGS_64BIT in the MSI capability, but implement less than 64 address bits. This breaks on platforms where such a device is assigned an MSI address higher than what's supported. With the binary 64-bit flag there is no other choice than disabling 64-bit MSI support which leaves the device disfunctional. By using a DMA mask the address limit of a device can be described correctly which provides support for the above scenario. - Make use of the DMA mask based address limit in the hda/intel and radeon drivers to enable them on affected platforms - The usual small cleanups and improvements" * tag 'irq-msi-2026-02-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ALSA: hda/intel: Make MSI address limit based on the device DMA limit drm/radeon: Make MSI address limit based on the device DMA limit PCI/MSI: Check the device specific address mask in msi_verify_entries() PCI/MSI: Convert the boolean no_64bit_msi flag to a DMA address mask genirq/redirect: Prevent writing MSI message on affinity change PCI/MSI: Unmap MSI-X region on error genirq: Update effective affinity for redirected interrupts PCI: dwc: Enable MSI affinity support PCI: dwc: Code cleanup genirq: Add interrupt redirection infrastructure genirq/msi: Correct kernel-doc in <linux/msi.h>
2026-02-10Merge tag 'rust-6.20-7.0' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull rust updates from Miguel Ojeda: "Toolchain and infrastructure: - Add '__rust_helper' annotation to the C helpers This is needed to inline these helpers into Rust code - Remove imports available via the prelude, treewide This was possible thanks to a new lint in Klint that Gary has implemented -- more Klint-related changes, including initial upstream support, are coming - Deduplicate pin-init flags 'kernel' crate: - Add support for calling a function exactly once with the new 'do_once_lite!' macro (and 'OnceLite' type) Based on this, add 'pr_*_once!' macros to print only once - Add 'impl_flags!' macro for defining common bitflags operations: impl_flags!( /// Represents multiple permissions. #[derive(Debug, Clone, Default, Copy, PartialEq, Eq)] pub struct Permissions(u32); /// Represents a single permission. #[derive(Debug, Clone, Copy, PartialEq, Eq)] pub enum Permission { /// Read permission. Read = 1 << 0, /// Write permission. Write = 1 << 1, /// Execute permission. Execute = 1 << 2, } ); let mut f: Permissions = Permission::Read | Permission::Write; assert!(f.contains(Permission::Read)); assert!(!f.contains(Permission::Execute)); f |= Permission::Execute; assert!(f.contains(Permission::Execute)); let f2: Permissions = Permission::Write | Permission::Execute; assert!((f ^ f2).contains(Permission::Read)); assert!(!(f ^ f2).contains(Permission::Write)); - 'bug' module: support 'CONFIG_DEBUG_BUGVERBOSE_DETAILED' in the 'warn_on!' macro in order to show the evaluated condition alongside the file path: ------------[ cut here ]------------ WARNING: [val == 1] linux/samples/rust/rust_minimal.rs:27 at ... Modules linked in: rust_minimal(+) - Add safety module with 'unsafe_precondition_assert!' macro, currently a wrapper for 'debug_assert!', intended to mark the validation of safety preconditions where possible: /// # Safety /// /// The caller must ensure that `index` is less than `N`. unsafe fn set_unchecked(&mut self, index: usize, value: T) { unsafe_precondition_assert!( index < N, "set_unchecked() requires index ({index}) < N ({N})" ); ... } - Add instructions to 'build_assert!' documentation requesting to always inline functions when used with function arguments - 'ptr' module: replace 'build_assert!' with a 'const' one - 'rbtree' module: reduce unsafe blocks on pointer derefs - 'transmute' module: implement 'FromBytes' and 'AsBytes' for inhabited ZSTs, and use it in Nova - More treewide replacements of 'c_str!' with C string literals 'macros' crate: - Rewrite most procedural macros ('module!', 'concat_idents!', '#[export]', '#[vtable]', '#[kunit_tests]') to use the 'syn' parsing library which we introduced last cycle, with better diagnostics This also allows to support '#[cfg]' properly in the '#[vtable]' macro, to support arbitrary types in 'module!' macro (not just an identifier) and to remove several custom parsing helpers we had - Use 'quote!' from the recently vendored 'quote' library and remove our custom one The vendored one also allows us to avoid quoting '"' and '{}' inside the template anymore and editors can now highlight it. In addition, it improves robustness as it eliminates the need for string quoting and escaping - Use 'pin_init::zeroed()' to simplify KUnit code 'pin-init' crate: - Rewrite all procedural macros ('[pin_]init!', '#[pin_data]', '#[pinned_drop]', 'derive([Maybe]Zeroable)') to use the 'syn' parsing library which we introduced last cycle, with better diagnostics - Implement 'InPlaceWrite' for '&'static mut MaybeUninit<T>'. This enables users to use external allocation mechanisms such as 'static_cell' - Support tuple structs in 'derive([Maybe]Zeroable)' - Support attributes on fields in '[pin_]init!' (such as '#[cfg(...)]') - Add a '#[default_error(<type>)]' attribute to '[pin_]init!' to override the default error (when no '? Error' is specified) - Support packed structs in '[pin_]init!' with '#[disable_initialized_field_access]' - Remove 'try_[pin_]init!' in favor of merging their feature with '[pin_]init!'. Update the kernel's own 'try_[pin_]init!' macros to use the 'default_error' attribute - Correct 'T: Sized' bounds to 'T: ?Sized' in the generated 'PinnedDrop' check by '#[pin_data]' Documentation: - Conclude the Rust experiment MAINTAINERS: - Add "RUST [RUST-ANALYZER]" entry for the rust-analyzer support. Tamir and Jesung will take care of it. They have both been active around it for a while. The new tree will flow through the Rust one - Add Gary as maintainer for "RUST [PIN-INIT]" - Update Boqun and Tamir emails to their kernel.org accounts And a few other cleanups and improvements" * tag 'rust-6.20-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (59 commits) rust: safety: introduce `unsafe_precondition_assert!` macro rust: add `impl_flags!` macro for defining common bitflag operations rust: print: Add pr_*_once macros rust: bug: Support DEBUG_BUGVERBOSE_DETAILED option rust: print: Add support for calling a function exactly once rust: kbuild: deduplicate pin-init flags gpu: nova-core: remove imports available via prelude rust: clk: replace `kernel::c_str!` with C-Strings MAINTAINERS: Update my email address to @kernel.org rust: macros: support `#[cfg]` properly in `#[vtable]` macro. rust: kunit: use `pin_init::zeroed` instead of custom null value rust: macros: rearrange `#[doc(hidden)]` in `module!` macro rust: macros: allow arbitrary types to be used in `module!` macro rust: macros: convert `#[kunit_tests]` macro to use `syn` rust: macros: convert `concat_idents!` to use `syn` rust: macros: convert `#[export]` to use `syn` rust: macros: use `quote!` for `module!` macro rust: macros: use `syn` to parse `module!` macro rust: macros: convert `#[vtable]` macro to use `syn` rust: macros: use `quote!` from vendored crate ...
2026-02-10drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm()Maciej Patelczyk
There is a unbalanced lock/unlock to gpusvm notifier lock: [ 931.045868] ===================================== [ 931.046509] WARNING: bad unlock balance detected! [ 931.047149] 6.19.0-rc6+xe-**************** #9 Tainted: G U [ 931.048150] ------------------------------------- [ 931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at: [ 931.049801] [<ffffffffa090c0d8>] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper] [ 931.050802] but there are no more locks to release! [ 931.051463] The drm_gpusvm_notifier_unlock() sits under err_free label and the first jump to err_free is just before calling the drm_gpusvm_notifier_lock() causing unbalanced unlock. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260209123433.1271053-1-maciej.patelczyk@intel.com
2026-02-10Merge tag 'hardening-v7.0-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardening updates from Kees Cook: "Mostly small cleanups and various scattered annotations and flex array warning fixes that we reviewed by unlanded in other trees. Introduces new annotation for expanding counted_by to pointer members, now that compiler behavior between GCC and Clang has been normalized. - Various missed __counted_by annotations (Thorsten Blum) - Various missed -Wflex-array-member-not-at-end fixes (Gustavo A. R. Silva) - Avoid leftover tempfiles for interrupted compile-time FORTIFY tests (Nicolas Schier) - Remove non-existant CONFIG_UBSAN_REPORT_FULL from docs (Stefan Wiehler) - fortify: Use C arithmetic not FIELD_xxx() in FORTIFY_REASON defines (David Laight) - Add __counted_by_ptr attribute, tests, and first user (Bill Wendling, Kees Cook) - Update MAINTAINERS file to make hardening section not include pstore" * tag 'hardening-v7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: MAINTAINERS: pstore: Remove L: entry nfp: tls: Avoid -Wflex-array-member-not-at-end warnings carl9170: Avoid -Wflex-array-member-not-at-end warning coredump: Use __counted_by_ptr for struct core_name::corename lkdtm/bugs: Add __counted_by_ptr() test PTR_BOUNDS compiler_types.h: Attributes: Add __counted_by_ptr macro fortify: Cleanup temp file also on non-successful exit fortify: Rename temporary file to match ignore pattern fortify: Use C arithmetic not FIELD_xxx() in FORTIFY_REASON defines ecryptfs: Annotate struct ecryptfs_message with __counted_by fs/xattr: Annotate struct simple_xattr with __counted_by crypto: af_alg - Annotate struct af_alg_iv with __counted_by Kconfig.ubsan: Remove CONFIG_UBSAN_REPORT_FULL from documentation drm/nouveau: fifo: Avoid -Wflex-array-member-not-at-end warning
2026-02-10drm/panel: jdi-lt070me05000: Use MIPI DSI multi functionsChintan Patel
Convert to the non-deprecated mipi_dsi_*_multi() helpers per the TODO list. This reduces boilerplate error checking while providing proper error accumulation. Use mipi_dsi_msleep() and mipi_dsi_usleep_range() macros for delays. Replace mdelay(10) and mdelay(20) with mipi_dsi_usleep_range() calls using tighter slop (10-11ms and 20-21ms respectively) since these functions aren't run often and don't need large timing windows. In jdi_panel_off(), reset the error context between display_off and enter_sleep_mode to preserve the original behavior of continuing power-down even if display_off fails. This ensures enter_sleep_mode executes before GPIO/regulator control, which is critical for proper power sequencing. Signed-off-by: Chintan Patel <chintanlike@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260203044605.5890-1-chintanlike@gmail.com
2026-02-10drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138Matt Roper
The PSS_CHICKEN register has been part of the RCS engine's LRC since it was first introduced in Xe_LP. That means that any workarounds that adjust its value (such as Wa_14019988906 and Wa_14019877138) need to be implemented in the lrc_was[] table so that they become part of the default LRC from which all subsequent LRCs are copied. Although these workarounds were implemented correctly on most platforms, they were incorrectly placed on the engine_was[] table for Xe2_HPG. Move the workarounds to the proper lrc_was[] table and switch the 'xe_rtp_match_first_render_or_compute' rule to specifically match the RCS since that's the engine whose LRC manages the register. Bspec: 65182 Fixes: 7f3ee7d88058 ("drm/xe/xe2hpg: Add initial GT workarounds") Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20260205220508.51905-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-10drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse()Felix Gu
The logicvc_drm_config_parse() function calls of_get_child_by_name() to find the "layers" node but fails to release the reference, leading to a device node reference leak. Fix this by using the __free(device_node) cleanup attribute to automatic release the reference when the variable goes out of scope. Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260130-logicvc_drm-v1-1-04366463750c@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-02-10drm/xe/nvlp: Bump maximum WOPCM sizeGustavo Sousa
On NVL-P, the primary GT's WOPCM gained an extra 8MiB for the Memory URB. As such, we need to bump the maximum size in the driver so that the driver is able to load without erroring out thinking that the WOPCM is too small. FIXME: The wopcm code in xe driver is a bit confusing. For the case where the offsets for GUC WOPCM are already locked, it appears we are using the maximum overall WOPCM size instead of the sizes relative to each type of GT. The function __check_layout() should be checking against the latter. Bspec: 67090 Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-15-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/i915/nvlp: Hook up display supportMatt Roper
Although NVL-S and NVL-P are quite different on the GT side, they use identical Xe3p_LPD display IP and should take all the same codepaths. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-14-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/nvlp: Attach MOCS table for nvlpDnyaneshwar Bhadane
The MOCS table for NVL-P is same as for Xe2/Xe3 platforms. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-13-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/nvlp: Add NVL-P platform definitionShekhar Chauhan
Add platform definition along with device IDs for NVL-P. Here is the list of device descriptor fields and associated Bspec references: .dma_mask_size (Bspec 74198) .has_cached_pt (Bspec 71582) .has_display (Bspec 74196) .has_flat_ccs (Bspec 74110) .has_page_reclaim_hw_assist (Bspec 73451) .max_gt_per_tile (Bspec 74196) .va_bits (Bspec 74198) .vm_max_level (Bspec 59507) v2: - Add list of descriptor fields and Bspec references. (Matt) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-12-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KBAradhya Bhatia
Since the dominant size of the pages referred in an i-gpu, such as Xe3p_LPG, will be 4KB, the HW default of mix of 64K and 2M for STLB bank hash mode does not make sense. Allow the SW to change it to 4KB Mode, for Xe3p_LPG. v2: - Add Bspec reference. (Matt) Bspec: 78248 Signed-off-by: Aradhya Bhatia <aradhya.bhatia@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-11-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Update LRC sizesGustavo Sousa
Like with previous generations, the engine context images for of both RCS and CCS in Xe3p_LPG contain a common layout at the end for the context related to the "Compute Pipeline". The size of the memory area written to such section varies; it depends on the type of preemption has taken place during the execution and type of command streamer instruction that was used on the pipeline. For Xe3p_LPG, the maximum possible size, including NOOPs for cache line alignment, is 4368 dwords, which would be the case of a mid-thread preemption during the execution of a COMPUTE_WALKER_2 instruction. The maximum size has increased in such a way that we need to update xe_gt_lrc_size() to match the new sizing requirement. When we add that to the engine-specific parts, we have: - RCS context image: 6672 dwords = 26688 bytes -> 7 pages - CCS context image: 5024 dwords = 20096 bytes -> 5 pages Bspec: 65182, 55793, 73590 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-10-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Extend 'group ID' mask sizeMatt Roper
Xe3p_LPG extends the 'group ID' register mask by one bit. Since the new upper bit (12) was unused on previous platforms, we can safely extend the existing mask size without worrying about adding conditional version checks to the register programming. Bspec: 67175 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-9-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Drop unnecessary tuning settingsMatt Roper
From Xe3p onward, the desired settings are now the hardware's default values and the driver does not need to program them explicitly. Since 35.xx seems to be the starting point for "Xe3p" version numbers; we'll adjust the bounds of the old programming to stop at 34.99. Even though there's no platform with version 35.00 at the moment, this is simplest in case one does show up in the future. Bspec: 72161, 59928, 59930 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-8-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Disable reporting of context switch status to GHWSPMatt Roper
By default the hardware reports context switch status into the global hardware status page. The Xe driver doesn't use this information for anything, and as of Xe3p, leaving this setting enabled will prevent other hardware optimizations from being enabled. Disable this reporting as suggested by the tuning guide. Bspec: 72161 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-7-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add LRC parsing for additional RCS engine stateMatt Roper
Xe3p_LPG adds some additional state instructions to the RCS engine's LRC. Add support for these to the debugfs LRC parser. Note that the bspec's LRC description page seems to have a few mistakes in the name/spelling of these new instructions (e.g., "3DSTATE_TASK_DATA_EXT" instead of "3DSTATE_TASK_SHADER_DATA_EXT" or "3DSTATE_VIEWPORT_STATE_POINTERS_CL_SF_2" instead of "3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP_2"). Bspec: 65182 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-6-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add MCR steeringMatt Roper
Xe3p_LPG has nearly identical steering to Xe2 and Xe3. The only DSS/XeCore change from those IPs is an additional range from 0xDE00-0xDE7F that was previously reserved, so we can simply grow one of the existing ranges in the Xe2 table to include it. Similarly, the "instance0" table is also almost identical, but gains one additional PSMI range and requires a separate table. v2: - Drop reserved range from MEMPIPE range. (Dnyaneshwar) Bspec: 75242 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-5-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add new PAT tableMatt Roper
PAT programming for Xe3p_LPG is more similar to Xe2 and Xe3 than it is to Xe3p_XPC. Compared to Xe2/Xe3 we have: * There's a slight update to the PAT table, where two new indices (18 and 19) are added to expose a new "WB - Transient App" L3 caching mode. * The PTA_MODE entry must be programmed differently according to the media type, and both differ from Xe2. There are no changes to the underlying registers, so the Xe2 ops can be re-used for Xe3p. Bspec: 71582, 74160 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-4-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/pat: Differentiate between primary and media for PTAGustavo Sousa
Differently from currently supported platforms, in upcoming changes we will need to have different PAT entries for PTA based on the GT type. As such, let's prepare the code to support that by having two separate PTA-specific members in the pat struct, one for each type of GT. While at it, also fix the kerneldoc for pat_ats. Co-developed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-3-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add initial workarounds for graphics version 35.10Shekhar Chauhan
Add the initial set of workarounds for Xe3p_LPG graphics version 35.10. v2: - Fix spacing style for field LOCALITYDIS. (Matt) - Drop unnecessary Wa_14025780377. (Matt) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Co-developed-by: Nitin Gote <nitin.r.gote@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Co-developed-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Co-developed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-2-636e1ad32688@intel.com Co-developed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add support for graphics IP 35.10Shekhar Chauhan
Add Xe3p_LPG graphics IP version 35.10. Xe3p_LPG supports all features described by XE2_GFX_FEATURES and also multi-queue feature on BCS and CCS engines. As such, create a new struct xe_graphics_desc named graphics_xe3p_lpg that inherits from XE2_GFX_FEATURES and also includes the necessary .multi_queue_engine_class_mask. Here is a list of fields and associated Bspec references for the members of the IP descriptor: .hw_engine_mask (Bspec 60149) .multi_queue_engine_class_mask (Bspec 74110) .has_asid (Bspec 71132) .has_atomic_enable_pte_bit (Bspec 59510, 74675) .has_indirect_ring_state (Bspec 67296) .has_range_tlb_inval (Bspec 71126) .has_usm (Bspec 59651) .has_64bit_timestamp (Bspec 60318) .num_geometry_xecore_fuse_regs (Bspec 62566, 67401, 67536) .num_compute_xecore_fuse_regs (Bspec 62565, 62561, 67537) v2: - Drop non-existing fields from the list in the commit message. (Matt) - Squash patch adding .multi_queue_engine_class_mask here. (Matt) - Rename graphics_xe3p to graphics_xe3p_lpg. (Matt) - Add fields .num_geometry_xecore_fuse_regs and .num_compute_xecore_fuse_regs after rebasing and inheriting commit 6acf3d3ed6c1 ("drm/xe: Move number of XeCore fuse registers to graphics descriptor"). (Gustavo) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-1-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/i915/overlay: remove dead code with MTL platform checksJani Nikula
Commit c5741c5c1122 ("drm/i915/display: Do not use stolen on MTL") added some checks for MTL in overlay code. However, this is never run on MTL. Clean it up. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260206125949.243643-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-10drm/imagination: Mark FWCCB_CMD_UPDATE_STATS as knownMatt Coster
Suppress the "unknown type" warning when processing a FWCCB command of type CMD_UPDATE_STATS which is known but (currently) unused. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://patch.msgid.link/20260206-improve-bad-fwccb-cmd-v1-2-831a852ca127@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-02-10drm/imagination: Improve handling of unknown FWCCB commandsMatt Coster
A couple small changes: - Validate the magic value at the head of FWCCB commands, and - Mask off the magic value before logging unknown command types to make them easier to interpret on sight. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://patch.msgid.link/20260206-improve-bad-fwccb-cmd-v1-1-831a852ca127@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-02-10drm/i915/dp: Verify valid pipe BPP rangeImre Deak
Ensure that the pipe BPP range is valid after calculating the minimum and maximum pipe BPP values separately. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260209133817.395823-2-imre.deak@intel.com
2026-02-10drm/i915/dp: Fix pipe BPP clamping due to HDRImre Deak
The pipe BPP value shouldn't be set outside of the source's / sink's valid pipe BPP range, ensure this when increasing the minimum pipe BPP value to 30 due to HDR. While at it debug print if the HDR mode was requested for a connector by setting the corresponding HDR connector property. This indicates if the requested HDR mode could not be enabled, since the selected pipe BPP is below 30, due to a sink capability or link BW limit. v2: - Also handle the case where the sink could support the target 30 BPP only in DSC mode due to a BW limit, but the sink doesn't support DSC or 30 BPP as a DSC input BPP. (Chaitanya) - Debug print the connector's HDR mode in the link config dump, to indicate if a BPP >= 30 required by HDR couldn't be reached. (Ankit) - Add Closes: trailer. (Ankit) - Don't print the 30 BPP-outside of valid BPP range debug message if the min BPP is already > 30 (and so a target BPP >= 30 required for HDR is ensured). Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503 Fixes: ba49a4643cf53 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> # v1 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260209133817.395823-1-imre.deak@intel.com
2026-02-10drm/vc4: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The vc4 driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-14-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/msm: dpu1: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The MSM dpu1 driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-11-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/msm: mdp5: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The MSM mdp5 driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-10-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/ingenic: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The ingenic driver relies on two drm_private_objs, that are initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-9-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/arm: komeda: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The ARM komeda driver relies on a number of drm_private_objs, that are initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-8-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/dp_tunnel: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The DP tunnel implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-6-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>