Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp13008367rwl; Wed, 4 Jan 2023 02:05:25 -0800 (PST) X-Google-Smtp-Source: AMrXdXvoFChvLiPCtUY/zRz2TUl4/kJg3DSUnQID5dyPhZX5fEt3SPH53myLvZPFKuoDqtSnC25V X-Received: by 2002:a17:902:c10c:b0:192:a8e0:2612 with SMTP id 12-20020a170902c10c00b00192a8e02612mr20101432pli.47.1672826725304; Wed, 04 Jan 2023 02:05:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672826725; cv=none; d=google.com; s=arc-20160816; b=AIVEczuHL9Z+xOYUraeF3ZcTOPUwzXXK/d5rcLB8X6IQwaJs9Mlle7Jiu7cmKgtT9x 0mII1nNr68KJECXxZzYYSSwsZD+ySOGNPjDy+o+br9OnBsgLAYMW+D8Ff0BdEj08BKeg +5m8rcwnjhWC7+puIfMNPEHAehI8mdpSIYqGJwofM7SGNdpKINj9WSiXKMla1PYh9TO0 0aMZidt5z7yY+k5zUybrMur/J1dBjkBpGs/A5WUsJ088d+Bf6m8s4SFbvAeaVksOz65W 66z/yGOqYnzXwSjNEraOuVla6+uoSH/NMApPAvJoDXMhqHHRUE4NmlC1ttk0fp+9KpQX sxJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id; bh=ENIUHxJXY0zfjonSiL5+VuS34fI0fqAerfmg5Q8n5Jo=; b=uB/gidjuB5JZeqYa1MMwAxl4DeZtsj9R0WIPewYOWAlCk3kQjpjuScF8SpbCbh2Psw tZ2eGJDabirBU1vYrI65z/W69uCT3qqI+pIisgzXulkZqNx3dbO3LwPnbk6vVHQtz3JA 9ZM7nBGChYTFNlPChgpH6GaJU342bGUnETVPBY99NyHVxLlFJYMtixsZfKNiWpjKk39Y CCnYgu3jL0gKc4FobnoFi6o4hcQHn/p0QD9Zh68/6gclm0X8nitPz6EPEUCfhcOFrrGe ACb+j149NOWiMSnQLcXWxq8bXcfklTojJzrZBFC+Eb8cBa7qXuW704xOSRor8rxcFb6c foeA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u10-20020a170902e80a00b00176c891c8a0si36196586plg.6.2023.01.04.02.05.18; Wed, 04 Jan 2023 02:05:25 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234103AbjADJ53 (ORCPT + 57 others); Wed, 4 Jan 2023 04:57:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234691AbjADJ5W (ORCPT ); Wed, 4 Jan 2023 04:57:22 -0500 Received: from imap4.hz.codethink.co.uk (imap4.hz.codethink.co.uk [188.40.203.114]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECF531C932; Wed, 4 Jan 2023 01:57:19 -0800 (PST) Received: from cpc152649-stkp13-2-0-cust121.10-2.cable.virginm.net ([86.15.83.122] helo=[192.168.0.17]) by imap4.hz.codethink.co.uk with esmtpsa (Exim 4.94.2 #2 (Debian)) id 1pD0Kx-00G7tJ-Mm; Wed, 04 Jan 2023 09:45:31 +0000 Message-ID: <6ef122f6-12fa-777f-b4e7-a02531380391@codethink.co.uk> Date: Wed, 4 Jan 2023 09:45:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [RFC v5.1 9/9] [DON'T APPLY] cache: sifive-ccache: add cache flushing capability Content-Language: en-GB To: Conor Dooley , 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 References: <20230103210400.3500626-10-conor@kernel.org> From: Ben Dooks Organization: Codethink Limited. In-Reply-To: <20230103210400.3500626-10-conor@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_PASS,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: X-Mailing-List: linux-kernel@vger.kernel.org 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. > --- > 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 -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html