Messages in this thread | | | From | Anup Patel <> | Date | Wed, 21 Aug 2019 09:22:48 +0530 | Subject | Re: [v2 PATCH] RISC-V: Optimize tlb flush path. |
| |
On Wed, Aug 21, 2019 at 7:10 AM hch@infradead.org <hch@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
| |