Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2719424imu; Thu, 29 Nov 2018 09:11:01 -0800 (PST) X-Google-Smtp-Source: AFSGD/UEm87lGRViBqs7tY37RsO0Smt0PRNEkKhGswXuxpw8WbNxdooI4rr5Ansu5eQKTRalmkhd X-Received: by 2002:a65:6392:: with SMTP id h18mr1925453pgv.107.1543511461186; Thu, 29 Nov 2018 09:11:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543511461; cv=none; d=google.com; s=arc-20160816; b=06j8xKCQJ82siY8rGxBBv82P19UuYRW2NQltjyEqskhsKeB5uDMMF44o0ChMwv5TiZ Yl/OdHE3+uiLcjdTfari2fFQws/7nsZXNpqsWW46QvusPLO+2LN75B/JFT8T9vwZOdy8 6d1oP1hpLSp5r9lN14vyaOItY4Fs4ofA9lXPZhaKYJbQdCdZNy15AufhybNpL+gR5FBG XA4zArHXjfgvniLLA8lGxN5kZVx42zgvfOBFQ72auWGVpuSFgzZNXC+Pf/Pa17uVaGNb 9ZtmKTDELXbgnh+/SAiRYIA7ok2rb3xdgDHv8f9KvlUAOtfWA6d5OUbXYf4BlRpAs34a 9A2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mX3m/T7ZX+mlVgtePqOj42Qe2cGFFbsZREFTxdeAi1o=; b=llqdtWPv9THLIZxLsuSzHR24UwX8XISlFmhO80QpTe4Kvws5iI9c3FRNrVSXOmWvWu VOPaztnwifMK+GIgf+6N6yO3XwNcip2QCti2oVnMWnhFJ+aLi3Qx9omA+cyBDSfDwIPz AdPW7q9Z0+X3LE9Fz0WEdc8ndLNrKPUQhkG9TwwQUv1aSNg+rav8/tA3Vcx9b54ezOrI Huih0kGM1fiv+IRI2YpQHA057fBaoUEYeltmrstNMzjwB2j3q23+uColb+rQx2aAo4Kw QaOlv38L4AGX408YhKCegcM7iJbMIdZGDLGFMrUkxN69vWUDBq9wxSX+/yV2lJKdNCnH 1FiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=Oh275gsx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p5si2553454pls.338.2018.11.29.09.10.10; Thu, 29 Nov 2018 09:11:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=Oh275gsx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730319AbeK3EPW (ORCPT + 99 others); Thu, 29 Nov 2018 23:15:22 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:44268 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728444AbeK3EPW (ORCPT ); Thu, 29 Nov 2018 23:15:22 -0500 Received: by mail-io1-f66.google.com with SMTP id r200so2143212iod.11 for ; Thu, 29 Nov 2018 09:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mX3m/T7ZX+mlVgtePqOj42Qe2cGFFbsZREFTxdeAi1o=; b=Oh275gsxoxffS1JgnRR6gNrfXnng7aLPXN0YpHc8HTxpBdiJWFIcvZxqCJ8gIhnVxZ /o8CuDrbyJGY31B1ootx0SFxGRY0srPTWiaRbDCuJboQNTHBb61qHafYkEykujSFK38B THKnXZNqz5B+6+9toZy/sFxKv3B26Dd+KIlEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mX3m/T7ZX+mlVgtePqOj42Qe2cGFFbsZREFTxdeAi1o=; b=pemAuLMT6xGo571As4urWm32YtY4DXVOqfwGCuHw1k6xJiuuYwmScqlnAwlMDYTp/p wV+iBf8KtT+FpuQB8Xbr7+NLB8MVhKQnDDn7buM5993n1YOCdlfA1VoHH/zyqARqwmbz t1i7yGlASftJ0776vW2QqZ3u6+YKm58BmPFJRulrZP0ZHFqPpw8bIDnewJsnGPuVLtai UYIAKZR0OE9duPMiaXw/v0cfiaiUSdEuWROlhUB5WOj7LEPfAzx0kmda+9N53Dz/9Iej Fz0Ul1wtqnnlHydxse5oRbarKj5J2+XoxJRICEkNEyNc7WYPuFLdGrR47zk7u8Bo2XeC qYmg== X-Gm-Message-State: AA+aEWY7ccPvcxk0+vuFy8HmO3vRngoYaoFXNeEx0oF9CWWt4rSaTwak Ue/YNYGof13/DWZDN80+lRx9B4VYsU4O1R2AKidMeg== X-Received: by 2002:a6b:4001:: with SMTP id k1mr2057711ioa.34.1543511357463; Thu, 29 Nov 2018 09:09:17 -0800 (PST) MIME-Version: 1.0 References: <20181129140315.28476-1-vivek.gautam@codeaurora.org> <20181129141429.GA22638@lst.de> <20181129155758.GC26537@lst.de> <20181129162807.GL21184@phenom.ffwll.local> <20181129165715.GA27786@lst.de> In-Reply-To: <20181129165715.GA27786@lst.de> From: Daniel Vetter Date: Thu, 29 Nov 2018 18:09:05 +0100 Message-ID: Subject: Re: [PATCH v3 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg* To: Christoph Hellwig Cc: "Clark, Rob" , Dave Airlie , linux-arm-msm , Linux Kernel Mailing List , dri-devel , Tomasz Figa , Sean Paul , vivek.gautam@codeaurora.org, freedreno , Robin Murphy Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote: > On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote: > > Just spend a bit of time reading through the implementations already > > merged. Is the struct device *dev parameter actually needed anywhere? > > dma-api definitely needs it, because we need that to pick the right iommu. > > But for cache management from what I've seen the target device doesn't > > matter, all the target specific stuff will be handled by the iommu. > > It looks like only mips every uses the dev argument, and even there > the function it passes dev to ignores it. So it could probably be removed. > > > > > Dropping the dev parameter would make this a perfect fit for coherency > > management of buffers used by multiple devices. Right now there's all > > kinds of nasty tricks for that use cases needed to avoid redundant > > flushes. > > Note that one thing I'd like to avoid is exposing these funtions directly > to drivers, as that will get us into all kinds of abuses. What kind of abuse do you expect? It could very well be that gpu folks call that "standard use case" ... At least on x86 with the i915 driver we pretty much rely on architectural guarantees for how cache flushes work very much. Down to userspace doing the cache flushing for mappings the kernel has set up. > So I'd much prefer if we could have iommu APIs wrapping these that are > specific to actual uses cases that we understand well. > > As for the buffer sharing: at least for the DMA API side I want to > move the current buffer sharing users away from dma_alloc_coherent > (and coherent dma_alloc_attrs users) and the remapping done in there > required for non-coherent architectures. Instead I'd like to allocate > plain old pages, and then just dma map them for each device separately, > with DMA_ATTR_SKIP_CPU_SYNC passed for all but the first user to map > or last user to unmap. On the iommu side it could probably work > similar. I think this is what's often done. Except then there's also the issue of how to get at the cma allocator if your device needs something contiguous. There's a lot of that still going on in graphics/media. -Daniel > I have done some preliminary work on this, and want to get it into this > merge window, but there is a few other bits I need to sort out first. > > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > ---end quoted text--- > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch