Re: [PATCH v15 6/7] ext4: disable map_sync for async flush

2019-07-07 Thread Theodore Ts'o
On Fri, Jul 05, 2019 at 07:33:27PM +0530, Pankaj Gupta wrote: > Dont support 'MAP_SYNC' with non-DAX files and DAX files > with asynchronous dax_device. Virtio pmem provides > asynchronous host page cache flush mechanism. We don't > support 'MAP_SYNC' with virtio pmem and ext4. > > Signed-off-by:

Re: [PATCH v2 3/6] drm/fb-helper: Instanciate shadow FB if configured in device's mode_config

2019-07-07 Thread Noralf Trønnes
Den 05.07.2019 11.26, skrev Thomas Zimmermann: > Generic framebuffer emulation uses a shadow buffer for framebuffers with > dirty() function. If drivers want to use the shadow FB without such a > function, they can now set prefer_shadow or prefer_shadow_fbdev in their > mode_config structures.

Re: [PATCH v2 3/6] drm/fb-helper: Instanciate shadow FB if configured in device's mode_config

2019-07-07 Thread Thomas Zimmermann
Hi Am 07.07.19 um 16:37 schrieb Noralf Trønnes: > > > Den 05.07.2019 11.26, skrev Thomas Zimmermann: >> Generic framebuffer emulation uses a shadow buffer for framebuffers with >> dirty() function. If drivers want to use the shadow FB without such a >> function, they can now set prefer_shadow

Re: [PATCH v2 1/6] drm/client: Support unmapping of DRM client buffers

2019-07-07 Thread Noralf Trønnes
Den 05.07.2019 11.26, skrev Thomas Zimmermann: > DRM clients, such as the fbdev emulation, have their buffer objects > mapped by default. Mapping a buffer implicitly prevents its relocation. > Hence, the buffer may permanently consume video memory while it's > allocated. This is a problem for

Re: [PATCH v2 2/6] drm/fb-helper: Map DRM client buffer only when required

2019-07-07 Thread Noralf Trønnes
Den 05.07.2019 11.26, skrev Thomas Zimmermann: > This patch changes DRM clients to not map the buffer by default. The > buffer, like any buffer object, should be mapped and unmapped when > needed. > > An unmapped buffer object can be evicted to system memory and does > not consume video ram