From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E8EDC43381 for ; Fri, 1 Mar 2019 08:55:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EF27F2087E for ; Fri, 1 Mar 2019 08:55:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jnpa0c1T"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="EgI6t+UO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF27F2087E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VpIP+LUpk9EG8DuGz+4HsFG619Z55UTJ/B0fU3BgTD8=; b=jnpa0c1Tvc7nT3 fIRtms/jJC34Joba0Rc0gxEHtWasP/nuVhdlCUvXuGSM3D9rJQ2zUtfJhCY7cvGd9Bn3GwL1aSoh/ QGy5Faa5jNZ5gmlHAGFwBcpdwnvuBMoCupbZoIOStSiIc6Q932ByRjQUqYIBJ9bLzCyVVkBY2mKHm 7fRtWdmBV69jC4V3V1EK5aeYlNIcci++xUO+wOEBAG6sb8ns9hPeLyFNvwTzHvD9fEVRicMpR0hNo CXkolWalyK9Rerk1uzXwS0ATp7bsyxzS8b457DB5YArSJ84Zl7Z14twIfY/dPHhWWsmSGvpDW0EtF C9T/SLOxYmW29xEaphBQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzdwu-0008Uy-42; Fri, 01 Mar 2019 08:55:20 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzdwl-0008UY-8h for linux-arm-kernel@lists.infradead.org; Fri, 01 Mar 2019 08:55:17 +0000 Received: by mail-ed1-x541.google.com with SMTP id b20so19319647edw.11 for ; Fri, 01 Mar 2019 00:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=6JSj88hu2XntZH+r/9g9XYQars3muYppbN70BI4AiSM=; b=EgI6t+UOodnsmhx5WYqEuMC1u7kkC44U30Dcdzcj24sqj0zU2mEjjjo6AjYaGVM73V XsiqV3F7zVOZXRO93ZrJizFLf08JssaxOB+hFoUSc0+xgSnPete42XEvWw1uPoBd0dN/ TjUtGX27SFyfaL2R3rgR2HZTUPeHRGnCRAmz4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=6JSj88hu2XntZH+r/9g9XYQars3muYppbN70BI4AiSM=; b=p8lOksc99L0jEbAGUsEiC/WTtML0DVu8NYJfA8YO2XtwGT9VfRD6kDQnLlf07ManEy ABlZC/yPWvT4jJDbQLsNWA3+J9tXpgStyQUpRdwi9JTFynpMy+jHxb6wkjpZ26xSD1Si ZK9iJmmj0mmDmpYW0xA1csnVd5AJ3e1D+bvf46YcVd7h6OaHSO709u13aPM0f/lIgT9y +cY0yrT3soZC0VwX0rbn0jt5d65dFQKa0HX7XlyzOdXHvtvNOBfyc0JSbFRAj/qDg7Ky serPnBd/VQ3qMH5uU0Gy1zOu4cJV9/Z+OrE0rN2zF2JHxQOmrNmhN1LnN6SYG8Vs+Ye0 aPFg== X-Gm-Message-State: APjAAAU66q2iaM+gVLcDTgCdZ7RvjlAVtCaZki19R2RBi1RKHHxnC2fG vbpaCojkZgpmHoNVC1V7mHvuBQ== X-Google-Smtp-Source: APXvYqwpKe4onHsyeu8lzM1whULTPhJ0l7teuN5TnDSTMEdUeUexIv2Rcp0Ei7uUDUwWyl0mpxNFPg== X-Received: by 2002:a50:b4e6:: with SMTP id x35mr3248822edd.123.1551430507212; Fri, 01 Mar 2019 00:55:07 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id a58sm5810068eda.91.2019.03.01.00.55.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Mar 2019 00:55:05 -0800 (PST) Date: Fri, 1 Mar 2019 09:55:03 +0100 From: Daniel Vetter To: Hyun Kwon Subject: Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls Message-ID: <20190301085503.GV2665@phenom.ffwll.local> Mail-Followup-To: Hyun Kwon , Hyun Kwon , Greg Kroah-Hartman , Stefano Stabellini , Sonal Santan , Cyril Chemparathy , Jiaying Liang , dri-devel , Linux Kernel Mailing List , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Michal Simek , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" References: <1550953697-7288-1-git-send-email-hyun.kwon@xilinx.com> <1550953697-7288-2-git-send-email-hyun.kwon@xilinx.com> <20190226115311.GA4094@kroah.com> <20190226221817.GB10631@smtp.xilinx.com> <20190228003606.GA1063@smtp.xilinx.com> <20190228100146.GK2665@phenom.ffwll.local> <20190301001856.GA20971@smtp.xilinx.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190301001856.GA20971@smtp.xilinx.com> X-Operating-System: Linux phenom 4.19.0-1-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190301_005511_310666_45D9C7E4 X-CRM114-Status: GOOD ( 42.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Hyun Kwon , Sonal Santan , Greg Kroah-Hartman , Cyril Chemparathy , Jiaying Liang , dri-devel , Linux Kernel Mailing List , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Michal Simek , Daniel Vetter , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 28, 2019 at 04:18:57PM -0800, Hyun Kwon wrote: > Hi Daniel, > > On Thu, 2019-02-28 at 02:01:46 -0800, Daniel Vetter wrote: > > On Wed, Feb 27, 2019 at 04:36:06PM -0800, Hyun Kwon wrote: > > > Hi Daniel, > > > > > > On Wed, 2019-02-27 at 06:13:45 -0800, Daniel Vetter wrote: > > > > On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon wrote: > > > > > > > > > > Hi Daniel, > > > > > > > > > > Thanks for the comment. > > > > > > > > > > On Tue, 2019-02-26 at 04:06:13 -0800, Daniel Vetter wrote: > > > > > > On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote: > > > > > > > > Add the dmabuf map / unmap interfaces. This allows the user driver > > > > > > > > to be able to import the external dmabuf and use it from user space. > > > > > > > > > > > > > > > > Signed-off-by: Hyun Kwon > > > > > > > > --- > > > > > > > > drivers/uio/Makefile | 2 +- > > > > > > > > drivers/uio/uio.c | 43 +++++++++ > > > > > > > > drivers/uio/uio_dmabuf.c | 210 +++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > drivers/uio/uio_dmabuf.h | 26 ++++++ > > > > > > > > include/uapi/linux/uio/uio.h | 33 +++++++ > > > > > > > > 5 files changed, 313 insertions(+), 1 deletion(-) > > > > > > > > create mode 100644 drivers/uio/uio_dmabuf.c > > > > > > > > create mode 100644 drivers/uio/uio_dmabuf.h > > > > > > > > create mode 100644 include/uapi/linux/uio/uio.h > > > > > > > > > > > > > > > > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile > > > > > > > > index c285dd2..5da16c7 100644 > > > > > > > > --- a/drivers/uio/Makefile > > > > > > > > +++ b/drivers/uio/Makefile > > > > > > > > @@ -1,5 +1,5 @@ > > [snip] > > > > > > > Frankly looks like a ploy to sidestep review by graphics folks. We'd > > > > > > ask for the userspace first :-) > > > > > > > > > > Please refer to pull request [1]. > > > > > > > > > > For any interest in more details, the libmetal is the abstraction layer > > > > > which provides platform independent APIs. The backend implementation > > > > > can be selected per different platforms: ex, rtos, linux, > > > > > standalone (xilinx),,,. For Linux, it supports UIO / vfio as of now. > > > > > The actual user space drivers sit on top of libmetal. Such drivers can be > > > > > found in [2]. This is why I try to avoid any device specific code in > > > > > Linux kernel. > > > > > > > > > > > > > > > > > Also, exporting dma_addr to userspace is considered a very bad idea. > > > > > > > > > > I agree, hence the RFC to pick some brains. :-) Would it make sense > > > > > if this call doesn't export the physicall address, but instead takes > > > > > only the dmabuf fd and register offsets to be programmed? > > > > > > > > > > > If you want to do this properly, you need a minimal in-kernel memory > > > > > > manager, and those tend to be based on top of drm_gem.c and merged > > > > > > through the gpu tree. The last place where we accidentally leaked a > > > > > > dma addr for gpu buffers was in the fbdev code, and we plugged that > > > > > > one with > > > > > > > > > > Could you please help me understand how having a in-kernel memory manager > > > > > helps? Isn't it just moving same dmabuf import / paddr export functionality > > > > > in different modules: kernel memory manager vs uio. In fact, Xilinx does have > > > > > such memory manager based on drm gem in downstream. But for this time we took > > > > > the approach of implementing this through generic dmabuf allocator, ION, and > > > > > enabling the import capability in the UIO infrastructure instead. > > > > > > > > There's a group of people working on upstreaming a xilinx drm driver > > > > already. Which driver are we talking about? Can you pls provide a link > > > > to that xilinx drm driver? > > > > > > > > > > The one I was pushing [1] is implemented purely for display, and not > > > intended for anything other than that as of now. What I'm refering to above > > > is part of Xilinx FPGA (acceleration) runtime [2]. As far as I know, > > > it's planned to be upstreamed, but not yet started. The Xilinx runtime > > > software has its own in-kernel memory manager based on drm_cma_gem with > > > its own ioctls [3]. > > > > > > Thanks, > > > -hyun > > > > > > [1] https://patchwork.kernel.org/patch/10513001/ > > > [2] https://github.com/Xilinx/XRT > > > [3] https://github.com/Xilinx/XRT/tree/master/src/runtime_src/driver/zynq/drm > > > > I've done a very quick look only, and yes this is kinda what I'd expect. > > Doing a small drm gem driver for an fpga/accelarator that needs lots of > > memories is the right architecture, since at the low level of kernel > > interfaces a gpu really isn't anything else than an accelarater. > > > > And from a very cursory look the gem driver you mentioned (I only scrolled > > through the ioctl handler quickly) looks reasonable. > > Thanks for taking time to look and share input. But still I'd like to > understand why it's more reasonable if the similar ioctl exists with drm > than with uio. Is it because such drm ioctl is vendor specific? We do have quite a pile of shared infrastructure in drm beyond just the vendor specific ioctl. So putting accelerator drivers there makes sense, whether the programming is a GPU, some neural network folder, an FPGA or something else. The one issue is that we require open source userspace together with your driver, since just the accelerator shim in the kernel alone is fairly useless (both for review and for doing anything with it). But there's also some kernel maintainers who disagree and happily take drivers originally written for drm and then rewritten for non-drm for upstream to avoid the drm folks (or at least it very much looks like that, and happens fairly regularly). Cheers, Daniel > > Thanks, > -hyun > > > -Daniel > > > > > > > Thanks, Daniel > > > > > > > > > Thanks, > > > > > -hyun > > > > > > > > > > [1] https://github.com/OpenAMP/libmetal/pull/82/commits/951e2762bd487c98919ad12f2aa81773d8fe7859 > > > > > [2] https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers > > > > > > > > > > > > > > > > > commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a (tag: > > > > > > drm-misc-next-fixes-2018-10-03) > > > > > > Author: Neil Armstrong > > > > > > Date: Fri Sep 28 14:05:55 2018 +0200 > > > > > > > > > > > > drm/fb_helper: Allow leaking fbdev smem_start > > > > > > > > > > > > Together with cuse the above patch should be enough to implement a drm > > > > > > driver entirely in userspace at least. > > > > > > > > > > > > Cheers, Daniel > > > > > > -- > > > > > > Daniel Vetter > > > > > > Software Engineer, Intel Corporation > > > > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > > > > > > > > > > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel