[U-Boot] [PATCH 05/19] riscv: Add a SYSCON driver for Core Local Interruptor

[Auer, Lukas]

Hi Bin,

On Wed, 2018-11-14 at 09:48 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Tue, Nov 13, 2018 at 10:45 PM Auer, Lukas
> <lukas.auer at aisec.fraunhofer.de> wrote:
> > 
> > Hi Bin,
> > 
> > On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> > > This adds U-Boot syscon driver for RISC-V Core Local Interruptor
> > > (CLINT). The CLINT block holds memory-mapped control and status
> > > registers associated with software and timer interrupts.
> > > 
> > > 3 APIs are provided for U-Boot to implement Supervisor Binary
> > > Interface (SBI) as defined by the RISC-V privileged architecture
> > > spec v1.10.
> > > 
> > > Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
> > > ---
> > 
> > Would it make sense to also abstract the functions provided by the
> > CLINT more? The reason why I am asking is because the CLINT is
> > (unfortunately) not specified as part of RISC-V. It is developing
> > into
> > a de facto standard since other platforms are following SiFive's
> > implementation, but there is nothing that would prevent them from
> > implementing something else.
> > 
> 
> I think your observation is correct about CLINT. Rick, does Andes's
> RISC-V processor also follow SiFive's CLINT model?
> 
> > Two immediate examples I can think of would be mtime and the IPI
> > implementation. Many SoC vendors will likely already have a
> > suitable
> > timer IP block for mtime. I can imagine that they would choose to
> > re-
> > use their memory map instead of following that of the CLINT.
> > For the IPI implementation there is already an alternative, the
> > SBI. If
> > U-Boot should be able to run in supervisor mode, it would be
> > helpful to
> > support both the SBI and the CLINT interface.
> > 
> 
> I am not sure I followed you here. This driver provides 3 APIs:
> riscv_send_ipi() is for IPI, and the other 2 are for mtime/mtimecmp.
> 

It does, but I am not sure how easy it is to support different devices.
Supporting the SBI is not going to be an issue, more problematic would
be if we have two different devices and device tree nodes to implement
the functionality of the APIs. Now we have to bind this driver to two
devices and call the APIs from the correct instantiation, which would
not work.

Thinking about this a little more, I think the only issue is that we
have both IPI- and mtime-related APIs in one driver. How about
something like this? Instead of binding this driver to riscv,clint0, we
add a new misc driver for the clint0. The only thing the driver does,
is to bind the syscon driver and the timer driver (see for example
tegra-car.c). Other architectures with separate device tree nodes for
the API functionality won't need the misc driver and can just bind the
devices to the syscon driver and a timer driver.

Thanks,
Lukas

> > So what we would need is some kind of API for the functionality
> > provided by the CLINT. For the multi-core support (I will try to
> > send
> > out a series soon) I am re-using the IRQ uclass ID (it is only used
> > in
> > arch code) to define a irq-uclass for RISC-V, which handles
> > everything
> > with IPIs. The CLINT0 and SBI are then just different driver
> > implementing the uclass.
> > 
> > This is just an idea right now, what do you think?
> > 
> 
> Regards,
> Bin