- 23 Feb, 2021 5 commits
-
-
Daniel Vetter authored
One of these drivers that predates the nonblocking support in helpers, and hand-rolled its own thing. Entirely not anything specific here, we can just delete it all and replace it with the helper version. Could also perhaps use the drm_mode_config_helper_suspend/resume stuff, for another few lines deleted. But I'm not looking at that stuff, I'm just going through all the atomic commit functions and make sure they have properly annotated dma-fence critical sections everywhere. v2: - Also delete the workqueue (Sam) - drop the @commit kerneldoc, I missed that one. Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20210121152959.1725404-7-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Nothing special, just put the end right after hw_done(). Note that in one path there's a wait for the flip/update to complete. But as far as I understand from comments and code that's only relevant for modesets, and skipped if there wasn't a modeset done on a given crtc. For a bit more clarity pull the hw_done() call out of the if/else, that way it's a bit clearer flow. But happy to shuffle this around as is seen fit. Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Daniel Vetter authored
Again ends just after drm_atomic_helper_commit_hw_done(), but with the twist that we need to make sure we're only annotate the custom version. And not the other clause which just calls drm_atomic_helper_commit_tail_rpm(), which is already annotated. Signed-off-by:
Thierry Reding <treding@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210121152959.1725404-11-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Ends right after hw_done(), totally standard case. Acked-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Thomas Zimmermann authored
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting, but currently located next to framebuffer helpers. Move it to GEM atomic helpers, rename it slightly and adopt the drivers. Same for the rsp simple-pipe helper. Compile-tested with x86-64, aarch64 and arm. The patch is fairly large, but there are no functional changes. v3: * remove out-comented line in drm_gem_framebuffer_helper.h (Maxime) v2: * rename to drm_gem_plane_helper_prepare_fb() (Daniel) * add tutorial-style documentation Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210222141756.7864-1-tzimmermann@suse.de
-
- 22 Feb, 2021 3 commits
-
-
Tong Zhang authored
a connector is leaked upon module unload, it seems that we should do similar to sample driver as suggested in drm_drv.c. Adding drm_atomic_helper_shutdown() in ast_pci_remove to prevent leaking. [ 153.822134] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cle0 [ 153.822698] Modules linked in: ast(-) drm_vram_helper drm_ttm_helper ttm [last unloaded: ttm] [ 153.823197] CPU: 0 PID: 173 Comm: modprobe Tainted: G W 5.11.0-03615-g55f62bc873474 [ 153.823708] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [ 153.824333] RIP: 0010:drm_mode_config_cleanup+0x418/0x470 [ 153.824637] Code: 0c 00 00 00 00 48 8b 84 24 a8 00 00 00 65 48 33 04 25 28 00 00 00 75 65 48 81 c0 [ 153.825668] RSP: 0018:ffff888103c9fb70 EFLAGS: 00010212 [ 153.825962] RAX: ffff888102b0d100 RBX: ffff888102b0c298 RCX: ffffffff818d8b2b [ 153.826356] RDX: dffffc0000000000 RSI: 000000007fffffff RDI: ffff888102b0c298 [ 153.826748] RBP: ffff888103c9fba0 R08: 0000000000000001 R09: ffffed1020561857 [ 153.827146] R10: ffff888102b0c2b7 R11: ffffed1020561856 R12: ffff888102b0c000 [ 153.827538] R13: ffff888102b0c2d8 R14: ffff888102b0c2d8 R15: 1ffff11020793f70 [ 153.827935] FS: 00007f24bff456a0(0000) GS:ffff88815b400000(0000) knlGS:0000000000000000 [ 153.828380] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 153.828697] CR2: 0000000001c39018 CR3: 0000000103c90000 CR4: 00000000000006f0 [ 153.829096] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 153.829486] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 153.829883] Call Trace: [ 153.830024] ? drmm_mode_config_init+0x930/0x930 [ 153.830281] ? cpumask_next+0x16/0x20 [ 153.830488] ? mnt_get_count+0x66/0x80 [ 153.830699] ? drm_mode_config_cleanup+0x470/0x470 [ 153.830972] drm_managed_release+0xed/0x1c0 [ 153.831208] drm_dev_release+0x3a/0x50 [ 153.831420] release_nodes+0x39e/0x410 [ 153.831631] ? devres_release+0x40/0x40 [ 153.831852] device_release_driver_internal+0x158/0x270 [ 153.832143] driver_detach+0x76/0xe0 [ 153.832344] bus_remove_driver+0x7e/0x100 [ 153.832568] pci_unregister_driver+0x28/0xf0 [ 153.832821] __x64_sys_delete_module+0x268/0x300 [ 153.833086] ? __ia32_sys_delete_module+0x300/0x300 [ 153.833357] ? call_rcu+0x372/0x4f0 [ 153.833553] ? fpregs_assert_state_consistent+0x4d/0x60 [ 153.833840] ? exit_to_user_mode_prepare+0x2f/0x130 [ 153.834118] do_syscall_64+0x33/0x40 [ 153.834317] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 153.834597] RIP: 0033:0x7f24bfec7cf7 [ 153.834797] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41 [ 153.835812] RSP: 002b:00007fff72e6cb58 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0 [ 153.836234] RAX: ffffffffffffffda RBX: 00007f24bff45690 RCX: 00007f24bfec7cf7 [ 153.836623] RDX: 00000000ffffffff RSI: 0000000000000080 RDI: 0000000001c2fb10 [ 153.837018] RBP: 0000000001c2fac0 R08: 2f2f2f2f2f2f2f2f R09: 0000000001c2fac0 [ 153.837408] R10: fefefefefefefeff R11: 0000000000000202 R12: 0000000001c2fac0 [ 153.837798] R13: 0000000001c2f9d0 R14: 0000000000000000 R15: 0000000000000001 [ 153.838194] ---[ end trace b92031513bbe596c ]--- [ 153.838441] [drm:drm_mode_config_cleanup] *ERROR* connector VGA-1 leaked! Signed-off-by:
Tong Zhang <ztong0001@gmail.com> Signed-off-by:
-
Kai-Heng Feng authored
We are seeing root ports on some desktop boards support D3cold for discrete graphics card. So when efifb is in use while graphics device isn't bound to a driver, PCI and ACPI will put the graphics to D3cold when runtime suspend kicks in, makes efifb stop working. So ensure the graphics device won't be runtime suspended, to keep efifb work all the time. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Tian Tao authored
Address the following checkpatch errors: ERROR: do not initialise statics to false Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Acked-by:
-
- 19 Feb, 2021 11 commits
-
-
Gerd Hoffmann authored
Try avoid re-introducing locking bugs. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
-
Gerd Hoffmann authored
Add helper functions to create and move the cursor. Create the cursor_bo in prepare_fb callback, in the atomic_commit callback we only send the update command to the host. Signed-off-by:
-
Gerd Hoffmann authored
Pure code motion, no functional change. Signed-off-by:
-
Gerd Hoffmann authored
Use the correct vmap variant. We don't hold a reservation here, so we can't use the _locked variant. We can drop the pin because qxl_bo_vmap will do that for us. Signed-off-by:
-
Gerd Hoffmann authored
Use the correct vmap variant. We don't have a reservation here, so we can't use the _locked version. Signed-off-by:
-
Gerd Hoffmann authored
Add vmap/vunmap variants which reserve (and pin) the bo. They can be used in case the caller doesn't hold a reservation for the bo. Signed-off-by:
-
Gerd Hoffmann authored
Append _locked to Make clear that these functions should be called with reserved bo's only. While being at it also rename kmap -> vmap. No functional change. Signed-off-by:
-
Gerd Hoffmann authored
Call qxl_bo_unpin (which does a reservation) without holding the release_mutex lock. Fixes lockdep (correctly) warning on a possible deadlock. Fixes: 65ffea3c ("drm/qxl: unpin release objects") Signed-off-by:
-
Gerd Hoffmann authored
Allow to set priorities for buffer objects. Use priority 1 for surface and cursor command releases. Use priority 0 for drawing command releases. That way the short-living drawing commands are first in line when it comes to eviction, making it *much* less likely that ttm_bo_mem_force_space() picks something which can't be evicted and throws an error after waiting a while without success. Signed-off-by:
-
Gerd Hoffmann authored
Move qxl_io_notify_oom() call into wait condition. That way the driver will call it again if one call wasn't enough. Also allows to remove the extra dma_fence_is_signaled() check and the goto. Fixes: 5a838e5d ("drm/qxl: simplify qxl_fence_wait") Signed-off-by:
-
Gerd Hoffmann authored
Specifically do not try release resources which where not allocated in the first place. Cc: Tong Zhang <ztong0001@gmail.com> Tested-by:
-
- 18 Feb, 2021 6 commits
-
-
Dario Binacchi authored
The fdd property of the tilcdc_panel_info structure must set the reqdly bit field (bit 12 to 19) of the raster control register. The previous statement set the least significant bit instead. Signed-off-by:
Dario Binacchi <dariobin@libero.it> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi> Tested-by:
-
Tian Tao authored
The code has been in a irq-disabled context since it is hard IRQ. There is no necessity to do it again. Signed-off-by:
-
Imre Deak authored
It's possible to modeset a connector/mst port that has a 0 full_pbn value: if the sink on the port deasserts its HPD and a branch device reports this via a CSN with the port's ddps=0 and pdt!=NONE the driver clears full_pbn, but the corresponding connector can be still modesetted. This happened on a DELL U2719D monitor as the branch device and an LG 27UL650-W daisy-chained to it, the LG monitor generating a long HPD pulse (doing this for some reason always when waking up from some power saving state). Tune down the WARN about this scenario to a debug message. v2: Use the correct atomic debug message level. (Lyude) References: https://gitlab.freedesktop.org/drm/intel/-/issues/1917 Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210216123448.410545-1-imre.deak@intel.com
-
Sebastian Andrzej Siewior authored
The driver uses in_atomic() to distinguish between mdelay() and msleep(). The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. I traced the usage of in_interrupt() back to its initial merge: bfe694f8 ("[ARM] Add ARM AMBA CLCD framebuffer driver.") https://git.kernel.org/history/history/c/bfe694f833643 The driver has been removed and added back in the meantime. I've been looking for the IRQ context as described in the comment and couldn't find it. The functions calling clcdfb_sleep() also call conditionally backlight_update_status() which acquires a mutex. If it is okay to acquire a mutex then it is okay to use msleep() since both functions must be used in preemptible context. Replace clcdfb_sleep() with msleep(). Cc: Peter Collingbourne <pcc@google.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210208223810.388502-4-bigeasy@linutronix.de
-
Ahmed S. Darwish authored
dsi_sync_vc() uses in_interrupt() to create a warning if the function is used in non-preemptible context. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. The wait_for_completion() function (used in dsi_sync_vc_vp() and dsi_sync_vc_l4() has already a check if it is invoked from proper context. Remove WARN_ON(in_interrupt()) from the driver. Cc: linux-omap@vger.kernel.org Signed-off-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
-
Ahmed S. Darwish authored
alloc_req() uses in_interrupt() to detect if it is safe to use down(). The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. The semaphore is used as a counting semaphore, initialized with the number of slots in the request pool minus IRQ_REQ_POOL_SIZE - which are reserved for the in_interrupt() user to ensure that a request is always available. The preemptible user will block on the semphore waiting for a request to become available in case there are no requests available. Replace in_interrupt() with a `can_sleep' argument to indicate if it is safe to block on the sempahore. Cc: linux-omap@vger.kernel.org Signed-off-by:
-
- 17 Feb, 2021 13 commits
-
-
Sakari Ailus authored
Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a large number of temporary variables at the same time. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Sakari Ailus authored
Now that we can print FourCC codes directly using printk, make use of the feature in V4L2 core. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by:
-
Sakari Ailus authored
Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM pixel formats denoted by fourccs. The fourcc encoding is the same for both so the same implementation can be used. Suggested-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
-
Thomas Zimmermann authored
We used to update the cursor image in prepare_fb. Move all this code to atomic_update (where it belongs). The generic helper for shadow-buffered planes now implement the cursor plane's prepare_fb. Signed-off-by:
-
Thomas Zimmermann authored
As HW cursor BOs never move, we can store the offset in VRAM in the cursor-plane's HWC state. This removes the last possible source of runtime errors from atomic_update. Signed-off-by:
-
Thomas Zimmermann authored
The BOs of the hardware cursor are now mapped permanently while the cursor plane is being used. This reduces the CPU overhead of the cursor plane's atomic_update function. The change also resolves a problem with the vmap call in the commit tail. The vmap implementation could acquire the DMA reservation lock on the BO, which is not allowed that late in the atomic update. Removing the vmap call from atomic_update fixes the issue. Signed-off-by:
-
Thomas Zimmermann authored
The cursor uses two BOs in video RAM to implement double buffering. Store both in struct ast_cursor_plane. Signed-off-by:
-
Thomas Zimmermann authored
Cursor state is currently located throughout struct ast_private. Having struct ast_cursor_plane as dedicated data structure for cursors helps to organize the modesetting code. Signed-off-by:
-
Thomas Zimmermann authored
The logic for cursor updates is now located in the cursor plane's modesetting code. A number of helper functions remain to modify the rsp registers and image. Signed-off-by:
-
Thomas Zimmermann authored
The BOs are eventually released by the cursor plane's destroy callback. Signed-off-by:
-
Thomas Zimmermann authored
This change will help with inlining cursor functions into modesetting code. The primary plane's field used to be cleared with memset(). This has been dropped as the memory is always allocated with kzalloc(). Signed-off-by:
-
Thomas Zimmermann authored
Use AST_MAX_HWC_HEIGHT for setting offset_y in the cursor plane's atomic_check. The code used AST_MAX_HWC_WIDTH instead. This worked because both constants has the same value. Signed-off-by:
-
Thomas Zimmermann authored
Set the bits in VGACRCB with constants. Alo move the rsp code into a helper function. Signed-off-by:
-
- 15 Feb, 2021 2 commits
-
-
Marek Vasut authored
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no matter what polarity the next bridge or display might require, these flags are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and DISPLAY_FLAGS_DE_HIGH were always set. The fix for this problem is taken almost verbatim from MXSFB driver. In case there is a bridge attached to the LTDC, the bridge might have extra polarity requirements, so extract bus_flags from the bridge and use them for LTDC configuration. Otherwise, extract bus_flags from the connector, which is the display. Fixes: b759012c ("drm/stm: Add STM32 LTDC driver") Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Antonio Borneo <antonio.borneo@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: dri-devel@lists.freedesktop.org Tested-by:
Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-marex@denx.de
-
Boris Brezillon authored
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay in the threaded irq handler as long as we can. v2: * Rework the loop to avoid a goto Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-4-boris.brezillon@collabora.com
-
