Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3287163pxv; Sun, 25 Jul 2021 23:58:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQKAETgyLLTtuDwtxan4fXr8Pgb5ZARUjee9EVoVJFzRmJiF9wuld8751Im1ClVBTGGI1x X-Received: by 2002:a02:c013:: with SMTP id y19mr15200397jai.36.1627282686675; Sun, 25 Jul 2021 23:58:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627282686; cv=none; d=google.com; s=arc-20160816; b=uIX3uy2aZnbWvq1BdDkFNJhyMJdUhzsEbjy11/bGCgmGPSBDsS0mAOW4OSFJbots71 MvPDLmgs5bXIQTNG3Sq1NDAkvdqvkGufIdaaPrUBTLtC6J1bbV9o+9MA9mAweFZRIZ8k pQ4ykAGSThN2/Rk/hfpTuffT2628FlcQ7B3tfHIecJfizhZuL5CjnSZc5NUywozZgTfM NegmxOV9g8oNX8mtLD2F87hNpo1XZ9gXSSolVVTFjI3G0n7Xn/jztN740QprfA5Kvld9 O5yDiXvjJ3A8Wjw5zTWPdhoLFAJxQO2+2wXXahLtvVhgbaj5vDGeRGTVPC7siEKOcTIk H8kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ynBQ/AoxS9CUqu1XJqSjxNC/neeHvE7SP8HH1foZSUI=; b=qxUxNJPo12DRZPVNy1+xvOaCpg1LoI9S1V7mxKOkmBkrTzzRMd3QA1N1kxwwxR22Rw G9YOkGovKtQ66kN0RSBgwPV9rV4zKeAZQdxCILtni4C1GHDd+dk8w25jM/jurgTYwA6U tXftxWG074TlTShDsvraRQ++YkDGJd4bUDtusA5AxXlxnJOAf0iYjPAYI3RAq06BjgxG tKK5uhGBV6yQCatsHwJZAoMjvfeDuwHLrHPFFHBYt00RfBYAF6CEIEKgGgxncbpPNYgv a58v94pcvY2BeJFSVk38WZUo4b3A6z8HA3tbjkTEgtpCtrLHN2uS3pH7pgE5FGwfFzVJ EsnQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l20si18319379ion.36.2021.07.25.23.57.55; Sun, 25 Jul 2021 23:58:06 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231759AbhGZGQd (ORCPT + 99 others); Mon, 26 Jul 2021 02:16:33 -0400 Received: from verein.lst.de ([213.95.11.211]:43913 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229658AbhGZGQc (ORCPT ); Mon, 26 Jul 2021 02:16:32 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 408B168AFE; Mon, 26 Jul 2021 08:56:58 +0200 (CEST) Date: Mon, 26 Jul 2021 08:56:57 +0200 From: Christoph Hellwig To: Atish Patra Cc: linux-kernel@vger.kernel.org, Albert Ou , Christoph Hellwig , devicetree@vger.kernel.org, Dmitry Vyukov , Frank Rowand , Guo Ren , iommu@lists.linux-foundation.org, linux-riscv@lists.infradead.org, Marek Szyprowski , Palmer Dabbelt , Paul Walmsley , Rob Herring , Robin Murphy , Tobias Klauser Subject: Re: [RFC 1/5] RISC-V: Implement arch_sync_dma* functions Message-ID: <20210726065657.GA9035@lst.de> References: <20210723214031.3251801-1-atish.patra@wdc.com> <20210723214031.3251801-2-atish.patra@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210723214031.3251801-2-atish.patra@wdc.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +#ifdef CONFIG_RISCV_DMA_NONCOHERENT > +struct riscv_dma_cache_sync { > + void (*cache_invalidate)(phys_addr_t paddr, size_t size); > + void (*cache_clean)(phys_addr_t paddr, size_t size); > + void (*cache_flush)(phys_addr_t paddr, size_t size); > +}; > + > +void riscv_dma_cache_sync_set(struct riscv_dma_cache_sync *ops); > +#endif As told a bunch of times before: doing indirect calls here is a performance nightmare. Use something that actually does perform horribly like alternatives. Or even delay implementing that until we need it and do a plain direct call for now. static void __dma_sync(phys_addr_t paddr, size_t size, enum dma_data_direction dir) > +{ > + if ((dir == DMA_FROM_DEVICE) && (dma_cache_sync->cache_invalidate)) > + dma_cache_sync->cache_invalidate(paddr, size); > + else if ((dir == DMA_TO_DEVICE) && (dma_cache_sync->cache_clean)) > + dma_cache_sync->cache_clean(paddr, size); > + else if ((dir == DMA_BIDIRECTIONAL) && dma_cache_sync->cache_flush) > + dma_cache_sync->cache_flush(paddr, size); > +} The seletion of flush types is completely broken. Take a look at the comment in arch/arc/mm/dma.c above arch_sync_dma_for_device for a good explanation. > +void arch_dma_prep_coherent(struct page *page, size_t size) > +{ > + void *flush_addr = page_address(page); > + > + memset(flush_addr, 0, size); arch_dma_prep_coherent is not supposed to modify the content of the data.