[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57236AB9.5070508@ti.com>
Date: Fri, 29 Apr 2016 17:07:53 +0300
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Noralf Trønnes <noralf@...nnes.org>,
<dri-devel@...ts.freedesktop.org>, <linux-fbdev@...r.kernel.org>
CC: <daniel@...ll.ch>, <laurent.pinchart@...asonboard.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 4/7] fbdev: fb_defio: Export fb_deferred_io_mmap
On 28/04/16 18:18, Noralf Trønnes wrote:
> Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
> When the framebuffer memory is allocated using dma_alloc_writecombine()
> instead of vmalloc(), I get cache syncing problems on ARM.
> This solves it:
>
> static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> struct vm_area_struct *vma)
> {
> fb_deferred_io_mmap(info, vma);
> vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
>
> return 0;
> }
>
> Could this have been done in the core?
> Drivers that don't set (struct fb_ops *)->fb_mmap, gets a call to
> fb_pgprotect() at the end of the default fb_mmap implementation
> (drivers/video/fbdev/core/fbmem.c). This is an architecture specific
> function that on many platforms uses pgprot_writecombine(), but not on
> all. And looking at some of the fb_mmap implementations, some of them
> sets vm_page_prot to nocache for instance, so I think the safest bet is
> to do this in the driver and not in the fbdev core. And we can't call
> fb_pgprotect() from fb_deferred_io_mmap() either because we don't have
> access to the file pointer that powerpc needs.
>
> Signed-off-by: Noralf Trønnes <noralf@...nnes.org>
Acked-by: Tomi Valkeinen <tomi.valkeinen@...com>
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists