On Fri, Sep 15, 2023 at 02:14:40PM +0200, Andrew Jones wrote: > On Fri, Sep 15, 2023 at 12:37:50PM +0100, Conor Dooley wrote: > > On Thu, Sep 14, 2023 at 04:47:18PM +0200, Andrew Jones wrote: > > > On Thu, Sep 14, 2023 at 04:25:53PM +0200, Andrew Jones wrote: > > > > On Sun, Sep 10, 2023 at 04:28:57AM -0400, guoren@xxxxxxxxxx wrote: > > > > > From: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > > > So, we could maybe proceed with assuming we > > > can use zicbom_block_size for prefetch, for now. If a platform comes along > > > that interpreted the spec differently, requiring prefetch block size to > > > be specified separately, then we'll cross that bridge when we get there. > > > > That said, I think I suggested originally having the zicboz stuff default > > to the zicbom size too, so I'd be happy with prefetch stuff working > > exclusively that way until someone comes along looking for different sizes. > > The binding should be updated though since > > > > riscv,cbom-block-size: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > The blocksize in bytes for the Zicbom cache operations. > > > > would no longer be a complete description. > > > > While thinking about new wording though, it feels really clunky to describe > > it like: > > The block size in bytes for the Zicbom cache operations, Zicbop > > cache operations will default to this block size where not > > explicitly defined. > > > > since there's then no way to actually define the block size if it is > > different. Unless you've got some magic wording, I'd rather document > > riscv,cbop-block-size, even if we are going to use riscv,cbom-block-size > > as the default. > > > > Sounds good to me, but if it's documented, then we should probably > implement its parsing. Then, at that point, I wonder if it makes sense to > have the fallback at all, or if it's not better just to require all the > DTs to be explicit (even if redundant). Sure, why not I guess.
Attachment:
signature.asc
Description: PGP signature
