On Thu, May 20, 2021 at 9:47 AM Guo Ren <guoren@xxxxxxxxxx> wrote: > > On Wed, May 19, 2021 at 3:15 PM Anup Patel <anup@xxxxxxxxxxxxxx> wrote: > > > > On Wed, May 19, 2021 at 12:24 PM Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, May 19, 2021 at 08:06:17AM +0200, Christoph Hellwig wrote: > > > > On Wed, May 19, 2021 at 02:05:00PM +0800, Guo Ren wrote: > > > > > Since the existing RISC-V ISA cannot solve this problem, it is better > > > > > to provide some configuration for the SOC vendor to customize. > > > > > > > > We've been talking about this problem for close to five years. So no, > > > > if you don't manage to get the feature into the ISA it can't be > > > > supported. > > > > > > Isn't it a good goal for Linux to support the capabilities present in > > > the SoC that a currently being fab'd? > > > > > > I believe the CMO group only started last year [1] so the RV64GC SoCs > > > that are going into mass production this year would not have had the > > > opporuntiy of utilizing any RISC-V ISA extension for handling cache > > > management. > > > > The current Linux RISC-V policy is to only accept patches for frozen or > > ratified ISA specs. > > (Refer, Documentation/riscv/patch-acceptance.rst) > > > > This means even if emulate CMO instructions in OpenSBI, the Linux I think it's CBO now. https://github.com/riscv/riscv-CMOs/blob/master/discussion-files/RISC_V_range_CMOs_bad_v1.00.pdf > > patches won't be taken by Palmer because CMO specification is > > still in draft stage. > How do you think about > sbi_ecall(SBI_EXT_DMA, SBI_DMA_SYNC, start, size, dir, 0, 0, 0); > ? thx CBO insn trap is okay for me ;-) > > > > Also, we all know how much time it takes for RISCV international > > to freeze some spec. Judging by that we are looking at another > > 3-4 years at minimum. > > > > Regards, > > Anup > > > > -- > Best Regards > Guo Ren > > ML: https://lore.kernel.org/linux-csky/ -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
