summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2025-03-21drm/i915/display: rename I915_HAS_HOTPLUG() to HAS_HOTPLUGJani Nikula6-9/+9
Most of the other display feature check macros are just HAS_<something>. Follow suit with hotplug check. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/c386ef007ae8bdda1bb9b1b353b1cd2957897842.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/irq: convert rest of intel_display_irq.[ch] to struct intel_displayJani Nikula1-280/+247
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_display_irq.[ch] to struct intel_display. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/b6e281875278ad84772938f81129fde6065b2745.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/irq: convert intel_display_irq.[ch] interfaces to struct intel_displayJani Nikula13-232/+263
Going forward, struct intel_display is the main display device data pointer. Convert the external interfaces of intel_display_irq.[ch] to struct intel_display. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/83b552154761d2790d8c774707e8d7612037bdf5.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/hotplug: convert intel_hotplug_irq.[ch] to struct intel_displayJani Nikula6-287/+276
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_hotplug_irq.[ch] to struct intel_display. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/8ddf27ea31b543f88c5f124f029c2eaa06a9aae7.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/hotplug: convert hotplug irq handling to intel_de_*()Jani Nikula1-91/+114
All the registers handled here are display registers. Switch from intel_uncore_*() to intel_de_*() functions. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/cd1149b3ebcb7a9f73830b99957f09e468cd5fd9.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/hotplug: convert hotplug debugfs to struct intel_displayJani Nikula1-11/+9
Pass struct intel_display as the cookie to debugfs functions. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/b1cbf64d366ca97005f9b139e85d8a32b460623a.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/hotplug: convert intel_hotplug.[ch] to struct intel_displayJani Nikula11-213/+240
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_hotplug.[ch] to struct intel_display. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/cf382dbfacf1445b26fbe1e7c011e7a3ea6e1594.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/connector: convert intel_connector.c to struct intel_displayJani Nikula1-22/+23
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_connector.c to struct intel_display. i915_inject_probe_failure() remains the only call that requires i915 pointer. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/398e3210459a65f74e78f2d34584cda6eea6a99b.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/color: prefer display->platform.<platform> checksJani Nikula1-10/+6
This let's us drop the dependency on i915_drv.h. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/d57fd6444c512b3cc35c0e216c86eeb95124eead.1742481923.git.jani.nikula@intel.com
2025-03-21Merge tag 'amd-drm-fixes-6.14-2025-03-20' of ↵Dave Airlie15-474/+526
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.14-2025-03-20: amdgpu: - Fix video caps limits on several asics - SMU 14.x fixes - GC 12 fixes - eDP fixes - DMUB fix amdkfd: - GC 12 trap handler fix - GC 7/8 queue validation fix radeon: - VCE IB parsing fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250320210800.1358992-1-alexander.deucher@amd.com
2025-03-21Merge tag 'drm-xe-fixes-2025-03-20' of ↵Dave Airlie2-3/+1
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix for an error if exporting a dma-buf multiple time (Tomasz) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z9xalLaCWsNbh0P0@fedora
2025-03-21Merge tag 'drm-misc-fixes-2025-03-20' of ↵Dave Airlie2-5/+29
ssh://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A sched fence reference leak fix, two fence fixes for v3d, two overflow fixes for quaic, and a iommu handling fix for host1x. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250320-valiant-outstanding-nightingale-e9acae@houat
2025-03-21drm/xe: Apply Wa_16023105232Vinay Belgaumkar6-12/+74
The WA requires KMD to disable DOP clock gating during a semaphore wait and also ensure that idle delay for every CS is lower than the idle wait time in the PWRCTX_MAXCNT register. Default values for these registers already comply with this restriction. v2: Store timestamp_base in gt info and other comments (Daniele) v3: Skip WA check for VF v4: Review comments (Matt Roper) v5: Cleanup the clock functions and use reg_field_get (Matt Roper) v6: Fix checkpatch issue v7: Fix CI issue Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250320175123.3026754-1-vinay.belgaumkar@intel.com
2025-03-20drm/xe/eustall: Fix a possible pointer dereference after freeHarish Chegondi1-7/+1
If devm_add_action_or_reset() isn't successful, xe_eu_stall_fini() is invoked. So, unsuccessful return from devm_add_action_or_reset() shouldn't dereference gt->eu_stall as xe_eu_stall_fini() already frees it. Fix this issue. Fixes: 9a0b11d4cf3b ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling") Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eae49a414a7314921108e0388810aaee6261ad92.1741800396.git.harish.chegondi@intel.com (cherry picked from commit 278469ff569e1082d56b4a7af26fbaecef9fbf3b) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-03-20drm/xe: Fix exporting xe buffers multiple timesTomasz Rusinowicz2-3/+1
The `struct ttm_resource->placement` contains TTM_PL_FLAG_* flags, but it was incorrectly tested for XE_PL_* flags. This caused xe_dma_buf_pin() to always fail when invoked for the second time. Fix this by checking the `mem_type` field instead. Fixes: 7764222d54b7 ("drm/xe: Disallow pinning dma-bufs in VRAM") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Tomasz Rusinowicz <tomasz.rusinowicz@intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250218100353.2137964-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> (cherry picked from commit b96dabdba9b95f71ded50a1c094ee244408b2a8e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-03-20drm/i915/display: Fix build error without DRM_FBDEV_EMULATIONYue Haibing1-0/+2
In file included from <command-line>: ./drivers/gpu/drm/i915/display/intel_fbdev.h: In function ‘intel_fbdev_framebuffer’: ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: error: ‘NULL’ undeclared (first use in this function) 32 | return NULL; | ^~~~ ./drivers/gpu/drm/i915/display/intel_fbdev.h:1:1: note: ‘NULL’ is defined in header ‘<stddef.h>’; did you forget to ‘#include <stddef.h>’? +++ |+#include <stddef.h> 1 | /* SPDX-License-Identifier: MIT */ ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: note: each undeclared identifier is reported only once for each function it appears in 32 | return NULL; | ^~~~ Build fails if CONFIG_DRM_FBDEV_EMULATION is n, add missing header file. Fixes: 9fa154f40eb6 ("drm/{i915,xe}: Run DRM default client setup") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250315120143.2344958-1-yuehaibing@huawei.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 97e81f78d3cbf061a809bbb8180a5b96395b8e03) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-20drm/i915/watermark: Check bounds for scaler_users for dsc prefill latencyAnkit Nautiyal1-1/+4
Currently, during the computation of global watermarks, the latency for each scaler user is calculated to compute the DSC prefill latency. At this point, the number of scaler users can exceed the number of supported scalers, which is checked later in intel_atomic_setup_scalers(). This can cause issues when the number of scaler users exceeds the number of supported scalers. While checking for DSC prefill, ensure that the number of scaler users does not exceed the number of supported scalers. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4341 Fixes: a9b14af999b0 ("drm/i915/dsc: Check if vblank is sufficient for dsc prefill") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227034106.1638203-1-ankit.k.nautiyal@intel.com (cherry picked from commit 5d6c69b712f9cb34063ef32168ce6a12af8acf0c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-20drm/i915/display: Fix build error without DRM_FBDEV_EMULATIONYue Haibing1-0/+2
In file included from <command-line>: ./drivers/gpu/drm/i915/display/intel_fbdev.h: In function ‘intel_fbdev_framebuffer’: ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: error: ‘NULL’ undeclared (first use in this function) 32 | return NULL; | ^~~~ ./drivers/gpu/drm/i915/display/intel_fbdev.h:1:1: note: ‘NULL’ is defined in header ‘<stddef.h>’; did you forget to ‘#include <stddef.h>’? +++ |+#include <stddef.h> 1 | /* SPDX-License-Identifier: MIT */ ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: note: each undeclared identifier is reported only once for each function it appears in 32 | return NULL; | ^~~~ Build fails if CONFIG_DRM_FBDEV_EMULATION is n, add missing header file. Fixes: 9fa154f40eb6 ("drm/{i915,xe}: Run DRM default client setup") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250315120143.2344958-1-yuehaibing@huawei.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-20drm/bridge: ti-sn65dsi86: Remove drm_encoder->crtc useMaxime Ripard1-17/+38
The TI sn65dsi86 driver follows the drm_encoder->crtc pointer that is deprecated and shouldn't be used by atomic drivers. Fortunately, the atomic hooks provide the drm_atomic_state and we can access our current CRTC from that, going from the bridge to its encoder, to its connector, and to its CRTC. This bridge driver uses the atomic hooks already, but dereferences the drm_encoder->crtc pointer in functions that don't have access to it. Let's rework the driver to pass the state where needed, and remove the need for the drm_encoder->crtc dereference. Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-16-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: tc358768: Convert to atomic helpersMaxime Ripard1-9/+19
The tc358768 driver follows the drm_encoder->crtc pointer that is deprecated and shouldn't be used by atomic drivers. Fortunately, the atomic hooks provide the drm_atomic_state and we can access our current CRTC from that, going from the bridge to its encoder, to its connector, and to its CRTC. Let's convert this bridge driver to atomic so we can get rid of the drm_encoder->crtc dereference. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-15-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: tc358768: Stop disabling when failing to enableMaxime Ripard1-8/+2
The tc358768 bridge driver, if enabling it fails, tries to disable it. This is pretty uncommon in bridge drivers, and also stands in the way for further reworks. Worse, since pre_enable and enable aren't expected to fail, disable and post_disable might be called twice: once to handle the failure, and once to actually disable the bridge. Since post_disable uses regulators and clocks, this would lead to enable count imbalances. In order to prevent that imbalance, and to allow further reworks, let's drop the calls to disable and post_disable, but keep the warning to let users know about what's going on. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-14-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: tc358775: Switch to atomic commitMaxime Ripard1-23/+19
The tc358775 driver follows the drm_encoder->crtc pointer that is deprecated and shouldn't be used by atomic drivers. Fortunately, the atomic hooks provide the drm_atomic_state and we can access our current CRTC from that, going from the bridge to its encoder, to its connector, and to its CRTC. Let's convert this bridge driver to atomic so we can get rid of the drm_encoder->crtc dereference. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-13-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: cdns-csi: Switch to atomic helpersMaxime Ripard1-9/+22
The Cadence DSI driver follows the drm_encoder->crtc pointer that is deprecated and shouldn't be used by atomic drivers. Fortunately, the atomic hooks provide the drm_atomic_state and we can access our current CRTC from that, going from the bridge to its encoder, to its connector, and to its CRTC. Let's convert this bridge driver to atomic so we can get rid of the drm_encoder->crtc dereference. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-12-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: Introduce drm_bridge_is_atomic() helperMaxime Ripard1-2/+7
We test for whether the bridge is atomic in several places in the source code, so let's consolidate them. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-11-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtcMaxime Ripard1-17/+11
Now that we have a helper for bridge drivers to call to reset the output pipeline, let's use it. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Tested-by: Herve Codina <herve.codina@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-10-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/tests: bridge: Provide tests for drm_bridge_helper_reset_crtcMaxime Ripard1-1/+208
Let's provide a bunch of kunit tests to make sure drm_bridge_helper_reset_crtc() works as expected. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-9-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: Add helper to reset bridge pipelineMaxime Ripard3-0/+62
Let's provide an helper to make it easier for bridge drivers to power-cycle their bridge. In order to avoid a circular dependency between that new helper and drm_atomic_helper_reset_crtc(), this new helper will be in a drm_bridge_helper.c file to follow the pattern we have for other objects. Reviewed-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Tested-by: Herve Codina <herve.codina@bootlin.com> Co-developed-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-8-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/tests: Create tests for drm_atomicMaxime Ripard2-0/+154
We don't have a set of kunit tests for the functions under drm_atomic.h. Let's use the introduction of drm_atomic_get_connector_for_encoder() to create some tests for it and thus create that set. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-7-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/tests: hdmi_state_helpers: Switch to new helperMaxime Ripard1-66/+92
We introduced a new helper that supersedes the light_up_connector() function in drm_hdmi_state_helper_test, so let's convert all our tests to it. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-6-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/tests: helpers: Create new helper to enable outputMaxime Ripard1-0/+61
We'll need the HDMI state tests light_up_connector() function in more tests, so let's promote it to a helper. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-5-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/atomic: Introduce helper to lookup connector by encoderMaxime Ripard1-0/+59
With the bridges switching over to drm_bridge_connector, the direct association between a bridge driver and its connector was lost. This is mitigated for atomic bridge drivers by the fact you can access the encoder, and then call drm_atomic_get_old_connector_for_encoder() or drm_atomic_get_new_connector_for_encoder() with drm_atomic_state. This was also made easier by providing drm_atomic_state directly to all atomic hooks bridges can implement. However, bridge drivers don't have a way to access drm_atomic_state outside of the modeset path, like from the hotplug interrupt path or any interrupt handler. Let's introduce a function to retrieve the connector currently assigned to an encoder, without using drm_atomic_state, to make these drivers' life easier. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Tested-by: Herve Codina <herve.codina@bootlin.com> Co-developed-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-4-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/tests: Add kunit tests for bridgesMaxime Ripard3-0/+212
None of the drm_bridge function have kunit tests so far. Let's change that, starting with drm_bridge_get_current_state(). Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-3-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-20drm/bridge: Add encoder parameter to drm_bridge_funcs.attachMaxime Ripard81-93/+169
The drm_bridge structure contains an encoder pointer that is widely used by bridge drivers. This pattern is largely documented as deprecated in other KMS entities for atomic drivers. However, one of the main use of that pointer is done in attach to just call drm_bridge_attach on the next bridge to add it to the bridge list. While this dereferences the bridge->encoder pointer, it's effectively the same encoder the bridge was being attached to. We can make it more explicit by adding the encoder the bridge is attached to to the list of attach parameters. This also removes the need to dereference bridge->encoder in most drivers. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-1-511c54a604fb@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-19drm/amdgpu: Skip pcie_replay_count sysfs creation for VFVictor Skvortsov1-7/+20
VFs cannot read the NAK_COUNTER register. This information is only available through PMFW metrics. Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu: Add active_umc_mask to ras init_flagsCandice Li2-0/+2
Add active_umc_mask to ras init_flags. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19Documentation/amdgpu: Add debug_mask documentationLijo Lazar1-0/+5
Add description for debug_mask bit options. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amd/pm: Add debug bit for smu pool allocationLijo Lazar3-2/+11
In certain cases, it's desirable to avoid PMFW log transactions to system memory. Add a mask bit to decide whether to allocate smu pool in device memory or system memory. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu/vcn: adjust workload profile handlingAlex Deucher2-20/+36
No need to make the workload profile setup dependent on the results of cancelling the delayed work thread. We have all of the necessary checking in place for the workload profile reference counting, so separate the two. As it is now, we can theoretically end up with the call from begin_use happening while the worker thread is executing which would result in the profile not getting set for that submission. It should not affect the reference counting. v2: bail early if the the profile is already active (Lijo) Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu/gfx: adjust workload profile handlingAlex Deucher1-11/+18
No need to make the workload profile setup dependent on the results of cancelling the delayed work thread. We have all of the necessary checking in place for the workload profile reference counting, so separate the two. As it is now, we can theoretically end up with the call from begin_use happening while the worker thread is executing which would result in the profile not getting set for that submission. It should not affect the reference counting. v2: bail early if the the profile is already active (Lijo) Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu: Add EEPROM I2C address support for smu v13_0_12Candice Li1-0/+2
Add EEPROM I2C address support for smu v13_0_12. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu/vcn: fix ref counting for ring based profile handlingAlex Deucher4-16/+40
We need to make sure the workload profile ref counts are balanced. This isn't currently the case because we can increment the count on submissions, but the decrement may be delayed as work comes in. Track when we enable the workload profile so the references are balanced. v2: switch to a mutex and active flag v3: fix mutex init Fixes: 1443dd3c67f6 ("drm/amd/pm: fix and simplify workload handling") Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu/gfx: fix ref counting for ring based profile handlingAlex Deucher3-10/+23
We need to make sure the workload profile ref counts are balanced. This isn't currently the case because we can increment the count on submissions, but the decrement may be delayed as work comes in. Track when we enable the workload profile so the references are balanced. v2: switch to a mutex and active flag v3: fix mutex init Fixes: 8fdb3958e396 ("drm/amdgpu/gfx: add ring helpers for setting workload profile") Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Kenneth Feng <kenneth.feng@amd.com> Tested-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdkfd: Fix bug in config_dequeue_wait_countsHarish Kasiviswanathan2-20/+32
For certain ASICs where dequeue_wait_count don't need to be initialized, pm_config_dequeue_wait_counts_v9 return without filling in the packet information. However, the calling function interprets this as a success and sends the uninitialized packet to firmware causing hang. Fix the above bug by not calling pm_config_dequeue_wait_counts_v9 for ASICs that don't need the value to be initialized. v2: Removed redudant code. Tidy up code based on review comments v3: Don't call pm_config_dequeue_wait_counts_v9 for certain ASICs Fixes: ed962f8d0603 ("drm/amdkfd: Add pm_config_dequeue_wait_counts API") Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Jonathan Kim <jonathan.kim@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/radeon/uvd: Replace nested max() with single max3()FengWei1-1/+1
Use max3() macro instead of nesting max() to simplify the return statement. Signed-off-by: FengWei <feng.wei8@zte.com.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/amdgpu: grab an additional reference on the gang fence v2Christian König1-1/+9
We keep the gang submission fence around in adev, make sure that it stays alive. v2: fix memory leak on retry Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-19drm/xe: Fix exporting xe buffers multiple timesTomasz Rusinowicz2-3/+1
The `struct ttm_resource->placement` contains TTM_PL_FLAG_* flags, but it was incorrectly tested for XE_PL_* flags. This caused xe_dma_buf_pin() to always fail when invoked for the second time. Fix this by checking the `mem_type` field instead. Fixes: 7764222d54b7 ("drm/xe: Disallow pinning dma-bufs in VRAM") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Tomasz Rusinowicz <tomasz.rusinowicz@intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250218100353.2137964-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-03-19Merge drm/drm-next into drm-xe-nextThomas Hellström628-10865/+20464
Backmerging to bring in the xe shrinker from drm-next. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-03-19drm/vmwgfx: Switch to exclusively using GEM referencesIan Forbes10-38/+18
Currently we use a combination of TTM and GEM reference counting which is cumbersome. TTM references are used for kernel internal BOs and operations like validation. Simply switching the ttm_bo_(get|put) calls to their GEM equivalents is insufficient as not all BOs are GEM BOs so we must set the GEM vtable for all BOs even if they are not exposed to userspace. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131200321.193939-1-ian.forbes@broadcom.com
2025-03-19drm/vmwgfx: Fix dumb buffer leakIan Forbes3-9/+17
Dumb buffers were not being freed because the GEM reference that was acquired in gb_surface_define was not dropped like it is in the 2D case. Dropping this ref uncovered a few additional issues with freeing the resources associated with dirty tracking in vmw_bo_free/release. Additionally the TTM object associated with the surface were also leaking which meant that when the ttm_object_file was closed at process exit the destructor unreferenced an already destroyed surface. The solution is to remove the destructor from the vmw_user_surface associated with the dumb_buffer and immediately unreferencing the TTM object which his removes it from the ttm_object_file. This also allows the early return in vmw_user_surface_base_release for the dumb buffer case to be removed as it should no longer occur. The chain of references now has the GEM handle(s) owning the dumb buffer. The GEM handles have a singular GEM reference to the vmw_bo which is dropped when all handles are closed. When the GEM reference count hits zero the vmw_bo is freed which then unreferences the surface via vmw_resource_release in vmw_bo_release. Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers") Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250123204424.836896-1-ian.forbes@broadcom.com
2025-03-19drm/i915: Fix harmful driver register/unregister asymmetryJanusz Krzysztofik1-4/+13
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if drm_dev_register() fails"), we return from i915_driver_register() immediately if drm_dev_register() fails, skipping remaining registration steps, and continue only with remaining probe steps. However, the _unregister() counterpart called at driver remove knows nothing about that skip and executes reverts of all those steps. As a consequence, a number of kernel warnings that taint the kernel are triggered: <3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access! ... <4> [525.831069] ------------[ cut here ]------------ <4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref) <4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915] ... <4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1 ... <4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915] ... <4> [525.831483] Call Trace: <4> [525.831484] <TASK> ... <4> [525.831943] i915_driver_remove+0x4b/0x140 [i915] <4> [525.832028] i915_pci_remove+0x1e/0x40 [i915] <4> [525.832099] pci_device_remove+0x3e/0xb0 <4> [525.832103] device_remove+0x40/0x80 <4> [525.832107] device_release_driver_internal+0x215/0x280 ... Moreover, that unexpected PM reference is left untouched (not released) but overwritten, then that triggers another kernel warning at driver release phase: <4> [526.685700] ------------[ cut here ]------------ <4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup <4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915] ... <4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915] ... <4> [526.686294] Call Trace: <4> [526.686296] <TASK> ... <4> [526.687025] i915_driver_release+0x7e/0xb0 [i915] <4> [526.687243] drm_dev_put.part.0+0x47/0x90 <4> [526.687250] devm_drm_dev_init_release+0x13/0x30 <4> [526.687255] devm_action_release+0x12/0x30 <4> [526.687261] release_nodes+0x3a/0x120 <4> [526.687268] devres_release_all+0x97/0xe0 <4> [526.687277] device_unbind_cleanup+0x12/0x80 <4> [526.687282] device_release_driver_internal+0x23a/0x280 ... A call to intel_power_domains_disable() was already there. It triggers the drm_WARN_ON() when it finds a reference to a wakeref taken on device probe and not released after device registration failure. That wakeref is then left held forever once its handle gets lost overwritten with another wakeref, hence another WARN() is called from intel_runtime_pm_driver_release(). The WARN() triggered by kernfs_remove_by_name_ns() from i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly i915_teardown_error_capture(), was also there when the return was added. A call to intel_gt_sysfs_unregister() that triggers the WARN() from kobject_put() was added to intel_gt_driver_unregister() with commit 69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs"). Fix the asymmetry by failing the driver probe on device registration failure and going through rewind paths. For that to work as expected, we apparently need to start the rewind path of i915_driver_register() with drm_dev_unregister(), even if drm_dev_register() returned an error. v5: Drop unsigned keyword from ret variable declaration (Krzysztof), - keep the "Failed to register driver for userspace access" error message (Krzysztof), - split PXP cleanup addition to rewind path out to a separate patch. v4: Switch to taking an error rewind path on device registration failure (Krzysztof, Lucas). v3: Based on Andi's commitment on introducing a flag, try to address Jani's "must find another way" by finding a better place and name for the flag (in hope that's what Jani had on mind), - split into a series of patches and limit the scope of the first (this) one to a minimum of omitting conditionally only those unregister (sub)steps that trigger kernel warnings when not registered. v2: Check in _unregister whether the drm_dev_register has succeeded and skip some of the _unregister() steps. (Andi) Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@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/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-17 01:16:00 +0300