Message ID | 20221019131128.237026-3-apatel@ventanamicro.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp331647wrs; Wed, 19 Oct 2022 06:37:16 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4VFHQEqYhmpPqHjrjKvFKFyXWJqXoLD5Q1dBYMJltV611bz4FJEQZUTy8iWql2zVVI6U1x X-Received: by 2002:a65:6d89:0:b0:421:94bc:cb89 with SMTP id bc9-20020a656d89000000b0042194bccb89mr7236741pgb.129.1666186635896; Wed, 19 Oct 2022 06:37:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666186635; cv=none; d=google.com; s=arc-20160816; b=xcfC0vkmMXZlklwiwHSLkMBLSQHtkjdBGpmMdz+l9aBqZtIhXHcR2Du6yleBNNB9yB gjxNm4mByrbjRAOeyfd+GqdzTwPpVheJVNwvNYMLRy215sOw///QoaJS6RAuZtH+rQwS o0tpzUdG2GWziPBYf9QWVQOeTvrWCju+jwCsOdGVx9Td2gHn3X9WOorIxV5M6NLIDxeJ wWCVuUsDSSjF/Dy1tXAPz2qpFki4THOKEiVTr8jz2zAwYF8dNtUlUEDzid/R79hX68U0 sON/UZs/qnWKbtPtY8mdbdn1oZIgmiE99TXNSpjjvfJJ14yeaWU9jOdMdKiAfBGZ3knA Eomw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=vAvEVwdPVzOcq2kBtufcX9nitBNib2gQ4gtkOEEFeSI=; b=HXPa1EbdR/kuaJ8hfQPQHVvtZfhq2QQWVHF4OLSpBjIGRi4mXz6t71HPRrZ9N9QAlW wGlnK5+mSFpSAO+C8Q6NkeRnXKrG9tzSH9nT1W0szC5+NwZT1aPG2V5eFL4hOrPGpT6b rVJrm9QYIwl4ZJdWlN3g2DwXWsHIoORkYD5f5eUIOJTBIS8V7NmgLtk+0hRRwtDB7XqF b9/jxNMlTQdpAn1V93ydD6jYzwLtHfwrFP98/ZQahyuwQ+Sgia70tlTgh0bnCvYopI2B 5kfynzX2Fd8ScecxhofHouBbG6KpsKqBJsAo/tZyPr+KKDEDfhW1tLAVJ/TMQmEPA0r4 zjnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=lxyzgM77; 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 9-20020a631849000000b0045f83471400si18574573pgy.328.2022.10.19.06.37.01; Wed, 19 Oct 2022 06:37:15 -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; dkim=pass header.i=@ventanamicro.com header.s=google header.b=lxyzgM77; 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 S231519AbiJSN1J (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 09:27:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230383AbiJSN0p (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 09:26:45 -0400 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 249A01DC80F for <linux-kernel@vger.kernel.org>; Wed, 19 Oct 2022 06:13:08 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id x188so19186821oig.5 for <linux-kernel@vger.kernel.org>; Wed, 19 Oct 2022 06:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vAvEVwdPVzOcq2kBtufcX9nitBNib2gQ4gtkOEEFeSI=; b=lxyzgM77oVhyr2xYFxJj6wgQvry6rw4Y/+zIvaG6JfmYtSzQ+X/1aPsePwBNrnegwI UrY3/A1/YLrrc1SIB0jp8+zD7aA98y9QtCArUpqYXnMw5Dl6VWnG3iDZuyf1BgGGohqT 1l9CyxXHnpqjwurbYuT9nD7l0kpliUcju0mwn+yFEAvwgXbH6lu8+EDbPW1ou1EWw4d0 i8arRfQLRw/k0jmr0IQml/LWHNUCdyXuEptr8wqAxovxLLP0t6dVC1zBEVwFmRU6HrPR foFXA9X8UDYRdXrxUc+XpDAQmh4P+zLMHzd7Q4Ct6xrxImFMYovLYXg9s6KdCxtlBdrg 3gMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vAvEVwdPVzOcq2kBtufcX9nitBNib2gQ4gtkOEEFeSI=; b=vjuYNauTUwzvhyf5vtFOPGDYvN6XWyYkh64tDz9iAL0KTcDB2P9cdFTpbWyLd4rB9a j908noITuEmRd5RCKNaeQKYMeCnGfBX5mNAGAlkxVHvX22mAejIzqZRLkFccLb4xI+mF 2IDrM+nxTfBBhBnlAzhIlJKrKHVrasT3a1HAdFc04h7mt/JVGws0WqeDAbY5TPplE3lO zXcfa0DGtBn0h34hY+CdDqsgQ32mCaP5J6oLttI35WkpnlWABRs1tE3RM9meVbs1qiZQ IUNXXKbSXSZ4CAO2DOympHRKZD/9hFDSNZSRFPPkO41Hj48tKLHHTp+1JkBh/jAQTY2h jnNg== X-Gm-Message-State: ACrzQf2cWQzrpesvBmYog8hgw1D3ayZ2DRs43PvVeuDiJjsvCwlLiDtH QvgmbdThcapYqDcY8cHErFQJF+SXtI871g== X-Received: by 2002:a17:90b:4c52:b0:20d:7917:4cb3 with SMTP id np18-20020a17090b4c5200b0020d79174cb3mr45614039pjb.6.1666185105397; Wed, 19 Oct 2022 06:11:45 -0700 (PDT) Received: from anup-ubuntu64-vm.. ([171.76.82.102]) by smtp.gmail.com with ESMTPSA id n12-20020a170902d2cc00b00172897952a0sm10934478plc.283.2022.10.19.06.11.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Oct 2022 06:11:44 -0700 (PDT) From: Anup Patel <apatel@ventanamicro.com> To: Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com> Cc: Atish Patra <atishp@atishpatra.org>, Heiko Stuebner <heiko@sntech.de>, Anup Patel <anup@brainfault.org>, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Anup Patel <apatel@ventanamicro.com>, Mayuresh Chitale <mchitale@ventanamicro.com> Subject: [PATCH v4 2/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Date: Wed, 19 Oct 2022 18:41:26 +0530 Message-Id: <20221019131128.237026-3-apatel@ventanamicro.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221019131128.237026-1-apatel@ventanamicro.com> References: <20221019131128.237026-1-apatel@ventanamicro.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, 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?1747123318271142042?= X-GMAIL-MSGID: =?utf-8?q?1747123318271142042?= |
Series |
Add PMEM support for RISC-V
|
|
Commit Message
Anup Patel
Oct. 19, 2022, 1:11 p.m. UTC
Currently, all flavors of ioremap_xyz() function maps to the generic ioremap() which means any ioremap_xyz() call will always map the target memory as IO using _PAGE_IOREMAP page attributes. This breaks ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP page attributes. To address above (just like other architectures), we implement RISC-V specific ioremap_cache() and ioremap_wc() which maps memory using page attributes as defined by the Svpbmt specification. Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> --- arch/riscv/include/asm/io.h | 10 ++++++++++ arch/riscv/include/asm/pgtable.h | 2 ++ 2 files changed, 12 insertions(+)
Comments
Am Mittwoch, 19. Oktober 2022, 15:11:26 CEST schrieb Anup Patel: > Currently, all flavors of ioremap_xyz() function maps to the generic > ioremap() which means any ioremap_xyz() call will always map the > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > page attributes. > > To address above (just like other architectures), we implement RISC-V > specific ioremap_cache() and ioremap_wc() which maps memory using page > attributes as defined by the Svpbmt specification. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> Wasn't there discussion around those functions in general in v2? In any case, the patch doesn't break anything on qemu and d1, so Tested-by: Heiko Stuebner <heiko@sntech.de> > --- > arch/riscv/include/asm/io.h | 10 ++++++++++ > arch/riscv/include/asm/pgtable.h | 2 ++ > 2 files changed, 12 insertions(+) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > index 92080a227937..92a31e543388 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > #define outsq(addr, buffer, count) __outsq(PCI_IOBASE + (addr), buffer, count) > #endif > > +#ifdef CONFIG_MMU > +#define ioremap_wc(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) > +#endif > + > #include <asm-generic/io.h> > > +#ifdef CONFIG_MMU > +#define ioremap_cache(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_KERNEL) > +#endif > + > #endif /* _ASM_RISCV_IO_H */ > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 7ec936910a96..346b7c1a3eeb 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) > +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ > + _PAGE_NOCACHE) > #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; >
On Wed, Oct 19, 2022 at 7:49 PM Heiko Stuebner <heiko@sntech.de> wrote: > > Am Mittwoch, 19. Oktober 2022, 15:11:26 CEST schrieb Anup Patel: > > Currently, all flavors of ioremap_xyz() function maps to the generic > > ioremap() which means any ioremap_xyz() call will always map the > > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > > page attributes. > > > > To address above (just like other architectures), we implement RISC-V > > specific ioremap_cache() and ioremap_wc() which maps memory using page > > attributes as defined by the Svpbmt specification. > > > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > Wasn't there discussion around those functions in general in v2? Yes, there was discussion about a few drivers using ioremap_xyz() which is discouraged and drivers should use memremap(). We still need the arch specific ioremap_xyz() functions/macros added by this patch because these are required by the generic kernel memremap() implementation (refer, kernel/iomem.c). > > In any case, the patch doesn't break anything on qemu and d1, so > > Tested-by: Heiko Stuebner <heiko@sntech.de> Regards, Anup > > > > --- > > arch/riscv/include/asm/io.h | 10 ++++++++++ > > arch/riscv/include/asm/pgtable.h | 2 ++ > > 2 files changed, 12 insertions(+) > > > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > > index 92080a227937..92a31e543388 100644 > > --- a/arch/riscv/include/asm/io.h > > +++ b/arch/riscv/include/asm/io.h > > @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > > #define outsq(addr, buffer, count) __outsq(PCI_IOBASE + (addr), buffer, count) > > #endif > > > > +#ifdef CONFIG_MMU > > +#define ioremap_wc(addr, size) \ > > + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) > > +#endif > > + > > #include <asm-generic/io.h> > > > > +#ifdef CONFIG_MMU > > +#define ioremap_cache(addr, size) \ > > + ioremap_prot((addr), (size), _PAGE_KERNEL) > > +#endif > > + > > #endif /* _ASM_RISCV_IO_H */ > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > > index 7ec936910a96..346b7c1a3eeb 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > > > #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) > > +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ > > + _PAGE_NOCACHE) > > #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > > > extern pgd_t swapper_pg_dir[]; > > > > > >
On Wed, Oct 19, 2022, at 18:10, Anup Patel wrote: > On Wed, Oct 19, 2022 at 7:49 PM Heiko Stuebner <heiko@sntech.de> wrote: >> >> Am Mittwoch, 19. Oktober 2022, 15:11:26 CEST schrieb Anup Patel: >> > Currently, all flavors of ioremap_xyz() function maps to the generic >> > ioremap() which means any ioremap_xyz() call will always map the >> > target memory as IO using _PAGE_IOREMAP page attributes. This breaks >> > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory >> > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP >> > page attributes. >> > >> > To address above (just like other architectures), we implement RISC-V >> > specific ioremap_cache() and ioremap_wc() which maps memory using page >> > attributes as defined by the Svpbmt specification. >> > >> > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") >> > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> >> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> >> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> >> >> Wasn't there discussion around those functions in general in v2? > > Yes, there was discussion about a few drivers using ioremap_xyz() > which is discouraged and drivers should use memremap(). > > We still need the arch specific ioremap_xyz() functions/macros > added by this patch because these are required by the generic > kernel memremap() implementation (refer, kernel/iomem.c). There is a difference between the strongly discouraged ioremap_cache() that pretty much has no valid users, and the ioremap_wt/ioremap_wc functions that are sometimes used for mapping video framebuffer or similar. It should be sufficient to provide a arch_memremap_wb() and no ioremap_cache() to make memremap() work correctly. Arnd
On Thu, Oct 20, 2022 at 2:20 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, Oct 19, 2022, at 18:10, Anup Patel wrote: > > On Wed, Oct 19, 2022 at 7:49 PM Heiko Stuebner <heiko@sntech.de> wrote: > >> > >> Am Mittwoch, 19. Oktober 2022, 15:11:26 CEST schrieb Anup Patel: > >> > Currently, all flavors of ioremap_xyz() function maps to the generic > >> > ioremap() which means any ioremap_xyz() call will always map the > >> > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > >> > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > >> > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > >> > page attributes. > >> > > >> > To address above (just like other architectures), we implement RISC-V > >> > specific ioremap_cache() and ioremap_wc() which maps memory using page > >> > attributes as defined by the Svpbmt specification. > >> > > >> > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > >> > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > >> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > >> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > >> > >> Wasn't there discussion around those functions in general in v2? > > > > Yes, there was discussion about a few drivers using ioremap_xyz() > > which is discouraged and drivers should use memremap(). > > > > We still need the arch specific ioremap_xyz() functions/macros > > added by this patch because these are required by the generic > > kernel memremap() implementation (refer, kernel/iomem.c). > > There is a difference between the strongly discouraged > ioremap_cache() that pretty much has no valid users, and > the ioremap_wt/ioremap_wc functions that are sometimes used > for mapping video framebuffer or similar. > > It should be sufficient to provide a arch_memremap_wb() > and no ioremap_cache() to make memremap() work correctly. > Okay, I will simplify this patch to only implement arch_memremap_wb(). This will make the MEMREMAP_WB flag to work correctly but other MEMREMAP_xyz flags will always use non-cacheable IO mappings. Regards, Anup
diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h index 92080a227937..92a31e543388 100644 --- a/arch/riscv/include/asm/io.h +++ b/arch/riscv/include/asm/io.h @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) #define outsq(addr, buffer, count) __outsq(PCI_IOBASE + (addr), buffer, count) #endif +#ifdef CONFIG_MMU +#define ioremap_wc(addr, size) \ + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) +#endif + #include <asm-generic/io.h> +#ifdef CONFIG_MMU +#define ioremap_cache(addr, size) \ + ioremap_prot((addr), (size), _PAGE_KERNEL) +#endif + #endif /* _ASM_RISCV_IO_H */ diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 7ec936910a96..346b7c1a3eeb 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; #define PAGE_TABLE __pgprot(_PAGE_TABLE) #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ + _PAGE_NOCACHE) #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) extern pgd_t swapper_pg_dir[];