Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp56633imm; Fri, 6 Jul 2018 13:56:08 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfENntg4UvjlUHeiCK4p5mYsSuRCSFqAKldXC/UPWg+4nv5I/XCAWcm1jboY0DNbs7jN2NL X-Received: by 2002:a65:6397:: with SMTP id h23-v6mr10628868pgv.380.1530910568645; Fri, 06 Jul 2018 13:56:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530910568; cv=none; d=google.com; s=arc-20160816; b=MHrxr4VupPH9vS+2WEsImG/+E5I5ttkGIFBYQyr2Qs3W+Fvf9Yxa9Fha15gpYFfX8G xnoRMn27kmF9xSVZhY2aYKt64mv3FXjHEKqd3ygvV9LHCzLYAjMexhHPZhmokcEW8CAK NzFZIY12hmPEF8P3mIXKd2bey90yPQjB3L3CRBOxR5LGIli6SETqF9jIl3Kn/T8ZjgHN HakyQ6txRMLjY3fQXVbLd8AHfFdiBa6yLga89/5YNFDex0b4FPOXWOBN9m7QF6jIK2qX k6MnsXV2CbQBLmFeX7uO+wZICZfhSRbLG8RSBOgfqJ0EfS+f1vT1UhmB/WvJHvwbtM0G WEFQ== 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:arc-authentication-results; bh=2Le0p0LRXdyfVpNH67+MVu9WM9mC0y29/NBi1taPLRA=; b=P43LQGtr001AQyqEYILP3azsDjwJnj2CmM1zma6MCb2yJ7ObS0TS0aGZtSoSuWFYun 6I65QokjCRCVv669ZJhzPs/I5iCY2lLiT/dgMYm/VJkx00lsrq6YXwzv+6QsEH0urjUf PCL6AKbJXW/e3xcaIWdzTUPrsZzySsICR2rv0evqAkt+F1jfkRzj3XsU+ADwdhjog3JM hY6M6HYN2lOMc3AO9cPUf9kGzzCTYjjrRXKYBEslhFXgy3TVNXLLazXRiJeeFpuakrL3 rB6cflotATEhKibo6x7jYmLU4kmGhIk33Glj7Va1FMjxaKBGNXRGZGOjMgYx1M1mms/O NW4w== 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 34-v6si8913177plc.346.2018.07.06.13.55.54; Fri, 06 Jul 2018 13:56:08 -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 S934471AbeGFUy4 (ORCPT + 99 others); Fri, 6 Jul 2018 16:54:56 -0400 Received: from ste-pvt-msa1.bahnhof.se ([213.80.101.70]:13541 "EHLO ste-pvt-msa1.bahnhof.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933856AbeGFUyz (ORCPT ); Fri, 6 Jul 2018 16:54:55 -0400 Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id 7256F3FCBD; Fri, 6 Jul 2018 22:54:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-9CjWFi2HYs; Fri, 6 Jul 2018 22:54:52 +0200 (CEST) Received: from localhost.localdomain (h-155-4-135-114.NA.cust.bahnhof.se [155.4.135.114]) (Authenticated sender: mb547485) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id D00EF3FC9F; Fri, 6 Jul 2018 22:54:51 +0200 (CEST) Date: Fri, 6 Jul 2018 22:54:50 +0200 From: Fredrik Noring To: Robin Murphy Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, "Maciej W. Rozycki" , JuergenUrban@gmx.de Subject: Re: [PATCH] dma-mapping: Relax warnings for per-device areas Message-ID: <20180706205449.GB2313@localhost.localdomain> References: <1f8262d206c6886072d04cc93454f6e3f812bd20.1530623284.git.robin.murphy@arm.com> <20180705193613.GA28905@lst.de> <5811ebe5-b2bd-efc1-bf54-a8f05432c4f8@arm.com> <20180706141926.GA2313@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, > > Does dma_set_coherent_mask want a device object representing the IOP? Such > > a thing is currently not implemented, but can certainly be done. > > Nope, just the same OHCI device as the dma_declare_coherent_memory() call. Ah... and then some kind of dma_ops structure is needed to avoid -EIO? Possibly using set_dma_ops()? By the way, the DMA hardware supports executing device->{memory,FIFO}, {memory,FIFO}->device and FIFO<->memory simultaneously, with hardware stall control, between different devices where memory or FIFOs act as intermediate buffers. Memory can also be a source or a destination. That might be a way to have the OHCI efficiently transfer data from/to main memory. I suppose it would be two simultaneously linked DMA transfers such as OHCI <-> SIF <-> main memory or even three linked DMA transfers as in OHCI <-> IOP memory <-> SIF <-> main memory where SIF is the IOP DMA interface, which is a bidirectional hardware FIFO. Does the kernel DMA subsystem support simultaneously linked DMA transfers? In addition, the DMA hardware also supports scatter-gather (chaining), so memory need not be physically continuous. > > As you noted, the kernel cannot and must not allocate any kind of normal > > memory for this device. Typical DMA addresses 0-0x200000 are mapped to > > 0x1c000000-0x1c200000 and is memory managed exclusively by the IOP. What > > would be a suitable mask for that? > > For the sake of accuracy, I guess maybe DMA_BIT_MASK(20) since that's what > the OHCI's effective addressing capability is, even if it does happen to be > to remote IOP RAM. Isn't it 21 for 2 MiB? Hmm... I'm considering raising that to 8 MiB since there are such devices too. > Alternatively, there is perhaps some degree of argument > for deliberately picking a nonzero but useless value like 1, although it > looks like the MIPS allocator (at least the dma-default one) never actually > checks whether the page it gets is within range of the device's coherent > mask, which it probably should do. Perhaps Maciej knows more about the details of the MIPS allocator? Fredrik