Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3526129imu; Fri, 30 Nov 2018 01:38:09 -0800 (PST) X-Google-Smtp-Source: AFSGD/Uh2noL5jss30wMSvpqCIYz4uxpa+0/ynidFgyqFoIRFhS6axbxz3vdgjUoIo6jFt8XqhrQ X-Received: by 2002:a63:9041:: with SMTP id a62mr4129061pge.163.1543570689145; Fri, 30 Nov 2018 01:38:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543570689; cv=none; d=google.com; s=arc-20160816; b=lxeU92NOkebGGLg538d2VJKl3u5ST9P7HgjmVg+qfSaJYJPBH7e7nu6q6tD028cyjV 4WitiC4xTxGwy6lbpMgQld+pmNRE3Ty5hkRN/Vh3xN3AOZbdKiSAHLRB8s7TS460gF/t RlUwXWf8a7ZnHA5h1RbriaJoPGXj+o0D+nIfEaYcV3ejqXcklPygzMgX7rDOfaiHNfj9 K9fz2mMLZpFtvUFXzBQLxWco6cy4g1mQv+Dqr5Xrs8e6nsLOWOCvcWEmUlYpDWzQMZGN rB387zxBQLahCveJmGcbT0oiuVpsn5zhJEQWSWowmfIYPz4GmkZg9b0mQGzZ6UulybQs qYpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=E+5aQwo8rWvtqb2rM/apRkpEkq1ocdRuDscTSu4rrJY=; b=roLI4k1b7P1l2ggCgyCh8s66UFTYwmLlGt4JjTb7UecSXZFmu1LKgDUcpLyDDaaWH5 +1w2Vgcns+fK3qSt4634MpW58wHWb5v0TVMcDjmaTUnB2NtqbKrdBVeRExAl2UltbZT/ fBG86H9avmft81dME7/eb2oHtTGjw+BG+6STswqxP7Y7ujYCS1sur7+OnBh9EKgPGnyl DPu2OZuiV/xY9bH9NncHf/f9wzpXsbcHbrJxyVKcoq+gq3vhc/Pvdj0F63d9b1xdmIUI 7KJP62/PcseINLKJTnRhKByODmegpAL6tH3eeCEVKBnu5L82lKfY3QO6QqL2j7U+hjdH SeMA== ARC-Authentication-Results: i=1; mx.google.com; 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 be9si4787072plb.143.2018.11.30.01.37.54; Fri, 30 Nov 2018 01:38:09 -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; 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 S1726709AbeK3Uo0 (ORCPT + 99 others); Fri, 30 Nov 2018 15:44:26 -0500 Received: from verein.lst.de ([213.95.11.211]:49168 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726469AbeK3UoZ (ORCPT ); Fri, 30 Nov 2018 15:44:25 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 0B40F68BDF; Fri, 30 Nov 2018 10:35:42 +0100 (CET) Date: Fri, 30 Nov 2018 10:35:41 +0100 From: Christoph Hellwig To: Rob Clark Cc: hch@lst.de, Daniel Vetter , David Airlie , linux-arm-msm , Linux Kernel Mailing List , dri-devel , Tomasz Figa , Sean Paul , Vivek Gautam , freedreno , Robin Murphy Subject: Re: [PATCH v3 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg* Message-ID: <20181130093541.GA21436@lst.de> References: <20181129140315.28476-1-vivek.gautam@codeaurora.org> <20181129141429.GA22638@lst.de> <20181129155758.GC26537@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) 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 08:15:23PM -0500, Rob Clark wrote: > As far as hiding cache ops behind iommu layer, I guess I'd been > thinking more of just letting the drivers that want to bypass dma > layer take things into their own hands.. tbh I think/assume/hope > drm/msm is more the exception than the rule as far as needing to > bypass the dma layer. Or at least I guess the # of drivers having > problems w/ the dma layer is less than the # of iommu drivers. So the whole bypass thing has already been a contentious discussion in the past. One thing that the API aready enforces is that we pass a DMA direction, which I want to keep. The other is that we need a struct device (or something similiar) that is used to check if the device is cache coherent or not. In your MSM case you might know that, but in general it really is a platform issue that I don't want every driver to know about. > (Not sure if that changes my thoughts on this patch, it isn't like > what this patch replaces isn't also a problematic hack around the > inability to bypass the dma layer. In the short term I just want > *something* that works, I'm totally happy to refactor later when there > are better options.) The current patch is simply broken. You can't just construct your own S/G list and pass it to the DMA API, and we enforce that very strictly with dma debug enabled. So your only options are: a) actually use the DMA API for creating the mapping, by e.g. using dma_direct_ops ontop of an actual IOMMU managed in the background, or b) figure out a way to do cache maintainance for raw IOMMU API drivers.