Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3445232ybg; Mon, 28 Oct 2019 12:58:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqyH+/sN5uI1Z/mq8WA1uLselJsd4EZ4AX5albUSYNiYvWUEycj8zUjlknnc8evaTR7g03mR X-Received: by 2002:aa7:d60c:: with SMTP id c12mr20792510edr.14.1572292696717; Mon, 28 Oct 2019 12:58:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572292696; cv=none; d=google.com; s=arc-20160816; b=raYAmoInguxTvhddPhUP9bi09Xog5sS97S224Oq/NGdL2FM7aLAuq5nsOEyqAcgDmG fyy3n8NASUJnCgFEUTXkEqMI+8bIB+Bc0HiSfp2+2JrCZ9eOpESGy49jN2jNTRkZfxtu GpjgZPxmrlXVQrCkAanKsZKISiRiGywZ1Rx1gFNtrVp+3G4blT1VtwYbgFpzoWw3MZzE C0Pt7EO6/UFXidFPzAKK6Er70pCuo4oNv6cxGNVLDs+UDME/QuM64YuUzbGdn9+udgys tBEos5XmiasCZOKoLsA4+xWASSOlsIfLjhAeV+noHJKqZO0k0ShfO5LkTZENvB+wALxk GFIQ== 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=Rde7XF3yp0qr2mRS2pGqsy/6eDDoS8HPFJzPi9zuvOM=; b=dbT0v9xvR8cfbhQIXM8U3CIstQ9Dvn7KwPMZWfwFOhzBZnsTpxVfCNOKM1PvmE8v1v 3mmKF06GhvYQUkY3VVlJ65h5ouh5FOAbuWHYn9LBlhye0/AFONzexrpsnKa4MIH+SCHn XtiTzjNENc4jXt78QmVy3g/lHl0jibWj1ZamByu9jaH4XaDz0jbYhS26ZXAAghQvYsRS tHptSfh8kYr1eE1vKJzFN743QpIhpMo1BjYvPV7sCwyDCMfvxFuzNPaSRseseQcWQtyX mUIG1fQ2JsnG5cbzxFQ0yFzanY+Q/3vYqRwNg8FgxxPxHpEOdMRK40s/DCzmr27mPYvO SjSg== 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 x17si1956017ejb.350.2019.10.28.12.57.53; Mon, 28 Oct 2019 12:58:16 -0700 (PDT) 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 S2388507AbfJ1Lhc (ORCPT + 99 others); Mon, 28 Oct 2019 07:37:32 -0400 Received: from verein.lst.de ([213.95.11.211]:34029 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbfJ1Lhb (ORCPT ); Mon, 28 Oct 2019 07:37:31 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id E4BA268AFE; Mon, 28 Oct 2019 12:37:28 +0100 (CET) Date: Mon, 28 Oct 2019 12:37:28 +0100 From: Christoph Hellwig To: Will Deacon Cc: Christoph Hellwig , isaacm@codeaurora.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, joro@8bytes.org, m.szyprowski@samsung.com, robin.murphy@arm.com, pratikp@codeaurora.org, lmark@codeaurora.org Subject: Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE Message-ID: <20191028113728.GA24055@lst.de> References: <1572050616-6143-1-git-send-email-isaacm@codeaurora.org> <20191026053026.GA14545@lst.de> <20191028074156.GB20443@lst.de> <20191028112457.GB4122@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191028112457.GB4122@willie-the-truck> 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 Mon, Oct 28, 2019 at 11:24:58AM +0000, Will Deacon wrote: > Agreed. The way I /think/ it works is that on many SoCs there is a > system/last-level cache (LLC) which effectively sits in front of memory for > all masters. Even if a device isn't coherent with the CPU caches, we still > want to be able to allocate into the LLC. Why this doesn't happen > automatically is beyond me, but it appears that on these Qualcomm designs > you actually have to set the memory attributes up in the page-table to > ensure that the resulting memory transactions are non-cacheable for the CPU > but cacheable for the LLC. Without any changes, the transactions are > non-cacheable in both of them which assumedly has a performance cost. > > But you can see that I'm piecing things together myself here. Isaac? If that is the case it sounds like we'd want to drive this through DT properties, not the driver API. But again, without an actual consumer it pretty much is a moot point anyway.