From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF8BFC4320A for ; Tue, 27 Jul 2021 08:52:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D2ABF6121E for ; Tue, 27 Jul 2021 08:52:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235969AbhG0Iws (ORCPT ); Tue, 27 Jul 2021 04:52:48 -0400 Received: from verein.lst.de ([213.95.11.211]:48928 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235885AbhG0Iwr (ORCPT ); Tue, 27 Jul 2021 04:52:47 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 9A8A16736F; Tue, 27 Jul 2021 10:52:44 +0200 (CEST) Date: Tue, 27 Jul 2021 10:52:44 +0200 From: Christoph Hellwig To: Atish Patra Cc: Christoph Hellwig , Atish Patra , devicetree , Albert Ou , Tobias Klauser , Robin Murphy , "linux-kernel@vger.kernel.org List" , Rob Herring , iommu@lists.linux-foundation.org, Guo Ren , Palmer Dabbelt , Paul Walmsley , linux-riscv , Frank Rowand , Dmitry Vyukov Subject: Re: [RFC 3/5] dma-mapping: Enable global non-coherent pool support for RISC-V Message-ID: <20210727085244.GA20609@lst.de> References: <20210723214031.3251801-1-atish.patra@wdc.com> <20210723214031.3251801-4-atish.patra@wdc.com> <20210726070030.GB9035@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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 26, 2021 at 03:47:54PM -0700, Atish Patra wrote: > arch_dma_set_uncached works as well in this case. However, mips, > niops2 & xtensa uses a > fixed (via config) value for the offset. Similar approach can't be > used here because the platform specific > offset value has to be determined at runtime so that a single kernel > image can boot on all platforms. Nothing in the interface requires a fixed offset. And using the offset has one enormous advantage in that there is no need to declare a statically sized pool - allocations are fully dynamic. And any kind of fixed pool tends to cause huge problems. > 1. a new DT property so that arch specific code is aware of the > non-cacheable window offset. Yes. > individual device if a per-device non-cacheable > window support is required in future. As of now, the beagleV memory If you require a per-device noncachable area you can use the per-device coherent pools. But why would you want that? > region lies in 0x10_0000_00000 - x17_FFFF_FFFF > which is mapped to start of DRAM 0x80000000. All of the > non-coherent devices can do 32bit DMA only. Adjust ZONE_DMA32 so that it takes the uncached offset into account. > > > - mem = dma_init_coherent_memory(phys_addr, phys_addr, size, true); > > > + if (phys_addr == device_addr) > > > + mem = dma_init_coherent_memory(phys_addr, device_addr, size, true); > > > + else > > > + mem = dma_init_coherent_memory(phys_addr, device_addr, size, false); > > > > Nak. The phys_addr != device_addr support is goign away. This needs > > ok. > > > to be filled in using dma-ranges property hanging of the struct device. > > struct device is only accessible in rmem_dma_device_init. I couldn't > find a proper way to access it during > dma_reserved_default_memory setup under global pool. > > Does that mean we should use a per-device memory pool instead of a > global non-coherent pool ? Indeed, that would be a problem in this case. But if we can just use the uncached offset directly I think everything will be much simpler.