[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190813162958.GA27821@lakrids.cambridge.arm.com>
Date: Tue, 13 Aug 2019 17:29:58 +0100
From: Mark Rutland <mark.rutland@....com>
To: Christoph Hellwig <hch@....de>
Cc: Palmer Dabbelt <palmer@...ive.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Damien Le Moal <damien.lemoal@....com>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/15] riscv: provide native clint access for M-mode
On Tue, Aug 13, 2019 at 05:47:40PM +0200, Christoph Hellwig wrote:
> RISC-V has the concept of a cpu level interrupt controller. Part of it
> is expose as bits in the status registers, and 2 new CSRs per privilege
> level in the instruction set, but the machanisms to trigger IPIs and
> timer events, as well as reading the actual timer value are not
> specified in the RISC-V spec but usually delegated to a block of MMIO
> registers. This patch adds support for those MMIO registers in the
> timer and IPI code. For now only the SiFive layout also supported by
> a few other implementations is supported, but the code should be
> easily extensible to others in the future.
>
> Signed-off-by: Christoph Hellwig <hch@....de>
> +/*
> + * This is the layout used by the SiFive clint, which is also shared by the qemu
> + * virt platform, and the Kendryte KD210 at least.
> + */
> +#define CLINT_IPI_OFF 0
> +#define CLINT_TIME_VAL_OFF 0xbff8
> +#define CLINT_TIME_CMP_OFF 0x4000;
> +
> +u32 __iomem *clint_ipi_base;
> +u64 __iomem *clint_time_val;
> +u64 __iomem *clint_time_cmp;
> +
> +void clint_init_boot_cpu(void)
> +{
> + struct device_node *np;
> + void __iomem *base;
> +
> + np = of_find_compatible_node(NULL, NULL, "riscv,clint0");
Since the MMIO layout is that of the SiFive clint, the compatible string
should be specific to that. e.g. "sifive,clint". That way it will be
possible to distinguish it from other implementations.
What exactly is the "0" suffix for? Is that a version number?
If that's a CPU index, then I don't think that's the right way to encode
this unless the programming interface actually differs across CPUs. It
would be better to use an explicit phandle to express the affinity.
Thanks,
Mark.
Powered by blists - more mailing lists