- 26 Sep, 2024 3 commits
-
-
Tvrtko Ursulin authored
Since drm_sched_entity_modify_sched() can modify the entities run queue, lets make sure to only dereference the pointer once so both adding and waking up are guaranteed to be consistent. Alternative of moving the spin_unlock to after the wake up would for now be more problematic since the same lock is taken inside drm_sched_rq_update_fifo(). v2: * Improve commit message. (Philipp) * Cache the scheduler pointer directly. (Christian) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: b37aced3 ("drm/scheduler: implement a function to modify sched list") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Philipp Stanner <pstanner@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.7+ Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-3-tursulin@igalia.comSigned-off-by:
-
Tvrtko Ursulin authored
Without the locking amdgpu currently can race between amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and drm_sched_job_arm(), leading to the latter accesing potentially inconsitent entity->sched_list and entity->num_sched_list pair. v2: * Improve commit message. (Philipp) Signed-off-by:
-
Thomas Zimmermann authored
The sysfb framebuffer handling only operates on graphics devices that provide the system's firmware framebuffer. If that device is not known, assume that any graphics device has been initialized by firmware. Fixes a problem on i915 where sysfb does not release the firmware framebuffer after the native graphics driver loaded. Reported-by:
Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com> Closes: https://lore.kernel.org/dri-devel/SJ1PR11MB6129EFB8CE63D1EF6D932F94B96F2@SJ1PR11MB6129.namprd11.prod.outlook.com/ Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Fixes: b49420d6 ("video/aperture: optionally match the device in sysfb_disable()") Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Helge Deller <deller@gmx.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> Cc: <stable@vger.kernel.org> # v6.11+ Acked-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924084227.262271-1-tzimmermann@suse.de
-
- 25 Sep, 2024 1 commit
-
-
Thomas Zimmermann authored
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI should only use UAPI types. Hence replace struct drm_rect with struct drm_mode_rect in drm_atomic_plane_set_property(). Both types are identical in practice, so there's no change in behavior. Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://lore.kernel.org/dri-devel/Zu1Ke1TuThbtz15E@intel.com/Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmermann@suse.de
-
- 24 Sep, 2024 1 commit
-
-
Derek Foreman authored
The largest infoframe we create is the DRM (Dynamic Range Mastering) infoframe which is 26 bytes + a 4 byte header, for a total of 30 bytes. With HDMI_MAX_INFOFRAME_SIZE set to 29 bytes, as it is now, we allocate too little space to pack a DRM infoframe in write_device_infoframe(), leading to an ENOSPC return from hdmi_infoframe_pack(), and never calling the connector's write_infoframe() vfunc. Instead of having HDMI_MAX_INFOFRAME_SIZE defined in two places, replace HDMI_MAX_INFOFRAME_SIZE with HDMI_INFOFRAME_SIZE(MAX) and make MAX 27 bytes - which is defined by the HDMI specification to be the largest infoframe payload. Fixes: f378b772 ("drm/connector: hdmi: Add Infoframes generation") Fixes: c602e495 ("drm/connector: hdmi: Create Infoframe DebugFS entries") Signed-off-by:
Derek Foreman <derek.foreman@collabora.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240827163918.48160-1-derek.foreman@collabora.comSigned-off-by:
-
- 23 Sep, 2024 3 commits
-
-
Rob Clark authored
Fixes a race condition reported here: https://github.com/AsahiLinux/linux/issues/309#issuecomment-2238968609 The whole premise of lockless access to a single-producer-single- consumer queue is that there is just a single producer and single consumer. That means we can't call drm_sched_can_queue() (which is about queueing more work to the hw, not to the spsc queue) from anywhere other than the consumer (wq). This call in the producer is just an optimization to avoid scheduling the consuming worker if it cannot yet queue more work to the hw. It is safe to drop this optimization to avoid the race condition. Suggested-by:
Asahi Lina <lina@asahilina.net> Fixes: a78422e9 ("drm/sched: implement dynamic job-flow control") Closes: https://github.com/AsahiLinux/linux/issues/309 Cc: stable@vger.kernel.org Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Danilo Krummrich <dakr@kernel.org> Tested-by:
Janne Grunau <j@jannau.net> Signed-off-by:
-
Philipp Stanner authored
DRM's GPU scheduler is arguably in need of more intensive maintenance. Danilo and Philipp volunteer to help with the maintainership. Signed-off-by:
Philipp Stanner <pstanner@redhat.com> Cc: Christian König <christian.koenig@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by:
Matthew Brost <matthew.brost@intel.com> Acked-by:
-
Steven Price authored
XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase(). Fixes: de854881 ("drm/panthor: Add the scheduler logical block") Signed-off-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923103406.2509906-1-steven.price@arm.com
-
- 14 Sep, 2024 1 commit
-
-
Hans de Goede authored
Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
- 12 Sep, 2024 2 commits
-
-
Dmitry Baryshkov authored
The commit 9da7ec9b ("drm/bridge-connector: move to DRM_DISPLAY_HELPER module") changed location of the drm_bridge_connector.c file, but didn't update the kerneldocs. Fix that. Fixes: 9da7ec9b ("drm/bridge-connector: move to DRM_DISPLAY_HELPER module") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20240904163018.214efaa7@canb.auug.org.au/Acked-by:
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911-drm-fix-dbc-docs-v1-1-ae5cb82fce1e@linaro.orgSigned-off-by:
-
Imre Deak authored
Atm it's assumed that all Synaptics MST branch devices support DSC, which is not exposed via a DP-to-DP peer device, rather a control flag in the branch device's UFP DPCD applying to all the streams going through it. This isn't true for all adapters with this branch device though (for instance the Cakitte USBC->2xHDMI adapter reported in the Closes link below doesn't support DSC). Fix the above by advertising the DSC decompression support only if the capability flag for this in the UFP DPCD is actually set. Cc: Lyude Paul <lyude@redhat.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12047Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240909144650.2931258-1-imre.deak@intel.com
-
- 10 Sep, 2024 5 commits
-
-
Lu Baolu authored
Commit <17de3f5f> ("iommu: Retire bus ops") removes iommu ops from the bus structure. The iommu subsystem no longer relies on bus for operations. So iommu_domain_alloc() interface is no longer relevant. Replace iommu_domain_alloc() with iommu_paging_domain_alloc() which takes the physical device from which the host1x_device virtual device was instantiated. This physical device is a common parent to all physical devices that are part of the virtual device. Suggested-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
-
Lu Baolu authored
Commit <421be3ee> ("drm/rockchip: Refactor IOMMU initialisation") has refactored rockchip_drm_init_iommu() to pass a device that the domain is allocated for. Replace iommu_domain_alloc() with iommu_paging_domain_alloc() to retire the former. Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Acked-by:
Andy Yan <andyshrk@163.com> Signed-off-by:
-
T.J. Mercier authored
A syncobj reference is taken in drm_syncobj_find, but not released if eventfd_ctx_fdget or kzalloc fails. Put the reference in these error paths. Reported-by:
Xingyu Jin <xingyuj@google.com> Fixes: c7a47229 ("drm/syncobj: add IOCTL to register an eventfd") Signed-off-by:
T.J. Mercier <tjmercier@google.com> Reviewed-by:
-
Arnd Bergmann authored
The added lvds driver and a change in the dsi driver resulted in failed builds when COMMON_CLK is disabled: x86_64-linux-ld: drivers/gpu/drm/stm/dw_mipi_dsi-stm.o: in function `dw_mipi_dsi_stm_remove': dw_mipi_dsi-stm.c:(.text+0x51e): undefined reference to `clk_hw_unregister' x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_remove': lvds.c:(.text+0xe3): undefined reference to `of_clk_del_provider' x86_64-linux-ld: lvds.c:(.text+0xec): undefined reference to `clk_hw_unregister' x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_pll_config': lvds.c:(.text+0xb5d): undefined reference to `clk_hw_get_rate' x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_probe': lvds.c:(.text+0x1476): undefined reference to `clk_hw_register' x86_64-linux-ld: lvds.c:(.text+0x148b): undefined reference to `of_clk_hw_simple_get' x86_64-linux-ld: lvds.c:(.text+0x1493): undefined reference to `of_clk_add_hw_provider' x86_64-linux-ld: lvds.c:(.text+0x1535): undefined reference to `clk_hw_unregister' Add this as a dependency for the stm driver itself, since it will be required in practice anyway. Fixes: 185f99b6 ("drm/stm: dsi: expose DSI PHY internal clock") Fixes: aca1cbc1 ("drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240719075454.3595358-1-arnd@kernel.orgSigned-off-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> (cherry picked from commit 26dbffb2) Signed-off-by:
-
Ben Skeggs authored
init() was removed from ramgp102 when reworking the memory detection, as it was thought that the code was only necessary when the driver performs mclk changes, which nouveau doesn't support on pascal. However, it turns out that we still need to execute this on some GPUs to restore settings after DEVINIT, so revert to the original behaviour. v2: fix tags in commit message, cc stable Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/319 Fixes: 2c0c15a2 ("drm/nouveau/fb/gp102-ga100: switch to simpler vram size detection method") Cc: stable@vger.kernel.org # 6.6+ Signed-off-by:
Ben Skeggs <bskeggs@nvidia.com> Signed-off-by:
-
- 09 Sep, 2024 1 commit
-
-
T.J. Mercier authored
Until VM_DONTEXPAND was added in commit 1c1914d6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping. Reported-by:
John Stultz <jstultz@google.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240830192627.2546033-1-tjmercier@google.com
-
- 05 Sep, 2024 5 commits
-
-
Thomas Zimmermann authored
Deferred I/O requires struct page for framebuffer memory, which is not guaranteed for all DMA ranges. We thus only install deferred I/O if we have a framebuffer that requires it. A reported bug affected the ipu-v3 and pl111 drivers, which have video memory in either Normal or HighMem zones [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff] [ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff] where deferred I/O only works correctly with HighMem. See the Closes tags for bug reports. v2: - test if screen_buffer supports deferred I/O (Sima) Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Closes: https://lore.kernel.org/all/23636953.6Emhk5qWAg@steina-w/Reported-by:
Linus Walleij <linus.walleij@linaro.org> Closes: https://lore.kernel.org/dri-devel/CACRpkdb+hb9AGavbWpY-=uQQ0apY9en_tWJioPKf_fAbXMP4Hg@mail.gmail.com/Tested-by:
Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by:
-
Adrián Larumbe authored
In the off-chance that waiting for the firmware to signal its booted status timed out in the fast reset path, one must flush the cache lines for the entire FW VM address space before reloading the regions, otherwise stale values eventually lead to a scheduler job timeout. Fixes: 647810ec ("drm/panthor: Add the MMU/VM logical block") Cc: stable@vger.kernel.org Signed-off-by:
Adrián Larumbe <adrian.larumbe@collabora.com> Acked-by:
-
Ryan Walklin authored
As per the previous dt-binding commit, update the WL-355608-A8 panel compatible to reflect the the integrating device vendor and name as the panel OEM is unknown. Fixes: 62ea2eeb ("drm: panel: nv3052c: Add WL-355608-A8 panel") Signed-off-by:
Ryan Walklin <ryan@testtoast.com> Signed-off-by:
-
Ryan Walklin authored
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown OEM used in a number of handheld gaming devices made by Anbernic. Previously committed using the OEM serial without a vendor prefix, however following subsequent discussion the preference is to use the integrating device vendor and name where the OEM is unknown. There are 4 RG35XX series devices from Anbernic based on an Allwinner H700 SoC using this panel, with the -Plus variant introduced first. Therefore the -Plus is used as the fallback for the subsequent -H, -2024, and -SP devices. Alter the filename and compatible string to reflect the convention. Fixes: 45b888a8 ("dt-bindings: display: panel: Add WL-355608-A8 panel") Signed-off-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
Mary Guillemard authored
We were allowing any users to create a high priority group without any permission checks. As a result, this was allowing possible denial of service. We now only allow the DRM master or users with the CAP_SYS_NICE capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM. As the sole user of that uAPI lives in Mesa and hardcode a value of MEDIUM [1], this should be safe to do. Additionally, as those checks are performed at the ioctl level, panthor_group_create now only check for priority level validity. [1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038Signed-off-by:
Mary Guillemard <mary.guillemard@collabora.com> Fixes: de854881 ("drm/panthor: Add the scheduler logical block") Cc: stable@vger.kernel.org Reviewed-by:
-
- 03 Sep, 2024 3 commits
-
-
Dmitry Baryshkov authored
On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI IGT chokes on the max_bpc property in several kms_properties tests due to the drm_bridge_connector failing to reset HDMI-related properties. Call __drm_atomic_helper_connector_hdmi_reset() if the drm_bridge_connector has bridge_hdmi. It is impossible to call this function from HDMI bridges, none of the bridge callbacks correspond to the drm_connector_funcs::reset(). Fixes: 6b4468b0 ("drm/bridge-connector: implement glue code for HDMI connector") Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
-
Dmitry Baryshkov authored
drm_bridge_connector is a "leaf" driver, belonging to the display helper, rather than the "CRTC" drm_kms_helper module. Move the driver to the drm/display and add necessary Kconfig selection clauses. Suggested-by:
-
Dmitry Baryshkov authored
Kconfig symbols should not declare dependency on DRM_DISPLAY_HELPER. Move all parts of DRM_DISPLAY_HELPER to an if DRM_DISPLAY_HELPER block. It is not possible to make those symbols select DRM_DISPLAY_HELPER because of the link issues when a part of the helper is selected to be built-in, while other part is selected to be as module. In such a case the modular part doesn't get built at all, leading to undefined symbols. The only viable alternative is to split drm_display_helper.ko into several small modules, each of them having their own dependencies. Suggested-by:
-
- 02 Sep, 2024 1 commit
-
-
Matt Coster authored
This caused a measurable memory leak. Although the individual allocations are small, the leaks occurs in a high-usage codepath (remapping or unmapping device memory) so they add up quickly. Fixes: ff5f643d ("drm/imagination: Add GEM and VM related code") Cc: stable@vger.kernel.org Reviewed-by:
Frank Binns <frank.binns@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/35867394-d8ce-4698-a8fd-919a018f1583@imgtec.comSigned-off-by:
Matt Coster <matt.coster@imgtec.com>
-
- 30 Aug, 2024 2 commits
-
-
Dave Airlie authored
This aligns with what open gpu does, the 0x15 hex is just to trick you. Fixes: 176fdcbd ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
hongchi.peng authored
We use komeda_crtc_normalize_zpos to normalize zpos of affected planes to their blending zorder in CU. If there's only one slave plane in affected planes and its layer_split property is enabled, order++ for its split layer, so that when calculating the normalized_zpos of master planes, the split layer of the slave plane is included, but the max_slave_zorder does not include the split layer and keep zero because there's only one slave plane in affacted planes, although we actually use two slave layers in this commit. In most cases, this bug does not result in a commit failure, but assume the following situation: slave_layer 0: zpos = 0, layer split enabled, normalized_zpos = 0;(use slave_layer 2 as its split layer) master_layer 0: zpos = 2, layer_split enabled, normalized_zpos = 2;(use master_layer 2 as its split layer) master_layer 1: zpos = 4, normalized_zpos = 4; master_layer 3: zpos = 5, normalized_zpos = 5; kcrtc_st->max_slave_zorder = 0; When we use master_layer 3 as a input of CU in function komeda_compiz_set_input and check it with function komeda_component_check_input, the parameter idx is equal to normailzed_zpos minus max_slave_zorder, the value of idx is 5 and is euqal to CU's max_active_inputs, so that komeda_component_check_input returns a -EINVAL value. To fix the bug described above, when calculating the max_slave_zorder with the layer_split enabled, count the split layer in this calculation directly. Signed-off-by:hongchi.peng <hongchi.peng@siengine.com> Acked-by:
-
- 28 Aug, 2024 1 commit
-
-
Tvrtko Ursulin authored
We forgot to disable preemption around the write_seqcount_begin/end() pair while updating GPU stats: [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d] [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] <...snip...> [ ] Call trace: [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d] [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d] [ ] v3d_bin_job_run+0x23c/0x388 [v3d] [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ ] process_one_work+0x62c/0xb48 [ ] worker_thread+0x468/0x5b0 [ ] kthread+0x1c4/0x1e0 [ ] ret_from_fork+0x10/0x20 Fix it. Cc: Maíra Canal <mcanal@igalia.com> Cc: stable@vger.kernel.org # v6.10+ Fixes: 6abe93b6 ("drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Signed-off-by:
-
- 26 Aug, 2024 4 commits
-
-
Alex Deucher authored
In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. NULL pointer dereference via sysfb_disable() since the resources have already been freed by aperture_detach_platform_device() when it was called by the other device. Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not. v2: Fix build when CONFIG_SCREEN_INFO is not set v3: Move device check into the mutex Drop primary variable in aperture_remove_conflicting_pci_devices() Drop __init on pci sysfb_pci_dev_is_enabled() Fixes: 5ae3716c ("video/aperture: Only remove sysfb on the default vga pci device") Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Helge Deller <deller@gmx.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: -
Zack Rusin authored
Coherent surfaces make only sense if the host renders to them using accelerated apis. Without 3d the entire content of dumb buffers stays in the guest making all of the extra work they're doing to synchronize between guest and host useless. Configurations without 3d also tend to run with very low graphics memory limits. The pinned console fb, mob cursors and graphical login manager tend to run out of 16MB graphics memory that those guests use. Fix it by making sure the coherent dumb buffers are only used on configs with 3d enabled. Signed-off-by:
Zack Rusin <zack.rusin@broadcom.com> Fixes: d6667f0d ("drm/vmwgfx: Fix handling of dumb buffers") Reported-by:
Christian Heusel <christian@heusel.eu> Closes: https://lore.kernel.org/all/0d0330f3-2ac0-4cd5-8075-7f1cbaf72a8e@heusel.eu Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.9+ Link: https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-4-zack.rusin@broadcom.comReviewed-by:
Martin Krastev <martin.krastev@broadcom.com> Reviewed-by:
Maaz Mombasawala <maaz.mombasawala@broadcom.com> Tested-by:
Benjamin Coddington <bcodding@redhat.com>
-
Zack Rusin authored
Make sure that for external buffers mapping goes through the dma_buf interface instead of trying to access pages directly. External buffers might not provide direct access to readable/writable pages so to make sure the bo's created from external dma_bufs can be read dma_buf interface has to be used. Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't trigger this due to the fact that virtual machines will not have multiple GPUs but it enables better test coverage in IGT. Signed-off-by:
-
Zack Rusin authored
The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus. Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0. Fixes: 485d98d4 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4") Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.19+ Signed-off-by:
-
- 23 Aug, 2024 1 commit
-
-
Alex Deucher authored
This reverts commit 0ddd2ae5. This patch causes sluggishness and stuttering in graphical apps. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3564 Link: https://www.spinics.net/lists/dri-devel/msg457005.htmlSigned-off-by:
-
- 16 Aug, 2024 1 commit
-
-
Dave Airlie authored
Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup, when the iommu is enabled: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace: <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? do_error_trap+0x65/0x80 ? sg_init_one+0x85/0xa0 ? exc_invalid_op+0x50/0x70 ? sg_init_one+0x85/0xa0 ? asm_exc_invalid_op+0x1a/0x20 ? sg_init_one+0x85/0xa0 nvkm_firmware_ctor+0x14a/0x250 [nouveau] nvkm_falcon_fw_ctor+0x42/0x70 [nouveau] ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau] r535_gsp_oneinit+0xb3/0x15f0 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? nvkm_udevice_new+0x95/0x140 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? ktime_get+0x47/0xb0 Fix this by using the non-coherent allocator instead, I think there might be a better answer to this, but it involve ripping up some of APIs using sg lists. Cc: stable@vger.kernel.org Fixes: 2541626c ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs") Signed-off-by:
-
- 15 Aug, 2024 1 commit
-
-
Alex Bee authored
HDMI analyser shows that the AVI infoframe is no being longer send. The switch to the HDMI connector api should have used the frame content which is now given in the buffer parameter, but instead still uses the (now) empty and superfluous packed_frame variable. Fix it. Fixes: 65548c8f ("drm/rockchip: inno_hdmi: Switch to HDMI connector") Signed-off-by:
Alex Bee <knaerzche@gmail.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240805110855.274140-2-knaerzche@gmail.com
-
- 12 Aug, 2024 3 commits
-
-
Maíra Canal authored
When enabling UBSAN on Raspberry Pi 5, we get the following warning: [ 387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3 [ 387.903868] index 7 is out of range for type '__u32 [7]' [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151 [ 387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched] [ 387.932525] Call trace: [ 387.935296] dump_backtrace+0x170/0x1b8 [ 387.939403] show_stack+0x20/0x38 [ 387.942907] dump_stack_lvl+0x90/0xd0 [ 387.946785] dump_stack+0x18/0x28 [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0 [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d] [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ 387.966862] process_one_work+0x62c/0xb48 [ 387.971296] worker_thread+0x468/0x5b0 [ 387.975317] kthread+0x1c4/0x1e0 [ 387.978818] ret_from_fork+0x10/0x20 [ 387.983014] ---[ end trace ]--- This happens because the UAPI provides only seven configuration registers and we are reading the eighth position of this u32 array. Therefore, fix the out-of-bounds read in `v3d_csd_job_run()` by accessing only seven positions on the '__u32 [7]' array. The eighth register exists indeed on V3D 7.1, but it isn't currently used. That being so, let's guarantee that it remains unused and add a note that it could be set in a future patch. Fixes: 0ad5bc1c ("drm/v3d: fix up register addresses for V3D 7.x") Reported-by:
Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240809152001.668314-1-mcanal@igalia.com
-
Bouke Sybren Haarsma authored
Add quirk orientation for Ayn Loki Max model. This has been tested by JELOS team that uses their own patched kernel for a while now and confirmed by users in the ChimeraOS discord servers. Signed-off-by:
Bouke Sybren Haarsma <boukehaarsma23@gmail.com> Reviewed-by:
-
Bouke Sybren Haarsma authored
Add quirk orientation for the Ayn Loki Zero. This also has been tested/used by the JELOS team. Signed-off-by:
-
- 08 Aug, 2024 1 commit
-
-
Douglas Anderson authored
The yaml had indentation errors: ./Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml:21:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml:23:11: [warning] wrong indentation: expected 12 but found 10 (indentation) Fix them. Reported-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240808114407.1.I099e8e9e36407a0785d846b953031d40ea71e559@changeid
-
