From: Robin Murphy <robin.murphy@arm.com>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>, linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
tsbogend@alpha.franken.de, mpe@ellerman.id.au,
paul.walmsley@sifive.com, palmer@dabbelt.com, robh+dt@kernel.org,
hch@lst.de, m.szyprowski@samsung.com,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH 3/3] of: address: Use dma_default_coherent to determine default coherency
Date: Wed, 22 Feb 2023 17:24:36 +0000 [thread overview]
Message-ID: <e9d882f4-d57d-f6b4-7ae0-bbfea0f5aa59@arm.com> (raw)
In-Reply-To: <20230222133712.8079-4-jiaxun.yang@flygoat.com>
On 2023-02-22 13:37, Jiaxun Yang wrote:
> As for now all arches have dma_default_coherent matched with default
> DMA coherency for of devices, so there is no need to have a standalone
> config option.
>
> This also fixes a case that for some MIPS platforms, coherency information
> is not carried in devicetree and kernel will override dma_default_coherent
> at early boot.
>
> Note for PowerPC: CONFIG_OF_DMA_DEFUALT_COHERENT was only selected when
> CONFIG_NOT_COHERENT_CACHE is false, in this case dma_default_coherent will
> be true, so it still matches present behavior.
>
> Note for RISC-V: dma_default_coherent is set to true at init code in this
> series.
OK, so the fundamental problem here is that we have two slightly
different conflicting mechanisms, the ex-PowerPC config option, and the
ex-MIPS dma_default_coherent for which of_dma_is_coherent() has
apparently been broken forever.
I'd agree that it's worth consolidating the two, but please separate out
the fix as below, so it's feasible to backport without having to muck
about in arch code.
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
> arch/powerpc/Kconfig | 1 -
> arch/riscv/Kconfig | 1 -
> drivers/of/Kconfig | 4 ----
> drivers/of/address.c | 2 +-
> 4 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2c9cdf1d8761..c67e5da714f7 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -272,7 +272,6 @@ config PPC
> select NEED_PER_CPU_PAGE_FIRST_CHUNK if PPC64
> select NEED_SG_DMA_LENGTH
> select OF
> - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
> select OF_EARLY_FLATTREE
> select OLD_SIGACTION if PPC32
> select OLD_SIGSUSPEND
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 1d46a268ce16..406c6816d289 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -119,7 +119,6 @@ config RISCV
> select MODULES_USE_ELF_RELA if MODULES
> select MODULE_SECTIONS if MODULES
> select OF
> - select OF_DMA_DEFAULT_COHERENT
> select OF_EARLY_FLATTREE
> select OF_IRQ
> select PCI_DOMAINS_GENERIC if PCI
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 644386833a7b..e40f10bf2ba4 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -102,8 +102,4 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> -config OF_DMA_DEFAULT_COHERENT
> - # arches should select this if DMA is coherent by default for OF devices
> - bool
> -
> endif # OF
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 4c0b169ef9bf..23ade4919853 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -1103,7 +1103,7 @@ phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
> bool of_dma_is_coherent(struct device_node *np)
> {
> struct device_node *node;
> - bool is_coherent = IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT);
> + bool is_coherent = dma_default_coherent;
AFAICS, all you should actually need is a single self-contained addition
here, something like:
+ /*
+ * DT-based MIPS doesn't use OF_DMA_DEFAULT_COHERENT, but
+ * might override the system-wide default at runtime.
+ */
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+ defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
+ defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
+ is_coherent = dma_default_coherent;
+#endif
>
> node = of_node_get(np);
>
Then *after* that's fixed, we can do a more comprehensive refactoring to
merge the two mechanisms properly. FWIW I think I'd prefer an approach
closer to the first one, where config options control the initial value
of dma_default_coherent rather than architectures having to override it
unconditionally (and TBH I'd also like to have a generic config symbol
for whether an arch supports per-device coherency or not).
Thanks,
Robin.
next prev parent reply other threads:[~2023-02-22 17:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 13:37 [PATCH 0/3] Use dma_default_coherent for devicetree default coherency Jiaxun Yang
2023-02-22 13:37 ` [PATCH 1/3] dma-mapping: Provide a fallback dma_default_coherent Jiaxun Yang
2023-02-22 13:37 ` [PATCH 2/3] riscv: Set dma_default_coherent to true Jiaxun Yang
2023-02-22 14:50 ` Conor Dooley
2023-02-22 15:55 ` Jiaxun Yang
2023-02-22 16:02 ` Conor Dooley
2023-02-22 16:20 ` Jiaxun Yang
2023-02-22 16:59 ` Conor Dooley
2023-02-22 13:37 ` [PATCH 3/3] of: address: Use dma_default_coherent to determine default coherency Jiaxun Yang
2023-02-22 17:24 ` Robin Murphy [this message]
2023-02-22 17:57 ` Jiaxun Yang
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=e9d882f4-d57d-f6b4-7ae0-bbfea0f5aa59@arm.com \
--to=robin.murphy@arm.com \
--cc=hch@lst.de \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=mpe@ellerman.id.au \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=tsbogend@alpha.franken.de \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).