summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-06-30drm/dp: Introduce new member in drm_backlight_infoSuraj Kandpal
Introduce luminance_set flag which indicates if we can manipulate backlight using luminance value or not which is only possible after eDP v1.5. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-2-suraj.kandpal@intel.com
2025-06-30drm/vmwgfx: drop printing the TTM refcount for debuggingChristian König
That is something TTM internal which is about to get dropped. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://lore.kernel.org/r/20250616130726.22863-1-christian.koenig@amd.com
2025-06-30drm/i915/gt: Fix timeline left held on VMA alloc errorJanusz Krzysztofik
The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform: <4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that's followed with: <3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ... Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt. All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular. If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error. In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind. Get the legacy timeline only after successful allocation of the context engine's VMA. v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue. Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061 Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@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/20250611104352.1014011-2-janusz.krzysztofik@linux.intel.com
2025-06-30drm/i915/display: Fix macro HAS_ULTRAJOINERAnkit Nautiyal
Currently, Ultrajoiner is supported only on Xe2_HPD. Update the HAS_ULTRAJOINER macro to reflect the same. v2: Clarify the commit message to specify platform. (Jani) Bspec: 69556 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Karthik B S <karthik.b.s@intel.com> Link: https://lore.kernel.org/r/20250611053039.377695-1-ankit.k.nautiyal@intel.com
2025-06-29drm/ci: i915: cml: Fix the runner tagVignesh Raman
The GitLab runner tags are case sensitive, and Flip-hatch's tag was incorrectly lowercase. This prevented jobs from being picked up by the runner. Fix the runner tag for Flip-hatch. Based on https://gitlab.freedesktop.org/mesa/mesa/-/commit/03b480d3 Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-29drm/ci: Remove sdm845/cheza jobsRob Clark
These runners are no more. So remove the jobs. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-28drm/ci: uprev mesa and ci-templatesVignesh Raman
The current s3cp stopped working after the migration. Update to the latest mesa and ci-templates to get s3cp working again and adapt to recent changes in mesa-ci. Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-28drm/ci: python-artifacts: use shallow cloneVignesh Raman
The python-artifacts job has a timeout of 10 minutes, which causes build failures as it was unable to clone the repository within the specified limits. Set GIT_DEPTH to 10 to speed up cloning and avoid build failures due to timeouts when fetching the full repository. Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-28Merge remote-tracking branch 'drm/drm-next' into msm-nextRob Clark
Back-merge drm-next to (indirectly) get arm-smmu updates for making stall-on-fault more reliable. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-06-28drm/xe: Fix conflicting intel_pcode_* symbolsLucas De Marchi
If CONFIG_DRM_XE_DISPLAY is set, the xe module can only be built as module to avoid duplicate symbols from i915. The interface for pcode was added without considering that, so the build breaks if both xe and i915 are built-in. Since the intel_pcode_* functions should only be called from the display side (xe side should call the xe interface directly) and there's already a protection in Kconfig to avoid the problematic configuration, ifdef it out in case CONFIG_DRM_XE_DISPLAY is disabled. Closes: https://lore.kernel.org/r/3667a992-a24b-4e49-aab2-5ca73f2c0a56@infradead.org Fixes: d9465cc8ac2d ("drm/xe/pcode: add struct drm_device based interface") Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250627-xe-kunit-v2-1-756fe5cd56cf@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-28drm/fourcc: Add RGB161616 and BGR161616 formatsJacopo Mondi
Add FourCC definitions for the 48-bit RGB/BGR formats to the DRM/KMS uapi. The format will be used by the Raspberry Pi PiSP Back End, supported by a V4L2 driver in kernel space and by libcamera in userspace, which uses the DRM FourCC identifiers. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Link: https://lore.kernel.org/r/20240226132544.82817-1-jacopo.mondi@ideasonboard.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-06-27drm/format-helper: Split off byte swapping from drm_fb_xrgb8888_to_rgb565()Thomas Zimmermann
Move big-endian support from drm_fb_xrgb8888_to_rgb565() into the new helper drm_xrgb8888_to_rgb565be(). The functionality is required for displays with big-endian byte order. Update all callers. With the change applied, drm_fb_xrgb8888_to_rgb565() has the same signature as the other conversion functions, which is required for further updates to drm_fb_blit(). Also makes the format-conversion helper available to panic handlers, if necessary. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250625114911.1121301-1-tzimmermann@suse.de
2025-06-27drm/i915/flipq: Add intel_flipq_dump()Ville Syrjälä
Add a function for dumping the entries of a specific flip queue. 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-9-ville.syrjala@linux.intel.com
2025-06-27drm/i915/flipq: Implement Wa_18034343758Ville Syrjälä
Implement the driver side of Wa_18034343758, which is supposed to prevent the DSB and DMC from accessing registers in parallel, and thus potentially corrupting the registers due to a hardware issue (which should be fixed in PTL-B0). The w/a sequence goes as follows: DMC starts the DSB | \ DMC halts itself | DSB waits a while for DMC to have time to halt . | DSB executes normally . | DSB unhalts the DMC at the very end . / DMC resumes execution v2: PTL-B0+ firmware no longer has the w/a since the hw got fixed v3: Do the w/a on all PTL for now since we only have the A0 firmware binaries which issues the halt instructions unconditionally v4: PTL DMC binaries do in fact have the A0 vs. B0 split, so skip the w/a on PTL-B0+ 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-7-ville.syrjala@linux.intel.com
2025-06-27drm/i915/flipq: Implement flip queue based commit pathVille Syrjälä
Support commits via the flip queue (as opposed to DSB or MMIO). As it's somewhat unknown if we can actually use it is currently gated behind the new use_flipq modparam, which defaults to disabled. The implementation has a bunch of limitations that would need real though to solve: - disabled when PSR is used - disabled when VRR is used - color management updates not performed via the flip queue v2: Don't use flip queue if there is no dmc v3: Use intel_flipq_supported() v3: Configure PKG_C_LATENCY appropriately Ignore INT_VECTOR if there is a real PIPEDMC interrupt (nothing in the hw appears to clear INT_VECTOR) v4: Leave added_wake_time=0 when flip queue isn't used, to avoid needleslly increasing pkg_c_latency on lnl/ptl due to Wa_22020432604. This is a bit racy though... Use IS_DISPLAY_VER() 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-6-ville.syrjala@linux.intel.com
2025-06-27drm/i915/flipq: Provide the nuts and bolts code for flip queueVille Syrjälä
Provide the lower level code for PIPEDMC based flip queue. We'll use the so called semi-full flip queue mode where the PIPEDMC will start the provided DSB on a scanline a little ahead of the vblank. We need to program the triggering scanline early enough so that the DSB has enough time to complete writing all the double buffered registers before they get latched (at start of vblank). The firmware implements several queues: - 3 "plane queues" which execute a single DSB per entry - 1 "general queue" which can apparently execute 2 DSBs per entry - 1 vestigial "fast queue" that replaced the "simple flip queue" on ADL+, but this isn't supposed to be used due to issues. But we only need a single plane queue really, and we won't actually use it as a real queue because we don't allow queueing multiple commits ahead of time. So the whole thing is perhaps useless. I suppose there migth be some power saving benefits if we would get the flip scheduled by userspace early and then could keep some hardware powered off a bit longer until the DMC kicks off the flipq programming. But that is pure speculation at this time and needs to be proven. The code to hook up the flip queue into the actual atomic commit path will follow later. TODO: need to think how to do the "wait for DMC firmware load" nicely need to think about VRR and PSR etc. v2: Don't write DMC_FQ_W2_PTS_CFG_SEL on pre-lnl Don't oops at flipq init if there is no dmc v3: Adapt to PTL+ flipq changes (different queue entry layout, different trigger event, need VRR TG) Use the actual CDCLK frequency Ask the DSB code how long things are expected to take v3: Adjust the cdclk rounding (docs are 100% vague, Windows rounds like this) Initialize some undocumented magic DMC variables on PTL v4: Use PIPEDMC_FQ_STATUS for busy check (the busy bit in PIPEDMC_FQ_CTRL is apparently gone on LNL+) Based the preempt timeout on the max exec time Preempt before disabling the flip queue Order the PIPEDMC_SCANLINECMP* writes a bit more carefully Fix some typos v5: Try to deal with some clang-20 div-by-zero false positive (Nathan) Add some docs (Jani) Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> epr Link: https://patchwork.freedesktop.org/patch/msgid/20250624170049.27284-5-ville.syrjala@linux.intel.com
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-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/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-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/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>
2025-06-26drm/tidss: Add OLDI bridge supportAradhya Bhatia
The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it possible to connect them in dual-link or cloned single-link OLDI display modes. The current OLDI support in tidss_dispc.c can only support for a single OLDI TX, connected to a VP and doesn't really support configuration of OLDIs in the other modes. The current OLDI support in tidss_dispc.c also works on the principle that the OLDI output can only be served by one, and only one, DSS video-port. This isn't the case in the AM62Px SoC, where there are 2 DSS controllers present that share the OLDI TXes. Having their own devicetree and their own bridge entity will help support the various display modes and sharing possiblilities of the OLDI hardware. For all these reasons, add support for the OLDI TXes as DRM bridges. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Michael Walle <mwalle@kernel.org> # on am67a Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/20250528122544.817829-5-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26drm/tidss: Mark AM65x OLDI code separatelyAradhya Bhatia
The dss dt schema and the tidss driver have kept the single-link OLDI in AM65x integrated with the parent video-port (VP) from DSS (as the OLDI configuration happens from the source VP only). To help configure the dual-lvds modes that the OLDI has to offer in devices AM62x and later, a new OLDI bridge driver will be introduced. Mark the existing OLDI code separately by renaming all the current OLDI identifiers with the 'AM65X_' prefix in tidss driver, to help distinguish from the upcoming OLDI bridge driver. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Link: https://lore.kernel.org/r/20250528122544.817829-4-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26drm/i915/display: move unordered works to new private workqueueLuca Coelho
Create a new unordered workqueue to be used by the display code instead of relying on the i915 one. Then move all the unordered works used in the display code to use this new queue. Since this is an unordered workqueue, by definition there can't be any order dependency with non-display works, so no extra care is needed in regard to that. This is part of the effort to isolate the display code from i915. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250620091632.1256135-1-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
generated by cgit (git 2.34.1) at 2025-09-11 19:13:51 +0000