summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-01-09drm/i915/scaler: Extract skl_scaler_max_src_size()Ville Syrjälä
The SKL_MAX_SRC_* defines just make things hard to read. Get rid of them and introduce an easy to read function in their place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-3-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-01-09drm/i915/scaler: Extract skl_scaler_min_src_size()Ville Syrjälä
The SKL_MIN_*SRC_* defines just make things hard to read. Get rid of them and introduce an easy to read function in their place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-2-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-01-09drm/xe: Fix all typos in xeNitin Gote
Fix all typos in files of xe, reported by codespell tool. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250106102646.1400146-2-nitin.r.gote@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2025-01-09drm/virtio: Factor out common dmabuf unmapping codeDmitry Osipenko
Move out dmabuf detachment and unmapping into separate function. This removes duplicated code and there is no need to check the GEM's kref now, since both bo->attached and bo->sgt are unset under held reservation lock. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241202053955.2451321-1-dmitry.osipenko@collabora.com
2025-01-09drm/virtio: Set missing bo->attached flagDmitry Osipenko
VirtIO-GPU driver now supports detachment of shmem BOs from host, but doing it only for imported dma-bufs. Mark all shmem BOs as attached, not just dma-bufs. This is a minor correction since detachment of a non-dmabuf BOs not supported today. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129155357.2265357-1-dmitry.osipenko@collabora.com
2025-01-09drm/virtio: Lock the VGA resources during initializationVivek Kasireddy
If another driver for a VGA compatible GPU (that is passthrough'd) locks the VGA resources (by calling vga_get()), then virtio_gpu driver would encounter the following errors and fail to load during probe and initialization: Invalid read at addr 0x7200005014, size 1, region '(null)', reason: rejected Invalid write at addr 0x7200005014, size 1, region '(null)', reason: rejected virtio_gpu virtio0: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1 virtio_gpu virtio0: probe with driver virtio_gpu failed with error -22 This issue is only seen if virtio-gpu and the other GPU are on different PCI buses, which can happen if the user includes an additional PCIe port and associates the VGA compatible GPU with it while launching Qemu: qemu-system-x86_64... -device virtio-vga,max_outputs=1,xres=1920,yres=1080,blob=true -device pcie-root-port,id=pcie.1,bus=pcie.0,addr=1c.0,slot=1,chassis=1,multifunction=on -device vfio-pci,host=03:00.0,bus=pcie.1,addr=00.0 ... In the above example, the device 03:00.0 is an Intel DG2 card and this issue is seen when both i915 driver and virtio_gpu driver are loading (or initializing) concurrently or when i915 is loaded first. Note that during initalization, i915 driver does the following in intel_vga_reset_io_mem(): vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); outb(inb(VGA_MIS_R), VGA_MIS_W); vga_put(pdev, VGA_RSRC_LEGACY_IO); Although, virtio-gpu might own the VGA resources initially, the above call (in i915) to vga_get_uninterruptible() would result in these resources being taken away, which means that virtio-gpu would not be able to decode VGA anymore. This happens in __vga_tryget() when it calls pci_set_vga_state(conflict->pdev, false, pci_bits, flags); where pci_bits = PCI_COMMAND_MEMORY | PCI_COMMAND_IO flags = PCI_VGA_STATE_CHANGE_DECODES | PCI_VGA_STATE_CHANGE_BRIDGE Therefore, to solve this issue, virtio-gpu driver needs to call vga_get() whenever it needs to reclaim and access VGA resources, which is during initial probe and setup. After that, a call to vga_put() would release the lock to allow other VGA compatible devices to access these shared VGA resources. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Reported-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064343.550153-1-vivek.kasireddy@intel.com Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
2025-01-09drm/virtio: Fix UAF in virtgpu_dma_buf_free_obj()Vivek Kasireddy
Fix the following issues identified by Smatch static checker: - The call to dma_buf_put(attach->dmabuf) after dma_buf_detach() leads to a UAF bug as dma_buf_detach() frees the attach object. Fix this by extracting the dmabuf object from attach and using that in the call to dma_buf_put(). - The resv object is extracted from attach before checking to see if attach is valid (that is !NULL) or not. Although, attach would very likely be valid, fix this by making sure that the resv object is used only after ensuring that attach is valid. Fixes: 2885e575abc7 ("drm/virtio: Add helpers to initialize and free the imported object") Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241212055421.775759-1-vivek.kasireddy@intel.com Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> [dmitry.osipenko@collabora.com: Edited commit title]
2025-01-09drm/i915/gt: Prefer IS_ENABLED() instead of defined() on config optionNitin Gote
Use IS_ENABLED() instead of defined() for checking whether a kconfig option is enabled. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103062651.798249-2-nitin.r.gote@intel.com
2025-01-09drm/xe/dg1: Fix power gate sequence.Rodrigo Vivi
sub-pipe PG is not present on DG1. Setting these bits can disable other power gates and cause GPU hangs on video playbacks. VLK: 16314, 4304 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13381 Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219235536.454270-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 2f12e9c029315c1400059b2e7fdf53117c09c3a9) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-01-09drm/xe: Fix tlb invalidation when wedgingLucas De Marchi
If GuC fails to load, the driver wedges, but in the process it tries to do stuff that may not be initialized yet. This moves the xe_gt_tlb_invalidation_init() to be done earlier: as its own doc says, it's a software-only initialization and should had been named with the _early() suffix. Move it to be called by xe_gt_init_early(), so the locks and seqno are initialized, avoiding a NULL ptr deref when wedging: xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged. ... BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G U W 6.13.0-rc4-xe+ #3 Tainted: [U]=USER, [W]=WARN Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022 RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe] This can be easily triggered by poking the GuC binary to force a signature failure. There will still be an extra message, xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100 but that's better than a NULL ptr deref. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3956 Fixes: c9474b726b93 ("drm/xe: Wedge the entire device") Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103001111.331684-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-01-09Merge tag 'drm-xe-next-2025-01-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - OA new property: 'unblock after N reports' (Ashutosh) i915 display Changes: - UHBR rates for Thunderbolt (Kahola) Driver Changes: - IRQ related fixes and improvements (Ilia) - Revert some changes that break a mesa debug tool (John) - Fix migration issues (Nirmoy) - Enable GuC's WA_DUAL_QUEUE for newer platforms (Daniele) - Move shrink test out of xe_bo (Nirmoy) - SRIOV PF: Use correct function to check LMEM provisioning (Michal) - Fix a false-positive "Missing outer runtime PM protection" warning (Rodrigo) - Make GSCCS disabling message less alarming (Daniele) - Fix DG1 power gate sequence (Rodrigo) - Xe files fixes (Lucas) - Fix a potential TP_printk UAF (Thomas) - OA Fixes (Umesh) - Fix tlb invalidation when wedging (Lucas) - Documentation fix (Lucas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z31579j3V3XCPFaK@intel.com
2025-01-09Merge tag 'drm-misc-next-2025-01-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.14: UAPI Changes: - Clarify drm memory stats documentation Cross-subsystem Changes: Core Changes: - sched: Documentation fixes, Driver Changes: - amdgpu: Track BO memory stats at runtime - amdxdna: Various fixes - hisilicon: New HIBMC driver - bridges: - Provide default implementation of atomic_check for HDMI bridges - it605: HDCP improvements, MCCS Support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250106-augmented-kakapo-of-action-0cf000@houat
2025-01-09Merge tag 'mediatek-drm-next-6.14' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 6.14 1. dp: Add sdp path reset 2. dp: Support flexible length of DP calibration data Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250104125538.111118-1-chunkuang.hu@kernel.org
2025-01-08drm/xe/slpc: Remove unnecessary force wakesVinay Belgaumkar
FORCEWAKE_ALL is not needed when we are trying to read the cur_freq, we just need to wake up the GT domain. We also do not need a force wake to for a H2G query to obtain min frequency. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241216194119.3017792-1-vinay.belgaumkar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-08drm/xe: Introduce the RPa informationRodrigo Vivi
RPa is the Achievable frequency, defined by PCODE at runtime based on multiple running conditions. v2: Remove RPA_MASK from i915 file Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241220152936.623627-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-08drm/i915/display: Update DBUF_TRACKER_STATE_SERVICE only on appropriate ↵Ravi Kumar Vodapalli
platforms The bspec only asks the driver to reprogram the DBUF_CTL's DBUF_TRACKER_STATE_SERVICE field to 0x8 on DG2 and platforms with display version 12. All other platforms should avoid reprogramming this register at driver init. Although we've been accidentally reprogramming DBUF_CTL on platforms where the spec does not ask us to, that mistake has been harmless so far because the value being programmed by the driver happened to match the hardware's default settings. So, update DBUF_TRACKER_STATE_SERVICE field to 0x8 only for 1. display version 12 2. DG2. Other platforms unless stated should use their default value. Bspec: 49213 Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250108200210.1815229-1-ravi.kumar.vodapalli@intel.com [mattrope: Tweaked patch subject to accurately reflect content] Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-08treewide: Introduce kthread_run_worker[_on_cpu]()Frederic Weisbecker
kthread_create() creates a kthread without running it yet. kthread_run() creates a kthread and runs it. On the other hand, kthread_create_worker() creates a kthread worker and runs it. This difference in behaviours is confusing. Also there is no way to create a kthread worker and affine it using kthread_bind_mask() or kthread_affine_preferred() before starting it. Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]() that behaves just like kthread_run(). kthread_create_worker[_on_cpu]() will now only create a kthread worker without starting it. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
2025-01-08drm/i915/gt: Prevent uninitialized pointer readsApoorva Singh
Initialize rq to NULL to prevent uninitialized pointer reads. Signed-off-by: Apoorva Singh <apoorva.singh@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241227112920.1547592-1-apoorva.singh@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-08drm/ssd130x: Set SPI .id_table to prevent an SPI core warningJavier Martinez Canillas
The only reason for the ssd130x-spi driver to have an spi_device_id table is that the SPI core always reports an "spi:" MODALIAS, even when the SPI device has been registered via a Device Tree Blob. Without spi_device_id table information in the module's metadata, module autoloading would not work because there won't be an alias that matches the MODALIAS reported by the SPI core. This spi_device_id table is not needed for device matching though, since the of_device_id table is always used in this case. For this reason, the struct spi_driver .id_table member is currently not set in the SPI driver. Because the spi_device_id table is always required for module autoloading, the SPI core checks during driver registration that both an of_device_id table and a spi_device_id table are present and that they contain the same entries for all the SPI devices. Not setting the .id_table member in the driver then confuses the core and leads to the following warning when the ssd130x-spi driver is registered: [ 41.091198] SPI driver ssd130x-spi has no spi_device_id for sinowealth,sh1106 [ 41.098614] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1305 [ 41.105862] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1306 [ 41.113062] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1307 [ 41.120247] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1309 [ 41.127449] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1322 [ 41.134627] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1325 [ 41.141784] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1327 [ 41.149021] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1331 To prevent the warning, set the .id_table even though it's not necessary. Since the check is done even for built-in drivers, drop the condition to only define the ID table when the driver is built as a module. Finally, rename the variable to use the "_spi_id" convention used for ID tables. Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241231114516.2063201-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-01-08drm/i915/gvt: store virtual_dp_monitor_edid in rodataJani Nikula
The virtual DP EDID isn't modified. Add const modifier to store it in rodata. Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Zhi Wang <zhiwang@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250107182240.1765311-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-08Revert "drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link"Suraj Kandpal
This reverts commit 483f7d94a0453564ad9295288c0242136c5f36a0. This needs to be reverted since HDCP even after updating the connector state HDCP property we don't reenable HDCP until the next commit in which the CP Property is set causing compliance to fail. --v2 -Fix build issue [Dnyaneshwar] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103084517.239998-1-suraj.kandpal@intel.com (cherry picked from commit fcf73e20cd1fe60c3ba5f9626f1e8f9cd4511edf) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-01-08drm/tests: Add test for drm_atomic_helper_check_modeset()Jessica Zhang
Add a test for drm_atomic_check_modeset() specifically to validate drm_atomic_check_valid_clones() helper Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-4-fe220297a7f0@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-08drm: Add valid clones checkJessica Zhang
Check that all encoders attached to a given CRTC are valid possible_clones of each other. Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-3-fe220297a7f0@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-08drm/tests: Add test for drm_crtc_in_clone_mode()Jessica Zhang
Add kunit test to validate drm_crtc_in_clone_mode() helper Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-2-fe220297a7f0@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-08drm: add clone mode check for CRTCJessica Zhang
Add a common helper to check if the given CRTC state is in clone mode. This can be used by drivers to help detect if a CRTC is being shared by multiple encoders Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-1-fe220297a7f0@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-08drm/tests: Add test for drm_atomic_helper_commit_modeset_disables()Jessica Zhang
Add a subtest to check that modeset is called when the connector is changed Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241211-abhinavk-modeset-fix-v3-2-0de4bf3e7c32@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-08drm: allow encoder mode_set even when connectors change for crtcAbhinav Kumar
In certain use-cases, a CRTC could switch between two encoders and because the mode being programmed on the CRTC remains the same during this switch, the CRTC's mode_changed remains false. In such cases, the encoder's mode_set also gets skipped. Skipping mode_set on the encoder for such cases could cause an issue because even though the same CRTC mode was being used, the encoder type could have changed like the CRTC could have switched from a real time encoder to a writeback encoder OR vice-versa. Allow encoder's mode_set to happen even when connectors changed on a CRTC and not just when the mode changed. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241211-abhinavk-modeset-fix-v3-1-0de4bf3e7c32@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-07drm/xe/vf: Don't apply Wa_22019338487 for VFMarcin Bernatowicz
Don't use Wa_22019338487 for VF. Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Narasimha C V <narasimha.c.v@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064211.781820-4-marcin.bernatowicz@linux.intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/xe/rtp: Add match helper to omit SR-IOV VF deviceMarcin Bernatowicz
Add a match helper that allows the application of a workaround when the device is not an SR-IOV VF (Virtual Function) device. Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Narasimha C V <narasimha.c.v@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064211.781820-3-marcin.bernatowicz@linux.intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/xe/vf: Don't check has flat ccs in bios on VFJakub Kolakowski
Don't check for flat ccs from VF-level as VF does not have direct access to the register. If the BIOS disables FlatCCS support (a use-case that will nearly never be used) and the has_flat_ccs flag is set, there shouldn't be any functional impact. The hardware will drop writes to the CCS region, and reads from the CCS region will always return 0. For the native case, the flag is disabled if the BIOS disables it to avoid unnecessary overhead in buffer object (BO) creation and migration. Signed-off-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Suggested-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Narasimha C V <narasimha.c.v@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064211.781820-2-marcin.bernatowicz@linux.intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/i915/dmc_wl: Allow enable_dmc_wl=3 to mean "always locked"Gustavo Sousa
When debugging issues that might be related to the DMC wakelock code, it might be useful to compare runs with the lock acquired while DC states are enabled vs the regular case. If issues disappear with the former, it might be a symptom of something wrong in our code. Support having this "always locked" behavior with enable_dmc_wl=3. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-5-gustavo.sousa@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/i915/dmc_wl: Allow enable_dmc_wl=2 to mean "match any register"Gustavo Sousa
When debugging issues that might be related to the DMC wakelock code, it is sometimes useful to compare runs when we match any register offset vs the regular case. If issues disappear when we take the wakelock for any register, it might indicate that we are missing some offset to be tracked. Support matching any register offset with enable_dmc_wl=2. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-4-gustavo.sousa@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/i915/dmc_wl: Show description string for enable_dmc_wlGustavo Sousa
We already provide the value resulting from sanitization of enable_dmc_wl in dmesg, however the reader will need to either have the meanings memorized or look them up in the parameter's documentation. Let's make things easier by providing a short human-readable name for the parameter in dmesg. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-3-gustavo.sousa@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/i915/dmc_wl: Use enum values for enable_dmc_wlGustavo Sousa
Currently, after sanitization, enable_dmc_wl will behave like a boolean parameter (enabled vs disabled). However, in upcoming changes, we will allow more values for debugging purposes. For that, let's make the sanitized value an enumeration. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-2-gustavo.sousa@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/i915/display: convert global state to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert intel_global_state.[ch] to it. This allows us to make intel_pmdemand.c completely independent of i915_drv.h. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2b5e743b285a86a59ee87085727847c758c8d552.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: convert to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert pmdemand to it. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c1d92e9490013d5aba50fc1d1ebc0ee18e82cf7e.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: make struct intel_pmdemand_state opaqueJani Nikula
Only intel_pmdemand.c should look inside the struct intel_pmdemand_state. Indeed, this is already the case. Finish the job and make struct intel_pmdemand_state opaque, preventing any direct pokes at the guts of it in the future. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bc5f418785ecd51454761e9a55f21340470a92e3.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: convert to_intel_pmdemand_state() to a functionJani Nikula
In preparation for making struct intel_pmdemand_state an opaque type, convert to_intel_pmdemand_state() to a function. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/10324781f9f7eae5a92506aaa7a40403efd345dd.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/bridge: ti-sn65dsi86: Fix multiple instancesGeert Uytterhoeven
Each bridge instance creates up to four auxiliary devices with different names. However, their IDs are always zero, causing duplicate filename errors when a system has multiple bridges: sysfs: cannot create duplicate filename '/bus/auxiliary/devices/ti_sn65dsi86.gpio.0' Fix this by using a unique instance ID per bridge instance. The instance ID is derived from the I2C adapter number and the bridge's I2C address, to support multiple instances on the same bus. Fixes: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/7a68a0e3f927e26edca6040067fb653eb06efb79.1733840089.git.geert+renesas@glider.be
2025-01-07drm/i915/dp: compute config for 128b/132b SST w/o DSCJani Nikula
Enable basic 128b/132b SST functionality without compression. Reuse intel_dp_mtp_tu_compute_config() to figure out the TU after we've determined we need to use an UHBR rate. It's slightly complicated as the M/N computation is done in different places in MST and SST paths, so we need to avoid trashing the values later for UHBR. If uncompressed UHBR fails, we drop to compressed non-UHBR, which is quite likely to fail as well. We still lack 128b/132b SST+DSC. We need mst_master_transcoder also for 128b/132b SST. Use cpu_transcoder directly. Enhanced framing is "don't care" for 128b/132b link. v2: mst_master_transcoder, enhanced framing (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/084e4e05bf25a5dd396dd391014943d42b11c88d.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: disable trancoder port select for 128b/132b SSTJani Nikula
128b/1232b SST will have mst_master_transcoder set and matching cpu_transcoder. Ensure disable also for 128b/132b SST. Reviewed-by: Imre Deak <imre.deak@intel.com> Co-developed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eaf705b3490d828ba33e85f40a7794d58de7c5ad.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()Jani Nikula
We'll only ever get here in MST mode from MST stream encoders; the primary encoder's ->get_config() won't be called when we've detected it's MST. v2: Read mst_master_transcoder in 128b/132b SST path (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/436854c0bb6ab5c14c3d3837694ea60ac2fbaba2.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readoutJani Nikula
We'll want to distinguish 128b/132b SST and MST modes at state readout. There's a catch, though. From the hardware perspective, 128b/132b SST and MST programming are pretty much the same. And we can't really ask the sink at this point. If we have more than one transcoder in 128b/132b mode associated with the port, we can safely assume it's MST. But for MST with only a single stream enabled, we are pretty much out of luck. Let's fall back to looking at the software state, i.e. intel_dp->is_mst. It should be fine for the state checker, but for hardware takeover at probe, we'll have to trust the GOP has only enabled SST. TODO: Not sure how this *or* our current code handles 128b/132b enabled by GOP. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/119a773a0d4d74ad204435e462f8d12cb0ea4128.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: enable ACT handling for 128b/132b SSTJani Nikula
Add ACT handling for 128b/132b SST enable/disable. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: - Check for !is_hdmi (Imre) - Add disable sequence (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b0226471f9445d988917cee49dbbd93a1493f3c7.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: initialize 128b/132b SST DP2 VFREQ registersJani Nikula
Write the DP2 specific VFREQ registers. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: Check for !is_hdmi (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7d90547e9ce01642b722efca0bf81cadb754e790.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: write payload for 128b/132b SSTJani Nikula
Write the payload allocation table for 128b/132b SST. Use VCPID 1 and start from slot 0, with dp_m_n.tu slots. This is preparation for enabling 128b/132b SST. This path is not reachable yet. Indeed, we don't yet compute TU for 128b/132b SST. v2: Handle drm_dp_dpcd_write_payload() failures (Imre) v3: Include drm_dp_helper.h (kernel test robot) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250107095414.1244286-1-jani.nikula@intel.com
2025-01-07drm/i915/ddi: 128b/132b SST also needs DP_TP_CTL_MODE_MSTJani Nikula
It's not very clearly specified, and the hardware bit is ill-named, but 128b/132b SST also needs the MST mode set in the DP_TP_CTL register. This is preparation for enabling 128b/132b SST. This path is not reachable yet. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b29fbba8c979a8bab2bf03088610fe408faaf704.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: enable 128b/132b TRANS_DDI_FUNC_CTL mode for UHBR SSTJani Nikula
128b/132b SST needs 128b/132b mode enabled in the TRANS_DDI_FUNC_CTL register. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: Use the MST path instead of SST to also set transport select (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/122ebeadf4bf0870fc26b7d12abdff88f4be8799.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: adapt intel_dp_mtp_tu_compute_config() for 128b/132b SSTJani Nikula
Handle 128b/132b SST in intel_dp_mtp_tu_compute_config(). The remote bandwidth overhead and time slot allocation are only relevant for MST; SST only needs the local bandwidth and a check that 64 slots isn't exceeded. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b59c94b0aac2c073b0306c0a0040b26330f94260.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: split out a helper for figuring out the TUJani Nikula
Extract intel_dp_mtp_tu_compute_config() for figuring out the TU. Move the link configuration and mst state access to the callers. This will be easier to adapt to 128b/132b SST. v2: Don't add SST stuff here yet Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c3ea8370c9bd3cdc579159e68a63f4ed2fadc66a.1735912293.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-18 03:43:06 +0000