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@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-rtc@vger.kernel.org, linux-spi@vger.kernel.org,
linux-usb@vger.kernel.org, krzysztof.kozlowski@canonical.com,
bin.meng@windriver.com
Subject: Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree
Date: Wed, 10 Nov 2021 15:58:32 +0100 [thread overview]
Message-ID: <CAMuHMdULO5gJcbnsDzZcVShmYkByyM30f9nYyDD8e4PJ6nrnCQ@mail.gmail.com> (raw)
In-Reply-To: <0e379411-2469-8c78-1a3f-0645579a967c@microchip.com>
Hi Conor,
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>
> >>
> >> Update the device tree for the icicle kit by splitting it into a third part,
> >> which contains peripherals in the fpga fabric, add new peripherals
> >> (spi, qspi, gpio, rtc, pcie, system services, i2c), update parts of the memory
> >> map which have been changed.
> >>
> >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> As I said in the replies to another patch this is my first time doing
> any upstreaming of a device tree, i didnt realise that this would be a
> problem.
No problem, we're here to help you ;-)
> >> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> >> @@ -1,5 +1,5 @@
> >> // SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >> -/* Copyright (c) 2020 Microchip Technology Inc */
> >> +/* Copyright (c) 2020-2021 Microchip Technology Inc */
> >>
> >> /dts-v1/;
> >>
> >> @@ -13,72 +13,187 @@ / {
> >> compatible = "microchip,mpfs-icicle-kit", "microchip,mpfs";
> >>
> >> aliases {
> >> - ethernet0 = &emac1;
> >> - serial0 = &serial0;
> >> - serial1 = &serial1;
> >> - serial2 = &serial2;
> >> - serial3 = &serial3;
> >> + mmuart0 = &mmuart0;
> >> + mmuart1 = &mmuart1;
> >> + mmuart2 = &mmuart2;
> >> + mmuart3 = &mmuart3;
> >> + mmuart4 = &mmuart4;
> >
> > Why? SerialN is the standard alias name.
> we changed the label to mmuart to match the microchip documentation.
The serialN aliases are standardized, so you cannot change them.
> would it make more sense to call mmuart but alias it to serial?
> ie serial0 = &mmuart0;
You can change the labels, so that's OK.
> >> +&spi1 {
> >> + status = "okay";
> >
> > No slave devices specified?
> no, but its exposed
But without specifying slave devices first you cannot use the
controller anyway? While I2C supports instantiating slaves from
userspace by writing to the new_device file in sysfs, SPI doesn't
have that feature.
> >> +&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.
> Using the common interrupt for GPIO2 is the default on the
> polarfire-soc, there are only 38 per gpio line interrupts available of
> which 14 are connected to gpio0 and 24 to gpio1.
> >> plic: interrupt-controller@c000000 {
> >> - #interrupt-cells = <1>;
> >> - compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
> >> + compatible = "sifive,plic-1.0.0";
> >
> > Why drop the first one again?
> we felt it didnt make sense to have something that specifically
> references the fu540 in the device tree for this board.
That would be a revert of commit 73d3c44115514616 ("riscv: dts:
microchip: add missing compatibles for clint and plic"), which you
supplied an R-b tag for?
Is this the same plic as in the FU540 SoC? Or do we need a new
microchip,mpfs-plic compatible value?
> >> - emac1: ethernet@20112000 {
> >> + mac0: ethernet@20110000 {
> >> compatible = "cdns,macb";
> >> - reg = <0x0 0x20112000 0x0 0x2000>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + reg = <0x0 0x20110000 0x0 0x2000>;
> >> + clocks = <&clkcfg CLK_MAC0>, <&clkcfg CLK_AHB>;
> >> + clock-names = "pclk", "hclk";
> >> interrupt-parent = <&plic>;
> >> - interrupts = <70 71 72 73>;
> >> - local-mac-address = [00 00 00 00 00 00];
> >> - clocks = <&clkcfg 5>, <&clkcfg 2>;
> >> + interrupts = <PLIC_INT_MAC0_INT
> >> + PLIC_INT_MAC0_QUEUE1
> >> + PLIC_INT_MAC0_QUEUE2
> >> + PLIC_INT_MAC0_QUEUE3
> >> + PLIC_INT_MAC0_EMAC
> >> + PLIC_INT_MAC0_MMSL>;
> >
> > Please group using angular brackets.
> >
> >> + mac-address = [56 34 12 00 FC 01];
> >
> > Please drop this.
> Is the problem here having mac-address instead of local-, having either
> at all or that we have populated it rather than just filling with 0s?
MAC addresses are supposed to be unique.
> We set it in u-boot anyway, so I think dropping entirely is okay.
Exactly.
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
next prev parent reply other threads:[~2021-11-10 14:58 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 15:05 [PATCH 00/13]Update the icicle kit device tree conor.dooley
2021-11-08 15:05 ` [PATCH 01/13] dt-bindings: interrupt-controller: create a header for RISC-V interrupts conor.dooley
2021-11-23 11:07 ` Heiko Stübner
2021-11-23 11:35 ` Anup Patel
2021-11-29 19:57 ` Rob Herring
2021-11-08 15:05 ` [PATCH 02/13] dt-bindings: interrupt-controller: add defines for mpfs-plic conor.dooley
2021-11-23 11:17 ` Heiko Stübner
2021-11-29 19:56 ` Rob Herring
2021-11-30 8:15 ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 03/13] dt-bindings: soc/microchip: update sys ctrlr compat string conor.dooley
2021-11-08 21:09 ` Krzysztof Kozlowski
2021-11-09 8:33 ` Geert Uytterhoeven
2021-11-09 15:20 ` Conor.Dooley
2021-11-29 20:03 ` Rob Herring
2021-11-30 8:35 ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 04/13] dt-bindings: riscv: update microchip polarfire binds conor.dooley
2021-11-08 21:10 ` Krzysztof Kozlowski
2021-11-09 8:34 ` Geert Uytterhoeven
2021-11-09 12:08 ` Conor.Dooley
2021-11-09 13:04 ` Geert Uytterhoeven
2021-11-23 11:24 ` Heiko Stübner
2021-11-08 15:05 ` [PATCH 05/13] dt-bindings: i2c: add bindings for microchip mpfs i2c conor.dooley
2021-11-08 21:13 ` Krzysztof Kozlowski
2021-11-09 4:06 ` Rob Herring
2021-11-08 15:05 ` [PATCH 06/13] dt-bindings: rng: add bindings for microchip mpfs rng conor.dooley
2021-11-08 21:16 ` Krzysztof Kozlowski
2021-11-09 12:54 ` Conor.Dooley
2021-11-09 12:56 ` Krzysztof Kozlowski
2021-11-09 13:36 ` Conor.Dooley
2021-11-10 7:43 ` Krzysztof Kozlowski
2021-11-10 9:46 ` Conor.Dooley
2021-11-29 20:08 ` Rob Herring
2021-11-09 8:37 ` Geert Uytterhoeven
2021-11-09 11:55 ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 07/13] dt-bindings: rtc: add bindings for microchip mpfs rtc conor.dooley
2021-11-08 21:20 ` Krzysztof Kozlowski
2021-11-09 4:06 ` Rob Herring
2021-11-09 8:39 ` Geert Uytterhoeven
2021-11-08 15:05 ` [PATCH 08/13] dt-bindings: soc/microchip: add bindings for mpfs system services conor.dooley
2021-11-08 21:20 ` Krzysztof Kozlowski
2021-11-08 15:05 ` [PATCH 09/13] dt-bindings: gpio: add bindings for microchip mpfs gpio conor.dooley
2021-11-08 21:22 ` Krzysztof Kozlowski
2021-11-09 4:06 ` Rob Herring
2021-11-09 8:43 ` Geert Uytterhoeven
2021-11-08 15:05 ` [PATCH 10/13] dt-bindings: spi: add bindings for microchip mpfs spi conor.dooley
2021-11-08 21:24 ` Krzysztof Kozlowski
2021-11-09 4:06 ` Rob Herring
2021-11-09 12:16 ` Conor.Dooley
2021-11-09 12:53 ` Krzysztof Kozlowski
2021-11-09 12:58 ` Conor.Dooley
2021-11-09 13:04 ` Krzysztof Kozlowski
2021-11-09 13:20 ` Conor.Dooley
2021-11-10 7:45 ` Krzysztof Kozlowski
2021-11-09 8:45 ` Geert Uytterhoeven
2021-11-09 10:56 ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 11/13] dt-bindings: usb: add bindings for microchip mpfs musb conor.dooley
2021-11-08 21:27 ` Krzysztof Kozlowski
2021-11-09 4:06 ` Rob Herring
2021-11-09 8:48 ` Geert Uytterhoeven
2021-11-08 15:05 ` [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree conor.dooley
2021-11-08 21:40 ` Krzysztof Kozlowski
2021-11-10 12:07 ` Conor.Dooley
2021-11-09 9:04 ` Geert Uytterhoeven
2021-11-10 14:19 ` Conor.Dooley
2021-11-10 14:58 ` Geert Uytterhoeven [this message]
2021-11-10 15:07 ` Conor.Dooley
2021-11-15 15:39 ` Conor.Dooley
2021-11-15 16:17 ` Geert Uytterhoeven
2021-11-17 12:17 ` Daire.McNamara
2021-11-08 15:05 ` [PATCH 13/13] MAINTAINERS: update riscv/microchip entry conor.dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdULO5gJcbnsDzZcVShmYkByyM30f9nYyDD8e4PJ6nrnCQ@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=Conor.Dooley@microchip.com \
--cc=Daire.McNamara@microchip.com \
--cc=Ivan.Griffin@microchip.com \
--cc=Lewis.Hanly@microchip.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@wdc.com \
--cc=bgolaszewski@baylibre.com \
--cc=bin.meng@windriver.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jassisinghbrar@gmail.com \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linus.walleij@linaro.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).