| Message ID | 20211217093325.30612-15-conor.dooley@microchip.com |
|---|---|
| State | New |
| Headers | show |
| Series | Update the Icicle Kit device tree | expand |
Hi Conor, On Fri, Dec 17, 2021 at 10:33 AM <conor.dooley@microchip.com> wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Split the device tree for the Microchip MPFS into two sections by adding > microchip-mpfs-fabric.dtsi, which contains peripherals contained in the > FPGA fabric. > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Thanks for your patch! > --- /dev/null > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi > @@ -0,0 +1,13 @@ > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > +/* Copyright (c) 2020-2021 Microchip Technology Inc */ > + > +/ { > + corePWM0: pwm@41000000 { > + compatible = "microchip,corepwm"; > + reg = <0x0 0x41000000 0x0 0xF0>; > + microchip,sync-update = /bits/ 8 <0>; > + #pwm-cells = <2>; > + clocks = <&clkcfg CLK_FIC3>; > + status = "disabled"; > + }; I'm wondering if these should be grouped under a "fabric" subnode, like we have an "soc" subnode for on-SoC devices? Rob? BTW, do you already have a naming plan for different revisions of FPGA fabric cores? 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
On 17/12/2021 10:33, conor.dooley@microchip.com wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Split the device tree for the Microchip MPFS into two sections by adding > microchip-mpfs-fabric.dtsi, which contains peripherals contained in the > FPGA fabric. > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > .../boot/dts/microchip/microchip-mpfs-fabric.dtsi | 13 +++++++++++++ > .../dts/microchip/microchip-mpfs-icicle-kit.dts | 4 ++++ > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > 3 files changed, 18 insertions(+) > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi > new file mode 100644 > index 000000000000..234c1f9bea40 > --- /dev/null > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi > @@ -0,0 +1,13 @@ > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > +/* Copyright (c) 2020-2021 Microchip Technology Inc */ > + > +/ { > + corePWM0: pwm@41000000 { Lowercase labels please, so could be "core_pwm0". Best regards, Krzysztof
On 17/12/2021 13:43, Geert Uytterhoeven wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Conor, > > On Fri, Dec 17, 2021 at 10:33 AM <conor.dooley@microchip.com> wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> Split the device tree for the Microchip MPFS into two sections by adding >> microchip-mpfs-fabric.dtsi, which contains peripherals contained in the >> FPGA fabric. >> >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > Thanks for your patch! > >> --- /dev/null >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi >> @@ -0,0 +1,13 @@ >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> +/* Copyright (c) 2020-2021 Microchip Technology Inc */ >> + >> +/ { >> + corePWM0: pwm@41000000 { >> + compatible = "microchip,corepwm"; >> + reg = <0x0 0x41000000 0x0 0xF0>; >> + microchip,sync-update = /bits/ 8 <0>; >> + #pwm-cells = <2>; >> + clocks = <&clkcfg CLK_FIC3>; >> + status = "disabled"; >> + }; > > I'm wondering if these should be grouped under a "fabric" subnode, > like we have an "soc" subnode for on-SoC devices? Rob? > > BTW, do you already have a naming plan for different revisions of > FPGA fabric cores? Not yet (assuming you mean specifically how we will handle it in the device tree) - although i was talking to someone about it yesterday. It's possible that we might handle that via a register, but if you have a suggestion or some precedence that you're aware of that would be useful. The actual naming convention of the IP cores themselves, yeah. I will dig it up for you on Monday. > > 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 >
Hi Conor, On Fri, Dec 17, 2021 at 4:32 PM <Conor.Dooley@microchip.com> wrote: > On 17/12/2021 13:43, Geert Uytterhoeven wrote: > > On Fri, Dec 17, 2021 at 10:33 AM <conor.dooley@microchip.com> wrote: > >> From: Conor Dooley <conor.dooley@microchip.com> > >> > >> Split the device tree for the Microchip MPFS into two sections by adding > >> microchip-mpfs-fabric.dtsi, which contains peripherals contained in the > >> FPGA fabric. > >> > >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > > > Thanks for your patch! > > > >> --- /dev/null > >> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi > >> @@ -0,0 +1,13 @@ > >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > >> +/* Copyright (c) 2020-2021 Microchip Technology Inc */ > >> + > >> +/ { > >> + corePWM0: pwm@41000000 { > >> + compatible = "microchip,corepwm"; > >> + reg = <0x0 0x41000000 0x0 0xF0>; > >> + microchip,sync-update = /bits/ 8 <0>; > >> + #pwm-cells = <2>; > >> + clocks = <&clkcfg CLK_FIC3>; > >> + status = "disabled"; > >> + }; > > > > I'm wondering if these should be grouped under a "fabric" subnode, > > like we have an "soc" subnode for on-SoC devices? Rob? > > > > BTW, do you already have a naming plan for different revisions of > > FPGA fabric cores? > Not yet (assuming you mean specifically how we will handle it in the > device tree) - although i was talking to someone about it yesterday. > It's possible that we might handle that via a register, but if you have > a suggestion or some precedence that you're aware of that would be useful. > > The actual naming convention of the IP cores themselves, yeah. I will > dig it up for you on Monday. I meant what if corepwm is enhanced, and how to detect that? SiFive uses an integer version number, even for hard cores[1]. OpenCores uses an "-rtlsvnN" suffix (isn't svn dead? ;-) No idea what e.g. LiteX and Microwatt are planning. [1] Documentation/devicetree/bindings/sifive/sifive-blocks-ip-versioning.txt 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
On 17/12/2021 16:00, Geert Uytterhoeven wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Conor, > > On Fri, Dec 17, 2021 at 4:32 PM <Conor.Dooley@microchip.com> wrote: >> On 17/12/2021 13:43, Geert Uytterhoeven wrote: >>> On Fri, Dec 17, 2021 at 10:33 AM <conor.dooley@microchip.com> wrote: >>>> From: Conor Dooley <conor.dooley@microchip.com> >>>> >>>> Split the device tree for the Microchip MPFS into two sections by adding >>>> microchip-mpfs-fabric.dtsi, which contains peripherals contained in the >>>> FPGA fabric. >>>> >>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >>> >>> Thanks for your patch! >>> >>>> --- /dev/null >>>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi >>>> @@ -0,0 +1,13 @@ >>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >>>> +/* Copyright (c) 2020-2021 Microchip Technology Inc */ >>>> + >>>> +/ { >>>> + corePWM0: pwm@41000000 { >>>> + compatible = "microchip,corepwm"; >>>> + reg = <0x0 0x41000000 0x0 0xF0>; >>>> + microchip,sync-update = /bits/ 8 <0>; >>>> + #pwm-cells = <2>; >>>> + clocks = <&clkcfg CLK_FIC3>; >>>> + status = "disabled"; >>>> + }; >>> >>> I'm wondering if these should be grouped under a "fabric" subnode, >>> like we have an "soc" subnode for on-SoC devices? Rob? >>> >>> BTW, do you already have a naming plan for different revisions of >>> FPGA fabric cores? >> Not yet (assuming you mean specifically how we will handle it in the >> device tree) - although i was talking to someone about it yesterday. >> It's possible that we might handle that via a register, but if you have >> a suggestion or some precedence that you're aware of that would be useful. >> >> The actual naming convention of the IP cores themselves, yeah. I will >> dig it up for you on Monday. > > I meant what if corepwm is enhanced, and how to detect that? > Looks like "microchip,core<name>-N" is the plan. More recent IP cores have a register from which the version number can be read but that isnt (and wont be) the case for all versions. Where this register does exist, we will use it & if not fall back onto the compat. string. > SiFive uses an integer version number, even for hard cores[1]. > OpenCores uses an "-rtlsvnN" suffix (isn't svn dead? ;-) At least here, "hardware" people seem to be a fan of it still (sadly?) > No idea what e.g. LiteX and Microwatt are planning. > > [1] Documentation/devicetree/bindings/sifive/sifive-blocks-ip-versioning.txt > > > 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
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi new file mode 100644 index 000000000000..234c1f9bea40 --- /dev/null +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi @@ -0,0 +1,13 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* Copyright (c) 2020-2021 Microchip Technology Inc */ + +/ { + corePWM0: pwm@41000000 { + compatible = "microchip,corepwm"; + reg = <0x0 0x41000000 0x0 0xF0>; + microchip,sync-update = /bits/ 8 <0>; + #pwm-cells = <2>; + clocks = <&clkcfg CLK_FIC3>; + status = "disabled"; + }; +}; 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 6d19ba196f12..174f977c164b 100644 --- a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts @@ -86,3 +86,7 @@ phy1: ethernet-phy@9 { ti,fifo-depth = <0x01>; }; }; + +&corePWM0 { + status = "okay"; +}; diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi index ce9151edd1b6..808500be26c3 100644 --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi @@ -4,6 +4,7 @@ /dts-v1/; #include "dt-bindings/clock/microchip,mpfs-clock.h" #include "dt-bindings/interrupt-controller/riscv-hart.h" +#include "microchip-mpfs-fabric.dtsi" / { #address-cells = <2>;