Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree
From: <Daire.McNamara@microchip.com>
Date: 2021-11-17 12:18:07
Also in:
linux-crypto, linux-devicetree, linux-gpio, linux-i2c, linux-riscv, linux-spi, linux-usb, lkml
On Mon, 2021-11-15 at 17:17 +0100, Geert Uytterhoeven wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Hi Conor, On Mon, Nov 15, 2021 at 4:39 PM [off-list ref] wrote:quoted
On 10/11/2021 14:58, Geert Uytterhoeven wrote:quoted
On Wed, Nov 10, 2021 at 3:20 PM [off-list ref] wrote:quoted
On 09/11/2021 09:04, Geert Uytterhoeven wrote:quoted
On Mon, Nov 8, 2021 at 4:07 PM [off-list ref] wrote:quoted
From: Conor Dooley <conor.dooley@microchip.com> +&gpio2 { + interrupts = <PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT + PLIC_INT_GPIO2_NON_DIRECT>;Why override interrupts in the board .dts file? Doesn't this belong in the SoC .dtsi file?The interrupt setup for the gpio isnt fixed, there is an option to either connect the individual gpio interrupts to the plic *or* they can be connected to a per gpio controller common interrupt, and it is up to the driver to read a register to determine which interrupt triggered the common/NON_DIRECT interrupt. This decision is made by a write to a system register in application code, which to us didn't seem like it belonged in the soc .dtsi.So it is software policy? Then it doesn't belong in the board DTS either.The write (if was to be done) would be done by the bootloader, based on the bitstream written to the FPGA, before even u-boot is started. By application I meant the bootloader (or some other bare metal application), not a program running in userspace in case that's what you interpreted. Am I incorrect in thinking that if it is set up by the bootloader that Linux can take it for granted?If it is to be provided by the boot loader, the boot loader should fill in the interrupts property, just like it already does (or should do, if it doesn't) for /memory and chosen/bootargs.
Whether a given GPIO is routed via a bank where it has its own interrupt line or via a bank where it shares an interrupt line is an SoC capability. A particular routing is instantiated by a particular board (e.g. Icicle). A custom bootloader feels like complete overkill for this job.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@linux-m68k.org
In personal conversations with technical people, I call myself a
hacker. But
when I'm talking to journalists I just say "programmer" or something
like that.
-- Linus Torvalds