Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp19501imn; Wed, 3 Aug 2022 17:44:13 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sRiqi3Kbybmdk+gLweIA0sAsLqlY7Jys/ooT0/XwvGmVrxNpaYsYnG82C/WY3MfVGh5n5H X-Received: by 2002:a50:ec0c:0:b0:43c:fd26:404d with SMTP id g12-20020a50ec0c000000b0043cfd26404dmr28581204edr.359.1659573853547; Wed, 03 Aug 2022 17:44:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659573853; cv=none; d=google.com; s=arc-20160816; b=lhEJxZnLJdLqpmnOglkBNqnEu76BmESBXZCtS35bxlZtkkN8P1dOrK6ergCxZWOP2Q seXRTcEAUw/bHpPnQO6sBN8mPNH5UmBt8ZFq60hWm7IrdYVpmmg1+CWJkXsY2d/hahlI o3g+286z66LCJQ1oI7C8sIHsRB5kXPlnVls5cF20AxO3cRe6/70Xy1gvlUZN4X+PBGqn XFqocZdOfJkwiL+oVds1K9vIUyxiHdrzcphIXNXH/3rTtOebPzq+EeiPJLnUjQadww8y nAFqhvOlt9mg14g0JN7aYyx072/osjaH8ppyvyzkvMfiiKg30QvtnacCwomxSW3m4shP TfwQ== 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:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=tO+wsGhSIZsG6c5Z1F7KUZCWEiBIeM5DSp57+76HAlQ=; b=Y/g29osTqXtDcY/DyuXSvFAYswzntlmdcedsUpZyhMEEyJJWx8ybiTnpX2bhbbA7Vi igZHGGw32X/H+UEa7o+UcXl7IGzOD0hAzWNHDYiqXKYseSMnSkkxUsN7wH43yaidKMsk uv5m8rmc7bVzUQDmLWXt1hNdbkDJbOIG1/YhLiHStXRmJEoVzNYOgN3mN0txJDMT/qF2 kxaByIgZmBxnAp84FHcmyCoCsKDZfjymwA7g5xyZl2yR1oiyF+MoZA2AjT5folkbbrQt n1YdWuAMtfyr57O2wfYnpV6wSvAOaonoiulxWdBuC1Lm7PBFd/ueWY0L5FgRNCncqjZ1 NITg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=XZA0eFns; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk20-20020a1709077f9400b00730412ff1efsi13939834ejc.843.2022.08.03.17.43.49; Wed, 03 Aug 2022 17:44:13 -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=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=XZA0eFns; 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 S238616AbiHDA3A (ORCPT + 99 others); Wed, 3 Aug 2022 20:29:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238499AbiHDA26 (ORCPT ); Wed, 3 Aug 2022 20:28:58 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 891DB59277 for ; Wed, 3 Aug 2022 17:28:56 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id d7so13485064pgc.13 for ; Wed, 03 Aug 2022 17:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc; bh=tO+wsGhSIZsG6c5Z1F7KUZCWEiBIeM5DSp57+76HAlQ=; b=XZA0eFnsUfz5rWb15WLff/IXlvW/hjpuRAikCDaV56k9OIuNq8mTZsqY8zpKJExSXU GZ4hPwqBWwRQyOfjyd+pzpNaLvIPr/rNqlZ0gZBQOgmqyrpjNPe+QQ9NG1Not+QUGuw8 XHjeRwTY2974E8cL6MkjWVXxHCeJwTFX3AuQD/G5s3m8Cnd5P6Jzubz2okXuWnnzOW12 X2KkZrr7ka5cORr1zQAH4FsdxlzMTPoudqLzYyZ21ueabdqXL8KH/Px+4tYCQwlWqjR1 F46+6RDZaIdhD38h5CRh1VrEHVclpJVqrxzNd/UJt/tbmg8muNuychEPOfV0trI5oP0l Gj3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc; bh=tO+wsGhSIZsG6c5Z1F7KUZCWEiBIeM5DSp57+76HAlQ=; b=K2lQx/w6ypY/258qAtdKZAHvl8WzhZWkZuWgWy2ulJ2tPpp6azsDwHpHJ4Ia9/9aZv BHs0jW0qibYVAhxFnxmVZI21tsZXlw4MPINsMCCZUx+rk52VTuAWzx2TxTKxI7tX85lz lupJPZRvOLlS7enYZJaZzkDyWdLXUgii5nLVIAr5euMTEHzPBvtw4DjP7Ym1DjPoKdsY /9V1F5z77oFyqTRV0svD1RPgvuwTjTyH7C/La9V8vjFHZ03pR5I2zQ/05fagKks7DePf 42cqame/3JmbZ72TbxB9jdOxkUeVWzxgG/KMp/31cdPeXUqg161bFPX+nj6LHtsyZ6VE 6crw== X-Gm-Message-State: AJIora+vRBh8wsnHVAOkpI7szFoVtV/be/Ca3w+j6k3fY3IQPkUg9IYW M6f6yvxHWhkHhUyngRrrnR200w== X-Received: by 2002:a63:1b13:0:b0:41a:6481:56e0 with SMTP id b19-20020a631b13000000b0041a648156e0mr22946113pgb.5.1659572935803; Wed, 03 Aug 2022 17:28:55 -0700 (PDT) Received: from localhost ([50.221.140.186]) by smtp.gmail.com with ESMTPSA id y18-20020a17090322d200b0016892555955sm2594114plg.179.2022.08.03.17.28.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Aug 2022 17:28:55 -0700 (PDT) Date: Wed, 03 Aug 2022 17:28:55 -0700 (PDT) X-Google-Original-Date: Wed, 03 Aug 2022 17:28:53 PDT (-0700) Subject: Re: [PATCH v7 4/4] riscv: implement cache-management errata for T-Head SoCs In-Reply-To: <20220706231536.2041855-5-heiko@sntech.de> CC: Paul Walmsley , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, wefu@redhat.com, guoren@kernel.org, cmuellner@linux.com, philipp.tomsich@vrull.eu, Christoph Hellwig , samuel@sholland.org, atishp@atishpatra.org, anup@brainfault.org, mick@ics.forth.gr, robh+dt@kernel.org, krzk+dt@kernel.org, devicetree@vger.kernel.org, drew@beagleboard.org, rdunlap@infradead.org, heiko@sntech.de From: Palmer Dabbelt To: heiko@sntech.de Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 06 Jul 2022 16:15:36 PDT (-0700), heiko@sntech.de wrote: > The T-Head C906 and C910 implement a scheme for handling > cache operations different from the generic Zicbom extension. > > Add an errata for it next to the generic dma coherency ops. > > Reviewed-by: Samuel Holland > Tested-by: Samuel Holland > Reviewed-by: Guo Ren > Signed-off-by: Heiko Stuebner > --- > arch/riscv/Kconfig.erratas | 11 +++++++ > arch/riscv/errata/thead/errata.c | 20 ++++++++++++ > arch/riscv/include/asm/errata_list.h | 48 +++++++++++++++++++++++++--- > 3 files changed, 74 insertions(+), 5 deletions(-) > > diff --git a/arch/riscv/Kconfig.erratas b/arch/riscv/Kconfig.erratas > index 457ac72c9b36..3223e533fd87 100644 > --- a/arch/riscv/Kconfig.erratas > +++ b/arch/riscv/Kconfig.erratas > @@ -55,4 +55,15 @@ config ERRATA_THEAD_PBMT > > If you don't know what to do here, say "Y". > > +config ERRATA_THEAD_CMO > + bool "Apply T-Head cache management errata" > + depends on ERRATA_THEAD > + select RISCV_DMA_NONCOHERENT > + default y > + help > + This will apply the cache management errata to handle the > + non-standard handling on non-coherent operations on T-Head SoCs. > + > + If you don't know what to do here, say "Y". > + > endmenu > diff --git a/arch/riscv/errata/thead/errata.c b/arch/riscv/errata/thead/errata.c > index b37b6fedd53b..202c83f677b2 100644 > --- a/arch/riscv/errata/thead/errata.c > +++ b/arch/riscv/errata/thead/errata.c > @@ -27,6 +27,23 @@ static bool errata_probe_pbmt(unsigned int stage, > return false; > } > > +static bool errata_probe_cmo(unsigned int stage, > + unsigned long arch_id, unsigned long impid) > +{ > +#ifdef CONFIG_ERRATA_THEAD_CMO > + if (arch_id != 0 || impid != 0) > + return false; > + > + if (stage == RISCV_ALTERNATIVES_EARLY_BOOT) > + return false; > + > + riscv_noncoherent_supported(); > + return true; > +#else > + return false; > +#endif > +} > + > static u32 thead_errata_probe(unsigned int stage, > unsigned long archid, unsigned long impid) > { > @@ -35,6 +52,9 @@ static u32 thead_errata_probe(unsigned int stage, > if (errata_probe_pbmt(stage, archid, impid)) > cpu_req_errata |= (1U << ERRATA_THEAD_PBMT); > > + if (errata_probe_cmo(stage, archid, impid)) > + cpu_req_errata |= (1U << ERRATA_THEAD_CMO); > + > return cpu_req_errata; > } > > diff --git a/arch/riscv/include/asm/errata_list.h b/arch/riscv/include/asm/errata_list.h > index 79d89aeeaa6c..19a771085781 100644 > --- a/arch/riscv/include/asm/errata_list.h > +++ b/arch/riscv/include/asm/errata_list.h > @@ -16,7 +16,8 @@ > > #ifdef CONFIG_ERRATA_THEAD > #define ERRATA_THEAD_PBMT 0 > -#define ERRATA_THEAD_NUMBER 1 > +#define ERRATA_THEAD_CMO 1 > +#define ERRATA_THEAD_NUMBER 2 > #endif > > #define CPUFEATURE_SVPBMT 0 > @@ -88,17 +89,54 @@ asm volatile(ALTERNATIVE( \ > #define ALT_THEAD_PMA(_val) > #endif > > +/* > + * dcache.ipa rs1 (invalidate, physical address) > + * | 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | > + * 0000001 01010 rs1 000 00000 0001011 > + * dache.iva rs1 (invalida, virtual address) > + * 0000001 00110 rs1 000 00000 0001011 > + * > + * dcache.cpa rs1 (clean, physical address) > + * | 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | > + * 0000001 01001 rs1 000 00000 0001011 > + * dcache.cva rs1 (clean, virtual address) > + * 0000001 00100 rs1 000 00000 0001011 > + * > + * dcache.cipa rs1 (clean then invalidate, physical address) > + * | 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | > + * 0000001 01011 rs1 000 00000 0001011 > + * dcache.civa rs1 (... virtual address) > + * 0000001 00111 rs1 000 00000 0001011 > + * > + * sync.s (make sure all cache operations finished) > + * | 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | > + * 0000000 11001 00000 000 00000 0001011 > + */ > +#define THEAD_inval_A0 ".long 0x0265000b" > +#define THEAD_clean_A0 ".long 0x0245000b" > +#define THEAD_flush_A0 ".long 0x0275000b" > +#define THEAD_SYNC_S ".long 0x0190000b" I'm not sure what to do with these: I really don't want to have a bunch of raw binary instruction encodings floating around, but it looks like the T-Head folks want to re-write their ISA manual before merging the GAS support for it which means we'd be stuck going another release cycle (and presumably another year of LTS) before getting the hardware supported. It really seems like we're just going in circles here trying to get everything lined up, and it's getting silly blocking real hardware from working because of a little bit of ugliness. I know I said I really don't want the executable .long stuff for this, and IIRC that's a pretty common sentiment. I'm not sure if I'm just fed up with all the craziness, but I'm kind of inclined to just merge this as-is -- at least that way we can get the hardware working. In the long run I think we're going to end up with some much uglier errata, so I doubt we'll be all that worried about this one later. That said, I'll give folks some time to chime in as IIRC this has been pointed out a handful of times. > + > #define ALT_CMO_OP(_op, _start, _size, _cachesize) \ > -asm volatile(ALTERNATIVE( \ > - __nops(5), \ > +asm volatile(ALTERNATIVE_2( \ > + __nops(6), \ > "mv a0, %1\n\t" \ > "j 2f\n\t" \ > "3:\n\t" \ > "cbo." __stringify(_op) " (a0)\n\t" \ > "add a0, a0, %0\n\t" \ > "2:\n\t" \ > - "bltu a0, %2, 3b\n\t", 0, \ > - CPUFEATURE_ZICBOM, CONFIG_RISCV_ISA_ZICBOM) \ > + "bltu a0, %2, 3b\n\t" \ > + "nop", 0, CPUFEATURE_ZICBOM, CONFIG_RISCV_ISA_ZICBOM, \ > + "mv a0, %1\n\t" \ > + "j 2f\n\t" \ > + "3:\n\t" \ > + THEAD_##_op##_A0 "\n\t" \ > + "add a0, a0, %0\n\t" \ > + "2:\n\t" \ > + "bltu a0, %2, 3b\n\t" \ > + THEAD_SYNC_S, THEAD_VENDOR_ID, \ > + ERRATA_THEAD_CMO, CONFIG_ERRATA_THEAD_CMO) \ > : : "r"(_cachesize), \ > "r"((unsigned long)(_start) & ~((_cachesize) - 1UL)), \ > "r"((unsigned long)(_start) + (_size)) \