[PATCH v1 2/3] riscv: errata: picoheart: Add workaround for cbo.clean errata
Vivian Wang
wangruikang at iscas.ac.cn
Fri Jul 17 06:25:38 PDT 2026
On 7/17/26 18:42, Yicong Yang wrote:
> On 7/17/26 4:06 PM, Vivian Wang wrote:
>> [...]
>>
>> So you only need to have the wback function, and inv and wback can be
>> left as zero initialized. In that case arch_dma_cache_*() in
> benefit?
>
> I don't have strong feelings for either way but I feel this implicit
> assignment will make the code a bit less readable and not that
> self-explained. Considering only ~10 more LOCs if implement all
> these three callbacks...
To me the benefit is showing more clearly that wback_inv and inv are
standard, and only wback is non-standard.
>> arch/riscv/mm/dma-noncoherent.c will just do the standard operation. See
>> e.g.:
>>
>> static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> {
>> void *vaddr = phys_to_virt(paddr);
>>
>> #ifdef CONFIG_RISCV_NONSTANDARD_CACHE_OPS
>> if (unlikely(noncoherent_cache_ops.inv)) { // <-- HERE
>> noncoherent_cache_ops.inv(paddr, size);
>> return;
>> }
>> #endif
>>
>> ALT_CMO_OP(INVAL, vaddr, size, riscv_cbom_block_size);
>> }
>>
>> And after you've done that, consider this somewhat out of left field
>> suggestion: Move the static inline void arch_dma_cache_*() functions to
>> dma-noncoherent.h and here just define the nonstandard cache ops here as:
>>
>> struct riscv_nonstd_cache_ops picoheart_errata_cmo_ops = {
>> .wback = arch_dma_cache_wback_inv
>> };
>>
>> It's somewhat weirdly recursive but in a way that I think makes sense:
>> It's saying "Instead of wback, do a wback_inv" (Inform 7, anyone? :P).
>> Perf-wise this has one extra cache-hot load for the NULL wback_inv (hot
>> since it's *right* next to the wback function pointer just loaded), and
>> one predictably non-taken branch, and in exchange you get to just
>> completely drop all of your own implementations.
>>
> But I'll just implement the custom callback directly for the readability
> here (as you also find it weirdly, and probably more person will have
> doubts here).
>
Sure. I'm more of a fan of arranging the existing stuff, but, well,
that's just a personal preference.
Vivian "dramforever" Wang.
More information about the linux-riscv
mailing list