From: Xi Ruoyao <xry111@xry111.site>
To: Huacai Chen <chenhuacai@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>
Cc: loongarch@lists.linux.dev, Xuefeng Li <lixuefeng@loongson.cn>,
Guo Ren <guoren@kernel.org>, Xuerui Wang <kernel@xen0n.name>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn
Subject: Re: [PATCH] LoongArch: Make WriteCombine configurable for ioremap()
Date: Tue, 14 Mar 2023 17:40:54 +0800 [thread overview]
Message-ID: <21f5aba50b7732b48d2610a5015186adf6bdfb38.camel@xry111.site> (raw)
In-Reply-To: <20230314085433.4078119-1-chenhuacai@loongson.cn>
On Tue, 2023-03-14 at 16:54 +0800, Huacai Chen wrote:
> LoongArch maintains cache coherency in hardware, but when works with
> LS7A chipsets the WUC attribute (Weak-ordered UnCached, which is similar
> to WriteCombine) is out of the scope of cache coherency machanism for
> PCIe devices (this is a PCIe protocol violation, may be fixed in newer
> chipsets).
IIUC all launched LS7A models (7A1000 and 7A2000) suffers this issue?
> This means WUC can only used for write-only memory regions now, so this
> option is disabled by default (means WUC falls back to SUC for ioremap).
> You can enable this option if the kernel is ensured to run on bug-free
> hardwares.
Hmm, is it possible to make a PCI quirk so SUC/WUC will be decided
automatically from the vendor:device ID of the PCI root controller?
Then we don't need to rely on the user or distro maintainer to select an
option. I see there is already many architecture-dependant #if
directives in drivers/pci/quirks.c so I guess such a quirk is acceptable
in PCI tree...
If a PCI quirk is not possible, then is it possible to make a kernel
command line option, leaving this CONFIG as the default value of the
option? I guess in the future many LoongArch users will just install a
binary distro, then it would be much easier to edit grub.cfg than
rebuilding the kernel when they finally buy a compliant PCIe controller.
> Suggested-by: WANG Xuerui <kernel@xen0n.name>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
> arch/loongarch/Kconfig | 14 ++++++++++++++
> arch/loongarch/include/asm/io.h | 5 +++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index 0d11738a861a..e3f5c422636f 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -446,6 +446,20 @@ config ARCH_IOREMAP
> protection support. However, you can enable LoongArch DMW-based
> ioremap() for better performance.
>
> +config ARCH_WRITECOMBINE
> + bool "Enable WriteCombine (WUC) for ioremap()"
> + help
> + LoongArch maintains cache coherency in hardware, but with LS7A
> + chipsets the WUC attribute (Weak-ordered UnCached, which is similar
> + to WriteCombine) is out of the scope of cache coherency machanism
> + for PCIe devices (this is a PCIe protocol violation, may be fixed
> + in newer chipsets).
> +
> + This means WUC can only used for write-only memory regions now, so
> + this option is disabled by default (means WUC falls back to SUC for
> + ioremap). You can enable this option if the kernel is ensured to run
> + on bug-free hardwares.
> +
> config ARCH_STRICT_ALIGN
> bool "Enable -mstrict-align to prevent unaligned accesses" if EXPERT
> default y
> diff --git a/arch/loongarch/include/asm/io.h b/arch/loongarch/include/asm/io.h
> index 402a7d9e3a53..079ef897ed1a 100644
> --- a/arch/loongarch/include/asm/io.h
> +++ b/arch/loongarch/include/asm/io.h
> @@ -54,8 +54,13 @@ static inline void __iomem *ioremap_prot(phys_addr_t offset, unsigned long size,
> * @offset: bus address of the memory
> * @size: size of the resource to map
> */
> +#ifdef CONFIG_ARCH_WRITECOMBINE
> #define ioremap_wc(offset, size) \
> ioremap_prot((offset), (size), pgprot_val(PAGE_KERNEL_WUC))
> +#else
> +#define ioremap_wc(offset, size) \
> + ioremap_prot((offset), (size), pgprot_val(PAGE_KERNEL_SUC))
> +#endif
>
> #define ioremap_cache(offset, size) \
> ioremap_prot((offset), (size), pgprot_val(PAGE_KERNEL))
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
next prev parent reply other threads:[~2023-03-14 9:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 8:54 Huacai Chen
2023-03-14 9:40 ` Xi Ruoyao [this message]
2023-03-14 10:02 ` Huacai Chen
2023-03-14 10:10 ` Xi Ruoyao
2023-03-14 10:11 ` WANG Xuerui
2023-03-14 11:08 ` Huacai Chen
2023-03-14 10:08 ` WANG Xuerui
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=21f5aba50b7732b48d2610a5015186adf6bdfb38.camel@xry111.site \
--to=xry111@xry111.site \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=guoren@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=loongarch@lists.linux.dev \
--cc=loongson-kernel@lists.loongnix.cn \
/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
all inboxes | Powered by JetHome®