- 21 Feb, 2023 2 commits
-
-
Ben Skeggs authored
During system shutdown nouveau might not be able to request firmware from Userspace, which then leads to a regression preventing the system from shutting down. Cache the scrubber binary for this case. Fixes: 0e44c217 ("drm/nouveau/flcn: new code to load+boot simple HS FWs (VPR scrubber)") Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7Uf5=K44y8YLsiy0aMnc1zvGEQdeDe7RQF=AV+fxxzuQ@mail.gmail.com
-
Jiri Slaby (SUSE) authored
gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)' drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of 'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)' It can be barely visible, but the declaration says about the parameters in the middle: enum nv50_disp_interlock_type, u32 interlock_data, u32 heads, While the definition states differently: u32 heads, enum nv50_disp_interlock_type interlock_type, u32 interlock_data, Unify/fix the declaration to match the definition. Fixes: 53e0a3e7 ("drm/nouveau/kms/nv50-: simplify tracking of channel interlocks") Cc: Martin Liska <mliska@suse.cz> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Signed-off-by:
-
- 17 Feb, 2023 1 commit
-
-
Alexandr Sapozhnikov authored
After having been compared to NULL value at cirrus.c:455, pointer 'pipe->plane.state->fb' is passed as 1st parameter in call to function 'cirrus_fb_blit_rect' at cirrus.c:461, where it is dereferenced at cirrus.c:316. Found by Linux Verification Center (linuxtesting.org) with SVACE. v2: * aligned commit message to line-length limits Signed-off-by:
Alexandr Sapozhnikov <alsp705@gmail.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
- 15 Feb, 2023 2 commits
-
-
Zack Rusin authored
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot. It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them. Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they're ready give the control back to userspace. Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn't grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point. Signed-off-by:
Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0 ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org (cherry picked from commit 9ef8d83e) Cc: <stable@vger.kernel.org> # v5.17+
-
Zack Rusin authored
ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function objects before checking the return status of vmw_bo_create leading to null pointer access. Fix the entire path by relaying on ttm_bo_init_reserved to delete the buffer objects on failure and making sure the return status is checked before setting the gem function objects on the buffer object. Signed-off-by:
-
- 13 Feb, 2023 1 commit
-
-
Ville Syrjälä authored
CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular) drm drivers. The debug prints can be reinstated by manually frobbing /sys/module/drm/parameters/debug after the fact, but at that point the damage is done and all debugs from driver probe are lost. This makes drivers totally undebuggable. There's a more complete fix in progress [1], with further details, but we need this fixed in stable kernels. Mark the feature as broken and disable it by default, with hopes distros follow suit and disable it as well. [1] https://lore.kernel.org/r/20230125203743.564009-1-jim.cromie@gmail.com Fixes: 84ec6728 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro") Cc: Jim Cromie <jim.cromie@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.1+ Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Jim Cromie <jim.cromie@gmail.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207143337.2126678-1-jani.nikula@intel.com
-
- 10 Feb, 2023 2 commits
-
-
Jocelyn Falempe authored
During the driver conversion to shmem, the start address for the scanout buffer was set to the base PCI address. In most cases it works because only the lower 24bits are used, and due to alignment it was almost always 0. But on some unlucky hardware, it's not the case, and some uninitialized memory is displayed on the BMC. With shmem, the primary plane is always at offset 0 in GPU memory. * v2: rewrite the patch to set the offset to 0. (Thomas Zimmermann) * v3: move the change to plane_init() and also fix the cursor plane. (Jammy Huang) Tested on a sr645 affected by this bug. Fixes: f2fa5a99 ("drm/ast: Convert ast to SHMEM") Signed-off-by:Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
Jammy Huang <jammy_huang@aspeedtech.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209094417.21630-1-jfalempe@redhat.com
-
Takashi Iwai authored
When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work. This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release(). Reviewed-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
Miko Larsson <mikoxyzzz@gmail.com> Fixes: 56c134f7 ("fbdev: Track deferred-I/O pages in pageref struct") Reviewed-by:
-
- 09 Feb, 2023 3 commits
-
-
Dom Cobley authored
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: 16e10105 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by:
Dom Cobley <popcornmix@gmail.com> Signed-off-by:
-
Dom Cobley authored
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-0Signed-off-by:
-
Dave Stevenson authored
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: fc04023f ("drm/vc4: Add support for YUV planes.") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
- 07 Feb, 2023 1 commit
-
-
Christian König authored
We reference dump buffers both by their handle as well as their object. The problem is now that when anybody iterates over the DRM framebuffers and exports the underlying GEM objects through DMA-buf we run into a circular reference count situation. The result is that the fbdev handling holds the GEM handle preventing the DMA-buf in the GEM object to be released. This DMA-buf in turn holds a reference to the driver module which on unload would release the fbdev. Break that loop by releasing the handle as soon as the DRM framebuffer object is created. The DRM framebuffer and the DRM client buffer structure still hold a reference to the underlying GEM object preventing its destruction. Signed-off-by:
Christian König <christian.koenig@amd.com> Fixes: c76f0f7c ("drm: Begin an API for in-kernel clients") Cc: <stable@vger.kernel.org> Reviewed-by:
-
- 06 Feb, 2023 1 commit
-
-
Ryan Neph authored
An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1, making the retry attempt fail at sync_file_get_fence(). The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the passed value for exbuf->fence_fd when returning anything besides a successful result from the ioctl. Fixes: 2cd7b6f0 ("drm/virtio: add in/out fence support for explicit synchronization") Signed-off-by:
Ryan Neph <ryanneph@chromium.org> Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
- 03 Feb, 2023 1 commit
-
-
Bert Karwatzki authored
amdgpu_sync_get_fence deletes the returned fence from the syncobj, so the refcount of fence needs to lowered to avoid a memory leak. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2360Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Tested-by:
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Reviewed-by:
Bert Karwatzki <spasswolf@web.de> Signed-off-by:
-
- 01 Feb, 2023 1 commit
-
-
Stephen Boyd authored
The unprepare sequence has started to fail after moving to panel bridge code in the msm drm driver (commit 007ac026 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs: panel-boe-tv101wum-nl6 ae94000.dsi.0: failed to set panel off: -22 This is because boe_panel_enter_sleep_mode() needs an operating DSI link to set the panel into sleep mode. Performing those writes in the unprepare phase of bridge ops is too late, because the link has already been torn down by the DSI controller in post_disable, i.e. the PHY has been disabled, etc. See dsi_mgr_bridge_post_disable() for more details on the DSI . Split the unprepare function into a disable part and an unprepare part. For now, just the DSI writes to enter sleep mode are put in the disable function. This fixes the panel off routine and keeps the panel happy. My Wormdingler has an integrated touchscreen that stops responding to touch if the panel is only half disabled too. This patch fixes it. And finally, this saves power when the screen is off because without this fix the regulators for the panel are left enabled when nothing is being displayed on the screen. Fixes: 007ac026 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE") Fixes: a869b9db ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Cc: yangcong <yangcong5@huaqin.corp-partner.google.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@chromium.org> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 30 Jan, 2023 3 commits
-
-
Ben Skeggs authored
Missed some Tegra-specific quirks when reworking ACR to support Ampere. Fixes: 2541626c ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs") Signed-off-by:
Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Tested-by:
Nicolas Chauvet <kwizart@gmail.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130223715.1831509-3-bskeggs@redhat.com
-
Ben Skeggs authored
Turing apparently needs to use the same register we use on Ampere. Not executing the scrubber ucode when required would result in large areas of VRAM being inaccessible to the driver. Signed-off-by:
-
Ben Skeggs authored
Starting from Turing, the driver is no longer responsible for initiating DEVINIT when required as the GPU started loading a FW image from ROM and executing DEVINIT itself after power-on. However - we apparently still need to wait for it to complete. This should correct some issues with runpm on some systems, where we get control of the HW before it's been fully reinitialised after resume from suspend. Signed-off-by:
-
- 27 Jan, 2023 1 commit
-
-
Danilo Krummrich authored
In dma_fence_allocate_private_stub() set the signaling bit of the newly allocated private stub fence rather than the signaling bit of the shared dma_fence_stub. Cc: <stable@vger.kernel.org> # v6.1 Fixes: c85d00d4 ("dma-buf: set signaling bit for the stub fence") Reviewed-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230126002844.339593-1-dakr@redhat.com
-
- 26 Jan, 2023 2 commits
-
-
Javier Martinez Canillas authored
Commit 622113b9 ("drm/ssd130x: Replace simple display helpers with the atomic helpers") changed the driver to just use the atomic helpers instead of the simple KMS abstraction layer. But the commit also made a subtle change on the display power sequence and initialization order, by moving the ssd130x_power_on() call to the encoder .atomic_enable handler and the ssd130x_init() call to CRTC .reset handler. Before this change, both ssd130x_power_on() and ssd130x_init() were called in the simple display pipeline .enable handler, so the display was already initialized by the time the SSD130X_DISPLAY_ON command was sent. For some reasons, it only made the ssd130x SPI driver to fail but the I2C was still working. That is the reason why the bug was not noticed before. To revert to the old driver behavior, move the ssd130x_init() call to the encoder .atomic_enable as well. Besides fixing the panel not being turned on when using SPI, it also gets rid of the custom CRTC .reset callback. Fixes: 622113b9 ("drm/ssd130x: Replace simple display helpers with the atomic helpers") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Hans Verkuil authored
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: 15b4511a ("drm/vc4: add HDMI CEC support") Signed-off-by:
-
- 24 Jan, 2023 2 commits
-
-
Javier Martinez Canillas authored
The DRM fbdev emulation layer sets the struct fb_info .fbdefio field to a struct fb_deferred_io pointer, that is shared across all drivers that use the generic drm_fbdev_generic_setup() helper function. It is a problem because the fbdev core deferred I/O logic assumes that the struct fb_deferred_io data is not shared between devices, and it's stored there state such as the list of pages touched and a mutex that is use to synchronize between the fb_deferred_io_track_page() function that track the dirty pages and fb_deferred_io_work() workqueue handler doing the actual deferred I/O. The latter can lead to the following error, since it may happen that two drivers are probed and then one is removed, which causes the mutex bo be destroyed and not existing anymore by the time the other driver tries to grab it for the fbdev deferred I/O logic: [ 369.756553] ------------[ cut here ]------------ [ 369.756604] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 369.756631] WARNING: CPU: 2 PID: 1023 at kernel/locking/mutex.c:582 __mutex_lock+0x348/0x424 [ 369.756744] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip v6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr btsdio bluetooth sunrpc brcmfmac snd_soc_hdmi_codec cpufreq_dt cfg80211 vfat fat vc4 rfkill brcmutil raspberrypi_cpufreq i2c_bcm2835 iproc_rng200 bcm2711_thermal snd_soc_core snd_pcm_dmaen gine leds_gpio nvmem_rmem joydev hid_cherry uas usb_storage gpio_raspberrypi_exp v3d snd_pcm raspberrypi_hwmon gpu_sched bcm2835_wdt broadcom bcm_phy_lib snd_timer genet snd mdio_bcm_unimac clk_bcm2711_dvp soundcore drm_display_helper pci e_brcmstb cec ip6_tables ip_tables fuse [ 369.757400] CPU: 2 PID: 1023 Comm: fbtest Not tainted 5.19.0-rc6+ #94 [ 369.757455] Hardware name: raspberrypi,4-model-b Raspberry Pi 4 Model B Rev 1.4/Raspberry Pi 4 Model B Rev 1.4, BIOS 2022.10 10/01/2022 [ 369.757538] pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 369.757596] pc : __mutex_lock+0x348/0x424 [ 369.757635] lr : __mutex_lock+0x348/0x424 [ 369.757672] sp : ffff80000953bb00 [ 369.757703] x29: ffff80000953bb00 x28: ffff17fdc087c000 x27: 0000000000000002 [ 369.757771] x26: ffff17fdc349f9b0 x25: fffffc5ff72e0100 x24: 0000000000000000 [ 369.757838] x23: 0000000000000000 x22: 0000000000000002 x21: ffffa618df636f10 [ 369.757903] x20: ffff80000953bb68 x19: ffffa618e0f18138 x18: 0000000000000001 [ 369.757968] x17: 0000000020000000 x16: 0000000000000002 x15: 0000000000000000 [ 369.758032] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 [ 369.758097] x11: 00000000ffffdfff x10: ffffa618e0c79f88 x9 : ffffa618de472484 [ 369.758162] x8 : 000000000002ffe8 x7 : c0000000ffffdfff x6 : 00000000000affa8 [ 369.758227] x5 : 0000000000001fff x4 : 0000000000000000 x3 : 0000000000000027 [ 369.758292] x2 : 0000000000000001 x1 : ffff17fdc087c000 x0 : 0000000000000028 [ 369.758357] Call trace: [ 369.758383] __mutex_lock+0x348/0x424 [ 369.758420] mutex_lock_nested+0x4c/0x5c [ 369.758459] fb_deferred_io_mkwrite+0x78/0x1d8 [ 369.758507] do_page_mkwrite+0x5c/0x19c [ 369.758550] wp_page_shared+0x70/0x1a0 [ 369.758590] do_wp_page+0x3d0/0x510 [ 369.758628] handle_pte_fault+0x1c0/0x1e0 [ 369.758670] __handle_mm_fault+0x250/0x380 [ 369.758712] handle_mm_fault+0x17c/0x3a4 [ 369.758753] do_page_fault+0x158/0x530 [ 369.758792] do_mem_abort+0x50/0xa0 [ 369.758831] el0_da+0x78/0x19c [ 369.758864] el0t_64_sync_handler+0xbc/0x150 [ 369.758904] el0t_64_sync+0x190/0x194 [ 369.758942] irq event stamp: 11395 [ 369.758973] hardirqs last enabled at (11395): [<ffffa618de472554>] __up_console_sem+0x74/0x80 [ 369.759042] hardirqs last disabled at (11394): [<ffffa618de47254c>] __up_console_sem+0x6c/0x80 [ 369.760554] softirqs last enabled at (11392): [<ffffa618de330a74>] __do_softirq+0x4c4/0x6b8 [ 369.762060] softirqs last disabled at (11383): [<ffffa618de3c9124>] __irq_exit_rcu+0x104/0x214 [ 369.763564] ---[ end trace 0000000000000000 ]--- Fixes: d536540f ("drm/fb-helper: Add generic fbdev emulation .fb_probe function") Signed-off-by:
-
Javier Martinez Canillas authored
The fb_deferred_io_init() can fail and return an errno code but currently there is no check for its return value. Fix that and propagate to errno to the caller in the case of a failure. Fixes: d536540f ("drm/fb-helper: Add generic fbdev emulation .fb_probe function") Signed-off-by:
-
- 19 Jan, 2023 2 commits
-
-
Nirmoy Das authored
drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. We call drm_vma_node_allow() once per-file everytime a user calls mmap_offset, but only call drm_vma_node_revoke once per-file on each mmap_offset. As the mmap_offset is reused by the client, the per-file vm_count may remain non-zero and the rbtree leaked. Call drm_vma_node_allow_once() instead to prevent that memory leak. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Fixes: 78655598 ("drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list") Reported-by:
Chuansheng Liu <chuansheng.liu@intel.com> Reported-by:
Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20230117175236.22317-2-nirmoy.das@intel.comSigned-off-by:
-
Nirmoy Das authored
Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Suggested-by:
Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
-
- 18 Jan, 2023 4 commits
-
-
Nirmoy Das authored
Removed unused i915 var. Fixes: a273e957 ("drm/i915: Allow switching away via vga-switcheroo if uninitialized") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Thomas Zimmermann authored
Set the framebuffer info for drivers that support VGA switcheroo. Only affects the amdgpu and nouveau drivers, which use VGA switcheroo and generic fbdev emulation. For other drivers, this does nothing. This fixes a potential regression in the console code. Both, amdgpu and nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev code. But the call got lost when the drivers switched to the generic emulation. Fixes: 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.") Fixes: 4a16dd9d ("drm/nouveau/kms: switch to drm fbdev helpers") Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Thomas Zimmermann authored
Always allow switching away via vga-switcheroo if the display is uninitalized. Instead prevent switching to i915 if the device has not been initialized. This issue was introduced by commit 5df7bd13 ("drm/i915: skip display initialization when there is no display") protected, which protects code paths from being executed on uninitialized devices. In the case of vga-switcheroo, we want to allow a switch away from i915's device. So run vga_switcheroo_process_delayed_switch() and test in the switcheroo callbacks if the i915 device is available. Fixes: 5df7bd13 ("drm/i915: skip display initialization when there is no display") Signed-off-by:
-
Arnd Bergmann authored
On ARMv5 and earlier, a randconfig build can still run into WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE Depends on [n]: IOMMU_SUPPORT [=y] && (ARM [=y] || ARM64 || COMPILE_TEST [=y]) && !GENERIC_ATOMIC64 [=y] Selected by [y]: - DRM_PANFROST [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARM [=y] || ARM64 || COMPILE_TEST [=y] && !GENERIC_ATOMIC64 [=y]) && MMU [=y] Rework the dependencies to always require a working cmpxchg64. Fixes: db594ba3 ("drm/panfrost: depend on !GENERIC_ATOMIC64 when using COMPILE_TEST") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
- 13 Jan, 2023 1 commit
-
-
Maxime Ripard authored
Commit 07a2975c ("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: 07a2975c ("drm/vc4: bo: Fix drmm_mutex_init memory hog") Reviewed-by:
Maíra Canal <mcanal@igalia.com> Signed-off-by:
-
- 12 Jan, 2023 3 commits
-
-
Maxime Ripard authored
Commit 374146ca ("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: 374146ca ("drm/vc4: Switch to drmm_mutex_init") Reviewed-by:
-
Arunpravin Paneer Selvam authored
We are observing performance drop in many usecases which include games, 3D benchmark applications,etc.. To solve this problem, We are strictly not allowing top down flag enabled allocations to steal the memory space from cpu visible region. The idea is, we are sorting each order list entries in ascending order and compare the last entry of each order list in the freelist and return the max block. This patch improves the 3D benchmark scores and solves fragmentation issues. All drm buddy selftests are verfied. drm_buddy: pass:6 fail:0 skip:0 total:6 Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Acked-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230112120027.3072-1-Arunpravin.PaneerSelvam@amd.comSigned-off-by:
-
Zack Rusin authored
The branch is explicitly taken if ttm == NULL which means that to avoid a null pointer reference the ttm object can not be used inside. Switch back to dst_mem to avoid kernel oops'es. This fixes kernel oops'es with any buffer objects which don't have ttm_tt, e.g. with vram based screen objects on vmwgfx. Signed-off-by:
-
- 11 Jan, 2023 1 commit
-
-
Thomas Zimmermann authored
Commit 4a16dd9d ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. The driver's internal implementation later got accidentally restored during a merge commit. Remove the file from the driver. No functional changes. v2: * point Fixes tag to merge commit (Alex) Signed-off-by:
-
- 10 Jan, 2023 2 commits
-
-
Christian König authored
This fixes a potential memory leak of dma_fence objects in the CS code as well as glitches in firefox because of missing pipeline sync. v2: use the scheduler instead of the fence context Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Acked-by:
-
Zack Rusin authored
User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. Fixes: e14c02e6 ("drm/vmwgfx: Look up objects without taking a reference") Signed-off-by:
-
- 09 Jan, 2023 1 commit
-
-
Rob Clark authored
Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Chia-I Wu <olvaffe@gmail.com> Fixes: 62fb7a5e ("virtio-gpu: add 3d/virgl support") Cc: stable@vger.kernel.org Signed-off-by:
-
- 06 Jan, 2023 1 commit
-
-
Patrick Thompson authored
Panel is 800x1280 but mounted on a detachable form factor sideways. Signed-off-by:
Patrick Thompson <ptf@google.com> Signed-off-by:
-
- 05 Jan, 2023 2 commits
-
-
Christian König authored
When the fence can't be added we need to drop the reference. Suggested-by:
Luben Tuikov <luben.tuikov@amd.com>
-
Christian König authored
drm_sched_job_add_dependency() consumes the references of the gang members. Only triggered by mesh shaders. Signed-off-by:
Mike Lothian <mike@fireburn.co.uk> Tested-by:
-
