Re: [PATCH v2 1/3] dt-bindings: riscv: document cbom-block-size

[Philipp Tomsich <philipp.tomsich@vrull.eu>]

On Wed, 18 May 2022 at 11:10, Anup Patel <anup@brainfault.org> wrote:
> > > > > +    description:
> > > > > +      Blocksize in bytes for the Zicbom cache operations. The block
> > > > > +      size is a property of the core itself and does not necessarily
> > > > > +      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 got
> > too much lead on by a kernel implementation detail (L1_CACHE_BYTES constant)
>
> 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 — 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.