On Fri, Jul 20, 2012 at 11:31 PM, InKi Dae <daeinki@xxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
