Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties

Hi Maxime, Thank you for the patch. On Thu, May 20, 2021 at 04:24:35PM +0200, Maxime Ripard wrote: > New KMS properties come with a bunch of requirements to avoid each > driver from running their own, inconsistent, set of properties, > eventually leading to issues like property conflicts,

Re: i915 gvt broke drm-tip; Fix ASAP

On 2021.05.22 21:19:38 +0200, Thomas Zimmermann wrote: > Hi, > > after creating drm-tip today as part of [1], building drm-tip is now broken > with the error message shown below. > > Some register constants appear to be missing from the GVT code. Please fix > ASAP. > Thanks, Thomas. Looks DMC

dma-resv ongoing discussion

I'd like to try and summarise where I feel we are all at with respect to the dma-buf discussions. I think I've gotten a fairly good idea of how things stand but I'm not sure we are really getting to the how to move things forward stage, where is probably when I need to step in. Thanks for keeping

Re: EPOLL for drm_syncfile (was Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6))

Hi Christian, On Sun, 23 May 2021 at 18:16, Christian König wrote: > Am 22.05.21 um 22:05 schrieb Daniel Stone: > > Anyway, the problem with syncobj is that the ioctl to wait for a > > sync_file to materialise for a given timeline point only allows us to > > block with a timeout; this is a

Re: [PATCH v5 0/3] Add option to mmap GEM buffers cached

Hi Thomas, Le dim., mai 23 2021 at 21:05:30 +0200, Thomas Zimmermann a écrit : Hi Am 23.05.21 um 19:04 schrieb Paul Cercueil: V5 of my patchset which adds the option for having GEM buffers backed by non-coherent memory. Changes from V4: - [2/3]: - Rename to

Re: [PATCH v5 0/3] Add option to mmap GEM buffers cached

Hi Am 23.05.21 um 19:04 schrieb Paul Cercueil: V5 of my patchset which adds the option for having GEM buffers backed by non-coherent memory. Changes from V4: - [2/3]: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the

Re: [PATCH v5 2/3] drm: Add and export function drm_fb_cma_sync_non_coherent

Hi Paul, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.13-rc2 next-20210521] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in

[PATCH v2] drm/i915/gem: Use list_entry to access list members

Use list_entry() instead of container_of() to access list members. Also drop unnecessary and misleading NULL checks on the result of list_entry(). Signed-off-by: Guenter Roeck --- v2: Checkpatch fixes: - Fix alignment - Replace comparison against NULL with !

EPOLL for drm_syncfile (was Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6))

Hi guys, separating that discussion out since Daniel had a rather interesting idea here. Am 22.05.21 um 22:05 schrieb Daniel Stone: [SNIP] Anyway, the problem with syncobj is that the ioctl to wait for a sync_file to materialise for a given timeline point only allows us to block with a

[PATCH v5 2/3] drm: Add and export function drm_fb_cma_sync_non_coherent

This function can be used by drivers that use damage clips and have CMA GEM objects backed by non-coherent memory. Calling this function in a plane's .atomic_update ensures that all the data in the backing memory have been written to RAM. v3: - Only sync data if using GEM objects backed by

[PATCH v5 3/3] drm/ingenic: Add option to alloc cached GEM buffers

Alloc GEM buffers backed by noncoherent memory on SoCs where it is actually faster than write-combine. This dramatically speeds up software rendering on these SoCs, even for tasks where write-combine memory should in theory be faster (e.g. simple blits). v3: The option is now selected per-SoC

[PATCH v5 1/3] drm: Add support for GEM buffers backed by non-coherent memory

Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on

[PATCH v5 0/3] Add option to mmap GEM buffers cached

V5 of my patchset which adds the option for having GEM buffers backed by non-coherent memory. Changes from V4: - [2/3]: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Properly sort includes

Re: [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default

On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel >

Re: [PATCH RESEND] drm/hisilicon/kirin: Use the correct HiSilicon copyright

Hi Am 22.05.21 um 12:15 schrieb Hao Fang: s/Hisilicon/HiSilicon/. It should use capital S, according to https://www.hisilicon.com/en. Signed-off-by: Hao Fang Acked-by: Tian Tao It's been acked already. Tian can merge it for you. Best regards Thomas ---

[PATCH RESEND] drm/hisilicon/kirin: Use the correct HiSilicon copyright

s/Hisilicon/HiSilicon/. It should use capital S, according to https://www.hisilicon.com/en. Signed-off-by: Hao Fang Acked-by: Tian Tao --- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 2 +- drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h| 2 +-