Message-ID: <CA+M3ks4KiHnCXWg4j3sd1dAm2b931QiiwEKTggioP=riq3C9xg@mail.gmail.com>
Date:	Fri, 19 Jun 2015 22:24:56 +0200
From:	Benjamin Gaignard <benjamin.gaignard@...aro.org>
To:	Daniel Thompson <daniel.thompson@...aro.org>,
	David Airlie <airlied@...ux.ie>,
	Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Benjamin Gaignard <benjamin.gaignard@...aro.org>,
	Damien Hobson-Garcia <dhobsong@...l.co.jp>
Subject: Re: [RESEND PATCH v2 v4.1-rc8 0/2] drm: prime: Allow exported
 dma-bufs to be mapped

I'm far of being an expert in cache coherency but, from past experiences,
I have notice that ION cache management give good performances and is
simple to understand.

ION mark as "dirty" the mapped pages in wm_fault function and check this
flag while mapping the buffer in kernel space.
If the flag is set it call dma_sync_sg_for_device() with the good direction.

ION allow with an iotcl to do explicit or implicit cache management but, for
me, it add complexity to the code when implicit mode should be the
preferred one.

Benjamin


2015-06-19 17:48 GMT+02:00 Daniel Vetter <daniel@...ll.ch>:
> On Fri, Jun 19, 2015 at 02:52:27PM +0100, Daniel Thompson wrote:
>> This patch set started out as a single patch with a trivial bit of
>> boilerplate to add dmabuf mmap support to the msm driver. However Rob
>> Clark pointed out that, rather than keep one of the tricks I had used, it
>> would be better to change the helpers resulting in this series.
>>
>> I've tested this both with a rather hacked about Android userspace
>> and with a fairly small test case run from debian. Both bits of code
>> currently use dumb buffers.
>>
>> Thanks to Benjamin Gaignard for his help in finding this bit of code and
>> to Damien Hobson-Garcia for pointing out that I'd forgotten (since 3.18)
>> to RESEND these patches.
>>
>> Dave: I guess its probably too late in the dev. cycle to take this code
>>       but don't worry, I will try really hard to remember to RESEND it
>>       for 4.2. ;-)
>>
>> v2:
>>
>> * Modified DRM_PRIME_HANDLE_TO_FD to honour the O_RDRW from the user
>>   and removed code to workaround this from the sti driver (Rob Clark).
>>
>> * Added a patch to (rather spartanly) document gem_prime_mmap. Only
>>   tacked into this series 'cos I spotted it was missing when I was
>>   checking whether I needed to describe DRM_RDRW anywhere.
>
> Oh hornets nest since I just screamed around again against drm prime mmap
> support ;-) Imo before we expose this for real we really need to somehow
> figure out what to do about cache coherency. Some intel folks are looking
> into adding suitable ioctls to the dma-buf fd to make this possible. I
> think we should wait with enabling drm prime mmaping before that's
> resolved somehow. I'll point them at your patches though to make sure they
> don't reinvent this wheel here.
> -Daniel
>
>>
>>
>> Daniel Thompson (2):
>>   drm: prime: Honour O_RDWR during prime-handle-to-fd
>>   drm: prime: Document gem_prime_mmap
>>
>>  drivers/gpu/drm/drm_prime.c | 13 ++++++-------
>>  include/uapi/drm/drm.h      |  1 +
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> --
>> 2.4.3
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@...ts.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists