summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-02-14drm/i915/ddi: Fix HDMI port width programming in DDI_BUF_CTLImre Deak2-2/+2
Fix the port width programming in the DDI_BUF_CTL register on MTLP+, where this had an off-by-one error. Cc: <stable@vger.kernel.org> # v6.5+ Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-3-imre.deak@intel.com
2025-02-14drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macroImre Deak1-2/+2
The format of the port width field in the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the x3 lane mode for HDMI FRL has a different encoding in the two registers. To account for this use the TRANS_DDI_FUNC_CTL's own port width macro. Cc: <stable@vger.kernel.org> # v6.5+ Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-2-imre.deak@intel.com
2025-02-14drm/xe/debugfs: fixed the return value of wedged_mode_setXin Wang1-1/+1
It is generally expected that the write() function should return a positive value indicating the number of bytes written or a negative error code if an error occurs. Returning 0 is unusual and can lead to unexpected behavior. When the user program writes the same value to wedged_mode twice in a row, a lockup will occur, because the value expected to be returned by the write() function inside the program should be equal to the actual written value instead of 0. To reproduce the issue: echo 1 > /sys/kernel/debug/dri/0/wedged_mode echo 1 > /sys/kernel/debug/dri/0/wedged_mode <- lockup here Signed-off-by: Xin Wang <x.wang@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213223615.2327367-1-x.wang@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-14drm/xe/debugfs: Add missing xe_pm_runtime_put in wedge_mode_setShuicheng Lin1-0/+1
xe_pm_runtime_put is missed in the failure path. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213230322.1180621-1-shuicheng.lin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-14nouveau/svm: fix missing folio unlock + put after make_device_exclusive_range()David Hildenbrand1-2/+7
In case we have to retry the loop, we are missing to unlock+put the folio. In that case, we will keep failing make_device_exclusive_range() because we cannot grab the folio lock, and even return from the function with the folio locked and referenced, effectively never succeeding the make_device_exclusive_range(). While at it, convert the other unlock+put to use a folio as well. This was found by code inspection. Fixes: 8f187163eb89 ("nouveau/svm: implement atomic SVM access") Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Tested-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250124181524.3584236-2-david@redhat.com
2025-02-14drm/i915/psr: Allow DSB usage when PSR is enabledJouni Högander1-1/+2
Now as we have correct PSR2_MAN_TRK_CTL handling in place we can allow DSB usage also when PSR is enabled for LunarLake onwards. v2: rebase Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-14-jouni.hogander@intel.com
2025-02-14drm/i915/display: Ensure we have "Frame Change" event in DSB commitJouni Högander1-0/+8
We may have commit which doesn't have any non-arming plane register writes. In that case there aren't "Frame Change" event before DSB vblank evasion which hangs as PIPEDSL register is reading as 0 when PSR state is SRDENT(PSR1) or DEEP_SLEEP(PSR2). Handle this by ensuring "Frame Change" event at the begin of DSB commit if using PSR/PR. v3: dsb_commit as a first parameter v2: use intel_psr_trigger_frame_change_event Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-13-jouni.hogander@intel.com
2025-02-14drm/i915/psr: Add function for triggering "Frame Change" eventJouni Högander2-0/+25
Add new function to trigger "Frame Change" event for ensuring we are waking up before vblank evasion. v2: dsb as a first parameter Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-12-jouni.hogander@intel.com
2025-02-14drm/i915/display: Evade scanline 0 as well if PSR1 or PSR2 is enabledJouni Högander1-0/+12
PIPEDSL is reading as 0 when in SRDENT(PSR1) or DEEP_SLEEP(PSR2). On wake-up scanline counting starts from vblank_start - 1. We don't know if wake-up is already ongoing when evasion starts. In worst case PIPEDSL could start reading valid value right after checking the scanline. In this scenario we wouldn't have enough time to write all registers. To tackle this evade scanline 0 as well. As a drawback we have 1 frame delay in flip when waking up. v2: - use intel_dsb_emit_wait_dsl - add evasion of scanline 0 also for Panel Replay Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-11-jouni.hogander@intel.com
2025-02-14drm/i915/psr: Remove DSB_SKIP_WAITS_EN chicken bitJouni Högander1-3/+12
We have different approach on how flip is considered being complete. We are waiting for vblank on DSB and generate interrupt when it happens and this interrupt is considered as indication of completion -> we definitely do not want to skip vblank wait. Also not skipping scanline wait shouldn't cause any problems if we are in DEEP_SLEEP PIPEDSL register is returning 0 -> evasion does nothing and if we are not in DEEP_SLEEP evasion works same way as without PSR. v2: add comment explaining why we are not setting DSB_SKIP_WAITS_EN Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-10-jouni.hogander@intel.com
2025-02-14drm/i915/display: Warn on use_dsb in non-dsb pipe update functionsJouni Högander2-1/+9
Add drm_WARN_ON(use_dsb) into commit_pipe_{pre,post}_planes() and intel_pipe_update_{start,end}() as they are not supposed to get called on non-dsb updates. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-9-jouni.hogander@intel.com
2025-02-14Merge tag 'drm-xe-fixes-2025-02-13' of ↵Dave Airlie2-25/+31
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Remove bo->clients out of bos_lock area (Tejas) - Carve out wopcm portion from the stolen memory (Nirmoy) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z64rCicgpBe_t5GY@intel.com
2025-02-14Merge tag 'drm-intel-fixes-2025-02-13' of ↵Dave Airlie1-2/+2
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Selftest fix: avoid using uninitialized context Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z64qg13R_72iN3_X@intel.com
2025-02-14Merge tag 'amd-drm-fixes-6.14-2025-02-13' of ↵Dave Airlie8-9/+49
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.14-2025-02-13: amdgpu: - Fix shutdown regression on old APUs - Fix compute queue hang on gfx9 APUs - Fix possible invalid access in PSP failure path - Avoid possible buffer overflow in pptable override amdkfd: - Properly free gang bo in failure path - GFX12 trap handler fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213153843.242640-1-alexander.deucher@amd.com
2025-02-14Merge tag 'drm-misc-fixes-2025-02-13' of ↵Dave Airlie6-100/+109
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Some locking fixes for the HDMI infrastructure tests, an unitialized mutex fix for host1x, an unitialized variable fix for panthor, and a config selection fix for hibmc. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213-brilliant-terrier-from-hell-d06dd5@houat
2025-02-14Merge tag 'drm-misc-next-2025-02-12' of ↵Dave Airlie231-2390/+6010
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.15: UAPI Changes: fourcc: - Add modifiers for MediaTek tiled formats Cross-subsystem Changes: bus: - mhi: Enable image transfer via BHIe in PBL dma-buf: - Add fast-path for single-fence merging Core Changes: atomic helper: - Allow full modeset on connector changes - Clarify semantics of allow_modeset - Clarify semantics of drm_atomic_helper_check() buddy allocator: - Fix multi-root cleanup ci: - Update IGT display: - dp: Support Extendeds Wake Timeout - dp_mst: Fix RAD-to-string conversion panic: - Encode QR code according to Fido 2.2 probe helper: - Cleanups scheduler: - Cleanups ttm: - Refactor pool-allocation code - Cleanups Driver Changes: amdxdma: - Fix error handling - Cleanups ast: - Refactor detection of transmitter chips - Refactor support of VBIOS display-mode handling - astdp: Fix connection status; Filter unsupported display modes bridge: - adv7511: Report correct capabilities - it6505: Fix HDCP V compare - sn65dsi86: Fix device IDs - Cleanups i915: - Enable Extendeds Wake Timeout imagination: - Check job dependencies with DRM-sched helper ivpu: - Improve command-queue handling - Use workqueue for IRQ handling - Add suport for HW fault injection - Locking fixes - Cleanups mgag200: - Add support for G200eH5 chips msm: - dpu: Add concurrent writeback support for DPU 10.x+ nouveau: - Move drm_slave_encoder interface into driver - nvkm: Refactor GSP RPC omapdrm: - Cleanups panel: - Convert several panels to multi-style functions to improve error handling - edp: Add support for B140UAN04.4, BOE NV140FHM-NZ, CSW MNB601LS1-3, LG LP079QX1-SP0V, MNE007QS3-7, STA 116QHD024002, Starry 116KHD024006, Lenovo T14s Gen6 Snapdragon - himax-hx83102: Add support for CSOT PNA957QT1-1, Kingdisplay kd110n11-51ie, Starry 2082109qfh040022-50e panthor: - Expose sizes of intenral BOs via fdinfo - Fix race between reset and suspend - Cleanups qaic: - Add support for AIC200 - Cleanups renesas: - Fix limits in DT bindings rockchip: - rk3576: Add HDMI support - vop2: Add new display modes on RK3588 HDMI0 up to 4K - Don't change HDMI reference clock rate - Fix DT bindings solomon: - Set SPI device table to silence warnings - Fix pixel and scanline encoding v3d: - Cleanups vc4: - Use drm_exec - Use dma-resv for wait-BO ioctl - Remove seqno infrastructure virtgpu: - Support partial mappings of GEM objects - Reserve VGA resources during initialization - Fix UAF in virtgpu_dma_buf_free_obj() - Add panic support vkms: - Switch to a managed modesetting pipeline - Add support for ARGB8888 xlnx: - Set correct DMA segment size - Fix error handling - Fix docs Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250212090625.GA24865@linux.fritz.box
2025-02-14drm/amdgpu: Enable async flip on overlay planesAndré Almeida1-4/+7
amdgpu can handle async flips on overlay planes, so allow it for atomic async checks. Signed-off-by: André Almeida <andrealmeid@igalia.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250127-tonyk-async_flip-v12-2-0f7f8a8610d3@igalia.com [DB: fixed checkpatch warning by adding braces] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-02-14drm/atomic: Let drivers decide which planes to async flipAndré Almeida8-17/+36
Currently, DRM atomic uAPI allows only primary planes to be flipped asynchronously. However, each driver might be able to perform async flips in other different plane types. To enable drivers to set their own restrictions on which type of plane they can or cannot flip, use the existing atomic_async_check() from struct drm_plane_helper_funcs to enhance this flexibility, thus allowing different plane types to be able to do async flips as well. Create a new parameter for the atomic_async_check(), `bool flip`. This parameter is used to distinguish when this function is being called from a plane update from a full page flip. In order to prevent regressions and such, we keep the current policy: we skip the driver check for the primary plane, because it is always allowed to do async flips on it. Signed-off-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Christopher Snowhill <chris@kode54.net> Tested-by: Christopher Snowhill <chris@kode54.net> Link: https://patchwork.freedesktop.org/patch/msgid/20250127-tonyk-async_flip-v12-1-0f7f8a8610d3@igalia.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-02-14drm/xe/display: Remove hpd cancel work sync from runtime pm pathRodrigo Vivi1-1/+2
This function will synchronously cancel and wait for many display work queue items, which might try to take the runtime pm reference causing a bad deadlock. So, remove it from the runtime_pm suspend patch. Reported-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212192447.402715-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-13drm/i915/gt: Use spin_lock_irqsave() in interruptible contextKrzysztof Karas1-2/+2
spin_lock/unlock() functions used in interrupt contexts could result in a deadlock, as seen in GitLab issue #13399, which occurs when interrupt comes in while holding a lock. Try to remedy the problem by saving irq state before spin lock acquisition. v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej) v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/pusppq5ybyszau2oocboj3mtj5x574gwij323jlclm5zxvimmu@mnfg6odxbpsv
2025-02-13drm/amdgpu: Use device wedged eventAndré Almeida1-0/+4
Use DRM's device wedged event to notify userspace that a reset had happened. For now, only use `none` method meant for telemetry capture. In the future we might want to report a recovery method if the reset didn't succeed. Acked-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204070528.1919158-6-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-13drm/i915: Use device wedged eventRaag Jadav1-0/+3
Now that we have device wedged event provided by DRM core, make use of it and support both driver rebind and bus-reset based recovery. With this in place, userspace will be notified of wedged device on gt reset failure. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204070528.1919158-5-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-13drm/xe: Use device wedged eventRaag Jadav1-1/+6
This was previously attempted as xe specific reset uevent but dropped in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now") as part of refactoring. Now that we have device wedged event provided by DRM core, make use of it and support both driver rebind and bus-reset based recovery. With this in place userspace will be notified of wedged device, on the basis of which, userspace may take respective action to recover the device. $ udevadm monitor --property --kernel monitor will print the received events for: KERNEL - the kernel uevent KERNEL[265.802982] change /devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/card0 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/card0 SUBSYSTEM=drm WEDGED=rebind,bus-reset DEVNAME=/dev/dri/card0 DEVTYPE=drm_minor SEQNUM=5208 MAJOR=226 MINOR=0 v2: Change authorship to Himal (Aravind) Add uevent for all device wedged cases (Aravind) v3: Generic implementation in DRM subsystem (Lucas) v4: Change authorship to Raag (Aravind) Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204070528.1919158-4-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-13drm: Introduce device wedged eventRaag Jadav1-0/+68
Introduce device wedged event, which notifies userspace of 'wedged' (hanged/unusable) state of the DRM device through a uevent. This is useful especially in cases where the device is no longer operating as expected and has become unrecoverable from driver context. Purpose of this implementation is to provide drivers a generic way to recover the device with the help of userspace intervention without taking any drastic measures (like resetting or re-enumerating the full bus, on which the underlying physical device is sitting) in the driver. A 'wedged' device is basically a device that is declared dead by the driver after exhausting all possible attempts to recover it from driver context. The uevent is the notification that is sent to userspace along with a hint about what could possibly be attempted to recover the device from userspace and bring it back to usable state. Different drivers may have different ideas of a 'wedged' device depending on hardware implementation of the underlying physical device, and hence the vendor agnostic nature of the event. It is up to the drivers to decide when they see the need for device recovery and how they want to recover from the available methods. Driver prerequisites -------------------- The driver, before opting for recovery, needs to make sure that the 'wedged' device doesn't harm the system as a whole by taking care of the prerequisites. Necessary actions must include disabling DMA to system memory as well as any communication channels with other devices. Further, the driver must ensure that all dma_fences are signalled and any device state that the core kernel might depend on is cleaned up. All existing mmaps should be invalidated and page faults should be redirected to a dummy page. Once the event is sent, the device must be kept in 'wedged' state until the recovery is performed. New accesses to the device (IOCTLs) should be rejected, preferably with an error code that resembles the type of failure the device has encountered. This will signify the reason for wedging, which can be reported to the application if needed. Recovery -------- Current implementation defines three recovery methods, out of which, drivers can use any one, multiple or none. Method(s) of choice will be sent in the uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in order of less to more side-effects. If driver is unsure about recovery or method is unknown (like soft/hard system reboot, firmware flashing, physical device replacement or any other procedure which can't be attempted on the fly), ``WEDGED=unknown`` will be sent instead. Userspace consumers can parse this event and attempt recovery as per the following expectations. =============== ======================================== Recovery method Consumer expectations =============== ======================================== none optional telemetry collection rebind unbind + bind driver bus-reset unbind + bus reset/re-enumeration + bind unknown consumer policy =============== ======================================== The only exception to this is ``WEDGED=none``, which signifies that the device was temporarily 'wedged' at some point but was recovered from driver context using device specific methods like reset. No explicit recovery is expected from the consumer in this case, but it can still take additional steps like gathering telemetry information (devcoredump, syslog). This is useful because the first hang is usually the most critical one which can result in consequential hangs or complete wedging. Consumer prerequisites ---------------------- It is the responsibility of the consumer to make sure that the device or its resources are not in use by any process before attempting recovery. With IOCTLs erroring out, all device memory should be unmapped and file descriptors should be closed to prevent leaks or undefined behaviour. The idea here is to clear the device of all user context beforehand and set the stage for a clean recovery. Example ------- Udev rule:: SUBSYSTEM=="drm", ENV{WEDGED}=="rebind", DEVPATH=="*/drm/card[0-9]", RUN+="/path/to/rebind.sh $env{DEVPATH}" Recovery script:: #!/bin/sh DEVPATH=$(readlink -f /sys/$1/device) DEVICE=$(basename $DEVPATH) DRIVER=$(readlink -f $DEVPATH/driver) echo -n $DEVICE > $DRIVER/unbind echo -n $DEVICE > $DRIVER/bind Customization ------------- Although basic recovery is possible with a simple script, consumers can define custom policies around recovery. For example, if the driver supports multiple recovery methods, consumers can opt for the suitable one depending on scenarios like repeat offences or vendor specific failures. Consumers can also choose to have the device available for debugging or telemetry collection and base their recovery decision on the findings. This is useful especially when the driver is unsure about recovery or method is unknown. v4: s/drm_dev_wedged/drm_dev_wedged_event Use drm_info() (Jani) Kernel doc adjustment (Aravind) v5: Send recovery method with uevent (Lina) v6: Access wedge_recovery_opts[] using helper function (Jani) Use snprintf() (Jani) v7: Convert recovery helpers into regular functions (Andy, Jani) Aesthetic adjustments (Andy) Handle invalid recovery method v8: Allow sending multiple methods with uevent (Lucas, Michal) static_assert() globally (Andy) v9: Provide 'none' method for device reset (Christian) Provide recovery opts using switch cases v11: Log device reset (André) Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204070528.1919158-2-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-13drm: panel: jd9365da-h3: fix reset signal polarityHugo Villeneuve1-4/+4
In jadard_prepare() a reset pulse is generated with the following statements (delays ommited for clarity): gpiod_set_value(jadard->reset, 1); --> Deassert reset gpiod_set_value(jadard->reset, 0); --> Assert reset for 10ms gpiod_set_value(jadard->reset, 1); --> Deassert reset However, specifying second argument of "0" to gpiod_set_value() means to deassert the GPIO, and "1" means to assert it. If the reset signal is defined as GPIO_ACTIVE_LOW in the DTS, the above statements will incorrectly generate the reset pulse (inverted) and leave it asserted (LOW) at the end of jadard_prepare(). Fix reset behavior by inverting gpiod_set_value() second argument in jadard_prepare(). Also modify second argument to devm_gpiod_get() in jadard_dsi_probe() to assert the reset when probing. Do not modify it in jadard_unprepare() as it is already properly asserted with "1", which seems to be the intended behavior. Fixes: 6b818c533dd8 ("drm: panel: Add Jadard JD9365DA-H3 DSI panel") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240927135306.857617-1-hugo@hugovil.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240927135306.857617-1-hugo@hugovil.com
2025-02-13drm: bridge: ti-sn65dsi83: Add error recovery mechanismHerve Codina1-0/+142
In some cases observed during ESD tests, the TI SN65DSI83 cannot recover from errors by itself. A full restart of the bridge is needed in those cases to have the bridge output LVDS signals again. Also, during tests, cases were observed where reading the status of the bridge was not even possible. Indeed, in those cases, the bridge stops to acknowledge I2C transactions. Only a full reset of the bridge (power off/on) brings back the bridge to a functional state. The TI SN65DSI83 has some error detection capabilities. Introduce an error recovery mechanism based on this detection. The errors detected are signaled through an interrupt. On system where this interrupt is not available, the driver uses a polling monitoring fallback to check for errors. When an error is present or when reading the bridge status leads to an I2C failure, the recovery process is launched. Restarting the bridge needs to redo the initialization sequence. This initialization sequence has to be done with the DSI data lanes driven in LP11 state. In order to do that, the recovery process resets the whole output path (i.e the path from the encoder to the connector) where the bridge is located. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250210132620.42263-5-herve.codina@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-13drm/vc4: hdmi: Use drm_atomic_helper_reset_crtc()Herve Codina1-29/+1
The current code uses a the reset_pipe() local function to reset the CRTC outputs. drm_atomic_helper_reset_crtc() has been introduced recently and it performs exact same operations. In order to avoid code duplication, use the new helper instead of the local function. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250210132620.42263-4-herve.codina@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-13drm/atomic-helper: Introduce drm_atomic_helper_reset_crtc()Herve Codina1-0/+41
drm_atomic_helper_reset_crtc() allows to reset the CRTC active outputs. This resets all active components available between the CRTC and connectors. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250210132620.42263-3-herve.codina@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-13drm/vkms: Fix use after free and double free on init errorJosé Expósito1-6/+9
If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. Reported-by: Louis Chauvet <louis.chauvet@bootlin.com> Closes: https://lore.kernel.org/all/Z5uDHcCmAwiTsGte@louis-chauvet-laptop/ Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmremann@suse.de> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212084912.3196-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-02-13drm/i915/psr: Write PSR2_MAN_TRK_CTL on DSB commit as wellJouni Högander1-0/+2
Add PSR2_MAN_TRK_CTL writing into DSB commit in intel_atomic_dsb_finish. Taking PSR lock over DSB commit is not needed because PSR2_MAN_TRK_CTL is now written only by DSB. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-8-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Allow writing PSR2_MAN_TRK_CTL using DSBJouni Högander3-8/+14
Allow writing PSR2_MAN_TRK_CTL using DSB by using intel_de_write_dsb. Do not check intel_dp->psr.lock being held when using DSB. This assertion doesn't make sense as in case of using DSB the actual write happens later and we are not taking intel_dp->psr.lock mutex over dsb commit. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-7-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwardsJouni Högander1-7/+15
In LunarLake we have SFF_CTL register which contains SFF bit ored with respective SFF bit in PSR2_MAN_TRK_CTL register. Use this register instead of the bit in PSR2_MAN_TRK_CTL on frontbuffer tracking callbacks. This helps us avoiding taking psr mutex when performing atomic commit. We don't need to set the CFF bit as selective update configuration in PSR2_MAN_TRL_CTL is not overwritten anymore. I.e. we have valid configuration in PSR2_MAN_TRK_CTL and in plane SEL_FETCH_* registers when SFF bit gets cleared by the HW in case something triggers "frame change" event after SFF bit is cleared. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-6-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Add register definitions for SFF_CTL and CFF_CTL registersJouni Högander1-0/+10
Add register definitions for SFF_CTL and CFF_CTL registers. Name them as LNL_SFF_CTL and LNL_CFF_CTL. v2: use _MMIO_TRANS instead of _MMIO_TRANS2 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-5-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Split setting sff and cff bits away from intel_psr_force_updateJouni Högander1-57/+31
This is a clean-up and a preparation for adding own SFF and CFF registers for LunarLake onwards. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-4-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Rename psr_force_hw_tracking_exit as intel_psr_force_updateJouni Högander1-4/+4
psr_force_hw_tracking_exit is misleading name as it is used for PSR1, PSR2 HW tracking and PSR2 selective fetch. Due to this rename it as intel_psr_force_update. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-3-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full updateJouni Högander1-1/+0
We are preparing for a change where only frontbuffer flush will use single full frame bit of a new register (SFF_CTL) available on LunarLake onwards. It shouldn't be necessary to have SFF bit set if CFF bit is set in PSR2_MAN_TRK_CTL -> removing setting it on all platforms as there is not reason to have it different on older platforms. v2: commit message improved Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-2-jouni.hogander@intel.com
2025-02-13drm/i915/selftests: use prandom in selftestMarkus Theil1-3/+4
This is part of a prandom cleanup, which removes next_pseudo_random32 and replaces it with the standard PRNG. Signed-off-by: Markus Theil <theil.markus@gmail.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211063332.16542-2-theil.markus@gmail.com
2025-02-13drm: writeback: Fix use after free in drm_writeback_connector_cleanup()Dan Carpenter1-1/+1
The drm_writeback_cleanup_job() function frees "pos" so call list_del(&pos->list_entry) first to avoid a use after free. Fixes: 1914ba2b91ea ("drm: writeback: Create drmm variants for drm_writeback_connector initialization") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/78abd541-71e9-4b3b-a05d-2c7caf8d5b2f@stanley.mountain Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-13drm/tests: Fix a test in drm_test_check_valid_clones()Dan Carpenter1-1/+1
The drm_atomic_get_crtc_state() function returns error pointers and not NULL. Update the check to check for error pointers as well as NULL. Fixes: 88849f24e2ab ("drm/tests: Add test for drm_atomic_helper_check_modeset()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/c50f11c7-932c-47dc-b40f-4ada8b9b6679@stanley.mountain Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-13drm/i915/display: convert i915_pipestat_enable_mask() to struct intel_displayJani Nikula3-13/+15
Going forward, struct intel_display is the main display device data pointer. Convert i915_pipestat_enable_mask() to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/975b382c703cfb62f24643e40eac247b8e8bbea8.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_fifo_underrun.[ch] to struct intel_displayJani Nikula6-67/+67
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_fifo_underrun.[ch] to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/682e667013e1726a6f2f78484b7e9618cee3b639.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/combo-phy: convert intel_combo_phy.[ch] to struct intel_displayJani Nikula8-113/+109
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_combo_phy.[ch] to struct intel_display, along with intel_phy_is_combo() in intel_display.c. Drive-by convert some drm_dbg() to drm_dbg_kms() while at it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2e0a6294a8eaa4c16632881edc4f2d23c576101.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/dsi: convert platform checks to display->platform.<platform> styleJani Nikula1-7/+4
These are stragglers from a time the display->platform mechanism didn't exist. Finish the conversion. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/493e4c550f9c515e2e82df1afd8a74a24156e76e.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_mode_valid_max_plane_size() to intel_displayJani Nikula6-15/+12
Going forward, struct intel_display is the main display device data pointer. Convert the intel_mode_valid_max_plane_size() helper to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e7810c793ecc8ff6a31569830bf162156245668.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_cpu_transcoder_mode_valid() to intel_displayJani Nikula12-23/+21
Going forward, struct intel_display is the main display device data pointer. Convert the intel_cpu_transcoder_mode_valid()() helper to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f9246a00a2e7aabaffb86f863915a4307e1fd3f8.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/sdvo: convert intel_sdvo.[ch] to struct intel_displayJani Nikula5-152/+150
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_sdvo.[ch] to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2e79909f8a060d7ff1744911f8da9300eb1f225c.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_set_{cpu,pch}_fifo_underrun_reporting() to ↵Jani Nikula9-91/+89
intel_display Going forward, struct intel_display is the main display device data pointer. Convert intel_set_cpu_fifo_underrun_reporting() and intel_set_pch_fifo_underrun_reporting() to struct intel_display, along with some of the call chains from there. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3b984d0183214d05d0cdecad35184ea8d89ae050.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/hpd: drop dev_priv parameter from intel_hpd_pin_default()Jani Nikula5-8/+5
The function doesn't use the parameter for anything. Drop it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4347a0f71a1a8c515617cf06471486d9bbb4a026.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert assert_port_valid() to struct intel_displayJani Nikula8-9/+10
Going forward, struct intel_display is the main display device data pointer. Convert the assert_port_valid() helper to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e06ef0e2cc34d42918f3208362587a17ea34e28f.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert assert_transcoder*() to struct intel_displayJani Nikula6-41/+38
Going forward, struct intel_display is the main display device data pointer. Convert the assert_transcoder*() helpers to struct intel_display, allowing further conversions elsewhere. Do a few small opportunistic conversions right away. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/430c2f3c899bc98beeb6ba8608f841c9271d0971.1739378095.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 11:25:37 +0300