[PATCH 3/3] drm/exynos: implement kmap/kunmap/kmap_atomic/kunmap_atomic functions of dma_buf_ops

[Rob Clark]

On Fri, Jul 20, 2012 at 11:31 PM, InKi Dae <daeinki at gmail.com> wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> index 913a23e..805b344 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> @@ -138,30 +138,35 @@ static void exynos_dmabuf_release(struct dma_buf
>> *dmabuf)
>>  static void *exynos_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
>>                                               unsigned long page_num)
>>  {
>> -     /* TODO */
>> +     struct exynos_drm_gem_obj *exynos_gem_obj = dma_buf->priv;
>> +     struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
>>
>> -     return NULL;
>
> kmap is used for cpu access so you should consider cache operation (dev to cpu).

might be worth to have a look at what I did in omapdrm w/
omap_gem_{cpu,dma}_sync()..  that is hooked in to the mmap handling
too, to deal w/ access to mmap'd cached buffers from userspace.
Although it is relying on the obj->filp (non-private object's shmem
file) to make the unmap-mapping-range stuff work properly for PTE
shootdown, but that should be fine assuming any cached gem obj is not
a 'private' gem obj.  Have a look at commit 8b6b569.

BR,
-R