summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-06-09drm/xe: Add xe_ggtt_might_lockMaarten Lankhorst3-1/+15
Another requirement of hiding more of struct xe_ggtt. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-3-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Use xe_ggtt_map_bo_unlocked for resumeMaarten Lankhorst3-5/+17
This is the first step to hide the details of struct xe_ggtt. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Remove IOSF_MBI select.Maarten Lankhorst1-1/+0
IOSF_MBI was only useful for some gen8 platforms, which were never supported by Xe. Presumably needed for display at one point, but display is fixed to put stubs in compat-i915-headers/vlv_sideband.h. (in drm-intel-next: vlv_iosf_sb.h) Link: https://lore.kernel.org/r/20250605074644.71036-1-dev@lankhorst.se Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm: renesas: rz-du: Implement MIPI DSI host transfersHugo Villeneuve2-0/+240
Add support for sending MIPI DSI command packets from the host to a peripheral. This is required for panels that need configuration before they accept video data. Also for long reads to work properly, set DCS maximum return packet size to the value of the DMA buffer size. Based on Renesas Linux kernel v5.10 repos [1]. Link: https://github.com/renesas-rz/rz_linux-cip.git Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Tested-by: Chris Brandt <Chris.Brandt@renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250604145306.1170676-2-hugo@hugovil.com
2025-06-09drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rateKrzysztof Kozlowski1-0/+7
Driver unconditionally saves current state on first init in dsi_pll_10nm_init(), but does not save the VCO rate, only some of the divider registers. The state is then restored during probe/enable via msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() -> dsi_10nm_pll_restore_state(). Restoring calls dsi_pll_10nm_vco_set_rate() with pll_10nm->vco_current_rate=0, which basically overwrites existing rate of VCO and messes with clock hierarchy, by setting frequency to 0 to clock tree. This makes anyway little sense - VCO rate was not saved, so should not be restored. If PLL was not configured configure it to minimum rate to avoid glitches and configuring entire in clock hierarchy to 0 Hz. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/sz4kbwy5nwsebgf64ia7uq4ee7wbsa5uy3xmlqwcstsbntzcov@ew3dcyjdzmi2/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Fixes: a4ccc37693a2 ("drm/msm/dsi_pll_10nm: restore VCO rate during Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/654796/ Link: https://lore.kernel.org/r/20250520111325.92352-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-09drm/msm/disp: Correct porch timing for SDM845James A. MacInnes1-5/+9
Type-C DisplayPort inoperable due to incorrect porch settings. - Re-used wide_bus_en as flag to prevent porch shifting Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: James A. MacInnes <james.a.macinnes@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/636945/ Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-2-4954e51458f4@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-09drm/msm/dp: Disable wide bus support for SDM845James A. MacInnes1-1/+6
When widebus was enabled for DisplayPort in commit c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets") it was clarified that it is only supported on DPU 5.0.0 onwards which includes SC7180 on DPU revision 6.2. However, this patch missed that the description structure for SC7180 is also reused for SDM845 (because of identical io_start address) which is only DPU 4.0.0, leading to a wrongly enbled widebus feature and corruption on that platform. Create a separate msm_dp_desc_sdm845 structure for this SoC compatible, with the wide_bus_supported flag turned off. Fixes: c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets") Signed-off-by: James A. MacInnes <james.a.macinnes@gmail.com> [DB: reworded commit text following Marijn's suggestion] Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/636944/ Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-1-4954e51458f4@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-08treewide, timers: Rename from_timer() to timer_container_of()Ingo Molnar21-23/+29
Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
2025-06-06drm/xe/topology: Stop trying to fix programming mistakesMichal Wajdeczko1-2/+1
We shouldn't ever pass more DSS registers than our hardcoded limit, it should be sufficient to just assert that instead of trying to fix it, as this will never happen in the production driver. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250604202908.769-4-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-06drm/xe/topology: Use register array size instead magic numberMichal Wajdeczko1-2/+2
Since we keep registers in the array we can simply count them and stop relying on magic number when checking if didn't make mistake. Also we can switch to use xe_gt_assert() since it could be just our programming mistake during platform bringup, no need to keep drm_WARN() in the production driver. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250604202908.769-3-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-06drm/xe/topology: Simplify code for loading DSS maskMichal Wajdeczko1-15/+18
Instead of passing registers using va_list we can keep them in the static array and pass as such and also lower driver footprint: add/remove: 2/0 grow/shrink: 0/2 up/down: 24/-175 (-151) Function old new delta geometry_regs - 12 +12 compute_regs - 12 +12 xe_gt_topology_init 550 527 -23 load_dss_mask 449 297 -152 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250604202908.769-2-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-06drm/xe: don't store the xe device pointer inside xe_ttm_ttDave Airlie2-31/+32
This device pointer is nearly always available without storing an extra copy for each tt in the system. Just noticed this while reading over the xe shrinker code. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250605062103.1234620-1-airlied@gmail.com
2025-06-06Merge tag 'drm-fixes-2025-06-06' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds2-2/+4
Pull more drm fixes from Simona Vetter: "Another small batch of drm fixes, this time with a different baseline and hence separate. Drivers: - ivpu: - dma_resv locking - warning fixes - reset failure handling - improve logging - update fw file names - fix cmdqueue unregister - panel-simple: add Evervision VGG644804 Core Changes: - sysfb: screen_info type check - video: screen_info for relocated pci fb - drm/sched: signal fence of killed job - dummycon: deferred takeover fix" * tag 'drm-fixes-2025-06-06' of https://gitlab.freedesktop.org/drm/kernel: sysfb: Fix screen_info type check for VGA video: screen_info: Relocate framebuffers behind PCI bridges accel/ivpu: Fix warning in ivpu_gem_bo_free() accel/ivpu: Trigger device recovery on engine reset/resume failure accel/ivpu: Use dma_resv_lock() instead of a custom mutex drm/panel-simple: fix the warnings for the Evervision VGG644804 accel/ivpu: Reorder Doorbell Unregister and Command Queue Destruction accel/ivpu: Use firmware names from upstream repo accel/ivpu: Improve buffer object logging dummycon: Trigger redraw when switching consoles with deferred takeover drm/scheduler: signal scheduled fence when kill job
2025-06-06drm/xe/vf: Store the GuC FW info in guc->fwDaniele Ceraolo Spurio4-10/+64
The GuC compatibility version that we read from the CSS header in native/PF and the GuC VF version that we get when a VF handshakes with the GuC are the same version number, so we should store it into the same structure. This makes all the checks based on the compatibility version automatically work for VFs without having to copy the value over. For completion, also copy the wanted version and set the path to a known string to indicate that the FW is PF-loaded. This way all the info will be coherent when dumped from debugfs. v2: several code cleanups and style changes (Michal), rebase on bootstrap changes. v3: s/min/wanted/, clarify that handshake must happen before we can get the VF versions (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-10-daniele.ceraolospurio@intel.com
2025-06-06drm/xe/vf: Use uc_fw_version to store the negotiated GuC ABIDaniele Ceraolo Spurio2-76/+78
Instead of using a VF-specific type, we can use the common uc_fw_version structure. This also means that we can use the available macros to compare ABI versions. While at it, exit early from the bootstrap if this is not the first time we're doing it and the version hasn't changed, so we don't end up logging it multiple times. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-9-daniele.ceraolospurio@intel.com
2025-06-06drm/xe/vf: Boostrap all GTs immediately after MMIO initDaniele Ceraolo Spurio2-13/+6
Currently we perform the bootstrap for the primary GT early on during device init, while the media GT bootstrap happens when we try and fetch the hwconfig table. For consistency, move the bootstrap of the media GT happen at the same time as the primary GT, so that all the subsequent code can rely on both GTs being in the same state. v2: Also drop config query from min_guc_load since we now do it early (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-8-daniele.ceraolospurio@intel.com
2025-06-06drm/xe/uc: Prepare uc_fw_version for storing the VF ABI versionDaniele Ceraolo Spurio2-1/+3
The VF ABI version has a branch field, so to store it inside the uc_fw_version we need to add a new branch variable to the latter. Existing code needs to be updated to handle the fact that we have the new field. v2: split out to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-7-daniele.ceraolospurio@intel.com
2025-06-06Merge tag 'drm-next-2025-06-06' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds134-617/+2274
Pull drm fixes from Dave Airlie: "This is pretty much two weeks worth of fixes, plus one thing that might be considered next: amdkfd is now able to be enabled on risc-v platforms. Otherwise, amdgpu and xe with the majority of fixes, and then a smattering all over. panel: - nt37801: fix IS_ERR - nt37801: fix KConfig connector: - Fix null deref in HDMI audio helper. bridge: - analogix_dp: fixup clk-disable removal nouveau: - minor typo fix (',' vs ';') msm: - mailmap updates i915: - Fix the enabling/disabling of DP audio SDP splitting - Fix PSR register definitions for ALPM - Fix u32 overflow in SNPS PHY HDMI PLL setup - Fix GuC pending message underflow when submit fails - Fix GuC wakeref underflow race during reset xe: - Two documentation fixes - A couple of vm init fixes - Hwmon fixes - Drop reduntant conversion to bool - Fix CONFIG_INTEL_VSEC dependency - Rework eviction rejection of bound external bos - Stop re-submitting signalled jobs - A couple of pxp fixes - Add back a fix that got lost in a merge - Create LRC bo without VM - Fix for the above fix amdgpu: - UserQ fixes - SMU 13.x fixes - VCN fixes - JPEG fixes - Misc cleanups - runtime pm fix - DCN 4.0.1 fixes - Misc display fixes - ISP fix - VRAM manager fix - RAS fixes - IP discovery fix - Cleaner shader fix for GC 10.1.x - OD fix - Non-OLED panel fix - Misc display fixes - Brightness fixes amdkfd: - Enable CONFIG_HSA_AMD on RISCV - SVM fix - Misc cleanups - Ref leak fix - WPTR BO fix radeon: - Misc cleanups" * tag 'drm-next-2025-06-06' of https://gitlab.freedesktop.org/drm/kernel: (105 commits) drm/nouveau/vfn/r535: Convert comma to semicolon drm/xe: remove unmatched xe_vm_unlock() from __xe_exec_queue_init() drm/xe: Create LRC BO without VM drm/xe/guc_submit: add back fix drm/xe/pxp: Clarify PXP queue creation behavior if PXP is not ready drm/xe/pxp: Use the correct define in the set_property_funcs array drm/xe/sched: stop re-submitting signalled jobs drm/xe: Rework eviction rejection of bound external bos drm/xe/vsec: fix CONFIG_INTEL_VSEC dependency drm/xe: drop redundant conversion to bool drm/xe/hwmon: Move card reactive critical power under channel card drm/xe/hwmon: Add support to manage power limits though mailbox drm/xe/vm: move xe_svm_init() earlier drm/xe/vm: move rebind_work init earlier MAINTAINERS: .mailmap: update Rob Clark's email address mailmap: Update entry for Akhil P Oommen MAINTAINERS: update my email address MAINTAINERS: drop myself as maintainer drm/i915/display: Fix u32 overflow in SNPS PHY HDMI PLL setup drm/amd/display: Fix default DC and AC levels ...
2025-06-06drm/tests: bridge: add KUnit tests for devm_drm_bridge_alloc()Luca Ceresoli1-0/+89
Add KUnit tests for the newly introduced devm_drm_bridge_alloc(). Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-3-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/bridge: add a .destroy funcLuca Ceresoli1-0/+2
Some users of DRM bridges may need to execute specific code just before deallocation. As of now the only known user would be KUnit tests. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-2-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/tests: bridge: convert to devm_drm_bridge_alloc() APILuca Ceresoli1-36/+51
Use the new DRM bridge allocation API, which is the only supported now, for the kunit tests. This change is more massive than for the typical DRM bridge driver because struct drm_bridge_init_priv currently embeds a struct drm_bridge, which is not supported anymore. We now have to use devm_drm_bridge_alloc() to dynamically allocate a "private driver struct", which is a bit awkward here because there is no real bridge driver. Thus let's add a "dummy" DRM bridge struct to represent it. As a nice cleanup we can now move the enable_count and disable_count members, which are counting bridge-specific events, into the new "private driver struct" (and avoid adding new unnecessary indirections). Also add a trivial bridge_to_dummy_bridge() function just like many drivers do. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-1-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06Merge tag 'drm-misc-fixes-2025-06-06' of ↵Simona Vetter1-2/+3
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: ivpu: - gem: Use dma-resv lock - gem. Fix a warning - Trigger recovery on device engine reset/resume failure panel: - panel-simple: Fix settings for Evervision VGG644804 sysfb: - Fix screen_info type check video: - Update screen_info for relocated PCI framebuffers Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250606072853.GA13099@linux.fritz.box
2025-06-06drm/bridge: cdns-dsi: Use pre_enable/post_disable to enable/disableAradhya Bhatia1-29/+35
The cdns-dsi controller requires that it be turned on completely before the input DPI's source has begun streaming[0]. Not having that, allows for a small window before cdns-dsi enable and after cdns-dsi disable where the previous entity (in this case tidss's videoport) to continue streaming DPI video signals. This small window where cdns-dsi is disabled but is still receiving signals causes the input FIFO of cdns-dsi to get corrupted. This causes the colors to shift on the output display. The colors can either shift by one color component (R->G, G->B, B->R), or by two color components (R->B, G->R, B->G). Since tidss's videoport starts streaming via crtc enable hooks, we need cdns-dsi to be up and running before that. Now that the bridges are pre_enabled before crtc is enabled, and post_disabled after crtc is disabled, use the pre_enable and post_disable hooks to get cdns-dsi ready and running before the tidss videoport to get pass the color shift issues. [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM TRM Link: http://www.ti.com/lit/pdf/spruil1 Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-5-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Re-order bridge chain pre-enable and post-disableAradhya Bhatia1-4/+4
Move the bridge pre_enable call before crtc enable, and the bridge post_disable call after the crtc disable. The sequence of enable after this patch will look like: bridge[n]_pre_enable ... bridge[1]_pre_enable crtc_enable encoder_enable bridge[1]_enable ... bridge[n]_enable And, the disable sequence for the display pipeline will look like: bridge[n]_disable ... bridge[1]_disable encoder_disable crtc_disable bridge[1]_post_disable ... bridge[n]_post_disable The definition of bridge pre_enable hook says that, "The display pipe (i.e. clocks and timing signals) feeding this bridge will not yet be running when this callback is called". Since CRTC is also a source feeding the bridge, it should not be enabled before the bridges in the pipeline are pre_enabled. Fix that by re-ordering the sequence of bridge pre_enable and bridge post_disable. While at it, update the drm bridge API documentation as well. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-4-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Separate out bridge pre_enable/post_disable from ↵Aradhya Bhatia1-3/+88
enable/disable The encoder-bridge ops occur by looping over the new connector states of the display pipelines. The enable sequence runs as follows - - pre_enable(bridge), - enable(encoder), - enable(bridge), while the disable sequnce runs as follows - - disable(bridge), - disable(encoder), - post_disable(bridge). Separate out the pre_enable(bridge), and the post_disable(bridge) operations into separate functions each. This patch keeps the sequence same for any singular disaplay pipe, but changes the sequence across multiple display pipelines. This patch is meant to be an interim patch, to cleanly pave the way for the sequence re-ordering patch, and maintain bisectability in the process. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-3-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Refactor crtc & encoder-bridge op loops into separate ↵Aradhya Bhatia1-20/+49
functions The way any singular display pipeline, in need of a modeset, gets enabled is as follows - crtc enable (all) bridge pre-enable encoder enable (all) bridge enable - and the disable sequence is exactly the reverse of this. The crtc operations occur by looping over the old and new crtc states, while the encoder and bridge operations occur together, by looping over the connector states of the display pipelines. Refactor these operations - crtc enable/disable, and encoder & bridge (pre/post) enable/disable - into separate functions each, to make way for the re-ordering of the enable/disable sequences. This patch doesn't alter the sequence of crtc/encoder/bridge operations in any way, but helps to cleanly pave the way for the next two patches, by maintaining logical bisectability. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-2-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/panthor: Clean up 64-bit register definitionsKarunika Choo5-80/+52
With the introduction of 64-bit register accessors, the separate *_HI definitions are no longer necessary. This change removes them and renames the corresponding *_LO entries for cleaner and more consistent register definitions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add 64-bit and poll register accessorsKarunika Choo7-161/+124
This patch adds 64-bit register accessors to simplify register access in Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout. This patch also updates Panthor to use the new 64-bit accessors and poll functions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Fix the user MMIO offset logic for emulatorsBoris Brezillon2-16/+58
Currently, we pick the MMIO offset based on the size of the pgoff_t type seen by the process that manipulates the FD, such that a 32-bit process can always map the user MMIO ranges. But this approach doesn't work well for emulators like FEX, where the emulator is a 64-bit binary which might be executing 32-bit code. In that case, the kernel thinks it's the 64-bit process and assumes DRM_PANTHOR_USER_MMIO_OFFSET_64BIT is in use, but the UMD library expects DRM_PANTHOR_USER_MMIO_OFFSET_32BIT, because it can't mmap() anything above the pgoff_t size. In order to solve that, we need a way to explicitly set the user MMIO offset from the UMD, such that the kernel doesn't have to guess it from the TIF_32BIT flag set on user thread. We keep the old behavior if DRM_PANTHOR_SET_USER_MMIO_OFFSET is never called. Changes in v2: - Drop the lock/immutable fields and allow SET_USER_MMIO_OFFSET requests to race with mmap() requests - Don't do the is_user_mmio_offset test twice in panthor_mmap() - Improve the uAPI docs Changes in v3: - Bump to version 1.5 instead of 1.4 after rebasing - Add R-bs - Fix/rephrase comment as suggested by Liviu Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06Merge tag 'drm-misc-fixes-2025-05-28' of ↵Simona Vetter1-0/+1
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: drm-scheduler: - signal scheduled fence when killing job dummycon: - trigger deferred takeover when switching consoles ivpu: - improve logging - update firmware filenames - reorder steps in command-queue unregistering Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250528153550.GA21050@linux.fritz.box
2025-06-06drm/nouveau/vfn/r535: Convert comma to semicolonChen Ni1-1/+1
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Fixes: cd3c62282b61 ("drm/nouveau/gsp: add usermode class id to gpu hal") Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250603061027.1310267-1-nichen@iscas.ac.cn
2025-06-06Merge tag 'amd-drm-fixes-6.16-2025-06-05' of ↵Dave Airlie17-51/+205
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-6.16-2025-06-05: amdgpu: - IP discovery fix - Cleaner shader fix for GC 10.1.x - OD fix - UserQ fixes - Non-OLED panel fix - Misc display fixes - Brightness fixes amdkfd: - Enable CONFIG_HSA_AMD on RISCV Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250606015932.835829-1-alexander.deucher@amd.com
2025-06-06Merge tag 'drm-xe-next-fixes-2025-06-05' of ↵Dave Airlie19-176/+476
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - A couple of vm init fixes (Matt Auld) - Hwmon fixes (Karthik) - Drop reduntant conversion to bool (Raag) - Fix CONFIG_INTEL_VSEC dependency (Arnd) - Rework eviction rejection of bound external bos (Thomas) - Stop re-submitting signalled jobs (Matt Auld) - A couple of pxp fixes (Daniele) - Add back a fix that got lost in a merge (Matt Auld) - Create LRC bo without VM (Niranjana) - Fix for the above fix (Maciej) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/aEHq44uIAZwfK-mG@fedora
2025-06-06Merge tag 'drm-misc-next-fixes-2025-06-05' of ↵Dave Airlie4-17/+12
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-fixes for v6.16-rc1: - Fixes for nt37801 panel - Fix null deref in HDMI audio helper. - Fixes for analogix_dp. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/14c2eff8-701d-4699-b187-08862715e1ac@linux.intel.com
2025-06-06Merge tag 'drm-intel-next-fixes-2025-06-05' of ↵Dave Airlie3-14/+25
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Fix PSR register definitions for ALPM - Fix u32 overflow in SNPS PHY HDMI PLL setup - Fix GuC pending message underflow when submit fails - Fix GuC wakeref underflow race during reset Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://lore.kernel.org/r/aEFW1wGnt1kTVNGF@jlahtine-mobl
2025-06-06drm/xe/xe3: Disable null query for anyhit shaderNitin Gote1-0/+5
Set DIS_NULL_QUERY bit of RT_CTRL register to disable null query for anyhit shader for Xe3 IP. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://lore.kernel.org/r/20250605100812.2547808-1-nitin.r.gote@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-05drm/xe: remove unmatched xe_vm_unlock() from __xe_exec_queue_init()Maciej Patelczyk1-5/+1
There is unmatched xe_vm_unlock() in the __xe_exec_queue_init(). Leftover from commit fbeaad071a98 ("drm/xe: Create LRC BO without VM") Fixes: 2b0a0ce0c20b ("drm/xe: Create LRC BO without VM") Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://lore.kernel.org/r/20250530135627.2821612-1-maciej.patelczyk@intel.com (cherry picked from commit 28b996ce73982a44fa86736ca0e3684cb1ae8b24) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe: Create LRC BO without VMNiranjana Vishwanathapura2-28/+4
Specifying VM during lrc->bo creation requires VM's reference to be held for the lifetime of lrc->bo as it will use VM's dma reservation object. Using VM's dma reservation object for lrc->bo doesn't provide any advantage. Hence do not pass VM while creating lrc->bo. v2: Use xe_bo_unpin_map_no_vm (Matthew Brost) Fixes: 264eecdba211 ("drm/xe: Decouple xe_exec_queue and xe_lrc") Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250529052031.2429120-2-niranjana.vishwanathapura@intel.com (cherry picked from commit fbeaad071a98fef87deccee81d564de1c8e8e16d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/guc_submit: add back fixMatthew Auld1-0/+11
Daniele noticed that the fix in commit 2d2be279f1ca ("drm/xe: fix UAF around queue destruction") looks to have been unintentionally removed as part of handling a conflict in some past merge commit. Add it back. Fixes: ac44ff7cec33 ("Merge tag 'drm-xe-fixes-2024-10-10' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes") Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250603174213.1543579-2-matthew.auld@intel.com (cherry picked from commit 9d9fca62dc49d96f97045b6d8e7402a95f8cf92a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/pxp: Clarify PXP queue creation behavior if PXP is not readyDaniele Ceraolo Spurio1-2/+6
The expected flow of operations when using PXP is to query the PXP status and wait for it to transition to "ready" before attempting to create an exec_queue. This flow is followed by the Mesa driver, but there is no guarantee that an incorrectly coded (or malicious) app will not attempt to create the queue first without querying the status. Therefore, we need to clarify what the expected behavior of the queue creation ioctl is in this scenario. Currently, the ioctl always fails with an -EBUSY code no matter the error, but for consistency it is better to distinguish between "failed to init" (-EIO) and "not ready" (-EBUSY), the same way the query ioctl does. Note that, while this is a change in the return code of an ioctl, the behavior of the ioctl in this particular corner case was not clearly spec'd, so no one should have been relying on it (and we know that Mesa, which is the only known userspace for this, didn't). v2: Minor rework of the doc (Rodrigo) Fixes: 72d479601d67 ("drm/xe/pxp/uapi: Add userspace and LRC support for PXP-using queues") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250522225401.3953243-7-daniele.ceraolospurio@intel.com (cherry picked from commit 21784ca96025b62d95b670b7639ad70ddafa69b8) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/pxp: Use the correct define in the set_property_funcs arrayDaniele Ceraolo Spurio1-1/+1
The define of the extension type was accidentally used instead of the one of the property itself. They're both zero, so no functional issue, but we should use the correct define for code correctness. Fixes: 41a97c4a1294 ("drm/xe/pxp/uapi: Add API to mark a BO as using PXP") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250522225401.3953243-6-daniele.ceraolospurio@intel.com (cherry picked from commit 1d891ee820fd0fbb4101eacb0d922b5050a24933) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/sched: stop re-submitting signalled jobsMatthew Auld1-1/+9
Customer is reporting a really subtle issue where we get random DMAR faults, hangs and other nasties for kernel migration jobs when stressing stuff like s2idle/s3/s4. The explosions seems to happen somewhere after resuming the system with splats looking something like: PM: suspend exit rfkill: input handler disabled xe 0000:00:02.0: [drm] GT0: Engine reset: engine_class=bcs, logical_mask: 0x2, guc_id=0 xe 0000:00:02.0: [drm] GT0: Timedout job: seqno=24496, lrc_seqno=24496, guc_id=0, flags=0x13 in no process [-1] xe 0000:00:02.0: [drm] GT0: Kernel-submitted job timed out The likely cause appears to be a race between suspend cancelling the worker that processes the free_job()'s, such that we still have pending jobs to be freed after the cancel. Following from this, on resume the pending_list will now contain at least one already complete job, but it looks like we call drm_sched_resubmit_jobs(), which will then call run_job() on everything still on the pending_list. But if the job was already complete, then all the resources tied to the job, like the bb itself, any memory that is being accessed, the iommu mappings etc. might be long gone since those are usually tied to the fence signalling. This scenario can be seen in ftrace when running a slightly modified xe_pm IGT (kernel was only modified to inject artificial latency into free_job to make the race easier to hit): xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=1, guc_state=0x0, flags=0x4 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=0, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 1:0x1, gt=1, width=1, guc_id=1, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=2, guc_state=0x0, flags=0x3 xe_exec_queue_resubmit: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... ..... xe_exec_queue_memory_cat_error: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x3, flags=0x13 So the job_run() is clearly triggered twice for the same job, even though the first must have already signalled to completion during suspend. We can also see a CAT error after the re-submit. To prevent this only resubmit jobs on the pending_list that have not yet signalled. v2: - Make sure to re-arm the fence callbacks with sched_start(). v3 (Matt B): - Stop using drm_sched_resubmit_jobs(), which appears to be deprecated and just open-code a simple loop such that we skip calling run_job() on anything already signalled. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4856 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: William Tseng <william.tseng@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20250528113328.289392-2-matthew.auld@intel.com (cherry picked from commit 38fafa9f392f3110d2de431432d43f4eef99cd1b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe: Rework eviction rejection of bound external bosThomas Hellström3-18/+105
For preempt_fence mode VM's we're rejecting eviction of shared bos during VM_BIND. However, since we do this in the move() callback, we're getting an eviction failure warning from TTM. The TTM callback intended for these things is eviction_valuable(). However, the latter doesn't pass in the struct ttm_operation_ctx needed to determine whether the caller needs this. Instead, attach the needed information to the vm under the vm->resv, until we've been able to update TTM to provide the needed information. And add sufficient lockdep checks to prevent misuse and races. v2: - Fix a copy-paste error in xe_vm_clear_validating() v3: - Fix kerneldoc errors. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Fixes: 0af944f0e308 ("drm/xe: Reject BO eviction if BO is bound to current VM") Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250528164105.234718-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 9d5558649f68e2e84a87a909631b30e15ca0f8ec) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/vsec: fix CONFIG_INTEL_VSEC dependencyArnd Bergmann1-1/+2
The XE driver can be built with or without VSEC support, but fails to link as built-in if vsec is in a loadable module: x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init': (.text+0x1e83e16): undefined reference to `intel_vsec_register' The normal fix for this is to add a 'depends on INTEL_VSEC || !INTEL_VSEC', forcing XE to be a loadable module as well, but that causes a circular dependency: symbol DRM_XE depends on INTEL_VSEC symbol INTEL_VSEC depends on X86_PLATFORM_DEVICES symbol X86_PLATFORM_DEVICES is selected by DRM_XE The problem here is selecting a symbol from another subsystem, so change that as well and rephrase the 'select' into the corresponding dependency. Since X86_PLATFORM_DEVICES is 'default y', there is no change to defconfig builds here. Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250529172355.2395634-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit e4931f8be347ec5f19df4d6d33aea37145378c42) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe: drop redundant conversion to boolRaag Jadav1-1/+1
The result of integer comparison already evaluates to bool. No need for explicit conversion. No functional impact. Fixes: 0e414bf7ad01 ("drm/xe: Expose PCIe link downgrade attributes") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505292205.MoljmkjQ-lkp@intel.com/ Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250529160937.490147-1-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 61761a6b57f2818983466d24aab60baab471ba21) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/hwmon: Move card reactive critical power under channel cardKarthik Poosa1-3/+3
Move power2/curr2_crit to channel 1 i.e power1/curr1_crit as this represents the entire card critical power/current. v2: Update the date of curr1_crit also in hwmon documentation. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: 345dadc4f68b ("drm/xe/hwmon: Add infra to support card power and energy attributes") Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-3-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 25e963a09e059ffdb15c09cc79cfded855b43668) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/hwmon: Add support to manage power limits though mailboxKarthik Poosa8-106/+318
Add support to manage power limits using pcode mailbox commands for supported platforms. v2: - Address review comments. (Badal) - Use mailbox commands instead of registers to manage power limits for BMG. - Clamp the maximum power limit to GPU firmware default value. v3: - Clamp power limit in write also for platforms with mailbox support. v4: - Remove unnecessary debug prints. (Badal) v5: - Update description of variable pl1_on_boot to fix kernel-doc error. v6: - Improve commit message, refer to BIOS as GPU firmware. - Change macro READ_PL_FROM_BIOS to READ_PL_FROM_FW. - Rectify drm_warn to drm_info. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: e90f7a58e659 ("drm/xe/hwmon: Add HWMON support for BMG") Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250529163458.2354509-2-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 7596d839f6228757fe17a810da2d1c5f3305078c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/vm: move xe_svm_init() earlierMatthew Auld1-7/+12
In xe_vm_close_and_put() we need to be able to call xe_svm_fini(), however during vm creation we can call this on the error path, before having actually initialised the svm state, leading to various splats followed by a fatal NPD. Fixes: 6fd979c2f331 ("drm/xe: Add SVM init / close / fini to faulting VMs") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4967 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250514152424.149591-4-matthew.auld@intel.com (cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/xe/vm: move rebind_work init earlierMatthew Auld1-4/+4
In xe_vm_close_and_put() we need to be able to call flush_work(rebind_work), however during vm creation we can call this on the error path, before having actually set up the worker, leading to a splat from flush_work(). It looks like we can simply move the worker init step earlier to fix this. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250514152424.149591-3-matthew.auld@intel.com (cherry picked from commit 96af397aa1a2d1032a6e28ff3f4bc0ab4be40e1d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-05drm/i915: use drm_modeset_lock_assert_held() in intel_connector_get_pipe()Luca Coelho1-2/+1
In the intel_connector_get_pipe() function, we check if connection_mutex is held and generate our own WARN_ON if that's the case. Instead of generating a non-standard warning for a mutex issue, we should use the standard lockdep framework. Change the function to use drm_modeset_lock_assert_held() instead. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250520095408.1310440-1-luciano.coelho@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 00:45:18 +0300