summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-13drm/bridge: analogix_dp: Attach the next bridge in analogix_dp_bridge_attach()Damon Ding
Uniformly, move the next bridge attachment to the Analogix side rather than scattered on Rockchip and Exynos sides. It can also help get rid of the callback &analogix_dp_plat_data.attach() and make codes more concise. 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-7-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/exynos: exynos_dp: Apply analogix_dp_finish_probe()Damon Ding
Apply analogix_dp_finish_probe() in order to move the panel/bridge parsing from Exynos side to the Analogix side. 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-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/rockchip: analogix_dp: Apply analogix_dp_finish_probe()Damon Ding
Apply analogix_dp_finish_probe() in order to move the panel/bridge parsing from Rockchip side to the Analogix side. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-5-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Add new API analogix_dp_finish_probe()Damon Ding
Since the panel/bridge should logically be positioned behind the Analogix bridge in the display pipeline, it makes sense to handle the panel/bridge parsing on the Analogix side. Therefore, we add a new API analogix_dp_finish_probe(), which combines the panel/bridge parsing with component addition, to do it. In order to process component binding right after the probe completes, the &analogix_dp_plat_data.ops is newly added to pass &component_ops, for which the &dp_aux_ep_device_with_data.done_probing() of DP AUX bus only supports passing &drm_dp_aux. 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-4-damon.ding@rock-chips.com [Luca: propagate 'depends on OF' to DRM_ANALOGIX_DP and reverse dependencies] Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13Merge branch 'nocache-cleanup'Linus Torvalds
This series cleans up some of the special user copy functions naming and semantics. In particular, get rid of the (very traditional) double underscore names and behavior: the whole "optimize away the range check" model has been largely excised from the other user accessors because it's so subtle and can be unsafe, but also because it's just not a relevant optimization any more. To do that, a couple of drivers that misused the "user" copies as kernel copies in order to get non-temporal stores had to be fixed up, but that kind of code should never have been allowed anyway. The x86-only "nocache" version was also renamed to more accurately reflect what it actually does. This was all done because I looked at this code due to a report by Jann Horn, and I just couldn't stand the inconsistent naming, the horrible semantics, and the random misuse of these functions. This code should probably be cleaned up further, but it's at least slightly closer to normal semantics. I had a more intrusive series that went even further in trying to normalize the semantics, but that ended up hitting so many other inconsistencies between different architectures in this area (eg 'size_t' vs 'unsigned long' vs 'int' as size arguments, and various iovec check differences that Vasily Gorbik pointed out) that I ended up with this more limited version that fixed the worst of the issues. Reported-by: Jann Horn <jannh@google.com> Tested-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/all/CAHk-=wgg1QVWNWG-UCFo1hx0zqrPnB3qhPzUTrWNft+MtXQXig@mail.gmail.com/ * nocache-cleanup: x86-64/arm64/powerpc: clean up and rename __copy_from_user_flushcache x86: rename and clean up __copy_from_user_inatomic_nocache() x86-64: rename misleadingly named '__copy_user_nocache()' function
2026-04-13drm/bridge: analogix_dp: Apply drm_bridge_connector helperDamon Ding
Initialize bridge_connector for both Rockchip and Exynos encoder sides. Then, make DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory for Analogix bridge side, as the private &drm_connector is no longer created. The previous &drm_connector_funcs and &drm_connector_helper_funcs APIs are replaced by the corresponding &drm_bridge_funcs APIs: analogix_dp_atomic_check() -> analogix_dp_bridge_atomic_check() analogix_dp_detect() -> analogix_dp_bridge_detect() analogix_dp_get_modes() -> analogix_dp_bridge_get_modes() analogix_dp_bridge_edid_read() Additionally, the compatibilities of Analogix DP bridge based on whether the next bridge is a 'panel'. If it is, OP_MODES and OP_DETECT are supported; If not (the next bridge is a 'monitor' or a bridge chip), OP_EDID and OP_DETECT are supported. The devm_drm_bridge_add() is placed in analogix_dp_bind() instead of analogix_dp_probe(), because the type of next bridge (the panel, monitor or bridge chip) can only be determined after the probe process has fully completed. 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-3-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Pass struct drm_atomic_state* for ↵Damon Ding
analogix_dp_bridge_mode_set() To avoid using &analogix_dp_device.connector for compatibility with the bridge connector framework, get &drm_connector from &drm_atomic_state instead. 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> Link: https://patch.msgid.link/20260413132551.1049307-2-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/panthor: Fix outdated function documentationAdrián Larumbe
'vm' is no longer allowed to be NULL. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408191228.537625-2-adrian.larumbe@collabora.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-04-13drm/panthor: Extend VM locked region for remap case to be a supersetAdrián Larumbe
In the event of an sm_step_remap() that leads to a partial unmap of a transparent huge page, the new locked region required by an extended unmap might not be a superset of the original one. Then, if it leaves a portion of the initially requested one out, the ensuing map will trigger a warning. Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408191228.537625-1-adrian.larumbe@collabora.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-04-13drm/i915/mst: Remove redundant has_pch_encoder=false assignmentVille Syrjälä
The entire crtc_state is zeroed by default, there is no need to fiddle with crtc_state->has_pch_encoder unless we are actually dealing with a port on the PCH (which we never are for DP MST). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409100841.1907-2-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-04-13drm/i915/mst: Call intel_pfit_compute_config() for sharpness filterVille Syrjälä
The sharpness filter property is on the CRTC (as opposed to the connector) so the expectation is that it's usable on all output types. Since the sharpness filter is now fully integrateds into the normal pfit code intel_pfit_compute_config() must be called from the encoder .compute_config() on all relevant output types. Sharpness filter is supported on LNL+ so only HDMI and DP SST/MST outputs are actually relevant. I already took care of HDMI and DP SST, but (as usual) forgot about DP MST. Add the missing intel_pfit_compute_config() call to make the sharpness filter operational on DP MST as well. Cc: Nemesa Garg <nemesa.garg@intel.com> Fixes: d4686f34bbeb ("drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409100841.1907-1-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-04-13drm/bridge: stm_lvds: Do not fail atomic_check on disabled connectorMarek Vasut
If the connector is disabled, the new connector state has .crtc field set to NULL and there is nothing more to validate after that point. The .crtc field being NULL is not an error. Test for .crtc being NULL, and if it is NULL, exit early with return 0. This fixes a failure in suspend/resume path, where the connector is already disabled, but .atomic_check is called, fails, returns -EINVAL and blocks the suspend entry. Fixes: aca1cbc1c986 ("drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver") Signed-off-by: Marek Vasut <marex@nabladev.com> Acked-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com> Link: https://patch.msgid.link/20260409024928.344010-1-marex@nabladev.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2026-04-13drm/i915: Walk crtcs in pipe orderVille Syrjälä
Currently our crtcs are registered in pipe order, and thus all the for_intel_crtc*() iterators walk the crtcs in pipe order. There are a bunch of places that more or less depend on that. Eg. during plane updates and such we want joined pipes to be processed back-to-back to give a better chance of an atomic update across the whole set. When we start to register crtcs in a different order we don't want to change the order in which the pipes get handled. Decouple the for_each_intel_crtc*() iterators from the crtc registration order by using a separate list which will be sorted by the pipe rather than the crtc index. We could probably use a simple array or something, but that would require some kind of extra iterator variable for the macros, and thus would require a lot more changes. Using a linked list keeps the fallout minimal. We can look at using a more optimal data structure later. I also added this extra junk to the atomic state iterators: "(__i) = drm_crtc_index(&(crtc)->base), (void)(__i)" even though the macro itself no longer needs the "__i" iterator. This in case the "__i" is used by the caller, and to avoid compiler warnings if it's completely unused now. v2: Flip the pipe comparison (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260408155744.13326-3-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-13drm/i915/joiner: Make joiner "nomodeset" state copy independent of pipe orderVille Syrjälä
Currently the joiner primary->secondary hw state copy still happens from the main compute_config loop alongside the primary uapi->hw state copy. The primary uapi->hw state copy must therefore happen first, or else we'll end up copying stale junk into the secondary. We have a WARN in intel_atomic_check_joiner() to make sure the CRTCs will be walked in the correct order. The plan is to reoder the CRTCs, which would mess up the order, unless we also adjust the iterators to keep the pipe order. The actual plan is to do both, so technically we should be able to just remove the WARN and call it a day. But relying on the iteration order like this is fragile and confusing, so let's move the "nomodeset" joiner state copy into the later loop where the "modeset" state copy is also done. The first loop having completely finished, we are guaranteed to have up to date hw state on the primary when we do the copy to the secondary. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260408155744.13326-2-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-12drm/pagemap: Fix drm_pagemap_migrate_unmap_pages kerneldocMatthew Brost
Replace @dma_addr with @pagemap_addr in the function documentation, as @pagemap_addr is the actual name of the function argument. Suggested-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-6-matthew.brost@intel.com
2026-04-12drm/pagemap: Use dma-map IOVA alloc, link, and sync API for DRM pagemapMatthew Brost
The dma-map IOVA alloc, link, and sync APIs perform significantly better than dma-map / dma-unmap, as they avoid costly IOMMU synchronizations. This difference is especially noticeable when mapping a 2MB region in 4KB pages. Use the IOVA alloc, link, and sync APIs for DRM pagemap, which create DMA mappings between the CPU and GPU for copying data. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-5-matthew.brost@intel.com
2026-04-12drm/pagemap: Split drm_pagemap_migrate_map_pages into device / systemMatthew Brost
Split drm_pagemap_migrate_map_pages into device / system helpers clearly seperating these operations. Will help with upcoming changes to split IOVA allocation steps. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-4-matthew.brost@intel.com
2026-04-12drm/pagemap: Drop source_peer_migrates flag and assume trueMatthew Brost
All current users of DRM pagemap set source_peer_migrates to true during migration, and it is unclear whether any user would ever want to disable this for performance reasons or for features such as compression. It is also questionable whether this flag could be made to work with high-speed fabric mapping APIs. Drop the flag and make DRM pagemap unconditionally assume that source_peer_migrates is true. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-3-matthew.brost@intel.com
2026-04-12drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVMMatthew Brost
The dma-map IOVA alloc, link, and sync APIs perform significantly better than dma-map / dma-unmap, as they avoid costly IOMMU synchronizations. This difference is especially noticeable when mapping a 2MB region in 4KB pages. Use the IOVA alloc, link, and sync APIs for GPU SVM, which create DMA mappings between the CPU and GPU. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260410205929.3914474-2-matthew.brost@intel.com
2026-04-12drm/xe/pf: Perform fair scheduling auto-provisioningMichal Wajdeczko
Default VF scheduling configuration is the same as for the PF and includes unlimited execution quantum (EQ) and unlimited preemption timeout (PT). While this setup gives the most flexibility it does not protect the PF or VFs from other VF that could constantly submit workloads without any gaps that would let GuC do a VF-switch. To avoid that, do some trivial auto-provisioning and configure PF and all VFs with 16ms EQ and PT. This setup should allow GuC to perform a full round-robin with up to 63 VFs within 2s, which in turn should match expectations from most of the VMs using VFs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> #v1 Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-14-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Extract helpers for bulk EQ/PT provisioningMichal Wajdeczko
We already have functions to bulk provision execution quantum and preemption timeout, but they are applying changes to all possible VFs, while in upcoming patch we would like to provision only subset of available VFs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-13-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Extract helper to show which VFs are provisionedMichal Wajdeczko
In upcoming patches we will want to show which VFs were already provisioned with resources other than LMEM(VRAM). Convert code from the LMEM reporting function into a more generic helper that can handle both u32 and u64 resources and can report also PF. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-12-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Reprovision scheduling to default when no VFsMichal Wajdeczko
Once we have disabled VFs there is no point in keeping potentially limited PF scheduling provisioning as we want to complete a cleanup of the VFs resources and return to the pure native mode, the same as before VFs were enabled, as soon as possible. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-11-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Allow to change sched_if_idle policy under lockMichal Wajdeczko
In upcoming patch we will need to update sched_if_idle policy when we already hold the provisioning mutex. Split existing function into two variants to allow that. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-10-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Check EQ/PT/PRIO when testing VF configMichal Wajdeczko
In addition to the hard resources (like GGTT, CTXs, DBs) we should also check if VF was already configured (by sysfs or debugfs) with optional parameters like execution quantum (EQ), preemption timeout (PT) or scheduling priority (PRIO) as otherwise we might miss to send to the GuC updated latest values after a resume or GT reset. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-9-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Encode scheduling priority KLV if neededMichal Wajdeczko
After a reset we missed to reprovision VFs scheduling priority config. But as of today, the GuC firmware allows to change scheduling priority using config SCHED_PRIORITY KLV only for the PF and configuration of all VFs relies on the previously applied value of the SCHED_IF_IDLE policy. Use this policy value to check and decide whether we need to encode VF priority KLV while reprovisioning this VF. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-8-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Don't reprovision policies if already defaultMichal Wajdeczko
There is no need to send policy updates to the GuC if policies were not changed from the default settings (usually zero value). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-7-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Reprovision policy settings after GT resetMichal Wajdeczko
In addition to the reprovisioning of individual VFs configurations, we should also reprovision GuC global policy settings. Note that we already had a draft function for that but we missed to call it once we started handling GT reset. Reuse it now but don't take extra RPM as this is now a caller responsibility and drop unused parameter. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-6-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Print applied policy KLVsMichal Wajdeczko
Under CONFIG_DRM_XE_DEBUG_SRIOV print all policy KLVs sent to the GuC for better diagnostics. This is similar what we are already doing with VF configuration KLVs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-5-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Force new VFs prorities only onceMichal Wajdeczko
We should force change of VFs scheduling priorities only after initial change of the SCHED_IF_IDLE policy. Doing that also during any later policy reprovisioning will overwrite changes done on the individual per-VF scheduling priorities (currently only for PF). While around also move priority change code to the _config component to maintain a proper isolation. Also document our expectation about the GuC version where the new meaning of the policy KLV is present. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-4-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Fix pf_get_sched_priority() function signatureMichal Wajdeczko
The pf_get_sched_priority() function returns scheduling priority that we defined as u32 so while it works we shouldn't return int. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-3-michal.wajdeczko@intel.com
2026-04-12drm/xe/guc: Update POLICY_SCHED_IF_IDLE documentationMichal Wajdeczko
Starting from the GuC firmware version 70.12.0 the meaning of the POLICY_SCHED_IF_IDLE has changed, which now acts as a bulk update of the VF_CFG_SCHED_PRIORITY configurations of all VFs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-2-michal.wajdeczko@intel.com
2026-04-11drm/xe/guc: Add support for NO_RESPONSE_BUSY in CTBMichal Wajdeczko
We only have support for G2H NO_RESPONSE_BUSY messages over MMIO, but it turned out that GuC also uses that type of messages in CTB. The following error was recently observed on BMG after adding VGT policy updates to the GT restart sequence: [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: G2H channel broken on read, type=3, reset required [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: CT dequeue failed: -95 ... [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: Timed out wait for G2H, fence 21965, action 5502, done no [] xe 0000:03:00.0: [drm] PF: Tile0: GT1: Failed to push 1 policy KLV (-ETIME) [] xe 0000:03:00.0: [drm] Tile0: GT1: { key 0x8004 : no value } # engine_group_config where type=3 was this unrecognized NO_RESPONSE_BUSY message. Note that GuC might send the real RESPONSE message right after the BUSY message, so we must be prepared to update our g2h_fence data twice before sender actually wakes up and clears the flags. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260410110457.573-1-michal.wajdeczko@intel.com
2026-04-11Merge tag 'drm-intel-fixes-2026-04-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Drop check for changed VM in EXECBUF - Fix refcount underflow race in intel_engine_park_heartbeat - Do not use pipe_src as borders for SU area in PSR Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/add6fPHRC7Bc8Uri@jlahtine-mobl
2026-04-10drm/connector: Make drm_connector_attach_hdr_output_metadata_property() ↵Maíra Canal
return void drm_connector_attach_hdr_output_metadata_property() always returns zero, since drm_object_attach_property() returns void. No caller checks the return value, so change the return type to void. Also fix a typo in the kerneldoc ("HDR_OUTPUT_METADA" -> "HDR_OUTPUT_METADATA"). Reviewed-by: Melissa Wen <mwen@igalia.com> Link: https://patch.msgid.link/20260330133446.3265938-2-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-04-10drm/i915/fb: Use intel_fb_needs_pot_stride_remap() in intel_fb_view_init()Ville Syrjälä
Replace the open coded intel_fb_needs_pot_stride_remap() check inside intel_fb_view_init() with the real thing. The current check doesn't have the intel_fb_uses_dpt() in there, but that is the only situation when we use the remapped view, and thus was always implied. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/fb: Use i915_gtt_view_is_*()Ville Syrjälä
Replace the naked GTT view type checks with the new i915_gtt_view_is_*() helpers. This isolates some of the code from GTT view implementation details. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/vma: Add helpers to check GTT view typeVille Syrjälä
I915_GTT_VIEW_ROTATED is going away and being replaced by just I915_GTT_VIEW_REMAPPED, so we're going to need another way to determine if the view is rotated or not (since width/height will need to be swapped when operating on the destination coordinate space). Provide small helper functions to hide such implementation details from most of the code using GTT views. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/fb: Reject per-plane remapping with DPTVille Syrjälä
We currently create a single DPT for the entire FB, so we can't actually do the per-plane remap. Reject it for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/fb: Make intel_fb_needs_pot_stride_remap() staticVille Syrjälä
intel_fb_needs_pot_stride_remap() isn't needed outside intel_fb.c. Make it static. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/fb: Nuke intel_tile_row_size()Ville Syrjälä
intel_tile_row_size() is unused. Nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm: rz-du: Ensure correct suspend/resume ordering with VSPTommaso Merciai
The VSP serves as an interface to memory and a compositor to the DU. It therefore needs to be suspended after and resumed before the DU, to be properly stopped and restarted in a controlled fashion driven by the DU driver. This currently works by chance. Avoid relying on luck by enforcing the correct suspend/resume ordering with device links. Based on similar work done by Laurent Pinchart for R-Car DU. commit db5be3a7d6bd ("drm: rcar-du: Ensure correct suspend/resume ordering with VSP") Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260330144651.817338-1-tommaso.merciai.xr@bp.renesas.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-04-10Merge tag 'topic/step-2026-04-09' of ↵Jani Nikula
https://gitlab.freedesktop.org/drm/i915/kernel into drm-intel-next topic/step to unify xe and i915 on common steppings header and enum Signed-off-by: Jani Nikula <jani.nikula@intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/cc1ff0a476ff457e88251e22b83c1a45ada11ecc@intel.com
2026-04-10drm: rcar-du: Fix crash when no CMM is availableLaurent Pinchart
Commit 3bce3fdd1ff2 ("drm: rcar-du: Don't leak device_link to CMM") refactored CMM handling, and introduced an incorrect test for CMM availability. When no CMM is present, the rcrtc->cmm field is NULL, testing rcrtc->cmm->dev causes a NULL pointer dereference. This slipped through testing as all tests were run with the CMM present. Fix this issue by correctly testing for rcrtc->cmm. Fixes: 3bce3fdd1ff2 ("drm: rcar-du: Don't leak device_link to CMM") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/dri-devel/CAMuHMdXomz9GFDqkBjGX9Sda_GLccPcrihvFbOz0GAitDVNTbw@mail.gmail.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260408124205.1962448-1-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-04-10Merge tag 'drm-misc-fixes-2026-04-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Several fixes for v3d about memory leak, runtime PM, and locking, and a Kconfig improvement for ethosu. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260409-omniscient-tomato-coucal-edbadc@penduick
2026-04-10Merge tag 'drm-misc-next-fixes-2026-04-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Short summary of fixes pull: dma-buf: - fence: fix docs for dma_fence_unlock_irqrestore() fb-helper: - unlock in error path gem-shmem: - fix PMD write update gem-vram: - remove obsolete documentation ivpu: - fix device-recovery handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260409113921.GA181028@linux.fritz.box
2026-04-10drm/panel: simple: add Waveshare LCD panelsDmitry Baryshkov
Waveshare have a serie of DSI panel kits with the DPI or LVDS panel being attached to the DSI2DPI or DSI2LVDS bridge. The commit 46be11b678e0 ("drm/panel: simple: Add Waveshare 13.3" panel support") added definitions for one of those panels, describe the rest of them. Note, since the panels are hidden behind the bridges which are not being programmed by the kernel, I could not confirm the pixel format for the panels. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260331-ws-lcd-v2-4-a1add63b6eb6@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-04-10drm/ttm/tests: Remove checks from ttm_pool_free_no_dma_allocMaarten Lankhorst
On !x86, the pool type is never initialised, and the pages are freed back to the system. The test broke on the list_lru rewrite, but I'm not sure how that it was supposed to work previously. In the meantime CI is broken so reverting for now. Fixes: 444e2a19d7fd ("ttm/pool: port to list_lru. (v2)") Cc: Christian Koenig <christian.koenig@amd.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260409142658.1511941-2-dev@lankhorst.se
2026-04-10drm/ttm/tests: fix lru_count ASSERTMatthew Auld
On pool init we should expect the lru_count for each node to be zeroed as per __list_lru_init -> init_one_lru, but here we are asserting the opposite. Currently our CI is blowing up with: 10:23:33] # ttm_device_init_pools: ASSERTION FAILED at drivers/gpu/drm/ttm/tests/ttm_device_test.c:178 [10:23:33] Expected !list_lru_count(&pt.pages) to be false, but is true [10:23:33] [FAILED] DMA allocations, DMA32 required [10:23:33] [PASSED] No DMA allocations, DMA32 required [10:23:33] # ttm_device_init_pools: ASSERTION FAILED at drivers/gpu/drm/ttm/tests/ttm_device_test.c:178 [10:23:33] Expected !list_lru_count(&pt.pages) to be false, but is true Fixes: 444e2a19d7fd ("ttm/pool: port to list_lru. (v2)") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Ryszard Knop <ryszard.knop@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260409121512.81298-3-matthew.auld@intel.com
2026-04-09Merge branch 'acpi-driver'Rafael J. Wysocki
Merge ACPI core driver core driver updates and assorted driver updates related to ACPI support for 7.1-rc1: - 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) * acpi-driver: watchdog: ni903x_wdt: Convert to a platform driver ACPI: PAD: xen: Convert to a platform driver ACPI: AC: Define ACPI_AC_CLASS in one place ACPI: driver: Do not set acpi_device_class() unnecessarily ACPI: driver: Avoid using pnp.device_class for netlink handling ACPI: event: Redefine acpi_notifier_call_chain() ACPI: driver: Do not set acpi_device_name() unnecessarily ACPI: video: Consolidate pnp.bus_id workarounds handling ACPI: video: Rework checking for duplicate video bus devices driver core: auxiliary bus: Introduce dev_is_auxiliary() ACPI: PAD: Rearrange notify handler installation and removal ACPI: AC: Get rid of unnecessary declarations
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-04 03:57:04 +0000