New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 705189 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Mar 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Implement LOCAL_DMA_BUF_SYNC_START/END ioctl in Rockchip driver

Project Member Reported by reve...@chromium.org, Mar 25 2017

Issue description

The 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.
 
Owner: gurcheta...@chromium.org
You 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.
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.
Summary: Implement LOCAL_DMA_BUF_SYNC_START/END ioctl in Rockchip driver (was: Implement LOCAL_DMA_BUF_SYNC_START/END ioctl in Mali driver)
Description: Show this description
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 29 2017

Labels: merge-merged-chromeos-4.4
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

Status: Fixed (was: Available)

Comment 8 by dchan@google.com, May 30 2017

Labels: VerifyIn-60

Comment 9 by dchan@chromium.org, Aug 1 2017

Labels: VerifyIn-61

Comment 10 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment