summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-23drm/xe/compat: remove old pcode compat interfaceJani Nikula
With display code using the struct drm_device based pcode interface, we can drop the old pcode compat interface. We can also drop the __compat_uncore_to_tile() helper from intel_uncore.h compat header. Turns out a couple of headers depended on the intel_uncore.h include via intel_pcode.h. Fix them. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/948016a031dcb2acef0c97071aac09fa49613e07.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/dram: switch to struct drm_device based pcode interfaceJani Nikula
With the struct drm_device based pcode interface in place in both i915 and xe, we can switch dram code to use that. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/e0d74a3317cc61d1cbb096b962cfbd7c60f038d4.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/display: switch to struct drm_device based pcode interfaceJani Nikula
With the struct drm_device based pcode interface in place in both i915 and xe, we can switch display code to use that, and ditch a number of struct drm_i915_private uses. Also drop the dependency on i915_drv.h from a couple of files. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/f948fad1b8208522e15140692c17cf493ef305d9.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/xe/pcode: add struct drm_device based interfaceJani Nikula
In preparation for dropping the dependency on struct intel_uncore or struct xe_tile from display code, add a struct drm_device based interface to pcode. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/eeaa9cc8438caab2e22f9cb2142fbc18cc0fd861.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/pcode: add struct drm_device based interfaceJani Nikula
In preparation for dropping the dependency on struct intel_uncore from display code, add a struct drm_device based interface to pcode. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/e4ee176ca5454cfc636cbe71feb9f55d9e91f4ea.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/pcode: drop fast wait from snb_pcode_write_timeout()Jani Nikula
Only use the ms granularity wait in snb_pcode_write_timeout(), primarily to better align with the xe driver, which also only has the millisecond wait. Use an arbitrary 250 us fast wait before the specified ms wait, and have snb_pcode_write() default to 1 ms. This means snb_pcode_write() and snb_pcode_write_timeout() will always be sleeping functions. There should not be any atomic users for pcode writes though, and any display code using pcode via xe has already been non-atomic. The uncore wait will do a might_sleep() annotation that should catch any problems. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/ba86280f53cea2d020308db35f1ecbd615d07d8a.1750678991.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/connector: move HDR sink metadata to display infoJani Nikula
Information parsed from the display EDID should be stored in display info. Move HDR sink metadata there. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250519112900.1383997-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/i915/dmc: Do not enable the pipe DMC on TGL when PSR is possibleVille Syrjälä
On TGL/derivatives the pipe DMC state is lost when PG1 is disabled, and the main DMC does not restore any of it. This means the state will also be lost during PSR+DC5/6. It seems safest to not even enable the pipe DMC in that case (the main DMC does restore the pipe DMC enable bit in PIPEDMC_CONTROL_A for some reason). Since pipe DMC is only needed for "fast LACE" on these platforms we aren't actually losing anything here. In the future if we do want to enable "fast LACE" we'll just have to remember that it won't be compatible with PSR. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-10-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Pass crtc_state to intel_dmc_{enable,disable}_pipe()Ville Syrjälä
I'll need to examine the crtc state during intel_dmc_enable_pipe(). To that end pass the whole crtc into intel_dmc_{enable,disable}_pipe(). Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-9-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Assert DMC is loaded harderVille Syrjälä
Currently we have some asserts to make sure the main DMC has been loaded. Add similar asserts for the pipe DMCs. And we might as well just check all the mmio registers the firmware has asked us to initialize. That also covers the hardcoded SSP/HTP registers we were checking for the main DMC. TODO: Maybe always configure DMC_EVT_CTL_ENABLE the way the firmware has it set so that we wouldn't need to special case in the assert? v2: Also assert in intel_dmc_load_program() Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-8-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Reload pipe DMC MMIO registers for pipe C/D on various platformsVille Syrjälä
On ADL/MTL pipe DMC MMIO state evidently lives in PG0. The main DMC saves/restores it for pipes A/B, but for pipes C/D we have to do it in the driver. On PTL the situation is mostly the same, except the main DMC firmware doesn't seem to have the PG0 save/restore code anymore, and instead the hardware (or maybe Punit?) seems to take care of this job now. Pipes C/D still need a manual restore by the driver. On LNL I've been unable to lose any pipe DMC state, despite the main DMC firmware still implementing the PG0 save/restore for pipes A/B. Not sure what's going on here. On DG2 I've also not been able to lose the pipe DMC state. DG2 doesn't support DC6, so that might explain part of it. But even DC9 doesn't make a difference here. Perhaps PG0 is just always on for DG2? BMG I've not tested at all. The main DMC firmware does appaer to implement the PG0 pipe A/B save/restore logic. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-7-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2025-06-23drm/i915/dmc: Reload pipe DMC state on TGL when enabling pipe AVille Syrjälä
On TGL/derivatives the entire pipe DMC state (program + MMIO) is lost when PG1 is disabled, and the main DMC does not restore any of it. Reload the state when enabling a pipe. The other option would be to not load the pipe DMC at all since it's only needed for "fast LACE" (which we don't use) on these platforms. But let's keep it around just in case we ever decide that "fast LACE" is something we want. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-6-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Extract dmc_load_program()Ville Syrjälä
We'll be needing to reload the program for individual DMCs. To make that possible pull the code to load the program for a single DMC into a new function. This does change the order of things during init/resume a bit; previously we loaded the program RAM for all DMCs first, and then loaded the MMIO registers for all DMCs. Now those operations will be interleaved between different DMCs. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-5-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Shuffle code aroundVille Syrjälä
Shuffle the DMC_EVT_CTL related stuff around once more. We'll need this stuff during intel_dmc_enable_pipe(), and this lets us avoid forward declarations. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-4-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Parametrize MTL_PIPEDMC_GATING_DISVille Syrjälä
The MTL+ pipe DMC clock gating bits can be parametrized. Make it so. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-3-ville.syrjala@linux.intel.com
2025-06-23drm/i915/dmc: Limit pipe DMC clock gating w/a to just ADL/DG2/MTLVille Syrjälä
Supposedly nothing post-MTL (even BMG) needs the pipe DMC clock gating w/a (Wa_16015201720), so don't apply it. TODO: check if the ADL/DG2 "clock gating needed during DMC loading" part is actually needed, not seeing anything in the docs about it... Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-2-ville.syrjala@linux.intel.com
2025-06-23drm/ci: Add jobs to run KUnit testsVignesh Raman
Add jobs to run KUnit tests using tools/testing/kunit/kunit.py tool. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250623085033.39680-3-vignesh.raman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-23drm/ci: Add jobs to validate devicetreesVignesh Raman
Add jobs to run dt_binding_check and dtbs_check. If warnings are seen, exit with a non-zero error code while configuring them as warning in the GitLab CI pipeline. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250623085033.39680-2-vignesh.raman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-23drm/bochs: Add support for drm_panicRyosuke Yasuoka
Add drm_panic module for bochs drm so that panic screen can be displayed on panic. Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250613132023.106946-1-ryasuoka@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-06-23drm/i915/panel: make panel funcs staticJani Nikula
The drm panel funcs should be static, fix it. Fixes: 3fdd5bfbd638 ("drm/i915/panel: register drm_panel and call prepare/unprepare for ICL+ DSI") Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250612124617.626958-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23Merge drm/drm-next into drm-intel-nextJani Nikula
Sync with drm_panel changes from drm-misc-next, and xe driver changes from drm-xe-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/xe/display: read PCON capability only when presentChaitanya Kumar Borah
Avoid reading the PCON capabilities redundantly on non-branch devices. v2: - Make commit description more accurate. (Imre) - Clear intel_dp->pcon_dsc_dpcd irrespective of presense of PCON. (Imre) Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250619042629.3980244-1-chaitanya.kumar.borah@intel.com
2025-06-23Merge tag 'drm-intel-next-2025-06-18' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull for v6.17: Features and functionality: - Add support for DSC fractional link bpp on DP MST (Imre) - Add support for simultaneous Panel Replay and Adaptive Sync (Jouni) - Add support for PTL+ double buffered LUT registers (Chaitanya, Ville) - Add PIPEDMC event handling in preparation for flip queue (Ville) Refactoring and cleanups: - Rename lots of DPLL interfaces to unify them (Suraj) - Allocate struct intel_display dynamically (Jani) - Abstract VLV IOSF sideband better (Jani) - Use str_true_false() helper (Yumeng Fang) - Refactor DSB code in preparation for flip queue (Ville) - Use drm_modeset_lock_assert_held() instead of open coding (Luca) - Remove unused arg from skl_scaler_get_filter_select() (Luca) - Split out a separate display register header (Jani) - Abstract DRAM detection better (Jani) - Convert LPT/WPT SBI sideband to struct intel_display (Jani) Fixes: - Fix DSI HS command dispatch with forced pipeline flush (Gareth Yu) - Fix BMG and LNL+ DP adaptive sync SDP programming (Ankit) - Fix error path for xe display workqueue allocation (Haoxiang Li) - Disable DP AUX access probe where not required (Imre) - Fix DKL PHY access if the port is invalid (Luca) - Fix PSR2_SU_STATUS access on ADL+ (Jouni) - Add sanity checks for porch and sync on BXT/GLK DSI (Ville) DRM core changes: - Change AUX DPCD access probe address (Imre) - Refactor EDID quirks, amd make them available to drivers (Imre) - Add quirk for DPCD access probe (Imre) - Add DPCD definitions for Panel Replay capabilities (Jouni) Merges: - Backmerges to sync with v6.15-rcs and v6.16-rc1 (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/fff9f231850ed410bd81b53de43eff0b98240d31@intel.com
2025-06-20arm64: dts: mediatek: mt8370: Enable gpu supportLouis-Alexis Eyraud
Add a new gpu node in mt8370.dtsi to enable support for the ARM Mali G57 MC2 GPU (Valhall-JM) found on the MT8370 SoC, using the Panfrost driver. On a Mediatek Genio 510 EVK board, the panfrost driver probed with the following message: ``` panfrost 13000000.gpu: clock rate = 390000000 panfrost 13000000.gpu: mali-g57 id 0x9093 major 0x0 minor 0x0 status 0x0 panfrost 13000000.gpu: features: 00000000,000019f7, issues: 00000003, 80000400 panfrost 13000000.gpu: Features: L2:0x08130206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7 panfrost 13000000.gpu: shader_present=0x5 l2_present=0x1 [drm] Initialized panfrost 1.3.0 for 13000000.gpu on minor 0 ``` Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-5-2833888cb1d3@collabora.com
2025-06-20drm/panfrost: Add support for Mali on the MT8370 SoCLouis-Alexis Eyraud
Add a compatible for the MediaTek MT8370 SoC, with an integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core), with new platform data for its support in the panfrost driver. It uses the same data as MT8186 for the power management features to describe power supplies, pm_domains and enablement (one regulator, two power domains) but also sets the FORCE_AARCH64_PGTABLE flag in the GPU configuration quirks bitfield to enable AARCH64 4K page table format mode. As MT8186 and MT8370 SoC have different GPU architecture (Mali G52 2EE MC2 for MT8186), making them not compatible, and this mode is only enabled for Mediatek SoC that are Mali G57 based (compatible with mediatek,mali-mt8188 or mediatek,mali-8192), having specific platform data allows to set this flag for MT8370 without modifying MT8186 configuration and behaviour. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-4-2833888cb1d3@collabora.com
2025-06-20drm/panfrost: Commonize Mediatek power domain array definitionsLouis-Alexis Eyraud
In the panfrost driver, the platform data of several Mediatek SoC declares and uses several different power domains arrays according to GPU core number present in the SoC: - mediatek_mt8186_pm_domains (2 cores) - mediatek_mt8183_pm_domains (3 cores) - mediatek_mt8192_pm_domains (5 cores) As they all are fixed arrays, starting with the same entries and the platform data also has a power domains array length field (num_pm_domains), they can be replaced by a single array, containing all entries, if the num_pm_domains field of the platform data is also set to the matching core number. So, create a generic power domain array (mediatek_pm_domains) and use it in the mt8183(b), mt8186, mt8188 and mt8192 platform data instead. Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-3-2833888cb1d3@collabora.com
2025-06-20drm/panfrost: Drop duplicated Mediatek supplies arraysLouis-Alexis Eyraud
In the panfrost driver, the platform data of several Mediatek SoC declares and uses custom supplies array definitions (mediatek_mt8192_supplies, mediatek_mt8183_b_supplies), that are the same as default_supplies (used by default platform data). So drop these duplicated definitions and use default_supplies instead. Also, rename mediatek_mt8183_supplies to a more generic name too (legacy_supplies). Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-2-2833888cb1d3@collabora.com
2025-06-20dt-bindings: gpu: mali-bifrost: Add compatible for MT8370 SoCLouis-Alexis Eyraud
Add a compatible for the MediaTek MT8370 SoC, with an integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core). None of the already existing SoC specific compatibles is usable as fallback, as those either do not match the number of cores (and number of power domains), or are for a different GPU architecture. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-1-2833888cb1d3@collabora.com
2025-06-20Merge tag 'drm-misc-next-2025-06-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.17: UAPI Changes: - Add Task Information for the wedge API Cross-subsystem Changes: Core Changes: - Fix warnings related to export.h - fbdev: Make CONFIG_FIRMWARE_EDID available on all architectures - fence: Fix UAF issues - format-helper: Improve tests Driver Changes: - ivpu: Add turbo flag, Add Wildcat Lake Support - rz-du: Improve MIPI-DSI Support - vmwgfx: fence improvement Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250619-perfect-industrious-whippet-8ed3db@houat
2025-06-20Merge tag 'drm-xe-next-2025-06-18' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - Expose media OA units (Ashutosh) Merge: - Restore GuC submit UAF fix around queue destruction accidentally removed in a drm-xe-fixes merge (Auld) Core Changes: - drm/gpusvm: Introduce devmem_only flag for allocation (Himal) - drm/gpusvm: Add timeslicing support to GPU SVM (Brost) Driver Changes: - Make gem shrinker drm managed (Thomas) - SRIOV VF Post-migration recovery of GGTT nodes and CTB (Tomasz) - Some W/A additions and updates (Aradhya, Shekhar, Vinay, Daniele) - Prefetch Support for svm ranges (Himal, Brost) - Don't allocate managed BO for each policy change (Michal) - Simplify and fix diff calculation in GuC submit (Lucas) - Track FAST_REQ GuC H2Gs to report where errors came from (John) - SRIOV PF: Don't allow LMEM provisioning if LMTT isn't available (Piotr) - Check if all domains awake for MOCS dump (Tejas) - Make creation of SLPC debugfs files conditional (Aradhya) - Default auto_link_downgrade status to false (Aradhya) - Use xe_mmio_read32() to read mtcfg register (Shuicheng) - Updates in PCI ID tables (Atwood, Shekhar) - SRIOV VF: Fail migration recovery if fixups needed but not supported (Tomasz) - Add missing documentation around freq and RPa (Rodrigo) - Some other SVM related fixes (Himal, Auld, Brost, Maarten) - Allow to trigger GT resets using debugfs writes (Michal) - Optimise CCS case for WB pages (Auld) - Create LRC BO without VM (Niranjana) - Initialize MOCS index early (Bala) - HWMON fixes for BMG (Karthik, Lucas) - Drop redundant conversion to bool (Raag) - Rework eviction rejection of bound external bos (Thomas) - Stop re-submitting signalled jobs (Auld) - Small fixes and cleanups for PXP (Daniele) - Convert some print messages to GT-oriented ones (Michal) - Resend potentially lost GuC H2G MMIO request (Michal) - Add configfs to load with fewer engines (Lucas) - Remove unmatched xe_vm_unlock from __xe_exec_queue_init (Maciej) - SRIOV VF: Small updates around GGTT handling (Michal) - Make VMA tile_present, tile_invalidated access rules clear (Brost) - Xe3 Tuning: Disable NULL query for Anyhit Shader (Nitin) - Fixes for VF GuC version (Daniele) - Don't store the xe device pointer inside xe_ttm_tt (Dave) - Small improvements in topology code (Michal) - Stop relying on GGTT internals (Maarten) - GSM size should be constant on most platforms (Roper) - Reorder 'Get pages failed' message (Brost) - WA BB related fixes and improvements (Lucas, Brost) - Fix early wedge on GuC load failure (Daniele) - Add helper function to inject fault into ct_dead_capture (Satyanarayana) - Determine ATS / PTA programming during early sw init (Roper) - Consolidate PAT programming logic for pre-Xe2 and post-Xe2 (Roper) - Fix kconfig prompt (Lucas) - Convert xe_pci tests to parametrized tests (Michal) - Do not kill VM in PT code on -ENODATA (Brost) - Move LRC_ENGINE_ID_PPHWSP_OFFSET outside of parallel offset (Brost) - Enable media OA (Ashutosh) - GuC log level tuning (Lucas) - Add xe_vm_has_valid_gpu_mapping helper (Brost) - Opportunistically skip TLB invalidaion on unbind (Brost) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aFMb_NVF_oCW7UVl@intel.com
2025-06-19drm/bridge: tc358767: convert to devm_drm_bridge_alloc() APILuca Ceresoli
This is the new API for allocating DRM bridges. Converting this driver is a bit complex because the drm_bridge funcs pointer differs based on the bridge mode. So the current code does: * tc_probe() * devm_kzalloc() private struct embedding drm_bridge * call tc_probe_bridge_endpoint() which * parses DT description into struct fields * computes the mode * calls different bridge init functions based on the mode * each sets a different bridge.funcs pointer The new API expects the funcs pointer to be known at alloc time, which does not fit in the current code structure. Solve this by splitting tc_probe_bridge_endpoint() in two functions: * tc_probe_get_mode(), computing the mode without needing the private driver structure * tc_probe_bridge_endpoint(), only initializing the endpoints So now the mode is known before allocation and so is the funcs pointer, while all other operations are still happening after allocation, directly into the private struct data, as they used to. The new code flow is: * tc_probe() * tc_probe_get_mode() * parses DT description * computes and returns the mode * based onf the mode, pick the funcs pointer * devm_drm_bridfge_alloc(..., funcs) * call tc_probe_bridge_endpoint() which * calls different bridge init functions based on the mode * these don't set the funcs pointer, it was done by _alloc This solution is chosen to minimize the changes in the driver logical code flow. The drawback is we now iterate twice over the endpoints during probe. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250528-drm-bridge-convert-to-alloc-api-v4-1-f04e698c9a77@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-19drm/i915/snps_hdmi_pll: Use clamp() instead of max(min())Ankit Nautiyal
The values of ana_cp_int, and ana_cp_prop are clamped between 1 and 127. Use the more intuitive and readable clamp() macro instead of using nested max(min(...)). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250618130951.1596587-3-ankit.k.nautiyal@intel.com
2025-06-19drm/i915/snps_hdmi_pll: Fix 64-bit divisor truncation by using div64_u64Ankit Nautiyal
DIV_ROUND_CLOSEST_ULL uses do_div(), which expects a 32-bit divisor. When passing a 64-bit constant like CURVE2_MULTIPLIER, the value is silently truncated to u32, potentially leading to incorrect results on large divisors. Replace DIV_ROUND_CLOSEST_ULL with DIV64_U64_ROUND_CLOSEST which correctly handles full 64-bit division. v2: Use DIV64_U64_ROUND_CLOSEST instead of div64_u64 macro. (Jani) Fixes: 5947642004bf ("drm/i915/display: Add support for SNPS PHY HDMI PLL algorithm for DG2") Reported-by: Vas Novikov <vasya.novikov@gmail.com> Closes: https://lore.kernel.org/all/8d7c7958-9558-4c8a-a81a-e9310f2d8852@gmail.com/ Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Vas Novikov <vasya.novikov@gmail.com> Cc: stable@vger.kernel.org # v6.15+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250618130951.1596587-2-ankit.k.nautiyal@intel.com
2025-06-19drm/i915/plane: rename intel_atomic_add_affected_planes() to ↵Jani Nikula
intel_plane_add_affected() Rename to follow filename based naming. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/c37bc557f831090c934b76d03485823bd45ebba8.1750147992.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-19drm/i915/plane: rename intel_atomic_check_planes() to intel_plane_atomic_check()Jani Nikula
Align with all the other atomic check functions. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/57c59e33e31fbea564f61c2ffaa81e979e33f106.1750147992.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-19drm/i915/plane: make intel_plane_atomic_check() static and renameJani Nikula
intel_plane_atomic_check() isn't used outside of intel_plane.c. Make it static. While at it, rename to vacate the name for subsequent changes. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/9da965c23c1485625d8713152751470ee758d540.1750147992.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-19drm/i915/plane: drop atomic from intel_atomic_plane_check_clipping()Jani Nikula
Align with intel_plane_check_src_coordinates(). The "atomic" is superfluous. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/0bebd67e583b6ca56f788bd795ffe77db342e809.1750147992.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-19drm/i915/plane: rename intel_atomic_plane.[ch] to intel_plane.[ch]Jani Nikula
It's all atomic, no need to emphasize this. v2: Also update Documentation/gpu/i915.rst (Gustavo) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/ba5f304e9fe71723191d872e6828d461e1a572bd.1750147992.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-19drm/i915/vrr: fix register file styleJani Nikula
Fix indents, use of spaces vs. tabs, grouping, remove superfluous comments, remove some line continuations, wrap macro arguments in parens, rename dev_priv to display. This is the way. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250618155137.1651865-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-18drm/i915/xe3lpd: Add support for display version 30.02Matt Roper
Display version 30.02 should be treated the same as other Xe3 IP, but will have a slightly different set of workarounds. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250613193146.3549862-2-dnyaneshwar.bhadane@intel.com
2025-06-18drm/i915/xe3lpd: Extend WA 16023981245 for display 30.02Dnyaneshwar Bhadane
wa_16023981245 need to be extended for display version 30.02 Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250613193146.3549862-10-dnyaneshwar.bhadane@intel.com
2025-06-18drm/i915/wcl: C10 phy connected to port A and BDnyaneshwar Bhadane
WCL added a c10 phy connected to port B. PTL code is currently restricting c10 to phy_a only. PTL doesn't have a PHY connected to PORT B; as such,there will never be a case where PTL uses PHY B. WCL uses PORT A and B with the C10 PHY.Reusing the condition for WCL and extending it for PORT B should not cause any issues for PTL. -v2: Reuse and extend PTL condition for WCL (Matt) Bspec: 73944 Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250613193146.3549862-9-dnyaneshwar.bhadane@intel.com
2025-06-18drm/i915/xe3lpd: Extend DMC load path for displayDnyaneshwar Bhadane
Display version 30.02 should be treated the same as other Xe3 IP. So exteding DMC load path the condition for it. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250613193146.3549862-8-dnyaneshwar.bhadane@intel.com
2025-06-18drm/i915: Set max cdclk for display 30.02Matt Atwood
Display version 30.02 has a lower max cdclk rate than 30.00. Bspec: 68861 Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250613193146.3549862-6-dnyaneshwar.bhadane@intel.com
2025-06-18drm/i915/xe3lpd: Update bandwidth parameters for display version 30.02Matt Atwood
Bandwidth parameters for WCL have been updated with respect to previous display releases. Encode them into xe3lpd_3002_sa_info and use that new struct. -v2: Resolve conflict to apply patch. Bspec: 68859 Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250613193146.3549862-5-dnyaneshwar.bhadane@intel.com
2025-06-18drm/xe/hwmon: Fix xe_hwmon_power_max_writeKarthik Poosa
Prevent other bits of mailbox power limit from being overwritten with 0. This issue was due to a missing read and modify of current power limit, before setting a requested mailbox power limit, which is added in this patch. v2: - Improve commit message. (Anshuman) v3: - Rebase. - Rephrase commit message. (Riana) - Add read-modify-write variant of xe_hwmon_pcode_write_power_limit() i.e. xe_hwmon_pcode_rmw_power_limit(). (Badal) - Use xe_hwmon_pcode_rmw_power_limit() to set mailbox power limits. - Remove xe_hwmon_pcode_write_power_limit() as all mailbox power limits writes use xe_hwmon_pcode_rmw_power_limit() only. v4: - Use PWR_LIM in place of (PWR_LIM_EN | PWR_LIM_VAL) wherever applicable. (Riana) Fixes: 7596d839f6228 ("drm/xe/hwmon: Add support to manage power limits though mailbox") Reviewed-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20250617120030.612819-1-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-18drm/amdgpu/sdma5.2: init engine reset mutexAlex Deucher
Missing the mutex init. Fixes: 47454f2dc0bf ("drm/amdgpu: Register the new sdma function pointers for sdma_v5_2") Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-06-18drm/amdkfd: Fix race in GWS queue schedulingJay Cornwall
q->gws is not updated atomically with qpd->mapped_gws_queue. If a runlist is created between pqm_set_gws and update_queue it will contain a queue which uses GWS in a process with no GWS allocated. This will result in a scheduler hang. Use q->properties.is_gws which is changed while holding the DQM lock. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-06-18drm/amdgpu/sdma5: init engine reset mutexAlex Deucher
Missing the mutex init. Fixes: e56d4bf57fab ("drm/amdgpu/: drm/amdgpu: Register the new sdma function pointers for sdma_v5_0") Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-06-18drm/amdgpu: switch job hw_fence to amdgpu_fenceAlex Deucher
Use the amdgpu fence container so we can store additional data in the fence. This also fixes the start_time handling for MCBP since we were casting the fence to an amdgpu_fence and it wasn't. Fixes: 3f4c175d62d8 ("drm/amdgpu: MCBP based on DRM scheduler (v9)") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-11 17:00:27 +0000