On Fri, Jul 20, 2012 at 11:31 PM, InKi Dae daeinki@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