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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8ADA0C433EF for ; Wed, 18 May 2022 09:20:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234071AbiERJUm (ORCPT ); Wed, 18 May 2022 05:20:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234045AbiERJUl (ORCPT ); Wed, 18 May 2022 05:20:41 -0400 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6045314A271 for ; Wed, 18 May 2022 02:20:40 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id l38-20020a05600c1d2600b00395b809dfbaso696365wms.2 for ; Wed, 18 May 2022 02:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eBrgiBGzrk60kAZSEVCexv1pWJW5TTEZ8MUjnMwLi/I=; b=bKCZxRM1GoQTtqmmmW5HOA0FKMOGvKrMx1cl1ODcLG19yE2nCh9+52uWp5JEeiUWWT 2yNY2n6uNTiOKmM/R87OZFim/s1zQgcicxY8uILlNGsvr2dtMxiV23UqCIOTL7sIh0qF pkY1FHbSxwLaPZRBeC5eKzoLHMDkHbETzTE9n6jZcz32Y2p4o1lHbljlyPCDMNYHgE+l 6V1kkUxJfqmqCSYSS5lXO6fjWiIbZqHVb0LYZurFDtChM14eTJdDJVBuDLFupp3ocNRc 5xO40GRRBQOLSkH6zjsCE7Nqo1y8/PzivfcxGMJgfnCsczobb4a+pKR6J/XC3tCd0C00 CKmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eBrgiBGzrk60kAZSEVCexv1pWJW5TTEZ8MUjnMwLi/I=; b=qG8LxUSLZimGlUtqQlDz6+W+5HKYBjNBRW24bJ1FdQQ8G1b0k7zRjn4EYvkiPrO4HF uwbdCDuAhaFnQ+Cb0yxh6ct9QrkSsdMiRgm+0AtYU/6JT+MhwStwTR5TCZ9SvUbQdyZ5 0hAScw56MZKzwfQ1qpJ734R6j5rMp54LKwN2c3WM/Ba23XN950d5QYMqTasWzWSHdXMG ujsKmbBigYCBMmgYfirsckS5WRBf118j5W8BUes+Qwuy4UHq+ioRKYzST8bWp/OkHtTo S3h3EBX7rrTs5Dj9krr6BSSSOWez+JtborODhhNQ+4uVtxgtRncivy6ilq2h3SH3CmtO 295w== X-Gm-Message-State: AOAM531WAhpBZnjIOTNNYw/jRENTscZuP2tOGPUX6t3x+0awUZjTcTud gj8hK1hr4vzAGcPNshl2gz32JeGQ27oiOXMfyUVXBw== X-Google-Smtp-Source: ABdhPJyNgdytB47LUliXc+x/PU5W1Vst1F3N/U9fluyBnS+APsQi7/YRSS6Psb+Lcx8jhj0DGPUy4mF0djw+vfks62s= X-Received: by 2002:a05:600c:35c1:b0:394:8621:a1d5 with SMTP id r1-20020a05600c35c100b003948621a1d5mr35267641wmq.196.1652865638784; Wed, 18 May 2022 02:20:38 -0700 (PDT) MIME-Version: 1.0 References: <20220511214132.2281431-1-heiko@sntech.de> <20220518002529.GA1928329-robh@kernel.org> <1893094.PYKUYFuaPT@diego> In-Reply-To: From: Philipp Tomsich Date: Wed, 18 May 2022 11:20:27 +0200 Message-ID: Subject: Re: [PATCH v2 1/3] dt-bindings: riscv: document cbom-block-size To: Anup Patel Cc: =?UTF-8?Q?Heiko_St=C3=BCbner?= , Rob Herring , Palmer Dabbelt , Paul Walmsley , linux-riscv , "linux-kernel@vger.kernel.org List" , Wei Fu , Guo Ren , Atish Patra , Nick Kossifidis , Samuel Holland , Christoph Muellner , krzk+dt@kernel.org, DTML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, 18 May 2022 at 11:10, Anup Patel wrote: > > > > > + description: > > > > > + Blocksize in bytes for the Zicbom cache operations. The bl= ock > > > > > + size is a property of the core itself and does not necessa= rily > > > > > + match other software defined cache sizes. > > > > > > > > What about hardware defined cache sizes? I'm scratching my head as = to > > > > what a 'software defined cache size' is. > > > > I agree that this should be worded better. The intent was to tell that = this > > is different from say the l1-cache-block-size. > > > > I.e. these values can be the same but don't need to be. But I guess I g= ot > > too much lead on by a kernel implementation detail (L1_CACHE_BYTES cons= tant) > > Better to just call it as "the cache block-size expected by Zicbom cache > operations" without getting details of relation with L1 cache block size. I would make this an even stronger statement and assert that Anup's recommended rewording (and staying away from L1 block/line sizes in terminology) is required to accurately reflect the design of the RISC-V CMOs. The Zicbom operation size is in fact decoupled from the l1-cache-block-size (as that would be the cache line size =E2=80=94 and therefore the size of fetches/replacements to the cache) as the deliberations within the CMO group showed. This is only the granule that Zicbom instructions operate on (and there might be additional mechanisms at work in the background that ensure that this is safe for any given underlying cache implementation). Cheers, Philipp.