summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-27drm/i915/dmc: Define flip queue related PIPEDMC registersVille Syrjälä
Add the register definitions for a bunch of flip queue related PIPEDMC registers. v2: The layout of flip queue entries changed on PTL Bump the DMC_FQ_W2_PTS_CFG_SEL bitfields sizes (Uma) Reduce the scanlines to 21 bits for now (Uma) v3: Also define some undocumented DMC variables we need on PTL v3: Drop PIPEDMC_FQ_CTRL_BUSY as it seems to no longer exist on LNL+ Fix up some typos 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/20250624170049.27284-4-ville.syrjala@linux.intel.com
2025-06-27drm/i915: Try to program PKG_C_LATENCY more correctlyVille Syrjälä
The current PKG_C_LATENCY stuff looks busted in several ways: - doesn't account for multiple pipes from different commits correctly - WM_LINETIME is in units of 0.125usec, PKG_C_LATENCY wants units on 1 usec - weird VRR state stuff being checked - use of pointless RMW Fix it all up. Note that it's still a bit unclear how all this works, especially how the added_wake_time ties into the flipq triggers in DMC, and how we need to sequence updates to PKG_C_LATENCY when enabling/disabling pipes/etc. We may also need to think what to about the WM1+ disabling and the related PSR chicken bits when we can use PKG_C_LATENCY for early wake... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250624170049.27284-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2025-06-27drm/i915: Set PKG_C_LATENCY.added_wake_time to 0Ville Syrjälä
AFAIK PKG_C_LATENCY.added_wake_time only matters for flip queue. As long as we're not using that there's no point in adding any extra wake time. 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/20250624170049.27284-2-ville.syrjala@linux.intel.com
2025-06-27drm/i915/dsi: Fix NULL pointer deref in vlv_dphy_param_init()Hans de Goede
Commit 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display") added a to_intel_display(connector) call to vlv_dphy_param_init() but when vlv_dphy_param_init() gets called the connector object has not been initialized yet, so this leads to a NULL pointer deref: BUG: kernel NULL pointer dereference, address: 000000000000000c ... Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.314 08/13/2015 RIP: 0010:vlv_dsi_init+0x4e6/0x1600 [i915] ... Call Trace: <TASK> ? intel_step_name+0x4be8/0x5c30 [i915] intel_setup_outputs+0x2d6/0xbd0 [i915] intel_display_driver_probe_nogem+0x13f/0x220 [i915] i915_driver_probe+0x3d9/0xaf0 [i915] Use to_intel_display(&intel_dsi->base) instead to fix this. Fixes: 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display") Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250626143317.101706-1-hansg@kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-27drm/bridge: samsung-dsim: Use HZ_PER_MHZ macro from units.hPhilipp Zabel
Drop the custom MHZ macro and replace it with HZ_PER_MHZ. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20250527-samsung-dsim-v1-2-5be520d84fbb@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-06-27drm/bridge: samsung-dsim: use while loop in samsung_dsim_transfer_startPhilipp Zabel
Turn the open-coded goto-again construct into a while loop, to make samsung_dsim_transfer_start() a bit shorter and easier to read. Hold the spinlock when looping back around and avoid the duplicated list_empty() check. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20250527-samsung-dsim-v1-1-5be520d84fbb@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-06-27firmware: sysfb: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250627103454.702606-1-andriy.shevchenko@linux.intel.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-06-27drm/i915/psr: Add intel_psr2_panic_force_full_updateJocelyn Falempe
When the panic handler is called, configure the psr to send the full framebuffer to the monitor, otherwise the panic screen is only partially visible. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-12-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915/display: Add drm_panic support for 4-tiling with DPTJocelyn Falempe
On Alder Lake and later, it's not possible to disable tiling when DPT is enabled. So this commit implements 4-Tiling support, to still be able to draw the panic screen. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-11-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915/display: Add drm_panic support for Y-tiling with DPTJocelyn Falempe
On Alder Lake and later, it's not possible to disable tiling when DPT is enabled. So this commit implements Y-Tiling support, to still be able to draw the panic screen. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-10-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915/display: Add drm_panic supportJocelyn Falempe
This adds drm_panic support for a wide range of Intel GPU. I've tested it only on 4 laptops, Haswell (with 128MB of eDRAM), Comet Lake, Raptor Lake, and Lunar Lake. For hardware using DPT, it's not possible to disable tiling, as you will need to reconfigure the way the GPU is accessing the framebuffer, so this will be handled by the following patches. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-9-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915: Add intel_bo_panic_setup() and intel_bo_panic_finish()Jocelyn Falempe
Implement both functions for i915 and xe, they prepare the work for drm_panic support. They both use kmap_try_from_panic(), and map one page at a time, to write the panic screen on the framebuffer. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-8-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915: Add intel_bo_alloc_framebuffer()Jocelyn Falempe
Encapsulate the struct intel_framebuffer into an xe_framebuffer or i915_framebuffer, and allow to add specific fields for each variant for the panic use-case. This is particularly needed to have a struct xe_res_cursor available to support drm panic on discrete GPU. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-7-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/ttm: Add ttm_bo_kmap_try_from_panic()Jocelyn Falempe
If the ttm bo is backed by pages, then it's possible to safely kmap one page at a time, using kmap_try_from_panic(). Unfortunately there is no way to do the same with ioremap, so it only supports the kmap case. This is needed for proper drm_panic support with xe driver. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250624091501.257661-6-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915/display: Add a disable_tiling() for skl planesJocelyn Falempe
drm_panic draws in linear framebuffer, so it's easier to re-use the current framebuffer, and disable tiling in the panic handler, to show the panic screen. This assumes that the alignment restriction is always smaller in linear than in tiled. It also assumes that the linear framebuffer size is always smaller than the tiled. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-5-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915/display/i9xx: Add a disable_tiling() for i9xx planesJocelyn Falempe
drm_panic draws in linear framebuffer, so it's easier to re-use the current framebuffer, and disable tiling in the panic handler, to show the panic screen. This assumes that the alignment restriction is always smaller in linear than in tiled. It also assumes that the linear framebuffer size is always smaller than the tiled. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-4-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915/fbdev: Add intel_fbdev_get_map()Jocelyn Falempe
The vaddr of the fbdev framebuffer is private to the struct intel_fbdev, so this function is needed to access it for drm_panic. Also the struct i915_vma is different between i915 and xe, so it requires a few functions to access fbdev->vma->iomap. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-3-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/panic: Add a private field to struct drm_scanout_bufferJocelyn Falempe
This allows driver to set some private data in get_scanout_buffer(), and re-use them in set_pixel() callback. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250624091501.257661-2-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-27drm/i915: move GEM_QUIRK_PIN_SWIZZLED_PAGES to i915_gem.hKrzysztof Karas
Move this macro where other GEM_* definitions live. Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/all/ca83a9d8aa86bb92de84c31fd075e92a61f78895.1750251040.git.krzysztof.karas@intel.com
2025-06-27drm/i915: Move out engine related macros from i915_drv.hKrzysztof Karas
Move macros related to engines out of i915_drv.h header and place them in intel_engine.h. Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/9b9ed5bbdb37470fa679c5baf961424c9cfbad11.1750251040.git.krzysztof.karas@intel.com
2025-06-27Merge tag 'drm-misc-next-2025-06-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.17: UAPI Changes: Cross-subsystem Changes: Core Changes: - ci: Add Device tree validation and kunit - connector: Move HDR sink metadat to drm_display_info Driver Changes: - bochs: drm_panic Support - panfrost: MT8370 Support - bridge: - tc358767: Convert to devm_drm_bridge_alloc() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250626-sincere-loon-of-effort-6dbdf9@houat
2025-06-27drm/fourcc: Add 32b float formatsRob Clark
Add 1, 2, 3, and 4 component 32b float formats, so that buffers with these formats can be imported/exported with fourcc+modifier, and/or created by gbm. These correspond to PIPE_FORMAT_{R32,R32G32,R32G32B32,R32G32B32A32}_FLOAT in mesa. v2: Fix comment describing float32 layout [Sima] Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Simona Vetter <simona@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250625173712.116446-3-robin.clark@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-27drm/fourcc: Add missing half-float formatsRob Clark
Not something that is likely to be scanned out, but GPUs usually support half-float formats with 1, 2, or possibly 3 components, and it is useful to be able to import/export them with a valid fourcc, and/or use gbm to create them. These correspond to PIPE_FORMAT_{R16,R16G16,R16G16B16}_FLOAT in mesa. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Simona Vetter <simona@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250625173712.116446-2-robin.clark@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-26drm/xe: Fix out-of-bounds field write in MI_STORE_DATA_IMMJia Yao
According to Bspec, bits 0~9 of MI_STORE_DATA_IMM must not exceed 0x3FE. The macro MI_SDI_NUM_QW(x) evaluates to 2 * x + 1, which means the condition 2 * x + 1 <= 0x3FE must be satisfied. Therefore, the maximum valid value for x is 0x1FE, not 0x1FF. v2 - Replace 0x1fe with macro MAX_PTE_PER_SDI (Auld, Matthew & Patelczyk, Maciej) v3 - Change macro MAX_PTE_PER_SDI from 0x1fe to 0x1feU (De Marchi, Lucas) Bspec: 60246 Fixes: 9c44fd5f6e8a ("drm/xe: Add migrate layer functions for SVM support") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Brian3 Nguyen <brian3.nguyen@intel.com> Cc: Alex Zuo <alex.zuo@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Maciej Patelczyk <maciej.patelczyk@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Jia Yao <jia.yao@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Link: https://lore.kernel.org/r/20250612224620.161105-1-jia.yao@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-26drm/xe: Rename xe_uc_init_hw to xe_uc_load_hwMaarten Lankhorst
It feels to me like load is closer to the intention than init_hw. It makes the init calls slightly less confusing to me. :) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-24-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Remove xe_uc_fini_hwMaarten Lankhorst
xe_uc_init_hw() is called multiple times from xe_gt.c, and that makes the name xe_uc_fini_hw(), called for a different reason in xe_guc.c confusing. Remove it and inline the xe_uc_sanitize_reset into xe_guc.c directly. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-23-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Remove xe_uc_init_hwconfig()Maarten Lankhorst
This function is called immediately after xe_uc_init(), so just put it there instead. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-22-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Move xe_ttm_sys_mgr_init() downwards.Maarten Lankhorst
Now that all previous allocations are gone, ensure no new allocations will ever be done before xe_display_init_early(), by moving the call that allows allocations downwards. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-21-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Split init of xe_gt_init_hwconfig to xe_gt_init and *_earlyMaarten Lankhorst
Now that we added the separate step of initialising GUC in xe_gt_init_early, it should be ok to initialise the minimum during early init, and the rest after allocations are allowed. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-20-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Rename gt_init sub-functionsMaarten Lankhorst
s/gt_fw_domain_init/gt_init_with_gt_forcewake()/ s/all_fw_domain_init/gt_init_with_all_forcewake()/ Clarify that the functions are the part of gt_init() that are called with the respective power domains held. all_domain() of course only works after discovering and initialisation of force_wake on all engines, that's why the split is needed in the first place. Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-19-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Only dump PAT when xe_hw_engines_init_early failsMaarten Lankhorst
After discussion with Lucas De Marchi, it turns out that is the specific caller requiring a dump. This allows us to cleanup gt_init in a bit. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-18-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Make it possible to read instance0 MCR registers after ↵Maarten Lankhorst
xe_gt_mcr_init_early After mcr_init_early, we need to be able to do VRAM and CCS probing without hwconfig probe. Fortunately the relevant registers are all instance 0, which fortunately means no dependencies on further initialization is required. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-17-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Simplify GuC early initializationMaarten Lankhorst
Add a 2-stage GuC init. An early one for everything that is needed for VF, and a full one that loads GuC and is allowed to do allocations. Link: https://lore.kernel.org/r/20250619104858.418440-16-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-26drm/xe/sriov: Move VF bootstrap and query_config to vf_guc_initMaarten Lankhorst
We want to split up GUC init to an alloc and noalloc part to keep the init path the same for VF and !VF as much as possible. Everything in vf_guc_init should be done as early as possible, otherwise VRAM probing becomes impossible. Also move xe_gt_mmio_init to the end of xe_gt_init_early(), cleaning up the init in xe_device slightly. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-15-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Defer memirq init until neededMaarten Lankhorst
memirqs require allocations into GGTT, which we cannot use until after display is enabled. Now that the initialisation of interrupts is postponed, move memirq init too. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-14-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/i915/power: convert {SKL, ICL}_PW_CTL_IDX_TO_PG() macros to a functionJani Nikula
Add pw_ctl_idx_to_pg() helper function to deduplicate the open-coded usage of the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/3aa74825db0b900f93b94aa89d0242a354929b85.1750855148.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/power: relocate {SKL,ICL}_PW_CTL_IDX_TO_PG()Jani Nikula
Move the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros from intel_display_regs.h to intel_display_power_well.c. The mapping from index to PG can be hidden there. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/18e40b77eeb3517a056f1e567672163ec568ec55.1750855148.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/power: move enum skl_power_gate under displayJani Nikula
When the display registers were split off from i915_reg.h, enum skl_power_gate was left behind. Move it to intel_display_regs.h. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/495054983b74163ca7dcbf5a1b6a24099047bc64.1750855148.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/xe: Implement and use the drm_pagemap populate_mm opThomas Hellström
Add runtime PM since we might call populate_mm on a foreign device. v3: - Fix a kerneldoc failure (Matt Brost) - Revert the bo type change from device to kernel (Matt Brost) v4: - Add an assert in xe_svm_alloc_vram (Matt Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250619134035.170086-4-thomas.hellstrom@linux.intel.com
2025-06-26drm/pagemap: Add a populate_mm opThomas Hellström
Add an operation to populate a part of a drm_mm with device private memory. Clarify how migration using it is intended to work. v3: - Kerneldoc fixes and updates (Matt Brost). v4: - More kerneldoc fixes. Rebase. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250619134035.170086-3-thomas.hellstrom@linux.intel.com
2025-06-26drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemapMatthew Brost
The migration functionality and track-keeping of per-pagemap VRAM mapped to the CPU mm is not per GPU_vm, but rather per pagemap. This is also reflected by the functions not needing the drm_gpusvm structures. So move to drm_pagemap. With this, drm_gpusvm shouldn't really access the page zone-device-data since its meaning is internal to drm_pagemap. Currently it's used to reject mapping ranges backed by multiple drm_pagemap allocations. For now, make the zone-device-data a void pointer. Alter the interface of drm_gpusvm_migrate_to_devmem() to ensure we don't pass a gpusvm pointer. Rename CONFIG_DRM_XE_DEVMEM_MIRROR to CONFIG_DRM_XE_PAGEMAP. Matt is listed as author of this commit since he wrote most of the code, and it makes sense to retain his git authorship. Thomas mostly moved the code around. v3: - Kerneldoc fixes (CI) - Don't update documentation about how the drm_pagemap migration should be interpreted until upcoming patches where the functionality is implemented. (Matt Brost) v4: - More kerneldoc fixes around timeslice_ms (Himal Ghimiray, Matt Brost) v6: - Fix an uninitialized pagemap pointer (CI) Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250619134035.170086-2-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm, drm_xe, Implement ttm_lru_walk_for_evict() using the guarded LRU ↵Thomas Hellström
iteration To avoid duplicating the tricky bo locking implementation, Implement ttm_lru_walk_for_evict() using the guarded bo LRU iteration. To facilitate this, support ticketlocking from the guarded bo LRU iteration. v2: - Clean up some static function interfaces (Christian König) - Fix Handling -EALREADY from ticketlocking in the loop by skipping to the next item. (Intel CI) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-4-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm, drm/xe: Modify the struct ttm_bo_lru_walk_cursor initializationThomas Hellström
Instead of the struct ttm_operation_ctx, Pass a struct ttm_lru_walk_arg to enable us to easily extend the walk functionality, and to implement ttm_lru_walk_for_evict() using the guarded LRU iteration. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-3-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm: Use a struct for the common part of struct ttm_lru_walk and struct ↵Thomas Hellström
ttm_bo_lru_cursor Let the locking functions take the new struct ttm_lru_walk_arg as argument in order for them to be easily used from both types of walk. v2: - Whitespace fix Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-2-thomas.hellstrom@linux.intel.com
2025-06-26drm/i915/selftests: Change mock_request() to return error pointersDan Carpenter
There was an error pointer vs NULL bug in __igt_breadcrumbs_smoketest(). The __mock_request_alloc() function implements the smoketest->request_alloc() function pointer. It was supposed to return error pointers, but it propogates the NULL return from mock_request() so in the event of a failure, it would lead to a NULL pointer dereference. To fix this, change the mock_request() function to return error pointers and update all the callers to expect that. Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/685c1417.050a0220.696f5.5c05@mx.google.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-26drm/panel-edp: Add CMN N116BCJ-EAKLangyan Ye
Add support for the CMN N116BCJ-EAK, pleace the EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0d ae 63 11 00 00 00 00 19 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20 a6 00 00 90 10 00 00 18 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 80 Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250626122854.193239-1-yelangyan@huaqin.corp-partner.google.com
2025-06-26drm/bridge: ti-sn65dsi86: remove unnecessary GPIO line direction checkBartosz Golaszewski
As of commit 92ac7de3175e3 ("gpiolib: don't allow setting values on input lines"), the GPIO core makes sure values cannot be set on input lines. Remove the unnecessary check. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250620074951.32758-1-brgl@bgdev.pl
2025-06-26drm/bridge: add warning for bridges not using devm_drm_bridge_alloc()Luca Ceresoli
To the best of my knowledge, all drivers in the mainline kernel adding a DRM bridge are now converted to using devm_drm_bridge_alloc() for allocation and initialization. Among others this ensures initialization of the bridge refcount, allowing dynamic allocation lifetime. devm_drm_bridge_alloc() is now mandatory for all new bridges. Code using the old pattern ([devm_]kzalloc + filling the struct fields + drm_bridge_add) is not allowed anymore. Any drivers that might have been missed during the conversion, patches in flight towards mainline and out-of-tre drivers still using the old pattern will already be caught by a warning looking like: ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 2 PID: 83 at lib/refcount.c:25 refcount_warn_saturate+0x120/0x148 [...] Call trace: refcount_warn_saturate+0x120/0x148 (P) drm_bridge_get.part.0+0x70/0x98 [drm] drm_bridge_add+0x34/0x108 [drm] sn65dsi83_probe+0x200/0x480 [ti_sn65dsi83] [...] This warning comes from the refcount code and happens because drm_bridge_add() is increasing the refcount, which is uninitialized and thus initially zero. Having a warning and the corresponding stack trace is surely useful, but the warning text does not clarify the root problem nor how to fix it. Add a DRM_WARN() just before increasing the refcount, so the log will be much more readable: [drm] DRM bridge corrupted or not allocated by devm_drm_bridge_alloc() ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. [...etc...] A DRM_WARN is used because drm_warn and drm_WARN require a struct drm_device pointer which is not yet available when adding a bridge. Do not print the dev_name() in the warning because struct drm_bridge has no pointer to the struct device. The affected driver should be easy to catch based on the following stack trace however. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-3-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/bridge: get/put the bridge reference in drm_bridge_attach/detach()Luca Ceresoli
drm_bridge_attach() adds the bridge to the encoder chain, so take a reference for that. Vice versa in drm_bridge_detach(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-2-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/bridge: get/put the bridge reference in drm_bridge_add/remove()Luca Ceresoli
drm_bridge_add() adds the bridge to the global bridge_list, so take a reference for that. Vice versa in drm_bridge_remove(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-1-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
generated by cgit (git 2.34.1) at 2025-09-22 11:14:38 +0000