From: <Conor.Dooley@microchip.com> To: <geert@linux-m68k.org> Cc: <linus.walleij@linaro.org>, <bgolaszewski@baylibre.com>, <robh+dt@kernel.org>, <jassisinghbrar@gmail.com>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <a.zummo@towertech.it>, <alexandre.belloni@bootlin.com>, <broonie@kernel.org>, <gregkh@linuxfoundation.org>, <Lewis.Hanly@microchip.com>, <Daire.McNamara@microchip.com>, <atish.patra@wdc.com>, <Ivan.Griffin@microchip.com>, <linux-gpio@vger.kernel.org>, <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 14:19:51 +0000 [thread overview] Message-ID: <0e379411-2469-8c78-1a3f-0645579a967c@microchip.com> (raw) In-Reply-To: <CAMuHMdWEhJj0Cqt3sgGvgZe7JSFqBmTgtZRkom30NKqEW27NvQ@mail.gmail.com> On 09/11/2021 09:04, Geert Uytterhoeven wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Conor, > > 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> > > Thanks for your patch! > > Please split it into logical separated parts. yeah, ive split it into several patches - one for the splitting into 3, one for the new defines, one for the changes to existing nodes and one for node additions. > >> --- /dev/null >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi >> @@ -0,0 +1,21 @@ >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> +/* Copyright (c) 2020-2021 Microchip Technology Inc */ >> + >> +/ { >> + fpgadma: fpgadma@60020000 { >> + compatible = "microchip,mpfs-fpga-dma-uio"; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x0 0x60020000 0x0 0x1000>; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_FABRIC_F2H_2>; >> + status = "okay"; >> + }; >> + >> + fpgalsram: fpga_lsram@61000000 { >> + compatible = "generic-uio"; >> + reg = <0x0 0x61000000 0x0 0x0001000 >> + 0x14 0x00000000 0x0 0x00010000>; > > Please group by angular brackets, to increase readability, and support > automatic validation: > > <0x0 0x61000000 0x0 0x0001000>, <0x14 0x00000000 0x0 0x00010000> > >> + status = "okay"; >> + }; > > Do we really want UIO nodes in upstream DT? 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. > >> +}; >> diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts >> index fc1e5869df1b..4212129fcdf1 100644 >> --- 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. would it make more sense to call mmuart but alias it to serial? ie serial0 = &mmuart0; > >> }; > >> >> -&emac0 { >> +&spi0 { >> + status = "okay"; >> + spidev@0 { >> + compatible = "spidev"; > > Please don't use "spidev", but a proper compatible value describing > what is really connected. If you want to use it with spidev (which > is software policy, not hardware description), add that compatible > value to drivers/spi/spidev.c:spidev_dt_ids[], or use driver_override > in sysfs at runtime. as i said to Krzysztof - this one was an oversight from me, that compatible has never been "spidev" on its own in our internal tree and i mustve accidentally omitted the vendor string while making these patches. Either way, after talking some more we decided that this entry is not appropriate anyway and i will drop it. > >> + reg = <0>; /* CS 0 */ >> + spi-max-frequency = <10000000>; >> + status = "okay"; >> + }; >> +}; >> + >> +&spi1 { >> + status = "okay"; > > No slave devices specified? no, but its exposed > >> +}; >> + >> +&qspi { >> + status = "okay"; >> +}; >> + >> +&i2c0 { >> + status = "okay"; >> +}; >> + >> +&i2c1 { >> + status = "okay"; >> + pac193x: pac193x@10 { > > adc@, I guess? sure > >> + compatible = "microchip,pac1934"; >> + reg = <0x10>; >> + samp-rate = <64>; >> + status = "okay"; >> + ch0: channel0 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDDREG"; >> + channel_enabled; >> + }; >> + ch1: channel1 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDDA25"; >> + channel_enabled; >> + }; >> + ch2: channel2 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDD25"; >> + channel_enabled; >> + }; >> + ch3: channel3 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDDA_REG"; >> + channel_enabled; >> + }; >> + }; >> +}; > >> +&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. 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. > Please group using angular brackets. > >> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > >> @@ -145,49 +149,55 @@ cpu4_intc: interrupt-controller { >> soc { >> #address-cells = <2>; >> #size-cells = <2>; >> - compatible = "simple-bus"; >> + compatible = "microchip,mpfs-soc", "simple-bus"; >> ranges; >> >> - cache-controller@2010000 { >> + cctrllr: cache-controller@2010000 { >> compatible = "sifive,fu540-c000-ccache", "cache"; >> + reg = <0x0 0x2010000 0x0 0x1000>; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_L2_METADATA_CORR >> + PLIC_INT_L2_METADAT_UNCORR >> + PLIC_INT_L2_DATA_CORR>; > > Please group using angular brackets. > >> cache-block-size = <64>; >> cache-level = <2>; >> cache-sets = <1024>; >> cache-size = <2097152>; >> cache-unified; >> - interrupt-parent = <&plic>; >> - interrupts = <1 2 3>; >> - reg = <0x0 0x2010000 0x0 0x1000>; >> }; >> >> - clint@2000000 { >> + clint: clint@2000000 { >> compatible = "sifive,fu540-c000-clint", "sifive,clint0"; >> reg = <0x0 0x2000000 0x0 0xC000>; >> - interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7 >> - &cpu1_intc 3 &cpu1_intc 7 >> - &cpu2_intc 3 &cpu2_intc 7 >> - &cpu3_intc 3 &cpu3_intc 7 >> - &cpu4_intc 3 &cpu4_intc 7>; >> + interrupts-extended = >> + <&cpu0_intc HART_INT_M_SOFT &cpu0_intc HART_INT_M_TIMER >> + &cpu1_intc HART_INT_M_SOFT &cpu1_intc HART_INT_M_TIMER >> + &cpu2_intc HART_INT_M_SOFT &cpu2_intc HART_INT_M_TIMER >> + &cpu3_intc HART_INT_M_SOFT &cpu3_intc HART_INT_M_TIMER >> + &cpu4_intc HART_INT_M_SOFT &cpu4_intc HART_INT_M_TIMER>; > > Please group using angular brackets. > >> }; >> >> 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. > >> reg = <0x0 0xc000000 0x0 0x4000000>; >> + #interrupt-cells = <1>; >> riscv,ndev = <186>; >> interrupt-controller; >> - interrupts-extended = <&cpu0_intc 11 >> - &cpu1_intc 11 &cpu1_intc 9 >> - &cpu2_intc 11 &cpu2_intc 9 >> - &cpu3_intc 11 &cpu3_intc 9 >> - &cpu4_intc 11 &cpu4_intc 9>; >> + interrupts-extended = <&cpu0_intc HART_INT_M_EXT >> + &cpu1_intc HART_INT_M_EXT &cpu1_intc HART_INT_S_EXT >> + &cpu2_intc HART_INT_M_EXT &cpu2_intc HART_INT_S_EXT >> + &cpu3_intc HART_INT_M_EXT &cpu3_intc HART_INT_S_EXT >> + &cpu4_intc HART_INT_M_EXT &cpu4_intc HART_INT_S_EXT>; >> }; >> >> - dma@3000000 { >> - compatible = "sifive,fu540-c000-pdma"; >> + pdma: pdma@3000000 { >> + compatible = "microchip,mpfs-pdma-uio"; >> reg = <0x0 0x3000000 0x0 0x8000>; >> interrupt-parent = <&plic>; >> - interrupts = <23 24 25 26 27 28 29 30>; >> + interrupts = <PLIC_INT_DMA_CH0_DONE PLIC_INT_DMA_CH0_ERR >> + PLIC_INT_DMA_CH1_DONE PLIC_INT_DMA_CH1_ERR >> + PLIC_INT_DMA_CH2_DONE PLIC_INT_DMA_CH2_ERR >> + PLIC_INT_DMA_CH3_DONE PLIC_INT_DMA_CH3_ERR>; > > Please group using angular brackets. > >> #dma-cells = <1>; >> }; >> >> @@ -205,7 +215,7 @@ clkcfg: clkcfg@20002000 { >> clocks = <&refclk>; >> #clock-cells = <1>; >> clock-output-names = "cpu", "axi", "ahb", "envm", /* 0-3 */ >> - "mac0", "mac1", "mmc", "timer", /* 4-7 */ >> + "mac0", "mac1", "mmc", "timer", /* 4-7 */ >> "mmuart0", "mmuart1", "mmuart2", "mmuart3", /* 8-11 */ >> "mmuart4", "spi0", "spi1", "i2c0", /* 12-15 */ >> "i2c1", "can0", "can1", "usb", /* 16-19 */ > > No need for clock-output-names at all. > >> >> - 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? We set it in u-boot anyway, so I think dropping entirely is okay. > >> status = "disabled"; >> + }; >> >> + rtc: rtc@20124000 { >> + compatible = "microchip,mpfs-rtc"; >> #address-cells = <1>; >> #size-cells = <0>; >> + reg = <0x0 0x20124000 0x0 0x1000>; >> + clocks = <&clkcfg CLK_RTC>; >> + clock-names = "rtc"; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_RTC_WAKEUP PLIC_INT_RTC_MATCH>; > > Please group using angular brackets. > >> + status = "disabled"; >> }; >> >> + usb: usb@20201000 { >> + compatible = "microchip,mpfs-usb-host"; >> + reg = <0x0 0x20201000 0x0 0x1000>; >> + reg-names = "mc","control"; >> + clocks = <&clkcfg CLK_USB>; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_USB_DMA PLIC_INT_USB_MC>; > > Please group using angular brackets. > >> + interrupt-names = "dma","mc"; >> + dr_mode = "host"; >> + status = "disabled"; >> + }; >> + > > 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 >
WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com> To: <geert@linux-m68k.org> Cc: <linus.walleij@linaro.org>, <bgolaszewski@baylibre.com>, <robh+dt@kernel.org>, <jassisinghbrar@gmail.com>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <a.zummo@towertech.it>, <alexandre.belloni@bootlin.com>, <broonie@kernel.org>, <gregkh@linuxfoundation.org>, <Lewis.Hanly@microchip.com>, <Daire.McNamara@microchip.com>, <atish.patra@wdc.com>, <Ivan.Griffin@microchip.com>, <linux-gpio@vger.kernel.org>, <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 14:19:51 +0000 [thread overview] Message-ID: <0e379411-2469-8c78-1a3f-0645579a967c@microchip.com> (raw) In-Reply-To: <CAMuHMdWEhJj0Cqt3sgGvgZe7JSFqBmTgtZRkom30NKqEW27NvQ@mail.gmail.com> On 09/11/2021 09:04, Geert Uytterhoeven wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Conor, > > 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> > > Thanks for your patch! > > Please split it into logical separated parts. yeah, ive split it into several patches - one for the splitting into 3, one for the new defines, one for the changes to existing nodes and one for node additions. > >> --- /dev/null >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi >> @@ -0,0 +1,21 @@ >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> +/* Copyright (c) 2020-2021 Microchip Technology Inc */ >> + >> +/ { >> + fpgadma: fpgadma@60020000 { >> + compatible = "microchip,mpfs-fpga-dma-uio"; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x0 0x60020000 0x0 0x1000>; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_FABRIC_F2H_2>; >> + status = "okay"; >> + }; >> + >> + fpgalsram: fpga_lsram@61000000 { >> + compatible = "generic-uio"; >> + reg = <0x0 0x61000000 0x0 0x0001000 >> + 0x14 0x00000000 0x0 0x00010000>; > > Please group by angular brackets, to increase readability, and support > automatic validation: > > <0x0 0x61000000 0x0 0x0001000>, <0x14 0x00000000 0x0 0x00010000> > >> + status = "okay"; >> + }; > > Do we really want UIO nodes in upstream DT? 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. > >> +}; >> diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts >> index fc1e5869df1b..4212129fcdf1 100644 >> --- 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. would it make more sense to call mmuart but alias it to serial? ie serial0 = &mmuart0; > >> }; > >> >> -&emac0 { >> +&spi0 { >> + status = "okay"; >> + spidev@0 { >> + compatible = "spidev"; > > Please don't use "spidev", but a proper compatible value describing > what is really connected. If you want to use it with spidev (which > is software policy, not hardware description), add that compatible > value to drivers/spi/spidev.c:spidev_dt_ids[], or use driver_override > in sysfs at runtime. as i said to Krzysztof - this one was an oversight from me, that compatible has never been "spidev" on its own in our internal tree and i mustve accidentally omitted the vendor string while making these patches. Either way, after talking some more we decided that this entry is not appropriate anyway and i will drop it. > >> + reg = <0>; /* CS 0 */ >> + spi-max-frequency = <10000000>; >> + status = "okay"; >> + }; >> +}; >> + >> +&spi1 { >> + status = "okay"; > > No slave devices specified? no, but its exposed > >> +}; >> + >> +&qspi { >> + status = "okay"; >> +}; >> + >> +&i2c0 { >> + status = "okay"; >> +}; >> + >> +&i2c1 { >> + status = "okay"; >> + pac193x: pac193x@10 { > > adc@, I guess? sure > >> + compatible = "microchip,pac1934"; >> + reg = <0x10>; >> + samp-rate = <64>; >> + status = "okay"; >> + ch0: channel0 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDDREG"; >> + channel_enabled; >> + }; >> + ch1: channel1 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDDA25"; >> + channel_enabled; >> + }; >> + ch2: channel2 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDD25"; >> + channel_enabled; >> + }; >> + ch3: channel3 { >> + uohms-shunt-res = <10000>; >> + rail-name = "VDDA_REG"; >> + channel_enabled; >> + }; >> + }; >> +}; > >> +&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. 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. > Please group using angular brackets. > >> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > >> @@ -145,49 +149,55 @@ cpu4_intc: interrupt-controller { >> soc { >> #address-cells = <2>; >> #size-cells = <2>; >> - compatible = "simple-bus"; >> + compatible = "microchip,mpfs-soc", "simple-bus"; >> ranges; >> >> - cache-controller@2010000 { >> + cctrllr: cache-controller@2010000 { >> compatible = "sifive,fu540-c000-ccache", "cache"; >> + reg = <0x0 0x2010000 0x0 0x1000>; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_L2_METADATA_CORR >> + PLIC_INT_L2_METADAT_UNCORR >> + PLIC_INT_L2_DATA_CORR>; > > Please group using angular brackets. > >> cache-block-size = <64>; >> cache-level = <2>; >> cache-sets = <1024>; >> cache-size = <2097152>; >> cache-unified; >> - interrupt-parent = <&plic>; >> - interrupts = <1 2 3>; >> - reg = <0x0 0x2010000 0x0 0x1000>; >> }; >> >> - clint@2000000 { >> + clint: clint@2000000 { >> compatible = "sifive,fu540-c000-clint", "sifive,clint0"; >> reg = <0x0 0x2000000 0x0 0xC000>; >> - interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7 >> - &cpu1_intc 3 &cpu1_intc 7 >> - &cpu2_intc 3 &cpu2_intc 7 >> - &cpu3_intc 3 &cpu3_intc 7 >> - &cpu4_intc 3 &cpu4_intc 7>; >> + interrupts-extended = >> + <&cpu0_intc HART_INT_M_SOFT &cpu0_intc HART_INT_M_TIMER >> + &cpu1_intc HART_INT_M_SOFT &cpu1_intc HART_INT_M_TIMER >> + &cpu2_intc HART_INT_M_SOFT &cpu2_intc HART_INT_M_TIMER >> + &cpu3_intc HART_INT_M_SOFT &cpu3_intc HART_INT_M_TIMER >> + &cpu4_intc HART_INT_M_SOFT &cpu4_intc HART_INT_M_TIMER>; > > Please group using angular brackets. > >> }; >> >> 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. > >> reg = <0x0 0xc000000 0x0 0x4000000>; >> + #interrupt-cells = <1>; >> riscv,ndev = <186>; >> interrupt-controller; >> - interrupts-extended = <&cpu0_intc 11 >> - &cpu1_intc 11 &cpu1_intc 9 >> - &cpu2_intc 11 &cpu2_intc 9 >> - &cpu3_intc 11 &cpu3_intc 9 >> - &cpu4_intc 11 &cpu4_intc 9>; >> + interrupts-extended = <&cpu0_intc HART_INT_M_EXT >> + &cpu1_intc HART_INT_M_EXT &cpu1_intc HART_INT_S_EXT >> + &cpu2_intc HART_INT_M_EXT &cpu2_intc HART_INT_S_EXT >> + &cpu3_intc HART_INT_M_EXT &cpu3_intc HART_INT_S_EXT >> + &cpu4_intc HART_INT_M_EXT &cpu4_intc HART_INT_S_EXT>; >> }; >> >> - dma@3000000 { >> - compatible = "sifive,fu540-c000-pdma"; >> + pdma: pdma@3000000 { >> + compatible = "microchip,mpfs-pdma-uio"; >> reg = <0x0 0x3000000 0x0 0x8000>; >> interrupt-parent = <&plic>; >> - interrupts = <23 24 25 26 27 28 29 30>; >> + interrupts = <PLIC_INT_DMA_CH0_DONE PLIC_INT_DMA_CH0_ERR >> + PLIC_INT_DMA_CH1_DONE PLIC_INT_DMA_CH1_ERR >> + PLIC_INT_DMA_CH2_DONE PLIC_INT_DMA_CH2_ERR >> + PLIC_INT_DMA_CH3_DONE PLIC_INT_DMA_CH3_ERR>; > > Please group using angular brackets. > >> #dma-cells = <1>; >> }; >> >> @@ -205,7 +215,7 @@ clkcfg: clkcfg@20002000 { >> clocks = <&refclk>; >> #clock-cells = <1>; >> clock-output-names = "cpu", "axi", "ahb", "envm", /* 0-3 */ >> - "mac0", "mac1", "mmc", "timer", /* 4-7 */ >> + "mac0", "mac1", "mmc", "timer", /* 4-7 */ >> "mmuart0", "mmuart1", "mmuart2", "mmuart3", /* 8-11 */ >> "mmuart4", "spi0", "spi1", "i2c0", /* 12-15 */ >> "i2c1", "can0", "can1", "usb", /* 16-19 */ > > No need for clock-output-names at all. > >> >> - 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? We set it in u-boot anyway, so I think dropping entirely is okay. > >> status = "disabled"; >> + }; >> >> + rtc: rtc@20124000 { >> + compatible = "microchip,mpfs-rtc"; >> #address-cells = <1>; >> #size-cells = <0>; >> + reg = <0x0 0x20124000 0x0 0x1000>; >> + clocks = <&clkcfg CLK_RTC>; >> + clock-names = "rtc"; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_RTC_WAKEUP PLIC_INT_RTC_MATCH>; > > Please group using angular brackets. > >> + status = "disabled"; >> }; >> >> + usb: usb@20201000 { >> + compatible = "microchip,mpfs-usb-host"; >> + reg = <0x0 0x20201000 0x0 0x1000>; >> + reg-names = "mc","control"; >> + clocks = <&clkcfg CLK_USB>; >> + interrupt-parent = <&plic>; >> + interrupts = <PLIC_INT_USB_DMA PLIC_INT_USB_MC>; > > Please group using angular brackets. > >> + interrupt-names = "dma","mc"; >> + dr_mode = "host"; >> + status = "disabled"; >> + }; >> + > > 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 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-11-10 14:20 UTC|newest] Thread overview: 140+ 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 ` 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-08 15:05 ` conor.dooley 2021-11-23 11:07 ` Heiko Stübner 2021-11-23 11:07 ` Heiko Stübner 2021-11-23 11:35 ` Anup Patel 2021-11-23 11:35 ` Anup Patel 2021-11-29 19:57 ` Rob Herring 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-08 15:05 ` conor.dooley 2021-11-23 11:17 ` Heiko Stübner 2021-11-23 11:17 ` Heiko Stübner 2021-11-29 19:56 ` Rob Herring 2021-11-29 19:56 ` Rob Herring 2021-11-30 8:15 ` Conor.Dooley 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 15:05 ` conor.dooley 2021-11-08 21:09 ` Krzysztof Kozlowski 2021-11-08 21:09 ` Krzysztof Kozlowski 2021-11-09 8:33 ` Geert Uytterhoeven 2021-11-09 8:33 ` Geert Uytterhoeven 2021-11-09 15:20 ` Conor.Dooley 2021-11-09 15:20 ` Conor.Dooley 2021-11-29 20:03 ` Rob Herring 2021-11-29 20:03 ` Rob Herring 2021-11-30 8:35 ` Conor.Dooley 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 15:05 ` conor.dooley 2021-11-08 21:10 ` Krzysztof Kozlowski 2021-11-08 21:10 ` Krzysztof Kozlowski 2021-11-09 8:34 ` Geert Uytterhoeven 2021-11-09 8:34 ` Geert Uytterhoeven 2021-11-09 12:08 ` Conor.Dooley 2021-11-09 12:08 ` Conor.Dooley 2021-11-09 13:04 ` Geert Uytterhoeven 2021-11-09 13:04 ` Geert Uytterhoeven 2021-11-23 11:24 ` Heiko Stübner 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 15:05 ` conor.dooley 2021-11-08 21:13 ` Krzysztof Kozlowski 2021-11-08 21:13 ` Krzysztof Kozlowski 2021-11-09 4:06 ` Rob Herring 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 15:05 ` conor.dooley 2021-11-08 21:16 ` Krzysztof Kozlowski 2021-11-08 21:16 ` Krzysztof Kozlowski 2021-11-09 12:54 ` Conor.Dooley 2021-11-09 12:54 ` Conor.Dooley 2021-11-09 12:56 ` Krzysztof Kozlowski 2021-11-09 12:56 ` Krzysztof Kozlowski 2021-11-09 13:36 ` Conor.Dooley 2021-11-09 13:36 ` Conor.Dooley 2021-11-10 7:43 ` Krzysztof Kozlowski 2021-11-10 7:43 ` Krzysztof Kozlowski 2021-11-10 9:46 ` Conor.Dooley 2021-11-10 9:46 ` Conor.Dooley 2021-11-29 20:08 ` Rob Herring 2021-11-29 20:08 ` Rob Herring 2021-11-09 8:37 ` Geert Uytterhoeven 2021-11-09 8:37 ` Geert Uytterhoeven 2021-11-09 11:55 ` Conor.Dooley 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 15:05 ` conor.dooley 2021-11-08 21:20 ` Krzysztof Kozlowski 2021-11-08 21:20 ` Krzysztof Kozlowski 2021-11-09 4:06 ` Rob Herring 2021-11-09 4:06 ` Rob Herring 2021-11-09 8:39 ` Geert Uytterhoeven 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 15:05 ` conor.dooley 2021-11-08 21:20 ` Krzysztof Kozlowski 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 15:05 ` conor.dooley 2021-11-08 21:22 ` Krzysztof Kozlowski 2021-11-08 21:22 ` Krzysztof Kozlowski 2021-11-09 4:06 ` Rob Herring 2021-11-09 4:06 ` Rob Herring 2021-11-09 8:43 ` Geert Uytterhoeven 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 15:05 ` conor.dooley 2021-11-08 21:24 ` Krzysztof Kozlowski 2021-11-08 21:24 ` Krzysztof Kozlowski 2021-11-09 4:06 ` Rob Herring 2021-11-09 4:06 ` Rob Herring 2021-11-09 12:16 ` Conor.Dooley 2021-11-09 12:16 ` Conor.Dooley 2021-11-09 12:53 ` Krzysztof Kozlowski 2021-11-09 12:53 ` Krzysztof Kozlowski 2021-11-09 12:58 ` Conor.Dooley 2021-11-09 12:58 ` Conor.Dooley 2021-11-09 13:04 ` Krzysztof Kozlowski 2021-11-09 13:04 ` Krzysztof Kozlowski 2021-11-09 13:20 ` Conor.Dooley 2021-11-09 13:20 ` Conor.Dooley 2021-11-10 7:45 ` Krzysztof Kozlowski 2021-11-10 7:45 ` Krzysztof Kozlowski 2021-11-09 8:45 ` Geert Uytterhoeven 2021-11-09 8:45 ` Geert Uytterhoeven 2021-11-09 10:56 ` Conor.Dooley 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 15:05 ` conor.dooley 2021-11-08 21:27 ` Krzysztof Kozlowski 2021-11-08 21:27 ` Krzysztof Kozlowski 2021-11-09 4:06 ` Rob Herring 2021-11-09 4:06 ` Rob Herring 2021-11-09 8:48 ` Geert Uytterhoeven 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 15:05 ` conor.dooley 2021-11-08 21:40 ` Krzysztof Kozlowski 2021-11-08 21:40 ` Krzysztof Kozlowski 2021-11-10 12:07 ` Conor.Dooley 2021-11-10 12:07 ` Conor.Dooley 2021-11-09 9:04 ` Geert Uytterhoeven 2021-11-09 9:04 ` Geert Uytterhoeven 2021-11-10 14:19 ` Conor.Dooley [this message] 2021-11-10 14:19 ` Conor.Dooley 2021-11-10 14:58 ` Geert Uytterhoeven 2021-11-10 14:58 ` Geert Uytterhoeven 2021-11-10 15:07 ` Conor.Dooley 2021-11-10 15:07 ` Conor.Dooley 2021-11-15 15:39 ` Conor.Dooley 2021-11-15 15:39 ` Conor.Dooley 2021-11-15 16:17 ` Geert Uytterhoeven 2021-11-15 16:17 ` Geert Uytterhoeven 2021-11-17 12:17 ` Daire.McNamara 2021-11-17 12:17 ` Daire.McNamara 2021-11-08 15:05 ` [PATCH 13/13] MAINTAINERS: update riscv/microchip entry conor.dooley 2021-11-08 15:05 ` 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=0e379411-2469-8c78-1a3f-0645579a967c@microchip.com \ --to=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=geert@linux-m68k.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.