From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0A67AC4332F for ; Wed, 4 Jan 2023 09:57:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) id BFDA7C433F0; Wed, 4 Jan 2023 09:57:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC297C433D2; Wed, 4 Jan 2023 09:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672826238; bh=nn4+G9YSkrL4uki7DFfbSpQY7XWkWI7/WUJbCvL0pIQ=; h=Date:From:To:List-Id:CC:Subject:In-Reply-To:References:From; b=PBUi/t5ZbzZMPnMtBTmgOinuQHcD+Sw2nd/7Xs6xM9Z+FvIpIFmQfn0RnoiomteWa Qdz61HxasUj+Yl24KoX3MN0c7+FNN9WEtoo31H24ddfeXcaAF7axFW6ovdCRoDCdeQ 2XigMFpNwE7jfnjir8p9y5V9BIX9RW55TRVdIpoKuDuSXPuOO9V7gi+LWqTWB9MQ8L GTLO2qSkb95djwjLw3VlKyYxiiHXli5kGUHG65c3bywTleN8tQmhA6CVrUx/jLsrC2 oZ7Mh0QN+qPmsvn4BouHbPWYSjZRfmtZiEfIZf0HczI7qnWc1w1UDb0NobEFzgtJES E4mrYoofh4wgQ== Date: Wed, 04 Jan 2023 09:57:16 +0000 From: Conor Dooley To: Ben Dooks , arnd@arndb.de, palmer@dabbelt.com, prabhakar.csengg@gmail.com List-Id: CC: Conor Dooley , ajones@ventanamicro.com, aou@eecs.berkeley.edu, apatel@ventanamicro.com, atishp@rivosinc.com, biju.das.jz@bp.renesas.com, devicetree@vger.kernel.org, geert@linux-m68k.org, guoren@kernel.org, hch@infradead.org, heiko@sntech.de, jszhang@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-riscv@lists.infradead.org, magnus.damm@gmail.com, nathan@kernel.org, paul.walmsley@sifive.com, philipp.tomsich@vrull.eu, prabhakar.mahadev-lad.rj@bp.renesas.com, robh+dt@kernel.org, samuel@sholland.org, soc@kernel.org, Daire McNamara Subject: =?US-ASCII?Q?Re=3A_=5BRFC_v5=2E1_9/9=5D_=5BDON=27T_APPLY=5D_cache=3A_si?= =?US-ASCII?Q?five-ccache=3A_add_cache_flushing_capability?= User-Agent: K-9 Mail for Android In-Reply-To: <6ef122f6-12fa-777f-b4e7-a02531380391@codethink.co.uk> References: <20230103210400.3500626-10-conor@kernel.org> <6ef122f6-12fa-777f-b4e7-a02531380391@codethink.co.uk> Message-ID: <298CA44E-DF97-4790-9CB1-F3ACD43E71FF@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4 January 2023 09:45:30 GMT, Ben Dooks wrote: >On 03/01/2023 21:04, Conor Dooley wrote: >> From: Daire McNamara >>=20 >> SiFive L2 cache controller can flush L2 cache=2E Expose this capability= via >> driver=2E >>=20 >> Signed-off-by: Daire McNamara >> [Conor: rebase on top of move to cache subsystem] >> Signed-off-by: Conor Dooley >> --- >> This commit needs more work, and a way to enable it from errata=2E I've >> not gone and done this as PolarFire SoC has archid etc all set to zero= =2E >> So we need to go figure out a workaround for this, before adding in >> errata enabling code for this=2E I've included it here as a second user= of >> the cache management stuff, since what's currently upstream for the >> ccache driver does not do any cache management=2E > >I think errata isn't the right word here, it's more of a system requireme= nt for anything that isn't coherent=2E All the SiFive systems >I have are coherent so won't need this=2E That's the mechanism we currently have for turning this stuff on=2E This patch is going away anyway for an actual submission, so we can debate= this sort of thing when it shows up for real=2E This patch does certainly seem to be distracting from the main point, whic= h was supposed to be the interface to arch/riscv=2E >> --- >> drivers/cache/sifive_ccache=2Ec | 45 ++++++++++++++++++++++++++++++++= +++ >> 1 file changed, 45 insertions(+) >>=20 >> diff --git a/drivers/cache/sifive_ccache=2Ec b/drivers/cache/sifive_cca= che=2Ec >> index 47e7d6557f85=2E=2E3c00f205bace 100644 >> --- a/drivers/cache/sifive_ccache=2Ec >> +++ b/drivers/cache/sifive_ccache=2Ec >> @@ -9,12 +9,14 @@ >> #define pr_fmt(fmt) "CCACHE: " fmt >> #include >> +#include >> #include >> #include >> #include >> #include >> #include >> #include >> +#include >> #include >> #define SIFIVE_CCACHE_DIRECCFIX_LOW 0x100 >> @@ -42,11 +44,15 @@ >> #define SIFIVE_CCACHE_WAYENABLE 0x08 >> #define SIFIVE_CCACHE_ECCINJECTERR 0x40 >> +#define SIFIVE_CCACHE_FLUSH64 0x200 >> +#define SIFIVE_CCACHE_FLUSH32 0x240 >> + >> #define SIFIVE_CCACHE_MAX_ECCINTR 4 >> static void __iomem *ccache_base; >> static int g_irq[SIFIVE_CCACHE_MAX_ECCINTR]; >> static struct riscv_cacheinfo_ops ccache_cache_ops; >> +static struct riscv_cache_maint_ops ccache_cmos; >> static int level; >> enum { >> @@ -205,6 +211,42 @@ static irqreturn_t ccache_int_handler(int irq, voi= d *device) >> return IRQ_HANDLED; >> } >> +static void sifive_ccache_dma_wback_inv(void* vaddr, unsigned long s= ize) >> +{ >> + void * __iomem flush =3D ccache_base + SIFIVE_CCACHE_FLUSH64; >> + phys_addr_t start =3D virt_to_phys(vaddr); >> + phys_addr_t aligned_start =3D start & ~0x3f; >> + u64 addr; >> + u64 end; >> + u64 aligned_end; >> + >> + size +=3D start - aligned_start; >> + end =3D start + size; >> + aligned_end =3D end +=3D 0x3f; > >I think you meant + 0x3f here=2E There is an align macro in the kernel >headers, and I'm not sure by inspection if you'd miss the last line >with this code=2E > >> + aligned_end &=3D ~0x3f; >> + >> + for (addr =3D aligned_start; addr < aligned_end; addr +=3D 64) >> + writeq(addr, flush); >> +} > >The p550 manual states that the zero device flush method is quicker for >any large area flush=2E However not sure what that level is and whether i= t >is worth dealing with here? If so we need to have the L3 zero are mapped= =2E > >> + >> +static void sifive_ccache_cmo(unsigned int cache_size, void *vaddr, si= ze_t size, >> + int dir, int ops) >> +{ > >technically dir should have been of type "enum dma_data_direction" > >> + switch (dir) { >> + case DMA_TO_DEVICE: >> + sifive_ccache_dma_wback_inv(vaddr, size); >> + break; >> + case DMA_FROM_DEVICE: >> + sifive_ccache_dma_wback_inv(vaddr, size); >> + break; >> + case DMA_BIDIRECTIONAL: >> + sifive_ccache_dma_wback_inv(vaddr, size); >> + break; >> + default: >> + break; >> + } >> +} > >I'm not sure why you'd bother checking the dir here, the cache can >only be flushed (I hope DMA_FROM_DEVICE is done /before/ the DMA op)=2E > >You could have saved yourself an include if just ignoring dir=2E > >> + >> static int __init sifive_ccache_init(void) >> { >> struct device_node *np; >> @@ -254,6 +296,9 @@ static int __init sifive_ccache_init(void) >> ccache_cache_ops=2Eget_priv_group =3D ccache_get_priv_group; >> riscv_set_cacheinfo_ops(&ccache_cache_ops); >> + ccache_cmos=2Ecmo_patchfunc =3D sifive_ccache_cmo; >> + riscv_set_cache_maint_ops(&ccache_cmos); >> + >> #ifdef CONFIG_DEBUG_FS >> setup_sifive_debug(); >> #endif > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 955BAC4332F for ; Wed, 4 Jan 2023 09:59:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:References: In-Reply-To:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IEpaY4PzPFzBnCu+7FfPsIs+8dFbbNRHr+aFbx6sj7k=; b=OQipPpU/5Nv0hi nRq64CYzfAC27L+U2tBhOdmZgSwd7noUqYsJxUmnHFkP4AhYNG1UQ2meqiG9woYEbXbFqKCpdPvJ+ VEj6NH/r5T9/6FiNbK6HHC4pWU15oieilggDpCWgLncwidp9cCvLl1QIyReFOSR67Uf6GZv9tdQKD JMo555FYeb+mrFGD2bSfEmVUg+9g0texpZHrQO6FKXcMAPiechaUGeE1lLrmETD/I7yDcfShXvUSi ABUPlrDtA1X1qsiRFRPRmsOn0CkybQT5WhPyTShOef3sHKz0vcabNCjL3S/WEMV3IDAizQ7+Vi+2Z nrhGGxhtWJSGs/nM/wzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pD0YE-008H6k-6d; Wed, 04 Jan 2023 09:59:14 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pD0WP-008Gei-MF for linux-riscv@lists.infradead.org; Wed, 04 Jan 2023 09:57:23 +0000 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 ams.source.kernel.org (Postfix) with ESMTPS id E909EB815DF; Wed, 4 Jan 2023 09:57:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC297C433D2; Wed, 4 Jan 2023 09:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672826238; bh=nn4+G9YSkrL4uki7DFfbSpQY7XWkWI7/WUJbCvL0pIQ=; h=Date:From:To:List-Id:CC:Subject:In-Reply-To:References:From; b=PBUi/t5ZbzZMPnMtBTmgOinuQHcD+Sw2nd/7Xs6xM9Z+FvIpIFmQfn0RnoiomteWa Qdz61HxasUj+Yl24KoX3MN0c7+FNN9WEtoo31H24ddfeXcaAF7axFW6ovdCRoDCdeQ 2XigMFpNwE7jfnjir8p9y5V9BIX9RW55TRVdIpoKuDuSXPuOO9V7gi+LWqTWB9MQ8L GTLO2qSkb95djwjLw3VlKyYxiiHXli5kGUHG65c3bywTleN8tQmhA6CVrUx/jLsrC2 oZ7Mh0QN+qPmsvn4BouHbPWYSjZRfmtZiEfIZf0HczI7qnWc1w1UDb0NobEFzgtJES E4mrYoofh4wgQ== Date: Wed, 04 Jan 2023 09:57:16 +0000 From: Conor Dooley To: Ben Dooks , arnd@arndb.de, palmer@dabbelt.com, prabhakar.csengg@gmail.com CC: Conor Dooley , ajones@ventanamicro.com, aou@eecs.berkeley.edu, apatel@ventanamicro.com, atishp@rivosinc.com, biju.das.jz@bp.renesas.com, devicetree@vger.kernel.org, geert@linux-m68k.org, guoren@kernel.org, hch@infradead.org, heiko@sntech.de, jszhang@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-riscv@lists.infradead.org, magnus.damm@gmail.com, nathan@kernel.org, paul.walmsley@sifive.com, philipp.tomsich@vrull.eu, prabhakar.mahadev-lad.rj@bp.renesas.com, robh+dt@kernel.org, samuel@sholland.org, soc@kernel.org, Daire McNamara Subject: =?US-ASCII?Q?Re=3A_=5BRFC_v5=2E1_9/9=5D_=5BDON=27T_APPLY=5D_cache=3A_si?= =?US-ASCII?Q?five-ccache=3A_add_cache_flushing_capability?= User-Agent: K-9 Mail for Android In-Reply-To: <6ef122f6-12fa-777f-b4e7-a02531380391@codethink.co.uk> References: <20230103210400.3500626-10-conor@kernel.org> <6ef122f6-12fa-777f-b4e7-a02531380391@codethink.co.uk> Message-ID: <298CA44E-DF97-4790-9CB1-F3ACD43E71FF@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230104_015722_103524_D3725059 X-CRM114-Status: GOOD ( 26.50 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On 4 January 2023 09:45:30 GMT, Ben Dooks wrote: >On 03/01/2023 21:04, Conor Dooley wrote: >> From: Daire McNamara >> >> SiFive L2 cache controller can flush L2 cache. Expose this capability via >> driver. >> >> Signed-off-by: Daire McNamara >> [Conor: rebase on top of move to cache subsystem] >> Signed-off-by: Conor Dooley >> --- >> This commit needs more work, and a way to enable it from errata. I've >> not gone and done this as PolarFire SoC has archid etc all set to zero. >> So we need to go figure out a workaround for this, before adding in >> errata enabling code for this. I've included it here as a second user of >> the cache management stuff, since what's currently upstream for the >> ccache driver does not do any cache management. > >I think errata isn't the right word here, it's more of a system requirement for anything that isn't coherent. All the SiFive systems >I have are coherent so won't need this. That's the mechanism we currently have for turning this stuff on. This patch is going away anyway for an actual submission, so we can debate this sort of thing when it shows up for real. This patch does certainly seem to be distracting from the main point, which was supposed to be the interface to arch/riscv. >> --- >> drivers/cache/sifive_ccache.c | 45 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 45 insertions(+) >> >> diff --git a/drivers/cache/sifive_ccache.c b/drivers/cache/sifive_ccache.c >> index 47e7d6557f85..3c00f205bace 100644 >> --- a/drivers/cache/sifive_ccache.c >> +++ b/drivers/cache/sifive_ccache.c >> @@ -9,12 +9,14 @@ >> #define pr_fmt(fmt) "CCACHE: " fmt >> #include >> +#include >> #include >> #include >> #include >> #include >> #include >> #include >> +#include >> #include >> #define SIFIVE_CCACHE_DIRECCFIX_LOW 0x100 >> @@ -42,11 +44,15 @@ >> #define SIFIVE_CCACHE_WAYENABLE 0x08 >> #define SIFIVE_CCACHE_ECCINJECTERR 0x40 >> +#define SIFIVE_CCACHE_FLUSH64 0x200 >> +#define SIFIVE_CCACHE_FLUSH32 0x240 >> + >> #define SIFIVE_CCACHE_MAX_ECCINTR 4 >> static void __iomem *ccache_base; >> static int g_irq[SIFIVE_CCACHE_MAX_ECCINTR]; >> static struct riscv_cacheinfo_ops ccache_cache_ops; >> +static struct riscv_cache_maint_ops ccache_cmos; >> static int level; >> enum { >> @@ -205,6 +211,42 @@ static irqreturn_t ccache_int_handler(int irq, void *device) >> return IRQ_HANDLED; >> } >> +static void sifive_ccache_dma_wback_inv(void* vaddr, unsigned long size) >> +{ >> + void * __iomem flush = ccache_base + SIFIVE_CCACHE_FLUSH64; >> + phys_addr_t start = virt_to_phys(vaddr); >> + phys_addr_t aligned_start = start & ~0x3f; >> + u64 addr; >> + u64 end; >> + u64 aligned_end; >> + >> + size += start - aligned_start; >> + end = start + size; >> + aligned_end = end += 0x3f; > >I think you meant + 0x3f here. There is an align macro in the kernel >headers, and I'm not sure by inspection if you'd miss the last line >with this code. > >> + aligned_end &= ~0x3f; >> + >> + for (addr = aligned_start; addr < aligned_end; addr += 64) >> + writeq(addr, flush); >> +} > >The p550 manual states that the zero device flush method is quicker for >any large area flush. However not sure what that level is and whether it >is worth dealing with here? If so we need to have the L3 zero are mapped. > >> + >> +static void sifive_ccache_cmo(unsigned int cache_size, void *vaddr, size_t size, >> + int dir, int ops) >> +{ > >technically dir should have been of type "enum dma_data_direction" > >> + switch (dir) { >> + case DMA_TO_DEVICE: >> + sifive_ccache_dma_wback_inv(vaddr, size); >> + break; >> + case DMA_FROM_DEVICE: >> + sifive_ccache_dma_wback_inv(vaddr, size); >> + break; >> + case DMA_BIDIRECTIONAL: >> + sifive_ccache_dma_wback_inv(vaddr, size); >> + break; >> + default: >> + break; >> + } >> +} > >I'm not sure why you'd bother checking the dir here, the cache can >only be flushed (I hope DMA_FROM_DEVICE is done /before/ the DMA op). > >You could have saved yourself an include if just ignoring dir. > >> + >> static int __init sifive_ccache_init(void) >> { >> struct device_node *np; >> @@ -254,6 +296,9 @@ static int __init sifive_ccache_init(void) >> ccache_cache_ops.get_priv_group = ccache_get_priv_group; >> riscv_set_cacheinfo_ops(&ccache_cache_ops); >> + ccache_cmos.cmo_patchfunc = sifive_ccache_cmo; >> + riscv_set_cache_maint_ops(&ccache_cmos); >> + >> #ifdef CONFIG_DEBUG_FS >> setup_sifive_debug(); >> #endif > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv