From: Robin Murphy <robin.murphy@arm.com> To: Christoph Hellwig <hch@lst.de>, Greg Ungerer <gerg@linux-m68k.org>, iommu@lists.linux.dev Cc: Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Conor Dooley <conor@kernel.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Wei Fang <wei.fang@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>, NXP Linux Team <linux-imx@nxp.com>, linux-m68k@lists.linux-m68k.org, netdev@vger.kernel.org, linux-riscv@lists.infradead.org, linux-renesas-soc@vger.kernel.org, Jim Quinlan <james.quinlan@broadcom.com> Subject: Re: [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc Date: Mon, 16 Oct 2023 12:58:47 +0100 [thread overview] Message-ID: <fffcf35b-0da5-4df5-9224-5ac4e28b5f3a@arm.com> (raw) In-Reply-To: <20231016054755.915155-8-hch@lst.de> On 16/10/2023 6:47 am, Christoph Hellwig wrote: > The logic in dma_direct_alloc when to use the atomic pool vs remapping > grew a bit unreadable. Consolidate it into a single check, and clean > up the set_uncached vs remap logic a bit as well. Reviewed-by: Robin Murphy <robin.murphy@arm.com> > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > kernel/dma/direct.c | 25 ++++++++++--------------- > 1 file changed, 10 insertions(+), 15 deletions(-) > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index ec410af1d8a14e..1327d04fa32a25 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size, > dma_handle); > > /* > - * Otherwise remap if the architecture is asking for it. But > - * given that remapping memory is a blocking operation we'll > - * instead have to dip into the atomic pools. > + * Otherwise we require the architecture to either be able to > + * mark arbitrary parts of the kernel direct mapping uncached, > + * or remapped it uncached. > */ > + set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED); > remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP); > - if (remap) { > - if (dma_direct_use_pool(dev, gfp)) > - return dma_direct_alloc_from_pool(dev, size, > - dma_handle, gfp); > - } else { > - if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) > - return NULL; > - set_uncached = true; > - } > + if (!set_uncached && !remap) > + return NULL; > } > > /* > - * Decrypting memory may block, so allocate the memory from the atomic > - * pools if we can't block. > + * Remapping or decrypting memory may block, allocate the memory from > + * the atomic pools instead if we aren't allowed block. > */ > - if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp)) > + if ((remap || force_dma_unencrypted(dev)) && > + dma_direct_use_pool(dev, gfp)) > return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp); > > /* we always manually zero the memory once we are done */
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: Christoph Hellwig <hch@lst.de>, Greg Ungerer <gerg@linux-m68k.org>, iommu@lists.linux.dev Cc: Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Conor Dooley <conor@kernel.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Wei Fang <wei.fang@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>, NXP Linux Team <linux-imx@nxp.com>, linux-m68k@lists.linux-m68k.org, netdev@vger.kernel.org, linux-riscv@lists.infradead.org, linux-renesas-soc@vger.kernel.org, Jim Quinlan <james.quinlan@broadcom.com> Subject: Re: [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc Date: Mon, 16 Oct 2023 12:58:47 +0100 [thread overview] Message-ID: <fffcf35b-0da5-4df5-9224-5ac4e28b5f3a@arm.com> (raw) In-Reply-To: <20231016054755.915155-8-hch@lst.de> On 16/10/2023 6:47 am, Christoph Hellwig wrote: > The logic in dma_direct_alloc when to use the atomic pool vs remapping > grew a bit unreadable. Consolidate it into a single check, and clean > up the set_uncached vs remap logic a bit as well. Reviewed-by: Robin Murphy <robin.murphy@arm.com> > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > kernel/dma/direct.c | 25 ++++++++++--------------- > 1 file changed, 10 insertions(+), 15 deletions(-) > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index ec410af1d8a14e..1327d04fa32a25 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size, > dma_handle); > > /* > - * Otherwise remap if the architecture is asking for it. But > - * given that remapping memory is a blocking operation we'll > - * instead have to dip into the atomic pools. > + * Otherwise we require the architecture to either be able to > + * mark arbitrary parts of the kernel direct mapping uncached, > + * or remapped it uncached. > */ > + set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED); > remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP); > - if (remap) { > - if (dma_direct_use_pool(dev, gfp)) > - return dma_direct_alloc_from_pool(dev, size, > - dma_handle, gfp); > - } else { > - if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) > - return NULL; > - set_uncached = true; > - } > + if (!set_uncached && !remap) > + return NULL; > } > > /* > - * Decrypting memory may block, so allocate the memory from the atomic > - * pools if we can't block. > + * Remapping or decrypting memory may block, allocate the memory from > + * the atomic pools instead if we aren't allowed block. > */ > - if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp)) > + if ((remap || force_dma_unencrypted(dev)) && > + dma_direct_use_pool(dev, gfp)) > return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp); > > /* we always manually zero the memory once we are done */ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-10-16 11:58 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-16 5:47 fix the non-coherent coldfire dma_alloc_coherent v2 Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 5:47 ` [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 12:49 ` Conor Dooley 2023-10-16 12:49 ` Conor Dooley 2023-10-16 13:17 ` Christoph Hellwig 2023-10-16 13:17 ` Christoph Hellwig 2023-10-16 17:16 ` Conor Dooley 2023-10-16 17:16 ` Conor Dooley 2023-10-16 5:47 ` [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 11:18 ` Robin Murphy 2023-10-16 11:18 ` Robin Murphy 2023-10-16 12:55 ` Conor Dooley 2023-10-16 12:55 ` Conor Dooley 2023-10-16 15:39 ` Lad, Prabhakar 2023-10-16 15:39 ` Lad, Prabhakar 2023-10-16 5:47 ` [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 12:53 ` Conor Dooley 2023-10-16 12:53 ` Conor Dooley 2023-10-16 15:40 ` Lad, Prabhakar 2023-10-16 15:40 ` Lad, Prabhakar 2023-10-17 7:59 ` Geert Uytterhoeven 2023-10-17 7:59 ` Geert Uytterhoeven 2023-10-16 5:47 ` [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043 Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 12:52 ` Conor Dooley 2023-10-16 12:52 ` Conor Dooley 2023-10-16 13:17 ` Christoph Hellwig 2023-10-16 13:17 ` Christoph Hellwig 2023-10-17 10:44 ` Geert Uytterhoeven 2023-10-17 10:44 ` Geert Uytterhoeven 2023-10-17 12:46 ` Christoph Hellwig 2023-10-17 12:46 ` Christoph Hellwig 2023-10-17 13:12 ` Geert Uytterhoeven 2023-10-17 13:12 ` Geert Uytterhoeven 2023-10-16 15:42 ` Lad, Prabhakar 2023-10-16 15:42 ` Lad, Prabhakar 2023-10-17 8:20 ` Geert Uytterhoeven 2023-10-17 8:20 ` Geert Uytterhoeven 2023-10-16 5:47 ` [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 11:18 ` Robin Murphy 2023-10-16 11:18 ` Robin Murphy 2023-10-16 15:44 ` Lad, Prabhakar 2023-10-16 15:44 ` Lad, Prabhakar 2023-10-16 5:47 ` [PATCH 06/12] dma-direct: add a CONFIG_ARCH_DMA_ALLOC symbol Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 11:33 ` Robin Murphy 2023-10-16 11:33 ` Robin Murphy 2023-10-16 5:47 ` [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 11:58 ` Robin Murphy [this message] 2023-10-16 11:58 ` Robin Murphy 2023-10-16 5:47 ` [PATCH 08/12] dma-direct: warn when coherent allocations aren't supported Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 11:59 ` Robin Murphy 2023-10-16 11:59 ` Robin Murphy 2023-10-16 5:47 ` [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-17 8:40 ` Geert Uytterhoeven 2023-10-17 8:40 ` Geert Uytterhoeven 2023-10-19 12:50 ` Greg Ungerer 2023-10-19 12:50 ` Greg Ungerer 2023-10-16 5:47 ` [PATCH 10/12] net: fec: use dma_alloc_noncoherent for data cache enabled coldfire Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-17 8:43 ` Geert Uytterhoeven 2023-10-17 8:43 ` Geert Uytterhoeven 2023-10-16 5:47 ` [PATCH 11/12] m68k: don't provide arch_dma_alloc for nommu/coldfire Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-16 5:47 ` [PATCH 12/12] m68k: remove unused includes from dma.c Christoph Hellwig 2023-10-16 5:47 ` Christoph Hellwig 2023-10-17 8:48 ` Geert Uytterhoeven 2023-10-17 8:48 ` Geert Uytterhoeven 2023-10-19 13:09 ` fix the non-coherent coldfire dma_alloc_coherent v2 Greg Ungerer 2023-10-19 13:09 ` Greg Ungerer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=fffcf35b-0da5-4df5-9224-5ac4e28b5f3a@arm.com \ --to=robin.murphy@arm.com \ --cc=conor@kernel.org \ --cc=geert+renesas@glider.be \ --cc=geert@linux-m68k.org \ --cc=gerg@linux-m68k.org \ --cc=hch@lst.de \ --cc=iommu@lists.linux.dev \ --cc=james.quinlan@broadcom.com \ --cc=linux-imx@nxp.com \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=m.szyprowski@samsung.com \ --cc=magnus.damm@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=shenwei.wang@nxp.com \ --cc=wei.fang@nxp.com \ --cc=xiaoning.wang@nxp.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.