On Wed, Aug 21, 2019 at 7:10 AM h...@infradead.org <h...@infradead.org> wrote: > > On Wed, Aug 21, 2019 at 09:29:22AM +0800, Alan Kao wrote: > > IMHO, this approach should be avoided because CLINT is compatible to but > > not mandatory in the privileged spec. In other words, it is possible that > > a Linux-capable RISC-V platform does not contain a CLINT component but > > rely on some other mechanism to deal with SW/timer interrupts. > > Hi Alan, > > at this point the above is just a prototype showing the performance > improvement if we can inject IPIs and timer interrups directly from > S-mode and delivered directly to S-mode. It is based on a copy of > the clint IPI block currently used by SiFive, qemu, Ariane and Kendryte. > > If the experiment works out (which I think it does), I'd like to > define interfaces for the unix platform spec to make something like > this available. My current plan for that is to have one DT node > each for the IPI registers, timer cmp and time val register each > as MMIO regions. This would fit the current clint block but also > allow other register layouts. Is that something you'd be fine with? > If not do you have another proposal? (note that eventually the > dicussion should move to the unix platform spec list, but now that > I have you here we can at least brain storm a bit).
I agree that IPI mechanism should be standardized for RISC-V but I don't support the idea of mandating CLINT as part of the UNIX platform spec. For example, the AndesTech SOC does not use CLINT instead they have PLMT for per-HART timer and PLICSW for per-HART IPIs. IMHO, we can also think of: RISC-V Timer Extension - For per-HART timer access to M-mode and S-mode RISC-V IPI Extension - HART IPI injection Regards, Anup
