summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-15drm/i915: Use a 1 second timeout for the polling vblank waitVille Syrjälä
40 msec seems like a very random number for a vblank wait timeout. Considering ~24Hz display modes are definitely a thing this seems way too low. Just bump it to a full second to match what we've been using for normal vblank waits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260410150449.9699-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-15drm/i915: Move initial plane vblank wait into display codeVille Syrjälä
The initial plane vblank wait operates on display registers, so it really belongs in the display code proper. Move it there. We can use intel_parent_irq_enabled() to determine if we can rely on interrupts or not. On average we should end up waiting half a frame here, so the polling interval can be fairly long. 1 ms (which actually makes poll_timeout_us() use ~250-1000 usec) seems good enough to me. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260410150449.9699-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-15drm/i915: Make plane_config->fb a struct drm_framebuffer*Ville Syrjälä
There's no need to use the intel specific struct intel_framebuffer* type in the initial plane_config structure. Just make it a struct drm_framebuffer*. I think the fewer special types we expose in the interface (even if just pointers) the better. At least then there is no need to change the interface definition if we ever change the internal types. And I hope that the existing examples will generally encourage people to not expose more special types unless absolutely necessary. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260410150449.9699-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-15drm/i915: Don't pass the whole plane_config to initial_plane_phys()Ville Syrjälä
initial_plane_phys() only needs the 'base' (== ggtt virtual address) from the plane_config. Stop passing the whole plane_config and just pass the 'base'. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260410150449.9699-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-15drm/i915: Remove 'mem' and 'phy_base' from struct intel_initial_plane_configVille Syrjälä
The 'mem' and 'phy_base' members of struct intel_initial_plane_config only exist to be passed from initial_plane_phys() to its sole caller. Just return them via function arguments. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260410150449.9699-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-15drm/i915: Introduce sanity to the plane_config pointer vs. array thingVille Syrjälä
The "plane_config" vs. "plane_configs" naming difference is very subtle, making it far too easy to use the wrong thing by accident. Introduce a separate type for the array, making it impossible to pass in the wrong thing. And while at it name the variable "all_plane_configs" to help the poor reader make sense of things. The .config_fini() prototype also mistakenly used the plural form despite only taking in a singular plane_config. So fix that one up as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260410150449.9699-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-15drm/i915/psr: Init variable to avoid early exit from et alignment loopJouni Högander
Uninitialized boolean variable may cause unwanted exit from et alignment loop. Fix this by initializing it as false. Fixes: 681e12440d8b ("drm/i915/psr: Repeat Selective Update area alignment") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260413112345.88853-1-jouni.hogander@intel.com
2026-04-14Merge tag 'bitmap-for-v7.1' of https://github.com/norov/linuxLinus Torvalds
Pull bitmap updates from Yury Norov: - new API: bitmap_weight_from() and bitmap_weighted_xor() (Yury) - drop unused __find_nth_andnot_bit() (Yury) - new tests and test improvements (Andy, Akinobu, Yury) - fixes for count_zeroes API (Yury) - cleanup bitmap_print_to_pagebuf() mess (Yury) - documentation updates (Andy, Kai, Kit). * tag 'bitmap-for-v7.1' of https://github.com/norov/linux: (24 commits) bitops: Update kernel-doc for sign_extendXX() powerpc/xive: simplify xive_spapr_debug_show() thermal: intel: switch cpumask_get() to using cpumask_print_to_pagebuf() coresight: don't use bitmap_print_to_pagebuf() lib/prime_numbers: drop temporary buffer in dump_primes() drm/xe: switch xe_pagefault_queue_init() to using bitmap_weighted_or() ice: use bitmap_empty() in ice_vf_has_no_qs_ena ice: use bitmap_weighted_xor() in ice_find_free_recp_res_idx() bitmap: introduce bitmap_weighted_xor() bitmap: add test_zero_nbits() bitmap: exclude nbits == 0 cases from bitmap test bitmap: test bitmap_weight() for more asm-generic/bitops: Fix a comment typo in instrumented-atomic.h bitops: fix kernel-doc parameter name for parity8() lib: count_zeros: unify count_{leading,trailing}_zeros() lib: count_zeros: fix 32/64-bit inconsistency in count_trailing_zeros() lib: crypto: fix comments for count_leading_zeros() x86/topology: use bitmap_weight_from() bitmap: add bitmap_weight_from() lib/find_bit_benchmark: avoid clearing randomly filled bitmap in test_find_first_bit() ...
2026-04-14drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl()Shuicheng Lin
Two error handling issues exist in xe_exec_queue_create_ioctl(): 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in preempt fence mode, xe_vm_add_compute_exec_queue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed. 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has succeeded, the error path does not call xe_hw_engine_group_del_exec_queue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free. Fix both by: - Changing the xe_hw_engine_group_add_exec_queue() failure path to jump to kill_exec_queue so that xe_exec_queue_kill() properly removes the queue from the VM's compute list. - Adding a del_hw_engine_group label before kill_exec_queue for the xa_alloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup. Fixes: 7970cb36966c ("'drm/xe/hw_engine_group: Register hw engine group's exec queues") Cc: Francois Dugast <francois.dugast@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408020647.3397933-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-14drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()Shuicheng Lin
When xe_dma_buf_init_obj() fails, the attachment from dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before returning the error. Note: we cannot use goto out_err here because xe_dma_buf_init_obj() already frees bo on failure, and out_err would double-free it. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Mattheq Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408175255.3402838-5-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-14drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failureShuicheng Lin
When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo is not freed. Add xe_bo_free(storage) before returning the error. xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the bo on error. Therefore, xe_dma_buf_init_obj() must also free the bo on its own error paths. Otherwise, since xe_gem_prime_import() cannot distinguish whether the failure originated from xe_dma_buf_init_obj() or from xe_bo_init_locked(), it cannot safely decide whether the bo should be freed. Add comments documenting the ownership semantics: on success, ownership of storage is transferred to the returned drm_gem_object; on failure, storage is freed before returning. v2: Add comments to explain the free logic. Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408175255.3402838-4-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-14drm/xe/bo: Fix bo leak on GGTT flag validation in xe_bo_init_locked()Shuicheng Lin
When XE_BO_FLAG_GGTT_ALL is set without XE_BO_FLAG_GGTT, the function returns an error without freeing a caller-provided bo, violating the documented contract that bo is freed on failure. Add xe_bo_free(bo) before returning the error. Fixes: 5a3b0df25d6a ("drm/xe: Allow bo mapping on multiple ggtts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408175255.3402838-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-14drm/xe/bo: Fix bo leak on unaligned size validation in xe_bo_init_locked()Shuicheng Lin
When type is ttm_bo_type_device and aligned_size != size, the function returns an error without freeing a caller-provided bo, violating the documented contract that bo is freed on failure. Add xe_bo_free(bo) before returning the error. Fixes: 4e03b584143e ("drm/xe/uapi: Reject bo creation of unaligned size") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408175255.3402838-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-14drm/xe: Fix potential NULL deref in ↵Shuicheng Lin
xe_exec_queue_tlb_inval_last_fence_put_unlocked xe_exec_queue_tlb_inval_last_fence_put_unlocked() uses q->vm->xe as the first argument to xe_assert(). This function is called unconditionally from xe_exec_queue_destroy() for all queues, including kernel queues that have q->vm == NULL (e.g., queues created during GT init in xe_gt_record_default_lrcs() with vm=NULL). While current compilers optimize away the q->vm->xe dereference (even in CONFIG_DRM_XE_DEBUG=y builds, the compiler pushes the dereference into the WARN branch that is only taken when the assert condition is false), the code is semantically incorrect and constitutes undefined behavior in the C abstract machine for the NULL pointer case. Use gt_to_xe(q->gt) instead, which is always valid for any exec queue. This is consistent with how xe_exec_queue_destroy() itself obtains the xe_device pointer in its own xe_assert at the top of the function. Fixes: b2d7ec41f2a3 ("drm/xe: Attach last fence to TLB invalidation job queues") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260409003449.3405767-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-14drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connectorLuca Ceresoli
Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the drm_bridge_connector framework which is the current DRM bridge best practice. Based on the in-tree dts[i] files this introduces no regression. Based on the kernel doc of drm_bridge_connector.c: * To make use of this helper, all bridges in the chain shall report bridge * operation flags (&drm_bridge->ops) and bridge output type * (&drm_bridge->type), as well as the DRM_BRIDGE_ATTACH_NO_CONNECTOR attach * flag (none of the bridges shall create a DRM connector directly). and each of the 3 LCDIF blocks in the i.MX8MP, all of them comply with the above requirement: * For the LCDIF3, the pipeline is: LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector And the involved bridges are: * fsl,imx8mp-hdmi-pvi has ops = 0 (it doesn't set it) because it implements none the optional features mentioned by those flags, and it honors the DRM_BRIDGE_ATTACH_NO_CONNECTOR by propagating it * fsl,imx8mp-hdmi-tx is implemented based on dw-hdmi, which sets ops as appropriate and also propagates the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag * display-connector (enabled via the DT overlay if needed) sets ops and makes DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory * The LCDIF2 involves the panel-bridge, display-connector and lvds-decoder (even though only the pane-bridge is currently supported), and all these three also set ops as needed and propagate DRM_BRIDGE_ATTACH_NO_CONNECTOR or make it mandatory. * The LCDIF1 is used with the adv7511, tc358767 and the panel bridge drivers which also comply with the requirements. Tested-by: Martyn Welch <martyn.welch@collabora.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-11-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTORLuca Ceresoli
The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn can operate in two different modes, depending on the platform data as set by the driver: A. hdmi->plat_data->output_port = 0: the HDMI output (port@1) in device tree is not used [0] B. hdmi->plat_data->output_port = 1: the HDMI output (port@1) is parsed to find the next bridge The imx8mp-hdmi-tx driver falls in case A. Switching to case B, which is the current best practice, requires that the HDMI connector is always described in the live device tree, and a previous commit ensured this is always the case by adding an overlay in case the device tree does not comply. So now we can simply switch to the new mode and support DRM_BRIDGE_ATTACH_NO_CONNECTOR. Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-10-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the ↵Luca Ceresoli
overlay Describing the HDMI connector in device tree is recommended. While the overlay insertion is a workaround to avoid breaking existing devices, every dts should be improved by adding a connector description. Add a warning to make users aware as far as possible. As a warning line cannot hold all the relevant info, add a detailed comment in the code so it easy to find when the warning is seen. Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-9-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/bridge: imx8mp-hdmi-tx-connector-fixup: add an hdmi-connector when ↵Luca Ceresoli
missing using a DT overlay at boot time The imx8mp-hdmi-tx is one of many drivers based on dw-hdmi. dw-hdmi in turn can operate in two different modes, depending on the platform data as set by the driver: A. hdmi->plat_data->output_port = 0: the HDMI output (port@1) in device tree is not used [0] B. hdmi->plat_data->output_port = 1: the HDMI output (port@1) is parsed to find the next bridge The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and in that case it adds an HDMI Type A connector programmatically at bridge attach time. Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in case B. However switching to base B requires that port@1 is connected to a "next bridge" DT node, typically the HDMI connector, because dw-hdmi won't add the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR. Many dts files for imx8mp-based boards in the kernel have such a connector described and linked to port@1, so the pipeline will be fully attached up to a display-connector and a drm_connector added by the bridge-connector. Sadly some of those dts files don't have the connector described. Adding it would solve the problem easily, but this would break existing devices which do not update the dtb when upgrading to a newer kernel. In preparation for switching to case B while preserving backward compatibility for such devices, introduce a module adding the hdmi-connector node to the live device tree at init time. This will allow the dw-hdmi code to find the next bridge (the one wrapping the hdmi-connector) and let the pipeline work as before. The module is inserted only if there is no endpoint in port@1. So boards whose device tree describe the connector will not have the device tre modified, and will start isntantiating the correct HDMI connector type as described in the device tree. For boards lacking a connector description in DT the overlay will be added, abd the HDMI connector will be Type A, which is a reasonable fallback and is what the driver is currently doing. [0] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310 [1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907 Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-8-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/bridge: dw-hdmi: move next_bridge lookup to attach timeLuca Ceresoli
This driver looks up the next_bridge at probe time and stores it in hdmi->bridge.next_bridge, but only uses the stored value when attaching, and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case. This will be problematic with an upcoming change, adding an hdmi-connector using a device tree overlay when not present. That change is in turn necessary to migrate the i.MX LCDIF driver to the bridge-connector. The problem is that, adding the hdmi-connector via an overlay, devlink considers hdmi-connector a consumer of the dw-hdmi device, generating a chicken-egg problem: * hdmi-connector probe won't be tried until dw-hdmi is probed (devlink) * dw-hdmi probe will defer until it finds the next_bridge (the hdmi-connector wrapper bridge) In preparation for those changes, move the next_bridge lookup from probe to attach, when it is actually used. This allows dw-hdmi to probe, so that the hdmi-connector can probe as well. Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is computed when needed, thus a local variable is enough. Finally, this also allows to slightly improve the code by not doing any DT lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case. Tested-by: Martyn Welch <martyn.welch@collabora.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL Acked-by: Liu Ying <victor.liu@nxp.com> Tested-by: Damon Ding <damon.ding@rock-chips.com> # rk3399 Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-7-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/bridge: dw-hdmi: warn on unsupported attach combinationLuca Ceresoli
dw-hdmi can operate in two different modes, depending on the platform data as set by the driver: A. hdmi->plat_data->output_port = 0: the HDMI output (port@1) in device tree is not used B. hdmi->plat_data->output_port = 1: the HDMI output (port@1) is parsed to find the next bridge Only case B is supported when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is passed to the attach callback. Emit a warning when this is violated. Also return -EINVAL which would be returned by drm_bridge_attach() right after anyway. Reviewed-by: Liu Ying <victor.liu@nxp.com> Tested-by: Martyn Welch <martyn.welch@collabora.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL Tested-by: Damon Ding <damon.ding@rock-chips.com> # rk3399 Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-6-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/mxsfb/lcdif: move iteration-specific variables declaration inside loop ↵Luca Ceresoli
in lcdif_attach_bridge The bridge and ret variables are per-iteration variables, whose values don't have to be carried to the next iteration or be used after the loop end. Move their declaration inside the loop scope as a cleanup and to make code clearer. Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-4-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridgeLuca Ceresoli
lcdif_attach_bridge() uses dev_err_probe() in some error paths, dev_err() + return in others. Use dev_err_probe() for all of them to make code consistent, simpler and with better error reporting. Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-3-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/mxsfb/lcdif: simplify ep pointer management using __freeLuca Ceresoli
Putting the ep device_node reference requires a of_node_put(ep) in many return points. Use a cleanup action to simplify the code. Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-2-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/mxsfb/lcdif: simplify remote pointer management using __freeLuca Ceresoli
Putting the remote device_node reference requires a of_node_put(remote) in two places. Use a cleanup action to simplify the code. Reviewed-by: Liu Ying <victor.liu@nxp.com> Tested-by: Martyn Welch <martyn.welch@collabora.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-1-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/xe/pf: Derive admin-only PF mode from xe_device stateSatyanarayana K V P
Stop tracking admin-only PF mode in a separate `xe->sriov.pf.admin_only` field and use `xe_device_is_admin_only(xe)` as the single source of admin mode. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260413095637.2871287-2-satyanarayana.k.v.p@intel.com
2026-04-14drm/xe/pf: Restrict device query responses in admin-only PF modeSatyanarayana K V P
When a PF is configured in admin-only mode, it is intended for management only and must not expose workload-facing capabilities to userspace. Limit the exposed ioctl set in admin-only PF mode to XE_DEVICE_QUERY and XE_OBSERVATION, and suppress capability-bearing query payloads so that the userspace cannot discover execution-related device details in this mode. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Dunajski Bartosz <bartosz.dunajski@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260409154423.2499340-5-satyanarayana.k.v.p@intel.com
2026-04-14drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach failsOsama Abdelkader
dw_mipi_dsi_host_attach() and dw_mipi_dsi2_host_attach() call drm_bridge_add() before pdata->host_ops->attach(). If attach fails, the bridge stayed registered without drm_bridge_remove(), leaking the bridge reference and leaving the device on the global bridge list. Fixes: 90910a651123 ("drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach") Fixes: 0d6d86253fef ("drm/bridge/synopsys: Add MIPI DSI2 host controller bridge") Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260403145208.15890-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/arcpgu: fix device node leakLuca Ceresoli
This function gets a device_node reference via of_graph_get_remote_port_parent() and stores it in encoder_node, but never puts that reference. Add it. There used to be a of_node_put(encoder_node) but it has been removed by mistake during a rework in commit 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init"). Fixes: 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init") Cc: stable@vger.kernel.org Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260402-drm-arcgpu-fix-device-node-leak-v2-1-d773cf754ae5@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/i915/wm: Verify the correct plane DDB entryVille Syrjälä
Actually verify the DDB entry for the plane we're looking at instead of always verifying the cursor DDB. Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> (cherry picked from commit f002f7c7439de18117a31ca84dc87a59719c3dd6) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-04-14drm/i915/backlight: Fix VESA backlight possible check conditionSuraj Kandpal
VESA backlight enable is possible when BACKLIGHT_AUX_ENABLE_CAPABLE is true via AUX command or when BACKLIGHT_PIN_ENABLE_CAPABLE is true via eDP connector pin. Similarly, backlight brightness adjustment can be done via AUX-based control or PWM pin-based control. It means there can be three configurations: 1) Full AUX-based: Enable and adjustment both via AUX. We currently support this (apart from the AUX luminance-based backlight control). 2) Hybrid: Enable via the BL_ENABLE pin, adjustment via either AUX or PWM. 3) Fully PWM pin-based: Enable via the BL_ENABLE pin, adjustment via PWM. Since that only 1 is supported as of now we need to make sure we do not try to manipulate backlight when BACKLIGHT_AUX_ENABLE_CAPABLE is not set. Also fix return value when condition is not fulfilled. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15907 Fixes: 0fb03890d182 ("drm/i915/backlight: Check if VESA backlight is possible") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260407030710.1440046-1-suraj.kandpal@intel.com (cherry picked from commit 102d44b3a8fad96e94e9ccd0579986c14a1f2f75) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-04-13drm/xe/vf: Use drm mm instead of drm sa for CCS read/writeSatyanarayana K V P
The suballocator algorithm tracks a hole cursor at the last allocation and tries to allocate after it. This is optimized for fence-ordered progress, where older allocations are expected to become reusable first. In fence-enabled mode, that ordering assumption holds. In fence-disabled mode, allocations may be freed in arbitrary order, so limiting allocation to the current hole window can miss valid free space and fail allocations despite sufficient total space. Use DRM memory manager instead of sub-allocator to get rid of this issue as CCS read/write operations do not use fences. Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408110145.1639937-6-satyanarayana.k.v.p@intel.com
2026-04-13drm/xe: Add memory pool with shadow supportSatyanarayana K V P
Add a memory pool to allocate sub-ranges from a BO-backed pool using drm_mm. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408110145.1639937-5-satyanarayana.k.v.p@intel.com
2026-04-13Merge tag 'acpi-7.1-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI support updates from Rafael Wysocki: "These include an update of the CMOS RTC driver and the related ACPI and x86 code that, among other things, switches it over to using the platform device interface for device binding on x86 instead of the PNP device driver interface (which allows the code in question to be simplified quite a bit), a major update of the ACPI Time and Alarm Device (TAD) driver adding an RTC class device interface to it, and updates of core ACPI drivers that remove some unnecessary and not really useful code from them. Apart from that, two drivers are converted to using the platform driver interface for device binding instead of the ACPI driver one, which is slated for removal, support for the Performance Limited register is added to the ACPI CPPC library and there are some janitorial updates of it and the related cpufreq CPPC driver, the ACPI processor driver is fixed and cleaned up, and NVIDIA vendor CPER record handler is added to the APEI GHES code. Also, the interface for obtaining a CPU UID from ACPI is consolidated across architectures and used for fixing a problem with the PCI TPH Steering Tag on ARM64, there are two updates related to ACPICA, a minor ACPI OS Services Layer (OSL) update, and a few assorted updates related to ACPI tables parsing. Specifics: - Update maintainers information regarding ACPICA (Rafael Wysocki) - Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy() (Kees Cook) - Trigger an ordered system power off after encountering a fatal error operator in AML (Armin Wolf) - Enable ACPI FPDT parsing on LoongArch (Xi Ruoyao) - Remove the temporary stop-gap acpi_pptt_cache_v1_full structure from the ACPI PPTT parser (Ben Horgan) - Add support for exposing ACPI FPDT subtables FBPT and S3PT (Nate DeSimone) - Address multiple assorted issues and clean up the code in the ACPI processor idle driver (Huisong Li) - Replace strlcat() in the ACPI processor idle drive with a better alternative (Andy Shevchenko) - Rearrange and clean up acpi_processor_errata_piix4() (Rafael Wysocki) - Move reference performance to capabilities and fix an uninitialized variable in the ACPI CPPC library (Pengjie Zhang) - Add support for the Performance Limited Register to the ACPI CPPC library (Sumit Gupta) - Add cppc_get_perf() API to read performance controls, extend cppc_set_epp_perf() for FFH/SystemMemory, and make the ACPI CPPC library warn on missing mandatory DESIRED_PERF register (Sumit Gupta) - Modify the cpufreq CPPC driver to update MIN_PERF/MAX_PERF in target callbacks to allow it to control performance bounds via standard scaling_min_freq and scaling_max_freq sysfs attributes and add sysfs documentation for the Performance Limited Register to it (Sumit Gupta) - Add ACPI support to the platform device interface in the CMOS RTC driver, make the ACPI core device enumeration code create a platform device for the CMOS RTC, and drop CMOS RTC PNP device support (Rafael Wysocki) - Consolidate the x86-specific CMOS RTC handling with the ACPI TAD driver and clean up the CMOS RTC ACPI address space handler (Rafael Wysocki) - Enable ACPI alarm in the CMOS RTC driver if advertised in ACPI FADT and allow that driver to work without a dedicated IRQ if the ACPI alarm is used (Rafael Wysocki) - Clean up the ACPI TAD driver in various ways and add an RTC class device interface, including both the RTC setting/reading and alarm timer support, to it (Rafael Wysocki) - Clean up the ACPI AC and ACPI PAD (processor aggregator device) drivers (Rafael Wysocki) - Rework checking for duplicate video bus devices and consolidate pnp.bus_id workarounds handling in the ACPI video bus driver (Rafael Wysocki) - Update the ACPI core device drivers to stop setting acpi_device_name() unnecessarily (Rafael Wysocki) - Rearrange code using acpi_device_class() in the ACPI core device drivers and update them to stop setting acpi_device_class() unnecessarily (Rafael Wysocki) - Define ACPI_AC_CLASS in one place (Rafael Wysocki) - Convert the ni903x_wdt watchdog driver and the xen ACPI PAD driver to bind to platform devices instead of ACPI devices (Rafael Wysocki) - Add devm_ghes_register_vendor_record_notifier(), use it in the PCI hisi driver, and Add NVIDIA vendor CPER record handler (Kai-Heng Feng) - Consolidate the interface for obtaining a CPU UID from ACPI across architectures and use it to address incorrect PCI TPH Steering Tag on ARM64 resulting from the invalid assumption that the ACPI Processor UID would always be the same as the corresponding logical CPU ID in Linux (Chengwen Feng)" * tag 'acpi-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (73 commits) ACPICA: Update maintainers information watchdog: ni903x_wdt: Convert to a platform driver ACPI: PAD: xen: Convert to a platform driver ACPI: processor: idle: Reset cpuidle on C-state list changes cpuidle: Extract and export no-lock variants of cpuidle_unregister_device() PCI/TPH: Pass ACPI Processor UID to Cache Locality _DSM ACPI: PPTT: Use acpi_get_cpu_uid() and remove get_acpi_id_for_cpu() perf: arm_cspmu: Switch to acpi_get_cpu_uid() from get_acpi_id_for_cpu() ACPI: Centralize acpi_get_cpu_uid() declaration in include/linux/acpi.h x86/acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval RISC-V: ACPI: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval LoongArch: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval arm64: acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval ACPI: APEI: GHES: Add NVIDIA vendor CPER record handler PCI: hisi: Use devm_ghes_register_vendor_record_notifier() ACPI: APEI: GHES: Add devm_ghes_register_vendor_record_notifier() ACPI: tables: Enable FPDT on LoongArch ACPI: processor: idle: Fix NULL pointer dereference in hotplug path ACPI: processor: idle: Reset power_setup_done flag on initialization failure ACPI: TAD: Add alarm support to the RTC class device interface ...
2026-04-13drm/xe/debugfs: Correct printing of register whitelist rangesMatt Roper
The register-save-restore debugfs prints whitelist entries as offset ranges. E.g., REG[0x39319c-0x39319f]: allow read access for a single dword-sized register. However the GENMASK value used to set the lower bits to '1' for the upper bound of the whitelist range incorrectly included one more bit than it should have, causing the whitelist ranges to sometimes appear twice as large as they really were. For example, REG[0x6210-0x6217]: allow rw access was also intended to be a single dword-sized register whitelist (with a range 0x6210-0x6213) but was printed incorrectly as a qword-sized range because one too many bits was flipped on. Similar 'off by one' logic was applied when printing 4-dword register ranges and 64-dword register ranges as well. Correct the GENMASK logic to print these ranges in debugfs correctly. No impact outside of correcting the misleading debugfs output. Fixes: d855d2246ea6 ("drm/xe: Print whitelist while applying") Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260408-regsr_wl_range-v1-1-e9a28c8b4264@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13drm/xe: Mark ROW_CHICKEN5 as a masked registerMatt Roper
ROW_CHICKEN5 is a masked register (i.e., to adjust the value of any of the lower 16 bits, the corresponding bit in the upper 16 bits must also be set). Add the XE_REG_OPTION_MASKED to its definition; failure to do so will cause workaround updates of this register to not apply properly. Bspec: 56853 Fixes: 835cd6cbb0d0 ("drm/xe/xe3p_lpg: Add initial workarounds for graphics version 35.10") Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-3-e206a62ee38f@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13drm/xe/tuning: Use proper register offset for GAMSTLB_CTRLMatt Roper
From Xe2 onward (i.e., all platforms officially supported by the Xe driver), the GAMSTLB_CTRL register is located at offset 0x477C and represented by the macro "GAMSTLB_CTRL" in code. However the register formerly resided at offset 0xCF4C on Xe1-era platforms, and we also have macro XEHP_GAMSTLB_CTRL that represents this old offset in the unofficial/developer-only Xe1 code. When tuning for the register was added for Xe3p_LPG, the old Xe1-era macro was accidentally used instead of the proper macro for Xe2 and beyond, causing the tuning to not be applied properly. Use the proper definition so that the correct offset is written to. Bspec: 59298 Fixes: 377c89bfaa5d ("drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KB") Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-2-e206a62ee38f@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13drm/xe/tuning: Stop applying CCCHKNREG1 tuning from Xe3p onwardMatt Roper
Whereas the tuning guide gave guidance on adjusting various CCCHKNREG1 on past platforms, starting from Xe3p the guidance is "Leave register at HW default settings." Set a version range upper bound of "34.99" so that the current programming will stop being applied on any Xe3p platforms that have graphics version 35. Bspec: 72161 Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-1-e206a62ee38f@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13Merge tag 'vfs-7.1-rc1.kino' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs i_ino updates from Christian Brauner: "For historical reasons, the inode->i_ino field is an unsigned long, which means that it's 32 bits on 32 bit architectures. This has caused a number of filesystems to implement hacks to hash a 64-bit identifier into a 32-bit field, and deprives us of a universal identifier field for an inode. This changes the inode->i_ino field from an unsigned long to a u64. This shouldn't make any material difference on 64-bit hosts, but 32-bit hosts will see struct inode grow by at least 4 bytes. This could have effects on slabcache sizes and field alignment. The bulk of the changes are to format strings and tracepoints, since the kernel itself doesn't care that much about the i_ino field. The first patch changes some vfs function arguments, so check that one out carefully. With this change, we may be able to shrink some inode structures. For instance, struct nfs_inode has a fileid field that holds the 64-bit inode number. With this set of changes, that field could be eliminated. I'd rather leave that sort of cleanups for later just to keep this simple" * tag 'vfs-7.1-rc1.kino' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group() EVM: add comment describing why ino field is still unsigned long vfs: remove externs from fs.h on functions modified by i_ino widening treewide: fix missed i_ino format specifier conversions ext4: fix signed format specifier in ext4_load_inode trace event treewide: change inode->i_ino from unsigned long to u64 nilfs2: widen trace event i_ino fields to u64 f2fs: widen trace event i_ino fields to u64 ext4: widen trace event i_ino fields to u64 zonefs: widen trace event i_ino fields to u64 hugetlbfs: widen trace event i_ino fields to u64 ext2: widen trace event i_ino fields to u64 cachefiles: widen trace event i_ino fields to u64 vfs: widen trace event i_ino fields to u64 net: change sock.sk_ino and sock_i_ino() to u64 audit: widen ino fields to u64 vfs: widen inode hash/lookup functions to u64
2026-04-13drm/i915/dp: Make the RGB fallback for "4:2:0 only" modes the last resortVille Syrjälä
Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes already during the first pass when respect_downstream_limits==true. It seems better to try everything else first (like ignoring TMDS clock limits) while still preferring 4:2:0, and only if everything else has failed fall back to RGB. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-10-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Make the RGB fallback for "4:2:0 only" modes the last resortVille Syrjälä
Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes already during the first pass when respect_downstream_limits==true. It seems better to try everything else first (like ignoring TMDS clock limits) while still preferring 4:2:0, and only if everything else has failed fall back to RGB. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-9-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Validate sink format in .mode_valid()Ville Syrjälä
Make sure the sink supports our chosen sink format. I suppose it might be at least possible that some PCONs might not snoop the EDID hard enough and filter out all the modes that they should. Also if we ever want to add a similar "force DVI" knob to DP outputs that we have for native HDMI, we'd need to manually get rid of anything DVI sinks can't handle. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-8-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Require a HDMI sink for YCbCr output via PCONVille Syrjälä
DVI sinks can't deal with YCbCr. Make sure we have a HDMI sink connected after the PCON before doing YCbCr 4:2:0 output. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-7-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Validate "4:2:0 also" modes twiceVille Syrjälä
Currently we only validate "4:2:0 also" modes as RGB. But if that fails we could perhaps still use the mode in with 4:2:0 output. All we have to do is retry the validation with the different sink format. So far we did the double validation only so far as it affects PCON TMDS clock limits. But validating everything twice seems a bit more sane. Note that intel_dp_output_format() might still end up picking RGB for the actual output format (and letting PCON deal with the YCbCr conversion). So I suppose we could still fail the validation due to that, and forcing even the output format to 4:2:0 might solve it on a third try. But we'd need the same fallback logic in intel_dp_compute_config(). For now this seems sufficient. v2: Pass output_format to intel_dp_mode_min_link_bpp_x16() Add TODO about remaining issues Nuke intel_dp_sink_format() Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-6-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Restructure the sink/output format selectionVille Syrjälä
Restructure intel_dp_compute_output_format() to resemble the new intel_hdmi_compute_output_formats(). Again, we basically have two main code paths: - YCbCr 4:2:0 only modes - everything else including YCbCr 4:2:0 also modes Take the exact same approach with the DP code, making the format selection much less convoluted. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-5-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Restructure 4:2:0 vs. 4:4:4 mode validationVille Syrjälä
Restructure the HDMI mode validation to resemble the new intel_hdmi_compute_formats(). Keeping the two in sync helps to avoid different bugs in each. The main difference between mode_valid() and intel_hdmi_compute_formats() is that we don't want the Hail Mary RGB fallback for "4:2:0 only" modes. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-4-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Restructure the sink/output format selectionVille Syrjälä
intel_hdmi_compute_output_format() is a bit of a mess. Try to restructure it into a more readable form. Right now we basically have two main code paths: - YCbCr 4:2:0 only modes - everything else including YCbCr 4:2:0 also modes Those two basically do the same two steps (try 4:2:0 and try 4:4:4) but in opposite orders. Let's write that out in a more explicit if-else form. And since I'm running out of function names I'll rename the function with that high level logic into intel_hdmi_compute_formats() and it will call (the new) intel_hdmi_compute_output_format() with an explicit sink_format as needed. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-3-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Add missing intel_pfit_mode_valid() for 4:2:0 also modesVille Syrjälä
intel_hdmi_mode_valid() is calling intel_pfit_mode_valid() only on the first attempt (4:2:0 for "4:2:0 only" modes, 4:4:4 for everything else). Add the call also for the "4:2:0 also" modes case so that we actually know the pipe scaler can actually produce the 4:2:0 output. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-2-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13Merge tag 'rust-7.1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust updates from Miguel Ojeda: "Toolchain and infrastructure: - Bump the minimum Rust version to 1.85.0 (and 'bindgen' to 0.71.1). As proposed in LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum versions. Debian Trixie was released on 2025-08-09 with a Rust 1.85.0 and 'bindgen' 0.71.1 toolchain, which is a fair amount of time for e.g. kernel developers to upgrade. Other major distributions support a Rust version that is high enough as well, including: + Arch Linux. + Fedora Linux. + Gentoo Linux. + Nix. + openSUSE Slowroll and openSUSE Tumbleweed. + Ubuntu 25.10 and 26.04 LTS. In addition, 24.04 LTS using their versioned packages. The merged patch series comes with the associated cleanups and simplifications treewide that can be performed thanks to both bumps, as well as documentation updates. In addition, start using 'bindgen''s '--with-attribute-custom-enum' feature to set the 'cfi_encoding' attribute for the 'lru_status' enum used in Binder. Link: https://lwn.net/Articles/1050174/ [1] - Add experimental Kconfig option ('CONFIG_RUST_INLINE_HELPERS') that inlines C helpers into Rust. Essentially, it performs a step similar to LTO, but just for the helpers, i.e. very local and fast. It relies on 'llvm-link' and its '--internalize' flag, and requires a compatible LLVM between Clang and 'rustc' (i.e. same major version, 'CONFIG_RUSTC_CLANG_LLVM_COMPATIBLE'). It is only enabled for two architectures for now. The result is a measurable speedup in different workloads that different users have tested. For instance, for the null block driver, it amounts to a 2%. - Support global per-version flags. While we already have per-version flags in many places, we didn't have a place to set global ones that depend on the compiler version, i.e. in 'rust_common_flags', which sometimes is needed to e.g. tweak the lints set per version. Use that to allow the 'clippy::precedence' lint for Rust < 1.86.0, since it had a change in behavior. - Support overriding the crate name and apply it to Rust Binder, which wanted the module to be called 'rust_binder'. - Add the remaining '__rust_helper' annotations (started in the previous cycle). 'kernel' crate: - Introduce the 'const_assert!' macro: a more powerful version of 'static_assert!' that can refer to generics inside functions or implementation bodies, e.g.: fn f<const N: usize>() { const_assert!(N > 1); } fn g<T>() { const_assert!(size_of::<T>() > 0, "T cannot be ZST"); } In addition, reorganize our set of build-time assertion macros ('{build,const,static_assert}!') to live in the 'build_assert' module. Finally, improve the docs as well to clarify how these are different from one another and how to pick the right one to use, and their equivalence (if any) to the existing C ones for extra clarity. - 'sizes' module: add 'SizeConstants' trait. This gives us typed 'SZ_*' constants (avoiding casts) for use in device address spaces where the address width depends on the hardware (e.g. 32-bit MMIO windows, 64-bit GPU framebuffers, etc.), e.g.: let gpu_heap = 14 * u64::SZ_1M; let mmio_window = u32::SZ_16M; - 'clk' module: implement 'Send' and 'Sync' for 'Clk' and thus simplify the users in Tyr and PWM. - 'ptr' module: add 'const_align_up'. - 'str' module: improve the documentation of the 'c_str!' macro to explain that one should only use it for non-literal cases (for the other case we instead use C string literals, e.g. 'c"abc"'). - Disallow the use of 'CStr::{as_ptr,from_ptr}' and clean one such use in the 'task' module. - 'sync' module: finish the move of 'ARef' and 'AlwaysRefCounted' outside of the 'types' module, i.e. update the last remaining instances and finally remove the re-exports. - 'error' module: clarify that 'from_err_ptr' can return 'Ok(NULL)', including runtime-tested examples. The intention is to hopefully prevent UB that assumes the result of the function is not 'NULL' if successful. This originated from a case of UB I noticed in 'regulator' that created a 'NonNull' on it. Timekeeping: - Expand the example section in the 'HrTimer' documentation. - Mark the 'ClockSource' trait as unsafe to ensure valid values for 'ktime_get()'. - Add 'Delta::from_nanos()'. 'pin-init' crate: - Replace the 'Zeroable' impls for 'Option<NonZero*>' with impls of 'ZeroableOption' for 'NonZero*'. - Improve feature gate handling for unstable features. - Declutter the documentation of implementations of 'Zeroable' for tuples. - Replace uses of 'addr_of[_mut]!' with '&raw [mut]'. rust-analyzer: - Add type annotations to 'generate_rust_analyzer.py'. - Add support for scripts written in Rust ('generate_rust_target.rs', 'rustdoc_test_builder.rs', 'rustdoc_test_gen.rs'). - Refactor 'generate_rust_analyzer.py' to explicitly identify host and target crates, improve readability, and reduce duplication. And some other fixes, cleanups and improvements" * tag 'rust-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (79 commits) rust: sizes: add SizeConstants trait for device address space constants rust: kernel: update `file_with_nul` comment rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0 rust: kbuild: support global per-version flags rust: declare cfi_encoding for lru_status docs: rust: general-information: use real example docs: rust: general-information: simplify Kconfig example docs: rust: quick-start: remove GDB/Binutils mention docs: rust: quick-start: remove Nix "unstable channel" note docs: rust: quick-start: remove Gentoo "testing" note docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title docs: rust: quick-start: update minimum Ubuntu version docs: rust: quick-start: update Ubuntu versioned packages docs: rust: quick-start: openSUSE provides `rust-src` package nowadays rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1 rust: kbuild: update `bindgen --rust-target` version and replace comment rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1 rust: rust_is_available: remove warning for `bindgen` 0.66.[01] rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie) rust: block: update `const_refs_to_static` MSRV TODO comment ...
2026-04-13drm/bridge: analogix_dp: Apply panel_bridge helperDamon Ding
In order to unify the handling of the panel and bridge, apply panel_bridge helpers for Analogix DP driver. With this patch, the bridge support will also become available. The following changes have ben made: - Apply plane_bridge helper to wrap the panel as the bridge. - Remove the explicit panel APIs calls, which can be replaced with the automic bridge APIs calls wrapped by the panel. - Remove the unnecessary analogix_dp_bridge_get_modes(). Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-9-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Remove bridge disabing and panel unpreparing in ↵Damon Ding
analogix_dp_unbind() The analogix_dp_unbind() should be balanced with analogix_dp_bind(). There are no bridge enabling and panel preparing in analogix_dp_bind(), so it should be reasonable to remove the bridge disabing and panel unpreparing in analogix_dp_unbind(). Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-8-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-03 21:27:58 +0000