Implement LOCAL_DMA_BUF_SYNC_START/END ioctl in Rockchip driver |
||||||||
Issue descriptionThe implementation of this ioctl for the Rockchip driver is currently returning an error status and this is causing Chrome to spew error messages in the log (only when DCHECKs are on after https://codereview.chromium.org/2774583002 lands). Noop implementation is sufficient when mapping of DMA bufs return uncached memory but we should not return an error as that adds confusing log output to chrome.
,
Mar 25 2017
Yes, I meant rockchip. This is returning a value that results in log output each time we map/unmap a buffer. We know that mapping works as this is currently used for low-latency stylus updates so the problem is not a bad fd. The ioctl is not returning a value that results in logging on Intel devices.
,
Mar 26 2017
,
Mar 26 2017
,
Mar 28 2017
,
Mar 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a7215699b8815b4aa6ff6d069414054f44065dbe commit a7215699b8815b4aa6ff6d069414054f44065dbe Author: Marek Szyprowski <m.szyprowski@samsung.com> Date: Wed Mar 29 00:16:53 2017 UPSTREAM: dma-buf: add support for compat ioctl Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC ioctl from 32bit application on 64bit kernel. Data structures for both 32 and 64bit modes are same, so there is no need for additional translation layer. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Christian Knig <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1487683261-2655-1-git-send-email-m.szyprowski@samsung.com (cherry picked from commit 888022c0473d079bff9b47fb50434b1f20f8f37f) Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> BUG= chromium:705189 TEST=local testing with SYNC ioctl Change-Id: Id83676d8ac8291a29602bad5e7cf135df2a691b1 Reviewed-on: https://chromium-review.googlesource.com/461287 Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org> [modify] https://crrev.com/a7215699b8815b4aa6ff6d069414054f44065dbe/drivers/dma-buf/dma-buf.c
,
Mar 29 2017
,
May 30 2017
,
Aug 1 2017
,
Jan 22 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by gurcheta...@chromium.org
, Mar 25 2017You mean the rockchip driver? I'm assuming the local Chromium copy of the DMA_BUF_IOCTL_SYNC ioctl (the headers are only exposed >= 4.4) is correct. Quickly scanning the code (dma-buf.c), the ioctl is a no-op when the driver specific hoot not defined (the rockchip driver uses the default drm_gem_prime_dmabuf_ops): if (WARN_ON(!dmabuf)) return -EINVAL; if (dmabuf->ops->begin_cpu_access) ret = dmabuf->ops->begin_cpu_access(dmabuf, direction); I would check the dmesg if the kernel spews any error when this happens cause it may signal you don't have a valid fd. Anyways, I have a few patches in works that implement cached mappings when DMA_BUF_SYNC_READ is specified on rockchip, write combined otherwise, so I'll assign this to myself.