Message ID | 20230314085433.4078119-1-chenhuacai@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1646598wrd; Tue, 14 Mar 2023 02:12:27 -0700 (PDT) X-Google-Smtp-Source: AK7set9pGtwGj5XcN6DFv73juykMp5budzpG5Xag6b98e9nHNslQOI5hDSscCQL3xfr0kYBWaBEd X-Received: by 2002:a17:902:e5d1:b0:1a0:468b:4b1f with SMTP id u17-20020a170902e5d100b001a0468b4b1fmr6894305plf.0.1678785147532; Tue, 14 Mar 2023 02:12:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678785147; cv=none; d=google.com; s=arc-20160816; b=Ty3MPvyut48/xikDWGZ148wE9yAiXe3KapVEA2Dl+huaxniRnyOndLmFWrym7MI/yu sq0IzJZ4xMOLuEJSF1yScMQmlv5suwq5UHwfVKZeBOQqJKSIb+g1QyWAE2t9hJmNxFzx KfKp55Y14WMzugwJ9poLQy6xbsArAgMkypW6OZvJeiBT4GbQkzLVfu+JIseUd9x16dWD IseaGFWC6rsO1DsIzGvdusgWCgLxPkwsWhCyXHoIGj73G6hJiFoQI+ldlLwLch+qAu5F k0Gxbc1o49GN53ie/oNvXPvpgHFOMmmSgqhODyKI1i1j97YX0ZxwE+giR6K0r/QlfDvI sTDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=/xzwjdqEbxlNB+CRstZUiLXGhf5swPN8oY6B6jRSfCg=; b=0pwBMgx0PmjA8bE6XEkpwj1PJU8HNjG0qH3P7MiQjpYB7ylJvL6dkwWE4Y4FMPiHp4 Gwj2HqHBdYhcR0ieeyVHe/Xjo2wcySUUntXy8BPiUYK+daqoAnF+cN2eQkEhr1ih2Kq2 OtOM3U7u9YKP+pGO18U6JyvSTefiYPz2tWQjFWAQWykuMuID3lKhxBV4gGiiK82f+0RY u8+7JmC4/EzXxyXBP3l/mJO9Hxaq7e0fQ0keGnRDv/5oKxEgK2Rk0/cnNSFY7KHefoEE uQlp4NYNiwOKOcOJ0uxs4l2bSkq23hpX/Rt7mV4ox5e9FAlJAYFcfu0z8RZCCnKoQ07/ LDXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ij21-20020a170902ab5500b0019c9999f4dcsi2026644plb.230.2023.03.14.02.12.14; Tue, 14 Mar 2023 02:12:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229801AbjCNIzM (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Tue, 14 Mar 2023 04:55:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230174AbjCNIyx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Mar 2023 04:54:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64CA1D308 for <linux-kernel@vger.kernel.org>; Tue, 14 Mar 2023 01:54:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F16806164D for <linux-kernel@vger.kernel.org>; Tue, 14 Mar 2023 08:54:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38380C433D2; Tue, 14 Mar 2023 08:54:45 +0000 (UTC) From: Huacai Chen <chenhuacai@loongson.cn> To: 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, Huacai Chen <chenhuacai@loongson.cn> Subject: [PATCH] LoongArch: Make WriteCombine configurable for ioremap() Date: Tue, 14 Mar 2023 16:54:33 +0800 Message-Id: <20230314085433.4078119-1-chenhuacai@loongson.cn> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760333815188412751?= X-GMAIL-MSGID: =?utf-8?q?1760333815188412751?= |
Series |
LoongArch: Make WriteCombine configurable for ioremap()
|
|
Commit Message
Huacai Chen
March 14, 2023, 8:54 a.m. UTC
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).
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.
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(+)
Comments
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))
Hi, Ruoyao, On Tue, Mar 14, 2023 at 5:41 PM Xi Ruoyao <xry111@xry111.site> wrote: > > 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? Yes, very unfortunately, but this issue is only observed in the amdgpu driver now. > > > 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... Not a good idea, pci quirks need too long a time to review, and we don't know when this issue can be fixed in hardware. > > 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. If we use command line parameter, we can remove this Kconfig option. Huacai > > > 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
On 2023/3/14 16:54, Huacai Chen wrote: > LoongArch maintains cache coherency in hardware, but when works with but when paired with current LS7A chipsets > 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 which may be fixed > 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). by default, making ioremap_wc silently fallback to SUC. > You can enable this option if the kernel is ensured to run on bug-free > hardwares. if you can ensure the kernel will always be running on hardware without this bug > > 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. Fix text here like with the commit message. Then add a "If unsure, say N" line to serve as a warning? > + > 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)) I'll test this later tonight with my RX 6400. See you in a few hours...
On Tue, 2023-03-14 at 18:02 +0800, Huacai Chen wrote: > > 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... > Not a good idea, pci quirks need too long a time to review, and we > don't know when this issue can be fixed in hardware. How about make a PCI fixup in arch/loongarch/pci/pci.c then? I think we just need to set a flag in the fixup, then check the flag in ioremap_wc...
On 2023/3/14 18:02, Huacai Chen wrote: > Hi, Ruoyao, > > On Tue, Mar 14, 2023 at 5:41 PM Xi Ruoyao <xry111@xry111.site> wrote: >> >> 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? > Yes, very unfortunately, but this issue is only observed in the amdgpu > driver now. It's PCIe protocol violation after all, and we can never be sure about the vast amount of hardware untested on loongarch after all. Miserable as the performance hit may get, we don't really have another choice, unfortunately. Someone needs to lecture the LS7A team real hard! >> >>> 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... > Not a good idea, pci quirks need too long a time to review, and we > don't know when this issue can be fixed in hardware. > >> >> 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. > If we use command line parameter, we can remove this Kconfig option. An option is still useful as specifying the compile-time default for such a kernel parameter, IMO.
On Tue, Mar 14, 2023 at 6:12 PM WANG Xuerui <kernel@xen0n.name> wrote: > > On 2023/3/14 18:02, Huacai Chen wrote: > > Hi, Ruoyao, > > > > On Tue, Mar 14, 2023 at 5:41 PM Xi Ruoyao <xry111@xry111.site> wrote: > >> > >> 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? > > Yes, very unfortunately, but this issue is only observed in the amdgpu > > driver now. > > It's PCIe protocol violation after all, and we can never be sure about > the vast amount of hardware untested on loongarch after all. Miserable > as the performance hit may get, we don't really have another choice, > unfortunately. Someone needs to lecture the LS7A team real hard! > > >> > >>> 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... > > Not a good idea, pci quirks need too long a time to review, and we > > don't know when this issue can be fixed in hardware. > > > >> > >> 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. > > If we use command line parameter, we can remove this Kconfig option. > > An option is still useful as specifying the compile-time default for > such a kernel parameter, IMO. I will update commit messages and add a kernel parameter, thanks. Huacai > > -- > WANG "xen0n" Xuerui > > Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/ > >
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))