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

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Conor Dooley <Conor.Dooley@microchip.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Mark Brown <broonie@kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Lewis Hanly <Lewis.Hanly@microchip.com>,
	Daire.McNamara@microchip.com, Atish Patra <atish.patra@wdc.com>,
	Ivan.Griffin@microchip.com,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux I2C <linux-i2c@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-rtc@vger.kernel.org, linux-spi <linux-spi@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Bin Meng <bin.meng@windriver.com>
Subject: Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree
Date: Mon, 15 Nov 2021 17:17:52 +0100	[thread overview]
Message-ID: <CAMuHMdUQRJHkbwj++jJBMG7QqLd5_bmzUrMzyxEd92bgZbvDYw@mail.gmail.com> (raw)
In-Reply-To: <e91ebf36-5a8b-9d9f-d4f0-aa9e38e7a41f@microchip.com>

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.

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