summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4
AgeCommit message (Collapse)AuthorFilesLines
2023-06-15Merge tag 'amd-drm-next-6.5-2023-06-09' of ↵Dave Airlie1-1/+1
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.5-2023-06-02: amdgpu: - SR-IOV fixes - Warning fixes - Misc code cleanups and spelling fixes - DCN 3.2 updates - Improved DC FAMS support for better power management - Improved DC SubVP support for better power management - DCN 3.1.x fixes - Max IB size query - DC GPU reset fixes - RAS updates - DCN 3.0.x fixes - S/G display fixes - CP shadow buffer support - Implement connector force callback - Z8 power improvements - PSP 13.0.10 vbflash support - Mode2 reset fixes - Store MQDs in VRAM to improve queue switch latency - VCN 3.x fixes - JPEG 3.x fixes - Enable DC_FP on LoongArch - GFXOFF fixes - GC 9.4.3 partition support - SDMA 4.4.2 partition support - VCN/JPEG 4.0.3 partition support - VCN 4.0.3 updates - NBIO 7.9 updates - GC 9.4.3 updates - Take NUMA into account when allocating memory - Handle NUMA for partitions - SMU 13.0.6 updates - GC 9.4.3 RAS updates - Stop including unused swiotlb.h - SMU 13.0.7 fixes - Fix clock output ordering on some APUs - Clean up DC FPGA code - GFX9 preemption fixes - Misc irq fixes - S0ix fixes - Add new DRM_AMDGPU_WERROR config parameter to help with CI - PCIe fix for RDNA2 - kdoc fixes - Documentation updates amdkfd: - Query TTM mem limit rather than hardcoding it - GC 9.4.3 partition support - Handle NUMA for partitions radeon: - Fix possible double free - Stop including unused swiotlb.h - Fix possible division by zero ttm: - Add query for TTM mem limit - Add NUMA awareness to pools - Export ttm_pool_fini() UAPI: - Add new ctx query flag to better handle GPU resets Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22290 - Add new interface to query and set shadow buffer for RDNA3 Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21986 - Add new INFO query for max IB size Proposed userspace: https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/commits/ib-rejection-v3 amd-drm-next-6.5-2023-06-09: amdgpu: - S0ix fixes - Initial SMU13 Overdrive support - kdoc fixes - Misc clode cleanups - Flexible array fixes - Display OTG fixes - SMU 13.0.6 updates - Revert some broken clock counter updates - Misc display fixes - GFX9 preemption fixes - Add support for newer EEPROM bad page table format - Add missing radeon secondary id - Add support for new colorspace KMS API - CSA fix - Stable pstate fixes for APUs - make vbl interface admin only - Handle PCI accelerator class amdkfd: - Add debugger support for gdb radeon: - Fix possible UAF drm: - Add Colorspace functionality UAPI: - Add debugger interface for enabling gdb Proposed userspace: https://github.com/ROCm-Developer-Tools/ROCdbgapi/tree/wip-dbgapi - Add KMS colorspace API Discussion: https://lists.freedesktop.org/archives/dri-devel/2023-June/408128.html From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230609174817.7764-1-alexander.deucher@amd.com
2023-06-09drm/connector: Allow drivers to pass list of supported colorspacesHarry Wentland1-1/+1
Drivers might not support all colorspaces defined in dp_colorspaces and hdmi_colorspaces. This results in undefined behavior when userspace is setting an unsupported colorspace. Allow drivers to pass the list of supported colorspaces when creating the colorspace property. v2: - Use 0 to indicate support for all colorspaces (Jani) - Print drm_dbg_kms message when drivers pass 0 to signal that drivers should specify supported colorspaecs explicity (Jani) v3: - Move changes to create a common colorspace_names array to separate patch v6: - Avoid magic when passing 0 for supported_colorspaces; be explicit in treating it as "all DP/HDMI" Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Reviewed-by: Joshua Ashton <joshua@froggi.es> Reviewed-by: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Vitaly.Prosyak@amd.com Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joshua Ashton <joshua@froggi.es> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Simon Ser <contact@emersion.fr> Cc: Melissa Wen <mwen@igalia.com> Cc: dri-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-25drm/vc4: hdmi: Add BT.2020 SupportDave Stevenson1-0/+38
Even though we report that we support the BT.2020 Colorspace, we were always using the BT.709 conversion matrices. Let's add the BT.2020 ones. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-9-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Add BT.601 SupportDave Stevenson1-0/+38
Even though we report that we support the BT601 Colorspace, we were always using the BT.709 conversion matrices. Let's add the BT601 ones. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-8-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Add a function to retrieve the CSC matrixDave Stevenson1-3/+21
The CSC matrix to use depends on the output format, its range and the colorspace. Since we're going to add more colorspaces, let's move the CSC matrix retrieval to a function. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-7-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Rework the CSC matrices organizationDave Stevenson1-45/+63
The CSC matrices were stored as separate matrix for each colorspace, and if we wanted a limited or full RGB output. This created some gaps in our support and we would not always pick the relevant matrix. Let's rework our data structure to store one per colorspace, and then a matrix for limited range and one for full range. This makes us add a new matrix to support full range BT709 YUV output. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-6-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Swap CSC matrix channels for YUV444Dave Stevenson1-20/+19
YUV444 and YUV422 actually require the same matrix, but programmed differently. We've dealt with it in the past by having two matrices, with the one for YUV444 reordered to accomodate the hardware. This gets in the way of subsequent reworks so let's define a function that will take the coefficients swap into account, and remove the now redundant YUV444 matrix. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-5-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Rename full range helperDave Stevenson1-5/+5
The VC4 HDMI driver has a helper function to figure out whether full range or limited range RGB is being used called vc4_hdmi_is_full_range_rgb(). We'll need it to support other colorspaces, so let's rename it to vc4_hdmi_is_full_range(). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-4-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Add Broadcast RGB property to allow override of RGB rangeDave Stevenson2-4/+102
Copy Intel's "Broadcast RGB" property semantics to add manual override of the HDMI pixel range for monitors that don't abide by the content of the AVI Infoframe. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Hans Verkuil <hverkuil-cisco at xs4all.nl> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-3-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: hdmi: Update all the planes if the TV margins are changedMaxime Ripard1-0/+26
On VC4, the TV margins on the HDMI connector are implemented by scaling the planes. However, if only the TV margins or the connector are changed by a new state, the planes ending up on that connector won't be. Thus, they won't be updated properly and we'll effectively ignore that change until the next commit affecting these planes. Let's make sure to add all the planes attached to the connector so that we can update them properly. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-2-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-25drm/vc4: Switch to container_of_constMaxime Ripard10-106/+51
container_of_const() allows to preserve the pointer constness and is thus more flexible than inline functions. Let's switch all our instances of container_of() to container_of_const(). Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-1-bdd54f66884e@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-04-16drm/aperture: Remove primary argumentDaniel Vetter1-1/+1
Only really pci devices have a business setting this - it's for figuring out whether the legacy vga stuff should be nuked too. And with the preceding two patches those are all using the pci version of this. Which means for all other callers primary == false and we can remove it now. v2: - Reorder to avoid compile fail (Thomas) - Include gma500, which retained it's called to the non-pci version. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Deepak Rawat <drawat.floss@gmail.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Emma Anholt <emma@anholt.net> Cc: Helge Deller <deller@gmx.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: linux-hyperv@vger.kernel.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-tegra@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230406132109.32050-4-tzimmermann@suse.de
2023-04-11drm/vc4: remove unused render_wait variableTom Rix1-2/+0
smatch reports drivers/gpu/drm/vc4/vc4_irq.c:60:1: warning: symbol 'render_wait' was not declared. Should it be static? This variable is not used so remove it. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230406151203.1953812-1-trix@redhat.com
2023-04-06drm/scdc-helper: Pimp SCDC debugsVille Syrjälä1-9/+12
Include the device and connector information in the SCDC debugs. Makes it easier to figure out who did what. v2: Rely on connector->ddc (Maxime) Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Cc: intel-gfx@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230403223652.18848-1-ville.syrjala@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Thierry Reding <treding@nvidia.com>
2023-03-28drm: Use of_property_present() for testing DT property presenceRob Herring1-1/+1
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Liu Ying <victor.liu@nxp.com> # i.MX bridge Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20230310144705.1542207-1-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-14drm/vc4: Use GEM DMA fbdev emulationThomas Zimmermann1-2/+2
Use the fbdev emulation that is optimized for DMA helpers. Avoids possible shadow buffering and makes the code simpler. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230313155138.20584-22-tzimmermann@suse.de
2023-03-13Merge drm/drm-next into drm-misc-nextThomas Zimmermann4-14/+17
Backmerging to get v6.3-rc1 and sync with the other DRM trees. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2023-02-28drm/vc4: replace obj lookup steps with drm_gem_objects_lookupMaíra Canal1-41/+2
As vc4_cl_lookup_bos() performs the same steps as drm_gem_objects_lookup(), replace the open-coded implementation in vc4 to simply use the DRM function. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230202111943.111757-3-mcanal@igalia.com
2023-02-28drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_infoMaíra Canal3-23/+20
The array of BOs that are lookup at the start of exec doesn't need to be instantiated as drm_gem_dma_object, as it doesn't benefit from its attributes. So, simplify the code by replacing the array of drm_gem_dma_object for an array of drm_gem_object in the struct vc4_exec_info. Suggested-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230202111943.111757-2-mcanal@igalia.com
2023-02-23Merge tag 'drm-next-2023-02-23' of git://anongit.freedesktop.org/drm/drmLinus Torvalds25-505/+2739
Pull drm updates from Dave Airlie: "There are a bunch of changes all over in the usual places. Highlights: - habanalabs moves from misc to accel - first accel driver for Intel VPU (Versatile Processing Unit) inference engine - dropped all the ancient legacy DRI1 drivers. I think it's been at least 10 years since anyone has heard about these. - Intel DG2 updates and prelim Meteorlake enablement - etnaviv adds support for Versilicon NPU device (a GPU like engine with inference accelerators) Detailed summary: Removals: - remove legacy dri1 drivers: i810, mga, r128, savage, sis, tdfx, via New driver: - intel VPU accelerator driver - habanalabs comes via drm tree now drm/core: - use drm_dbg_ helpers in several places - Document defaults for CRTC backgrounds - Document use of drm_minor edid: - improve mode parsing and refactoring connector: - support analog TV mode property media: - add some common formats udmabuf: - add vmap/vunmap methods fourcc: - add XRGB1555 and RGB565 formats - document open source user waiver firmware: - fix color-format selection for system framebuffer format-helper: - Add conversion from XRGB8888 to various sysfb formats - Make XRGB8888 the only driver-emulated legacy format - Add conversion from XRGB8888 to XBGR8888 and ABGR8888 fb-helper: - fix preferred depth and bpp values across drivers - Avoid blank consoles from selecting an incorrect color format probe-helper: - Enable/disable HPD on connectors scheduler: - Fix lockup in drm_sched_entity_kill() - Deprecate drm_sched_resubmit_jobs() bridge: - remove unused functions - implement i2c probe_new in various drivers - ite-it6505: Locking fixes, Cache EDID data - ite-it66121: Support IT6610 chip - lontium-tl9611: Fix HDMI on DragonBoard 845c - parade-ps8640: Use atomic bridge functions - Support i.MX93 LDB plus DT bindings debugfs: - add per device helpers and convert drivers displayport: - mst fixes - add DP adaptive sync DPCD definitions fbdev: - always pick 32bpp as default - remove some unused code simpledrm: - support system memory framebuffers panel: - add orientation quirks for Lenovo Yoga Tab 3 X90F and DynaBook K50 - Use ktime_get_boottime() to measure power-down delay - Fix auto-suspend delay - Visionox VTDR6130 AMOLED DSI - Support Himax HX8394 - Convert many drivers to common generic DSI write-sequence helper - AUO A030JTN01 ttm: - drop bo wait wrapper - fix MIPS build habanalabs: - moved driver to accel subsystem - gaudi2 decoder error improvement - more trace events - Gaudi2 abrupt reset by firmware support - add uAPI to flush memory transactions - add uAPI to pass through userspace reqs to fw - remove dma-buf export by handle amdgpu: - add new INFO queries for peak and min sclk/mclk for profile modes - Add PCIe info to the INFO IOCTL - secure display support for multiple displays - DML optimizations - DCN 3.2 updates - PSR updates - DP 2.1 updates - SR-IOV RAS updates - VCN RAS support - SMU 13.x updates - Switch 1 element arrays to flexible arrays - Add RAS support for DF 4.3 - Stack size improvements - S0ix rework - Allow 0 as a vram limit on APUs - Handle profiling modes for SMU13.x - Fix possible segfault in failure case - Rework FW requests to happen in early_init for all IPs so that we don't lose the sbios console if FW is missing - Fix power reporting on certain firmwares for CZN/RN - Allow S0ix without BIOS support - Enable freesync over PCon - Re-enable the AGP aperture on GMC 11.x amdkfd: - Error handling fixes - PASID fixes - Fix for cleared VRAM BOs - Fix cleanup if GPUVM creation fails - Memory accounting fix - Use resource_size rather than open codeing it - GC11 mGPU fix radeon: - Switch 1 element arrays to flexible arrays - Fix memory leak on shutdown - move to new logging i915: - Meteorlake display/OA/GSC fw/workarounds enabling - DP MST DSC support - Gamma/degamma readout support for the state checker - Enable SDP split support for DP 2.0 - Add probe blocking support to i915.force_probe parameter - Enable Xe HP 4tile support - Avoid display direct calls to uncore - Fix HuC delayed load memory leaks - Add DG2 workarounds Wa_18018764978 and Wa_18019271663 - Improve suspend / resume times with VT-d scanout workaround active - Fix DG2 visual corruption on small BAR systems by not forgetting to copy CCS aux state - Fix TLB invalidation for Gen12.50 video and compute engines - Enable HF-EEODB by switching HDMI, DP and LVDS to use struct drm_edid - Start using unversioned DMC firmware paths for new platforms - ELD refactor: Stop using hardware buffer, precompute ELD - lots of display code refactoring nouveau: - drop legacy ioctl support - replace 0-sized array msm: - dpu/dsi/mdss: Support for SM8350, SM8450 SM8550 and SC8280XP platform - Added bindings for SM8150 - dpu: Partial support for DSC on SM8150 and SM8250 - dpu: Fixed color transformation matrix being lost on suspend/resume - dp: Support SDM845 and SC8280XP platforms - dp: Support for limiting DP link rate via DT property - dsi: Validate display modes according to the DSI OPP table - dsi: DSI PHY support for the SM6375 platform - Add MSM_SUBMIT_BO_NO_IMPLICI - a2xx: Support to load legacy firmware - a6xx: GPU devcore dump updates for a650/a660 - GPU devfreq tuning and fixes - Turn 8960 HDMI PHY into clock provider, - Make 8960 HDMI PHY use PXO clock from DT etnaviv: - experimental versilicon NPU support - report GPU load via fdinfo format - MMU fault message improvements tegra: - rework syncpoint interrupt mediatek: - DSI timing fix - fix config deps ast: - various fixes exynos: - restore bridge chain order fixes gud: - convert to shadow plane buffers - perform flushing synchronously during atomic update - Use new debugfs helpers arm/hdlcd: - Use new debugfs helper ili9486: - Support 16-bit pixel data imx: - Split off IPUv3 driver mipi-dbi: - convert to DRM shadow-plane helpers - rsp driver changes - Support separate I/O-voltage supply mxsfb: - Depend on ARCH_MXS or ARCH_MXC sun4i: - convert to new TV mode property vc4: - convert to new TV mode property - kunit tests - Support RGB565 and RGB666 formats - convert dsi driver to bridge - Various HVS an CRTC fixes v3d: - Do not opencode drm_gem_object_lookup() virtio: - improve tracing vkms: - support small cursors in IGT tests - Fix SEGFAULT from incorrect GEM-buffer mapping rcar-du: - fixes and improvements" * tag 'drm-next-2023-02-23' of git://anongit.freedesktop.org/drm/drm: (1455 commits) msm/fbdev: fix unused variable warning with clang. drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini() dma-buf: make kobj_type structure constant drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt() drm/amd/display: disable SubVP + DRR to prevent underflow drm/amd/display: Fail atomic_check early on normalize_zpos error drm/amd/pm: avoid unaligned access warnings drm/amd/display: avoid unaligned access warnings drm/amd/display: Remove duplicate/repeating expressions drm/amd/display: Remove duplicate/repeating expression drm/amd/display: Make variables declaration inside ifdef guard drm/amd/display: Fix excess arguments on kernel-doc drm/amd/display: Add previously missing includes drm/amd/amdgpu: Add function prototypes to headers drm/amd/display: Add function prototypes to headers drm/amd/display: Turn global functions into static drm/amd/display: remove unused _calculate_degamma_curve function drm/amd/display: remove unused func declaration from resource headers drm/amd/display: unset initial value for tf since it's never used drm/amd/display: camel case cleanup in color_gamma file ...
2023-02-16Revert "drm/vc4: hdmi: Enforce the minimum rate at runtime_resume"Maxime Ripard1-9/+0
This reverts commit ae71ab585c819f83aec84f91eb01157a90552ef2. Commit ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") was introduced to work around an issue partly due to the clk-bcm2835 driver on the RaspberryPi0-3. Since we're not using that driver for our HDMI clocks, we can now revert it. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-4-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-02-16Revert "drm/vc4: hdmi: Fix HSM clock too low on Pi4"Maxime Ripard2-18/+4
This reverts commit 3bc6a37f59f21a8bfaf74d0975b2eb0b2d52a065. Commit 3bc6a37f59f2 ("drm/vc4: hdmi: Fix HSM clock too low on Pi4") was introduced to work around an issue partly due to the clk-bcm2835 driver on the RaspberryPi0-3. Since we're not using that driver for our HDMI clocks, we can now revert that inelegant solution. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-3-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-02-16drm/vc4: hdmi: Enable power domain before setting minimumMaxime Ripard1-7/+7
On the RaspberryPi0-3, the HSM clock was provided by the clk-bcm2835 driver, but on the Pi4 it was provided by the firmware through the clk-raspberrypi driver. The clk-bcm2835 driver registers the HSM clock using the CLK_SET_RATE_GATE flag that prevents any modification to the rate while the clock is active. This meant that we needed to call clk_set_min_rate() before our call to pm_runtime_resume_and_get() since our runtime_resume implementation needs to enable the HSM clock for the HDMI controller registers to be functional. However, the HSM clock is part of the HDMI power domain which might not be powered prior to the pm_runtime_resume_and_get() call, so we could end up changing the rate of the HSM clock while its power domain was disabled. We recently changed the backing driver for the RaspberryPi0-3 to clk-raspberrypi though, which doesn't have such restrictions. We can thus move the clk_set_min_rate() after our call to runtime_resume and avoid the access while the power domain is disabled. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-2-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-02-16drm/vc4: hdmi: Replace hardcoded value by defineMaxime Ripard1-1/+3
The 120MHz value hardcoded in the call to max_t to compute the HSM rate is defined in the driver as HSM_MIN_CLOCK_FREQ, let's switch to it so that it's more readable. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-1-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-02-09drm/vc4: crtc: Increase setup cost in core clock calculation to handle ↵Dom Cobley1-1/+1
extreme reduced blanking The formula that determines the core clock requirement based on pixel clock and blanking has been determined experimentally to minimise the clock while supporting all modes we've seen. A new reduced blanking mode (4kp60 at 533MHz rather than the standard 594MHz) has been seen that doesn't produce a high enough clock and results in "flip_done timed out" error. Increase the setup cost in the formula to make this work. The result is a reduced blanking mode increases by up to 7MHz while leaving the standard timing mode untouched Link: https://github.com/raspberrypi/linux/issues/4446 Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127145558.446123-1-maxime@cerno.tech
2023-02-09drm/vc4: hdmi: Always enable GCP with AVMUTE clearedDom Cobley1-9/+9
Issue is some displays go blank at the point of firmware to kms handover. Plugging/unplugging hdmi cable, power cycling display, or switching standby off/on typically resolve this case. Finally managed to find a display that suffers from this, and track down the issue. The firmware uses AVMUTE in normal operation. It will set AVMUTE before disabling hdmi clocks and phy. It will clear AVMUTE after clocks and phy are set up for a new hdmi mode. But with the hdmi handover from firmware to kms, AVMUTE will be set by firmware. kms driver typically has no GCP packet (except for deep colour modes). The spec isn't clear on whether to consider the AVMUTE as continuing indefinitely in the absence of a GCP packet, or to consider that state to have ended. Most displays behave as we want, but there are a number (from multiple manufacturers) which need to see AVMUTE cleared before displaying a picture. Lets just always enable GCP packet with AVMUTE cleared. That resolves the issue on problematic displays. From HDMI 1.4 spec: A CD field of zero (Color Depth not indicated) shall be used whenever the Sink does not indicate support for Deep Color. This value may also be used in Deep Color mode to transmit a GCP indicating only non-Deep Color information (e.g. AVMUTE). So use CD=0 where we were previously not enabling a GCP. Link: https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0 Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127161219.457058-1-maxime@cerno.tech
2023-02-09drm/vc4: Fix YUV plane handling when planes are in different buffersDave Stevenson1-2/+4
YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxime@cerno.tech
2023-02-02drm/vc4: allow DRM_VC4_KUNIT_TEST to be a loadable moduleArnd Bergmann1-1/+1
In configurations with CONFIG_KUNIT=m, builting the unit test into the kernel causes a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/vc4/tests/vc4_mock.o: in function `__build_mock': vc4_mock.c:(.text+0x6e): undefined reference to `kunit_do_failed_assertion' arm-linux-gnueabi-ld: vc4_mock.c:(.text+0x9c): undefined reference to `kunit_do_failed_assertion' arm-linux-gnueabi-ld: vc4_mock.c:(.text+0x100): undefined reference to `kunit_ptr_not_err_assert_format' ... Allow this to be a loadable module as well to have Kconfig sort out the dependencies correctly. Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230202102346.868771-1-arnd@kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-31Merge v6.2-rc6 into drm-nextDaniel Vetter1-4/+2
Due to holidays we started -next with more -fixes in-flight than usual, and people have been asking where they are. Backmerge to get things better in sync. Conflicts: - Tiny conflict in drm_fbdev_generic.c between variable rename and missing error handling that got added. - Conflict in drm_fb_helper.c between the added call to vgaswitcheroo in drm_fb_helper_single_fb_probe and a refactor patch that extracted lots of helpers and incidentally removed the dev local variable. Readd it to make things compile. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2023-01-26drm/vc4: hdmi: make CEC adapter name uniqueHans Verkuil1-1/+2
The bcm2711 has two HDMI outputs, each with their own CEC adapter. The CEC adapter name has to be unique, but it is currently hardcoded to "vc4" for both outputs. Change this to use the card_name from the variant information in order to make the adapter name unique. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/dcf1db75-d9cc-62cc-fa12-baf1b2b3bf31@xs4all.nl
2023-01-19vc4: fix build failure in vc4_dsi_dev_probe()Arnd Bergmann1-0/+2
The bridge->of_node field is defined inside of an #ifdef, which results in a build failure when compile-testing the vc4_dsi driver without CONFIG_OF: drivers/gpu/drm/vc4/vc4_dsi.c: In function 'vc4_dsi_dev_probe': drivers/gpu/drm/vc4/vc4_dsi.c:1822:20: error: 'struct drm_bridge' has no member named 'of_node' 1822 | dsi->bridge.of_node = dev->of_node; Add another #ifdef in the place it is used in. Alternatively we could consider dropping the #ifdef in the struct definition and all other users. Fixes: 78df640394cd ("drm/vc4: dsi: Convert to using a bridge instead of encoder") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230117165258.1979922-1-arnd@kernel.org
2023-01-13drm/vc4: bo: Fix unused variable warningMaxime Ripard1-1/+0
Commit 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog") removed the only use of the ret variable, but didn't remove the variable itself leading to a unused variable warning. Remove that variable. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog") Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230113154637.1704116-1-maxime@cerno.tech
2023-01-12drm/vc4: bo: Fix drmm_mutex_init memory hogMaxime Ripard1-3/+2
Commit 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") converted, among other functions, vc4_create_object() to use drmm_mutex_init(). However, that function is used to allocate a BO, and therefore the mutex needs to be freed much sooner than when the DRM device is removed from the system. For each buffer allocation we thus end up allocating a small structure as part of the DRM-managed mechanism that is never freed, eventually leading us to no longer having any free memory anymore. Let's switch back to mutex_init/mutex_destroy to deal with it properly. Fixes: 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230112091243.490799-1-maxime@cerno.tech
2023-01-10drm/vc4: dsi: Drop unused i2c includeUwe Kleine-König1-1/+0
The driver doesn't make use of any symbol provided by <linux/i2c.h>. So drop the include. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219084023.1402282-1-u.kleine-koenig@pengutronix.de
2023-01-09drm/vc4: vec: Support progressive modesMateusz Kwiatkowski1-1/+3
The VEC is able to output progressive analog modes, but the driver has never set the proper bit to do so. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-15-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hdmi: Correct interlaced timings againDave Stevenson1-2/+3
The back porch timings were correct, only the sync offset was wrong. Correct timing is now reported for 1080i and 576i, but the h offset is incorrect for 480i for non-obvious reasons. Fixes: fb10dc451c0f ("drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-14-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: crtc: Fix timings for VEC modesMateusz Kwiatkowski1-27/+44
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Changes to vc4_crtc.c have also been made, to make the PixelValve vertical timings accurately correspond to the DRM modeline in interlaced modes. The resulting VERTA/VERTB register values have been verified against the reference values set by the Raspberry Pi firmware. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-13-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: Add comments for which HVS_PIXEL_ORDER_xxx defines applyDave Stevenson1-0/+3
The HVS_PIXEL_ORDER_xxx defines apply to specific HVS_PIXEL_FORMAT_xxx modes, so add comments to make this obvious. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-12-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: plane: Add 3:3:2 and 4:4:4:4 RGB/RGBX/RGBA formatsDave Stevenson1-0/+70
The hardware supports the 332 8bpp and 4:4:4:4 16bpp formats, but the table of supported formats didn't include them. Add them in. In theory they are supported for T-format as well as linear, but without a way to test them just add them as linear for now. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-11-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: plane: Omit pixel_order from the hvs_format for hvs5 only formatsDave Stevenson1-5/+0
pixel_order is used for the earlier versions of the HVS, so is redundant on the 10:10:10:2 and 10bit YUV formats that are only supported on HVS5. Remove the assignment from the table to avoid confusion. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-10-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: plane: Allow using 0 as a pixel order valueDave Stevenson1-6/+14
vc4_plane_mode_set for HVS5 was using pixel_order unless pixel_order_hvs5 was non-zero, except 0 is a valid value for the pixel_order. Specify pixel_order_hvs5 for all formats and remove the conditional. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-9-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Ignore atomic_flush if we're disabledMaxime Ripard1-0/+3
atomic_flush will be called for each CRTC even if they aren't enabled. The whole code we have there will thus run without a properly affected channel, which can then result in all sorts of weird behaviour. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-8-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Add DRM 210101010 RGB formatsDave Stevenson1-0/+28
HVS5 supports the 210101010 RGB[A|X] formats, but they were missing from the DRM to HVS mapping list, so weren't available. Add them in. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-7-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Fix colour order for xRGB1555 on HVS5Dave Stevenson1-0/+2
Same as the xRGB8888 formats, HVS5 has managed to swap the colour channels for the xRGB1555 formats as well. Add the relevant config for pixel_order_hvs5. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-6-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Support zpos on all planesDave Stevenson3-18/+48
Adds the zpos property to all planes, and creates the dlist by placing the fragments in the correct order based on zpos. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-5-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Correct interrupt masking bit assignment for HVS5Dave Stevenson2-18/+44
HVS5 has moved the interrupt enable bits around within the DISPCTRL register, therefore the configuration has to be updated to account for this. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-4-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: SCALER_DISPBKGND_AUTOHS is only valid on HVS4Dave Stevenson2-4/+7
The bit used for SCALER_DISPBKGND_AUTOHS in SCALER_DISPBKGNDX has been repurposed on HVS5 to configure whether a display can win back-to-back arbitration wins for the COB. This is not desirable, therefore only select this bit on HVS4, and explicitly clear it on HVS5. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-3-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Set AXI panic modesDave Stevenson2-0/+17
The HVS can change AXI request mode based on how full the COB FIFOs are. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. With HVS channel 2 now being used for live video, change the panic mode for all channels to be explicitly set by the driver, and the same for all channels. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-2-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-09drm/vc4: hvs: Configure the HVS COB allocationsDave Stevenson1-1/+55
The HVS Composite Output Buffer (COB) is the memory used to generate the output pixel data. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. In testing triple screen support it has been noted that only 1 line was being assigned to HVS channel 2. Whilst that is fine for the transposer (TXP), and indeed needed as only some pixels have an alpha channel, it is insufficient to run a live display. Split the COB more evenly between the 3 HVS channels. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-1-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2023-01-02drm/vc4: drop all currently held locks if deadlock happensMaíra Canal1-1/+10
If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock happened in the locking context. This situation should be addressed by dropping all currently held locks and block until the contended lock becomes available. Currently, vc4 is not dealing with the deadlock properly, producing the following output when PROVE_LOCKING is enabled: [ 825.612809] ------------[ cut here ]------------ [ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.613458] Modules linked in: 8021q mrp garp stp llc raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211 btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6 [ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3 [ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper] [ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] [ 825.614829] sp : ffff800008313bf0 [ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000 [ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758 [ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001 [ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3 [ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000 [ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002 [ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800 [ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054 [ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10 [ 825.615219] Call trace: [ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] [ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper] [ 825.616233] process_one_work+0x2b4/0x618 [ 825.616264] worker_thread+0x24c/0x464 [ 825.616288] kthread+0xec/0x110 [ 825.616310] ret_from_fork+0x10/0x20 [ 825.616335] irq event stamp: 7634 [ 825.616349] hardirqs last enabled at (7633): [<ffffcd777831ee90>] _raw_spin_unlock_irq+0x3c/0x78 [ 825.616384] hardirqs last disabled at (7634): [<ffffcd7778315a78>] __schedule+0x134/0x9f0 [ 825.616411] softirqs last enabled at (7630): [<ffffcd7707aacea0>] local_bh_enable+0x4/0x30 [ipv6] [ 825.617019] softirqs last disabled at (7618): [<ffffcd7707aace70>] local_bh_disable+0x4/0x30 [ipv6] [ 825.617586] ---[ end trace 0000000000000000 ]--- Therefore, deal with the deadlock as suggested by [1], using the function drm_modeset_backoff(). [1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Maíra Canal <mcanal@igalia.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221229194638.178712-1-mcanal@igalia.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-29 14:54:11 +0300