Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1467303ybl; Wed, 29 Jan 2020 23:55:41 -0800 (PST) X-Google-Smtp-Source: APXvYqy2sEvwyCO8hLlwNaSExuQgH0LOig3z7OyIOAdeKpAMLExGL1Z/aHNaQViHbRpy0v4ATTfS X-Received: by 2002:a05:6830:114f:: with SMTP id x15mr2466891otq.291.1580370941301; Wed, 29 Jan 2020 23:55:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580370941; cv=none; d=google.com; s=arc-20160816; b=U+rtqL+s+YqTnCoyt7Xvx7Q2Zrxuufeihtwbab5zZVata3Fsfl2ilZxtJaBD9Z8hED dqRSIYkdbCrbsPd27ZeE0AYHZc6xdOyXkEOOADhMSXsHv8zh26MwiAscu9O8ORHjHt3Z h8wJp0jdcd1uDjrZF9/vAptDBWI5MdD9RgsTqfou+9RX9JA3xlVAkXPspzfZZMxOEDPU Z9ndE90IsrcVX+fwvp8GQfzxIB6HCjKf+1xlzJq/OSVps8b0a/KMPTrOF4lS7oYG6NDP g/6mHqKYOv91tLGDavBQVrgb7t2dyr1iRuGD704bQnXlMFxM801rG1maX2JrTLuTZN1h 4Hyw== 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=65tqqvRlG754BzWP7qM2abe1zHK1KJIv8ntwIyGX9N4=; b=CXoHcdopHOFOzTTUZLFsI8ABasKNDH0dqzdFiOZrE5fhoIRutQN8iuz3cHoxe4b9Z/ p+pE/qQtaukQ+XZ4Tskf1QHjw8IIaurrWaVMdZZ2Qwal8xTDXCuJ5VMt3/gsPnKEjyCT 30jmEAtyYJ7aOJOs5usjO1BIBFs6zOL8OYkWxY9GdC7bvIam4xjwIlflQe7DxIprqVlB f1+A1T8lDzm505ZRtRZdaUkb31lFJwTc6HXSz6i2KQOdhUsxuBUFMO3TrhRpLNGo1bRD A3pwbun45W9UnDE99SwMcF4FiHJPvi5F7Wrby8tqG4Ek4g4CO6sPa6vSIGnXIBcuOnUX 3eZw== 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 m24si2433746oic.11.2020.01.29.23.55.29; Wed, 29 Jan 2020 23:55:41 -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 S1726879AbgA3Hxg (ORCPT + 99 others); Thu, 30 Jan 2020 02:53:36 -0500 Received: from verein.lst.de ([213.95.11.211]:39306 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726464AbgA3Hxf (ORCPT ); Thu, 30 Jan 2020 02:53:35 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 57B3C68B05; Thu, 30 Jan 2020 08:53:32 +0100 (CET) Date: Thu, 30 Jan 2020 08:53:32 +0100 From: Christoph Hellwig To: Peter Ujfalusi Cc: Robin Murphy , hch@lst.de, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, rogerq@ti.com, robh@kernel.org Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130075332.GA30735@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> 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 [skipping the DT bits, as I'm everything but an expert on that..] On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > I agree on the phys_to_dma(). It should fail for addresses which does > not fall into any of the ranges. > It is just a that we in Linux don't have the concept atm for ranges, we > have only _one_ range which applies to every memory address. what does atm here mean? We have needed multi-range support for quite a while, as common broadcom SOCs do need it. So patches for that are welcome at least from the DMA layer perspective (kinda similar to your pseudo code earlier) > > Nobody's disputing that the current dma_direct_supported() > > implementation is broken for the case where ZONE_DMA itself is offset > > from PA 0; the more pressing question is why Christoph's diff, which was > > trying to take that into account, still didn't work. > > I understand that this is a bit more complex than I interpret it, but > the k2g is broken and currently the simplest way to make it work is to > use the arm dma_ops in case the pfn_offset is not 0. > It will be easy to test dma-direct changes trying to address the issue > in hand, but will allow k2g to be usable at the same time. Well, using the legacy arm dma ops means we can't use swiotlb if there is an offset, which is also wrong for lots of common cases, including the Rpi 4. I'm still curious why my patch didn't work, as I thought it should. We'll need to find the minimum change to make it work for now without switching ops, even if it isn't the correct one, and then work from there.