| Message ID | 20220117110755.3433142-1-conor.dooley@microchip.com |
|---|---|
| Headers | show |
| Series | Update the Icicle Kit device tree | expand |
Hi Conor, On Mon, Jan 17, 2022 at 12:06 PM <conor.dooley@microchip.com> wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Add device tree bindings for the i2c controller on > the Microchip PolarFire SoC. > > Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Thanks for your patch! > --- /dev/null > +++ b/Documentation/devicetree/bindings/i2c/microchip,mpfs-i2c.yaml > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/i2c/microchip,mpfs-i2c.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Microchip MPFS I2C Controller Device Tree Bindings > + > +maintainers: > + - Daire McNamara <daire.mcnamara@microchip.com> > + > +allOf: > + - $ref: /schemas/i2c/i2c-controller.yaml# > + > +properties: > + compatible: > + enum: > + - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs > + - microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core Wouldn't it be more logical to have: items: - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core ? If the IP core is reused, it can become: items: - enum: - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs - microchip,<foo>-i2c # ... - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core That way the driver can just match on the second (fallback) value, and no further driver changes will be needed (until v8 or later). 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 20/01/2022 08:30, Geert Uytterhoeven wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Conor, > > On Mon, Jan 17, 2022 at 12:06 PM <conor.dooley@microchip.com> wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> Add device tree bindings for the i2c controller on >> the Microchip PolarFire SoC. >> >> Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com> >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > Thanks for your patch! > >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/i2c/microchip,mpfs-i2c.yaml >> @@ -0,0 +1,55 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/i2c/microchip,mpfs-i2c.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Microchip MPFS I2C Controller Device Tree Bindings >> + >> +maintainers: >> + - Daire McNamara <daire.mcnamara@microchip.com> >> + >> +allOf: >> + - $ref: /schemas/i2c/i2c-controller.yaml# >> + >> +properties: >> + compatible: >> + enum: >> + - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs >> + - microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core > > Wouldn't it be more logical to have: > > items: > - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs > - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core > > ? This would be fine for mpfs-i2c since corei2c is a "superset" - but how would that look for the fabric core? I don't think falling back from the fabric core onto the "hard" one makes sense. This would mean the following two entries: i2c2: i2c@44000000 { //fabric compatible = "microchip,corei2c-rtl-v7"; }; i2c1: i2c@2010b000 { //"hard" mpfs peripheral compatible = "microchip,mpfs-i2c", "microchip,corei2c-rtl-v7"; }; But this generates errors in dt_binding_check w/ your suggestion - so how about the following (similar to ti,omap4-i2c.yaml): compatible: oneOf: - items: - const: microchip,mpfs-i2c # Microchip PolarFire... - const: microchip,corei2c-rtl-v7 # Microchip Fabric... - const: microchip,corei2c-rtl-v7 # Microchip Fabric... Is there a prettier way than this duplication? > > If the IP core is reused, it can become: > > items: > - enum: > - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs > - microchip,<foo>-i2c # ... > - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core > > That way the driver can just match on the second (fallback) value, > and no further driver changes will be needed (until v8 or later). > > 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 Thu, Jan 20, 2022 at 2:42 PM <Conor.Dooley@microchip.com> wrote: > On 20/01/2022 08:30, Geert Uytterhoeven wrote: > > On Mon, Jan 17, 2022 at 12:06 PM <conor.dooley@microchip.com> wrote: > >> From: Conor Dooley <conor.dooley@microchip.com> > >> > >> Add device tree bindings for the i2c controller on > >> the Microchip PolarFire SoC. > >> > >> Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com> > >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > > > Thanks for your patch! > > > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/i2c/microchip,mpfs-i2c.yaml > >> @@ -0,0 +1,55 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/i2c/microchip,mpfs-i2c.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Microchip MPFS I2C Controller Device Tree Bindings > >> + > >> +maintainers: > >> + - Daire McNamara <daire.mcnamara@microchip.com> > >> + > >> +allOf: > >> + - $ref: /schemas/i2c/i2c-controller.yaml# > >> + > >> +properties: > >> + compatible: > >> + enum: > >> + - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs > >> + - microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core > > > > Wouldn't it be more logical to have: > > > > items: > > - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs > > - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core > > > > ? > This would be fine for mpfs-i2c since corei2c is a "superset" - but how > would that look for the fabric core? I don't think falling back from the > fabric core onto the "hard" one makes sense. This would mean the > following two entries: > > i2c2: i2c@44000000 { //fabric > compatible = "microchip,corei2c-rtl-v7"; > }; > i2c1: i2c@2010b000 { //"hard" mpfs peripheral > compatible = "microchip,mpfs-i2c", "microchip,corei2c-rtl-v7"; > }; Oops, I missed that you have both forms. But in se, they're the same IP core, just hard vs. soft? Then the below makes sense. > But this generates errors in dt_binding_check w/ your suggestion - so > how about the following (similar to ti,omap4-i2c.yaml): > > compatible: > oneOf: > - items: > - const: microchip,mpfs-i2c # Microchip PolarFire... > - const: microchip,corei2c-rtl-v7 # Microchip Fabric... > - const: microchip,corei2c-rtl-v7 # Microchip Fabric... > > Is there a prettier way than this duplication? I'm afraid not, and the above scheme is used a lot. > > If the IP core is reused, it can become: > > > > items: > > - enum: > > - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs > > - microchip,<foo>-i2c # ... > > - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core > > > > That way the driver can just match on the second (fallback) value, > > and no further driver changes will be needed (until v8 or later). 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 Thu, Jan 20, 2022 at 2:42 PM <Conor.Dooley@microchip.com> wrote: >> On 20/01/2022 08:30, Geert Uytterhoeven wrote: >> > On Mon, Jan 17, 2022 at 12:06 PM <conor.dooley@microchip.com> wrote: >> > Wouldn't it be more logical to have: >> > >> > items: >> > - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs >> > - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core >> > >> > ? >> This would be fine for mpfs-i2c since corei2c is a "superset" - but how >> would that look for the fabric core? I don't think falling back from the >> fabric core onto the "hard" one makes sense. This would mean the >> following two entries: >> >> i2c2: i2c@44000000 { //fabric >> compatible = "microchip,corei2c-rtl-v7"; >> }; >> i2c1: i2c@2010b000 { //"hard" mpfs peripheral >> compatible = "microchip,mpfs-i2c", "microchip,corei2c-rtl-v7"; >> }; > >Oops, I missed that you have both forms. >But in se, they're the same IP core, just hard vs. soft? Then the >below makes sense. A lot (but not all) of the peripherals on Polarfire SoC are "subsets" of the IP cores: I think corei2c is almost identical but for others the hard version has some of the optional features disabled or slight changes made. If the IP is already written why not use it ;) > >> But this generates errors in dt_binding_check w/ your suggestion - so >> how about the following (similar to ti,omap4-i2c.yaml): >> >> compatible: >> oneOf: >> - items: >> - const: microchip,mpfs-i2c # Microchip PolarFire... >> - const: microchip,corei2c-rtl-v7 # Microchip Fabric... >> - const: microchip,corei2c-rtl-v7 # Microchip Fabric... >> >> Is there a prettier way than this duplication? > >I'm afraid not, and the above scheme is used a lot. Fair enough! > >> > If the IP core is reused, it can become: >> > >> > items: >> > - enum: >> > - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs >> > - microchip,<foo>-i2c # ... >> > - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core >> > >> > That way the driver can just match on the second (fallback) value, >> > and no further driver changes will be needed (until v8 or later).
On Mon, 17 Jan 2022 11:07:41 +0000, conor.dooley@microchip.com wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > This series updates the Microchip Icicle Kit device tree by adding a > host of peripherals, and some updates to the memory map. In addition, > the device tree has been split into a third part, which contains "soft" > peripherals that are in the fpga fabric. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [06/14] dt-bindings: spi: add bindings for microchip mpfs spi commit: 2da187304e556ac59cf2dacb323cc78ded988169 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
From: Conor Dooley <conor.dooley@microchip.com> This series updates the Microchip Icicle Kit device tree by adding a host of peripherals, and some updates to the memory map. In addition, the device tree has been split into a third part, which contains "soft" peripherals that are in the fpga fabric. Several of the entries are for peripherals that have not get had their drivers upstreamed, so in those cases the dt bindings are included where appropriate in order to avoid the many "DT compatible string <x> appears un-documented" errors. Depends on mpfs clock driver series [1] to provide: dt-bindings/clock/microchip,mpfs-clock.h and on the other changes to the icicle/mpfs device tree from geert that are already in linux/riscv/for-next. Additionally, the interrupt-extended warnings on the plic/clint are cleared by [2] & [3]. [1] https://lore.kernel.org/linux-clk/20211216140022.16146-1-conor.dooley@microchip.com/T/ [2] https://lore.kernel.org/linux-riscv/cover.1639744468.git.geert@linux-m68k.org/ [3] https://lore.kernel.org/linux-riscv/cover.1639744106.git.geert@linux-m68k.org/ Changes from v3: - drop "mailbox: change mailbox-mpfs compatible string", already upstream: commit f10b1fc0161cd99e - fix copy paste error in microchip,mpfs-mailbox dt-binding - remove whitespace in syscontroller dt entry Changes from v2: - dropped plic int header & corresponding defines in dts{,i} - use $ref to drmode in mpfs-musb binding - split changes to dts{,i} again: functional changes to existing elements now are in a new patch - drop num-cs property in mpfs-spi binding - dont make the system controller a simple-mfd - move the separate bindings for rng/generic system services into the system controller binding - added an instance corei2c as i2c2 in the fabric dtsi - add version numbering to corepwm and corei2c compat string (-rtl-vN) Conor Dooley (14): dt-bindings: soc/microchip: update syscontroller compatibles dt-bindings: soc/microchip: add services as children of sys ctrlr dt-bindings: i2c: add bindings for microchip mpfs i2c dt-bindings: rtc: add bindings for microchip mpfs rtc dt-bindings: gpio: add bindings for microchip mpfs gpio dt-bindings: spi: add bindings for microchip mpfs spi dt-bindings: usb: add bindings for microchip mpfs musb dt-bindings: pwm: add microchip corepwm binding riscv: dts: microchip: use clk defines for icicle kit riscv: dts: microchip: add fpga fabric section to icicle kit riscv: dts: microchip: refactor icicle kit device tree riscv: dts: microchip: update peripherals in icicle kit device tree riscv: dts: microchip: add new peripherals to icicle kit device tree MAINTAINERS: update riscv/microchip entry .../bindings/gpio/microchip,mpfs-gpio.yaml | 80 ++++++ .../bindings/i2c/microchip,mpfs-i2c.yaml | 55 ++++ ...ilbox.yaml => microchip,mpfs-mailbox.yaml} | 6 +- .../bindings/pwm/microchip,corepwm.yaml | 75 +++++ .../bindings/rtc/microchip,mfps-rtc.yaml | 63 +++++ .../microchip,mpfs-sys-controller.yaml | 73 +++++ ...icrochip,polarfire-soc-sys-controller.yaml | 35 --- .../bindings/spi/microchip,mpfs-spi.yaml | 52 ++++ .../bindings/usb/microchip,mpfs-musb.yaml | 59 ++++ MAINTAINERS | 2 + .../dts/microchip/microchip-mpfs-fabric.dtsi | 25 ++ .../microchip/microchip-mpfs-icicle-kit.dts | 115 ++++++-- .../boot/dts/microchip/microchip-mpfs.dtsi | 262 +++++++++++++++--- arch/riscv/configs/icicle_kit_defconfig | 134 +++++++++ 14 files changed, 932 insertions(+), 104 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml create mode 100644 Documentation/devicetree/bindings/i2c/microchip,mpfs-i2c.yaml rename Documentation/devicetree/bindings/mailbox/{microchip,polarfire-soc-mailbox.yaml => microchip,mpfs-mailbox.yaml} (82%) create mode 100644 Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml create mode 100644 Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml delete mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml create mode 100644 Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml create mode 100644 Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi create mode 100644 arch/riscv/configs/icicle_kit_defconfig