Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree

[<Daire.McNamara@microchip.com>]

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 <Conor.Dooley@microchip.com> wrote:
> > On 10/11/2021 14:58, Geert Uytterhoeven wrote:
> > > On Wed, Nov 10, 2021 at 3:20 PM <Conor.Dooley@microchip.com>
> > > wrote:
> > > > On 09/11/2021 09:04, Geert Uytterhoeven wrote:
> > > > > On Mon, Nov 8, 2021 at 4:07 PM <conor.dooley@microchip.com>
> > > > > wrote:
> > > > > > 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