Forcing initial Frame Transmission for dmabuf encoding on SPICE display channel connection

Hello, I’ve encountered an issue with the new DMA-BUF -> video encoding feature in SPICE. When connecting, the first frame is only sent once the GPU renders a new frame. However, this can take quite some time if the VM is idle (e.g., sitting on the desktop), since the GPU only renders a new f

[PATCH 04/19] drm: Pass the format info to .fb_create()

From: Ville Syrjälä Pass long the format information from the top to .fb_create() so that we can avoid redundant (and somewhat expensive) lookups in the drivers. Done with cocci (with some manual fixups): @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuff

[PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

dma_fence_is_signaled()'s name strongly reads as if this function were intended for checking whether a fence is already signaled. Also the boolean it returns hints at that. The function's behavior, however, is more complex: it can check with a driver callback whether the hardware's sequence number

[PATCH 07/19] drm/gem: Pass along the format info from .fb_create() to drm_helper_mode_fill_fb_struct()

From: Ville Syrjälä Pass along the format info from .fb_create() to aliminate the redundant drm_get_format_info() calls from the gem fb code. Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Andy Yan Cc: Oleksandr Andrushchenko Cc: virtualizat...@lists.linux.dev Cc

[PATCH 2/2] dma-fence: Improve docu for dma_fence_check_and_signal()

The documentation of the return value of dma_fence_check_and_signal() and dma_fence_check_and_signal_locked() reads as if the returned boolean only describes whether dma_fence_signal() (or similar) has been called before this function call already. That's not the case, since dma_fence_ops.signaled(

Re: [PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

Hi Philipp, On Wed, 9 Apr 2025 14:06:37 +0200 Philipp Stanner wrote: > dma_fence_is_signaled()'s name strongly reads as if this function were > intended for checking whether a fence is already signaled. Also the > boolean it returns hints at that. > > The function's behavior, however, is more

Re: [PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote: > Am 09.04.25 um 16:01 schrieb Philipp Stanner: > > On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote: > > > Am 09.04.25 um 14:56 schrieb Philipp Stanner: > > > > On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote: > > > > > On

Re: [PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote: > Am 09.04.25 um 14:56 schrieb Philipp Stanner: > > On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote: > > > On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote: > > > > Hi Philipp, > > > > > > > > On Wed,  9 Apr 2025 14:06:37 +

[PATCH 0/2] dma-fence: Rename dma_fence_is_signaled()

Hi all, I'm currently debugging a Nouveau issue [1] and potentially might want to add a function that just checks whether a fence is signaled already – which then would obviously be called dma_fence_is_signaled(). In any case, I think it is reasonable to rename dma_fence_is_signaled() so that it

Re: [PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote: > On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote: > > Hi Philipp, > > > > On Wed,  9 Apr 2025 14:06:37 +0200 > > Philipp Stanner wrote: > > > > > dma_fence_is_signaled()'s name strongly reads as if this function > > > were > > >

Re: [PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

Am 09.04.25 um 17:04 schrieb Philipp Stanner: > On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote: >>> I only see improvement by making things more obvious. >>> >>> In any case, how would you call a wrapper that just does >>> test_bit(IS_SIGNALED, …) ? >> Broken, that was very intentionally

RE: [RFC] PCI: add CONFIG_MMU dependency

[Public] > -Original Message- > From: Arnd Bergmann > Sent: Monday, April 7, 2025 6:38 AM > To: Bjorn Helgaas > Cc: Arnd Bergmann ; Jeff Hugo > ; Carl Vanderlip ; Oded > Gabbay ; Takashi Sakamoto ; > Maarten Lankhorst ; Maxime Ripard > ; Thomas Zimmermann ; David > Airlie ; Simona Vetter

Re: [PATCH 2/2] dma-fence: Improve docu for dma_fence_check_and_signal()

[AMD Official Use Only - AMD Internal Distribution Only] Hi Philipp, I feel like the problem has two parts. The documentation does not make explicit that DMA_FENCE_FLAG_SIGNALED_BIT is "caching" the hardware state when a fence is backed by hardware, so what dma_fence_is_signaled here is doing i

Re: [PATCH] usbredirhost: fix null dereference

Hi Dmitry, Thanks for testing and sending this patch. One comment below. On Wed, Apr 9, 2025 at 12:07 AM Dmitry Frolov wrote: > In function usbredirhost_open_full(), when host->parser==NULL, > the call sequence: > "usbredirhost_close() ---> > usbredirhost_clear_device() ---> > usbre

Re: [PATCH 1/2] dma-fence: Rename dma_fence_is_signaled()

On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote: > Hi Philipp, > > On Wed,  9 Apr 2025 14:06:37 +0200 > Philipp Stanner wrote: > > > dma_fence_is_signaled()'s name strongly reads as if this function > > were > > intended for checking whether a fence is already signaled. Also the > > boo

Re: [PATCH 07/19] drm/gem: Pass along the format info from .fb_create() to drm_helper_mode_fill_fb_struct()

Hi Ville, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.15-rc1 next-20250410] [cannot apply to drm-exynos/exynos-drm-next tegra/for-next rmk-arm/drm-armada-devel rmk-arm/drm-armada-fixes] [If your patch is