Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220511214132.2281431-1-heiko@sntech.de> <20220518002529.GA1928329-robh@kernel.org>
 <CAAeLtUBLpDHeJHfPtaUb_OLZb_6cUQa1Z_F+06pkdJMSHtWrfQ@mail.gmail.com>
 <1893094.PYKUYFuaPT@diego> <CAAhSdy1sG8uzg0W2Ufi=EYFB58+JZobUa9D+rcHeb4upJoMzng@mail.gmail.com>
In-Reply-To: <CAAhSdy1sG8uzg0W2Ufi=EYFB58+JZobUa9D+rcHeb4upJoMzng@mail.gmail.com>
From:   Philipp Tomsich <philipp.tomsich@vrull.eu>
Date:   Wed, 18 May 2022 11:20:27 +0200
Message-ID: <CAAeLtUBYF5qG3TkVCwz-DjaM4xGrwm9GyEPSBYJo04g70cNO4w@mail.gmail.com>
Subject: Re: [PATCH v2 1/3] dt-bindings: riscv: document cbom-block-size
To:     Anup Patel <anup@brainfault.org>
Cc:     =?UTF-8?Q?Heiko_St=C3=BCbner?= <heiko@sntech.de>,
        Rob Herring <robh@kernel.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>,
        Wei Fu <wefu@redhat.com>, Guo Ren <guoren@kernel.org>,
        Atish Patra <atishp@atishpatra.org>,
        Nick Kossifidis <mick@ics.forth.gr>,
        Samuel Holland <samuel@sholland.org>,
        Christoph Muellner <cmuellner@linux.com>, krzk+dt@kernel.org,
        DTML <devicetree@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 18 May 2022 at 11:10, Anup Patel <anup@brainfault.org> 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.