Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4898696pxu; Tue, 13 Oct 2020 09:38:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwR+aq2hQvNrx5bJMVOTB+ewvVTHxCw2Yr2cBnc77vTkf10PEKEnLFywDKfmZbYf+COPO7j X-Received: by 2002:a17:906:685a:: with SMTP id a26mr632220ejs.458.1602607114860; Tue, 13 Oct 2020 09:38:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602607114; cv=none; d=google.com; s=arc-20160816; b=fVs71bjGpOQuAB7RCOJfdf8Z0i1vrMtZ1zGXbqTudyvRKrUIkbob2zzlN0UhdKHaCy IV0ihJl/qPs5oFmWvBvlGpPiyguW+DIh6UmdUx/zEe/jmMnnFASRpprZ+Ul+iThbpf0m xHQ7VDdlJ260grZFqaTzaTJd7To1d/DASi7q3PVolQiUpJHKk8MxrMD89f88SRQSwAfl 4T8cWpfeAyPk2izc3FuSJeKwtkFGFEbV14BBKiItb4oqih821vkgUQ5VDMMYL/EXjmur NEi5GvGkhUY5+lVr6xWYfWG406CY/w5/XZ7/NNZUdiElpouS9KqGi3bMYL1W8nAIHbYG RebA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=wPIZQFBVOOymk9f9WQ2a+ptRpnqKhAM4DpRZZ20pA7s=; b=DgA2MEVFAxwQ1+nzX8NOAlEdnkXAOShvdykM0ddwN+Ewv3UcMLi/ZpoYo6dsgjT20a v322uSHyBTuM8AKFEEe2dFf4AnaVppsyVaiuscSbaoWBi/qFntpgrjbq9cNn34v53SvO /ErA2tCl3YTao5ikboIKqgj1wYhiqYVa9xNEJfe7Wd+MkMKnkBYhA8khYn+r42zUvGhL jtgCz4WnhtaoIT3NsLfNYIAk//Kz6HKkUQk0/PRHV8bzXIsjYFBO8Wz+wEBQuvjswn3M XQK2eRcnJbPi1lsGXBrEXBc3XFoh8bOyPIzH/yq6dHaGixHu9r0F6j8qN2TiIJ1jcl3N FA/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u3si152022ejg.130.2020.10.13.09.38.11; Tue, 13 Oct 2020 09:38:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387582AbgJMNmn (ORCPT + 99 others); Tue, 13 Oct 2020 09:42:43 -0400 Received: from foss.arm.com ([217.140.110.172]:60138 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728784AbgJMNmm (ORCPT ); Tue, 13 Oct 2020 09:42:42 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A164830E; Tue, 13 Oct 2020 06:42:41 -0700 (PDT) Received: from [10.57.48.76] (unknown [10.57.48.76]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A63CD3F719; Tue, 13 Oct 2020 06:42:39 -0700 (PDT) Subject: Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance To: Christoph Hellwig , Jonathan Marek Cc: freedreno@lists.freedesktop.org, Rob Clark , Sean Paul , David Airlie , Daniel Vetter , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR MSM ADRENO GPU" , open list , iommu@lists.linux-foundation.org, Joerg Roedel References: <20201001002709.21361-1-jonathan@marek.ca> <20201001002709.21361-3-jonathan@marek.ca> <20201002075321.GA7547@infradead.org> <20201005082914.GA31702@infradead.org> <3e0b91be-e4a4-4ea5-7d58-6e71b8d51932@marek.ca> <20201006072306.GA12834@infradead.org> <148a1660-f0fc-7163-2240-6b94725342b5@marek.ca> <20201007062519.GA23519@infradead.org> From: Robin Murphy Message-ID: Date: Tue, 13 Oct 2020 14:42:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <20201007062519.GA23519@infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-10-07 07:25, Christoph Hellwig wrote: > On Tue, Oct 06, 2020 at 09:19:32AM -0400, Jonathan Marek wrote: >> One example why drm/msm can't use DMA API is multiple page table support >> (that is landing in 5.10), which is something that definitely couldn't work >> with DMA API. >> >> Another one is being able to choose the address for mappings, which AFAIK >> DMA API can't do (somewhat related to this: qcom hardware often has ranges >> of allowed addresses, which the dma_mask mechanism fails to represent, what >> I see is drivers using dma_mask as a "maximum address", and since addresses >> are allocated from the top it generally works) > > That sounds like a good enough rason to use the IOMMU API. I just > wanted to make sure this really makes sense. I still think this situation would be best handled with a variant of dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set automatically when attaching to an unmanaged IOMMU domain. That way the device driver can make DMA API calls in the appropriate places that do the right thing either way, and only needs logic to decide whether to use the returned DMA addresses directly or ignore them if it knows they're overridden by its own IOMMU mapping. Robin.