All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Brad Larson <brad@pensando.io>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Mark Brown <broonie@kernel.org>,
	Serge Semin <fancer.lancer@gmail.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Olof Johansson <olof@lixom.net>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/8] arm64: dts: Add Pensando Elba SoC support
Date: Thu, 4 Mar 2021 10:06:11 +0100	[thread overview]
Message-ID: <CAK8P3a1dwtXqneyNdNNdG4f03o3a+SCUXCb5ESDap+mjyG3Ohg@mail.gmail.com> (raw)
In-Reply-To: <20210304034141.7062-8-brad@pensando.io>

On Thu, Mar 4, 2021 at 4:41 AM Brad Larson <brad@pensando.io> wrote:
>
> Add Pensando common and Elba SoC specific device nodes
> and corresponding binding documentation.
>
> Signed-off-by: Brad Larson <brad@pensando.io>
> ---
>  .../bindings/gpio/pensando,elba-spics.txt     |  24 ++
>  .../devicetree/bindings/mmc/cdns,sdhci.yaml   |   2 +-
>  .../bindings/spi/cadence-quadspi.txt          |   1 +

It would be better to split each of the above out into a separate patch for
easier review, and send them along with the driver changes.

> diff --git a/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt b/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> new file mode 100644
> index 000000000000..30f5f3275238
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> @@ -0,0 +1,24 @@
> +Pensando Elba SPI Chip Select Driver
> +
> +The Pensando Elba ASIC provides four SPI bus chip selects
> +
> +Required properties:
> +- compatible: Should be "pensando,elba-spics"
> +- reg: Address range of spics controller
> +- gpio-controller: Marks the device node as gpio controller
> +- #gpio-cells: Must be 2

You need to document what each of the cells are for. In your
example, the second cell is always zero, is that intentional?

> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index af7442f73881..645ae696ba24 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> @@ -122,7 +122,7 @@ unevaluatedProperties: false
>  examples:
>    - |
>      emmc: mmc@5a000000 {
> -        compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> +        compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc", "pensando,elba-emmc";
>          reg = <0x5a000000 0x400>;
>          interrupts = <0 78 4>;
>          clocks = <&clk 4>;

These are in the wrong order, the most generic one (cdns,sd4hc) always
comes last.

If you add the string in the example, it also has to be an option in the
actual binding, otherwise neither the example nor your dtb would
be valid.

You also wouldn't find a controller that is compatible with both the uniphier
variant and the elba variant, unless your 'elba' SoC is strictly derived from
Socionext's Uniphier products and inherits all the quirks in its sdhci
implementation that were not already part of Cadence's IP block.

> diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> index 8ace832a2d80..dbb346b2b1d7 100644
> --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> @@ -6,6 +6,7 @@ Required properties:
>         For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
>         For TI AM654 SoC  - "ti,am654-ospi", "cdns,qspi-nor".
>         For Intel LGM SoC - "intel,lgm-qspi", "cdns,qspi-nor".
> +       For Pensando SoC - "pensando,cdns-qspi".

This does not look specific enough: There is no guarantee that this
is the only time Pensando uses any Cadenci qspi block. If the company
is not yet out of business, you should be prepared for future products
and have the name of the chip in there as well.

> +               cpu0: cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a72", "arm,armv8";
> +                       reg = <0 0x0>;
> +                       enable-method = "spin-table";
> +                       next-level-cache = <&l2_0>;

spin-table is not really something we want to see for new machines.
Please add proper psci support to your boot loader.

> index 000000000000..9623df208131
> --- /dev/null
> +++ b/arch/arm64/boot/dts/pensando/elba-asic-common.dtsi
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> +       model = "Elba ASIC Board";
> +
> +       aliases {
> +               serial0 = &uart0;
> +                spi0 = &spi0;
> +                spi1 = &qspi;
> +       };
> +
> +       chosen {
> +               stdout-path = "serial0:19200n8";
> +       };
> +};

These properties are usually board specific, and should be moved into the
.dts file.

> +       spi@0 {
> +               compatible = "pensando,cpld";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               spi-max-frequency = <12000000>;
> +               reg = <0>;
> +       };


> +       spi@2 {
> +               compatible = "pensando,cpld-rd1173";

These don't seem to have a binding document, which needs to be added
first. What is a Pensando "cpld"? Is it possible that there will be multiple
versions of it that need to be uniquely identified?

> +
> +       /* Common UIO device for MSI drivers */
> +       uio_penmsi {
> +               compatible = "pensando,uio_penmsi";
> +               name = "uio_penmsi";
> +       };

Missing binding again. Since you name this a UIO device, I assume this
is actually tied to a particular Linux device driver and exported to user
space. The information in the dts should however not assume a particular
OS implementation but describe the platform.

Is this for PCI MSI? If so, I would recommend just using the GICv3 that you
also have, and leave this device completely unused.

In either case, please leave out the device node until a binding has
been agreed and a matching kernel driver was reviewed (if any)

> +
> +               /*
> +                * Until we  know the interrupt domain following this, we
> +                * are forced to use this is the place where interrupts from
> +                * PCI converge. In the ideal case, we use one domain higher,
> +                * where the PCI-ness has been shed.
> +                */
> +               pxc0_intr: intc@20102200 {
> +                       compatible = "pensando,soc-ictlr-csrintr";
> +                       interrupt-controller;
> +                       reg = <0x0 0x20102200 0x0 0x4>;
> +                       #interrupt-cells = <3>;
> +                       interrupt-parent = <&gic>;
> +                       interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> +                       interrupt-names = "pxc0_intr";
> +               };

Leave this one out as well, this has to be reviewed in combination with the
PCI driver.

> +               pcie@307c2480 {
> +                       compatible = "pensando,pcie";
> +                       reg = <0x0 0x307c2480 0x0 0x4   /* MS CFG_WDT */
> +                              0x0 0x00001400 0x0 0x10  /* WDT0 */
> +                              0x0 0x20000000 0x0 0x00380000>; /* PXB Base */
> +               };

This does not follow the PCI host bridge binding. Leave it out for now,
and bring it back once you have a proper PCI driver.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Brad Larson <brad@pensando.io>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	 Mark Brown <broonie@kernel.org>,
	Serge Semin <fancer.lancer@gmail.com>,
	 Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	 Olof Johansson <olof@lixom.net>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	 linux-spi <linux-spi@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	 DTML <devicetree@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/8] arm64: dts: Add Pensando Elba SoC support
Date: Thu, 4 Mar 2021 10:06:11 +0100	[thread overview]
Message-ID: <CAK8P3a1dwtXqneyNdNNdG4f03o3a+SCUXCb5ESDap+mjyG3Ohg@mail.gmail.com> (raw)
In-Reply-To: <20210304034141.7062-8-brad@pensando.io>

On Thu, Mar 4, 2021 at 4:41 AM Brad Larson <brad@pensando.io> wrote:
>
> Add Pensando common and Elba SoC specific device nodes
> and corresponding binding documentation.
>
> Signed-off-by: Brad Larson <brad@pensando.io>
> ---
>  .../bindings/gpio/pensando,elba-spics.txt     |  24 ++
>  .../devicetree/bindings/mmc/cdns,sdhci.yaml   |   2 +-
>  .../bindings/spi/cadence-quadspi.txt          |   1 +

It would be better to split each of the above out into a separate patch for
easier review, and send them along with the driver changes.

> diff --git a/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt b/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> new file mode 100644
> index 000000000000..30f5f3275238
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> @@ -0,0 +1,24 @@
> +Pensando Elba SPI Chip Select Driver
> +
> +The Pensando Elba ASIC provides four SPI bus chip selects
> +
> +Required properties:
> +- compatible: Should be "pensando,elba-spics"
> +- reg: Address range of spics controller
> +- gpio-controller: Marks the device node as gpio controller
> +- #gpio-cells: Must be 2

You need to document what each of the cells are for. In your
example, the second cell is always zero, is that intentional?

> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index af7442f73881..645ae696ba24 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> @@ -122,7 +122,7 @@ unevaluatedProperties: false
>  examples:
>    - |
>      emmc: mmc@5a000000 {
> -        compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> +        compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc", "pensando,elba-emmc";
>          reg = <0x5a000000 0x400>;
>          interrupts = <0 78 4>;
>          clocks = <&clk 4>;

These are in the wrong order, the most generic one (cdns,sd4hc) always
comes last.

If you add the string in the example, it also has to be an option in the
actual binding, otherwise neither the example nor your dtb would
be valid.

You also wouldn't find a controller that is compatible with both the uniphier
variant and the elba variant, unless your 'elba' SoC is strictly derived from
Socionext's Uniphier products and inherits all the quirks in its sdhci
implementation that were not already part of Cadence's IP block.

> diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> index 8ace832a2d80..dbb346b2b1d7 100644
> --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> @@ -6,6 +6,7 @@ Required properties:
>         For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
>         For TI AM654 SoC  - "ti,am654-ospi", "cdns,qspi-nor".
>         For Intel LGM SoC - "intel,lgm-qspi", "cdns,qspi-nor".
> +       For Pensando SoC - "pensando,cdns-qspi".

This does not look specific enough: There is no guarantee that this
is the only time Pensando uses any Cadenci qspi block. If the company
is not yet out of business, you should be prepared for future products
and have the name of the chip in there as well.

> +               cpu0: cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a72", "arm,armv8";
> +                       reg = <0 0x0>;
> +                       enable-method = "spin-table";
> +                       next-level-cache = <&l2_0>;

spin-table is not really something we want to see for new machines.
Please add proper psci support to your boot loader.

> index 000000000000..9623df208131
> --- /dev/null
> +++ b/arch/arm64/boot/dts/pensando/elba-asic-common.dtsi
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> +       model = "Elba ASIC Board";
> +
> +       aliases {
> +               serial0 = &uart0;
> +                spi0 = &spi0;
> +                spi1 = &qspi;
> +       };
> +
> +       chosen {
> +               stdout-path = "serial0:19200n8";
> +       };
> +};

These properties are usually board specific, and should be moved into the
.dts file.

> +       spi@0 {
> +               compatible = "pensando,cpld";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               spi-max-frequency = <12000000>;
> +               reg = <0>;
> +       };


> +       spi@2 {
> +               compatible = "pensando,cpld-rd1173";

These don't seem to have a binding document, which needs to be added
first. What is a Pensando "cpld"? Is it possible that there will be multiple
versions of it that need to be uniquely identified?

> +
> +       /* Common UIO device for MSI drivers */
> +       uio_penmsi {
> +               compatible = "pensando,uio_penmsi";
> +               name = "uio_penmsi";
> +       };

Missing binding again. Since you name this a UIO device, I assume this
is actually tied to a particular Linux device driver and exported to user
space. The information in the dts should however not assume a particular
OS implementation but describe the platform.

Is this for PCI MSI? If so, I would recommend just using the GICv3 that you
also have, and leave this device completely unused.

In either case, please leave out the device node until a binding has
been agreed and a matching kernel driver was reviewed (if any)

> +
> +               /*
> +                * Until we  know the interrupt domain following this, we
> +                * are forced to use this is the place where interrupts from
> +                * PCI converge. In the ideal case, we use one domain higher,
> +                * where the PCI-ness has been shed.
> +                */
> +               pxc0_intr: intc@20102200 {
> +                       compatible = "pensando,soc-ictlr-csrintr";
> +                       interrupt-controller;
> +                       reg = <0x0 0x20102200 0x0 0x4>;
> +                       #interrupt-cells = <3>;
> +                       interrupt-parent = <&gic>;
> +                       interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> +                       interrupt-names = "pxc0_intr";
> +               };

Leave this one out as well, this has to be reviewed in combination with the
PCI driver.

> +               pcie@307c2480 {
> +                       compatible = "pensando,pcie";
> +                       reg = <0x0 0x307c2480 0x0 0x4   /* MS CFG_WDT */
> +                              0x0 0x00001400 0x0 0x10  /* WDT0 */
> +                              0x0 0x20000000 0x0 0x00380000>; /* PXB Base */
> +               };

This does not follow the PCI host bridge binding. Leave it out for now,
and bring it back once you have a proper PCI driver.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-03-04  9:19 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04  3:41 [PATCH 0/8] Support Pensando Elba SoC Brad Larson
2021-03-04  3:41 ` Brad Larson
2021-03-04  3:41 ` [PATCH 1/8] gpio: Add Elba SoC gpio driver for spi cs control Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  8:29   ` Linus Walleij
2021-03-04  8:29     ` Linus Walleij
2021-03-04  9:10     ` Serge Semin
2021-03-04  9:10       ` Serge Semin
2021-03-04 13:38       ` Linus Walleij
2021-03-04 13:38         ` Linus Walleij
2021-08-23  1:05         ` Brad Larson
2021-08-23  1:05           ` Brad Larson
2021-08-29 21:09           ` Linus Walleij
2021-08-29 21:09             ` Linus Walleij
2021-10-04 16:46             ` Brad Larson
2021-10-04 16:46               ` Brad Larson
2021-10-12 23:51               ` Linus Walleij
2021-10-12 23:51                 ` Linus Walleij
2021-10-14 20:06                 ` Brad Larson
2021-10-14 20:06                   ` Brad Larson
2021-03-30  2:44     ` Brad Larson
2021-03-30  2:44       ` Brad Larson
2021-08-23  1:05     ` Brad Larson
2021-08-23  1:05       ` Brad Larson
2021-03-04 20:43   ` Elliott, Robert (Servers)
2021-03-04 20:43     ` Elliott, Robert (Servers)
2021-08-23  1:06     ` Brad Larson
2021-08-23  1:06       ` Brad Larson
2021-03-05 11:25   ` Krzysztof Kozlowski
2021-03-05 11:25     ` Krzysztof Kozlowski
2021-08-23  1:07     ` Brad Larson
2021-08-23  1:07       ` Brad Larson
2021-03-05 13:57   ` Geert Uytterhoeven
2021-03-05 13:57     ` Geert Uytterhoeven
2021-08-23  1:08     ` Brad Larson
2021-08-23  1:08       ` Brad Larson
2021-03-07 19:21   ` Andy Shevchenko
2021-03-07 19:21     ` Andy Shevchenko
2021-03-29  1:19     ` Brad Larson
2021-03-29  1:19       ` Brad Larson
2021-03-29 10:39       ` Andy Shevchenko
2021-03-29 10:39         ` Andy Shevchenko
2021-08-23  1:13         ` Brad Larson
2021-08-23  1:13           ` Brad Larson
2021-08-23  7:50           ` Geert Uytterhoeven
2021-08-23  7:50             ` Geert Uytterhoeven
2021-08-23 16:30             ` Brad Larson
2021-08-23 16:30               ` Brad Larson
2021-08-23 20:11               ` Geert Uytterhoeven
2021-08-23 20:11                 ` Geert Uytterhoeven
2021-10-04 17:14                 ` Brad Larson
2021-10-04 17:14                   ` Brad Larson
2021-10-04 17:16                   ` Geert Uytterhoeven
2021-10-04 17:16                     ` Geert Uytterhoeven
2021-08-23  1:10     ` Brad Larson
2021-08-23  1:10       ` Brad Larson
2021-03-04  3:41 ` [PATCH 2/8] spi: cadence-quadspi: Add QSPI support for Pensando Elba SoC Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  9:29   ` Arnd Bergmann
2021-03-04  9:29     ` Arnd Bergmann
2021-03-04  3:41 ` [PATCH 3/8] spi: dw: Add support for Pensando Elba SoC SPI Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  6:44   ` Serge Semin
2021-03-04  6:44     ` Serge Semin
2021-08-23  1:17     ` Brad Larson
2021-08-23  1:17       ` Brad Larson
2021-03-04  8:48   ` Linus Walleij
2021-03-04  8:48     ` Linus Walleij
2021-03-10  3:52     ` Brad Larson
2021-03-10  3:52       ` Brad Larson
2021-03-04  3:41 ` [PATCH 4/8] spidev: Add Pensando CPLD compatible Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  9:33   ` Arnd Bergmann
2021-03-04  9:33     ` Arnd Bergmann
2021-03-04  3:41 ` [PATCH 5/8] mmc: sdhci-cadence: Add Pensando Elba SoC support Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  9:41   ` Arnd Bergmann
2021-03-04  9:41     ` Arnd Bergmann
2021-03-04  3:41 ` [PATCH 6/8] arm64: Add config for Pensando SoC platforms Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  9:42   ` Arnd Bergmann
2021-03-04  9:42     ` Arnd Bergmann
2021-03-04  3:41 ` [PATCH 7/8] arm64: dts: Add Pensando Elba SoC support Brad Larson
2021-03-04  3:41   ` Brad Larson
2021-03-04  8:03   ` Serge Semin
2021-03-04  8:03     ` Serge Semin
2021-03-29  1:07     ` Brad Larson
2021-03-29  1:07       ` Brad Larson
2021-08-23  0:54     ` Brad Larson
2021-08-23  0:54       ` Brad Larson
2021-03-04  8:51   ` Linus Walleij
2021-03-04  8:51     ` Linus Walleij
2021-03-29  0:54     ` Brad Larson
2021-03-29  0:54       ` Brad Larson
2021-03-04  9:06   ` Arnd Bergmann [this message]
2021-03-04  9:06     ` Arnd Bergmann
2021-03-04 20:47   ` Rob Herring
2021-03-04 20:47     ` Rob Herring
2021-03-05 11:22   ` Krzysztof Kozlowski
2021-03-05 11:22     ` Krzysztof Kozlowski
2021-03-04  3:41 ` [PATCH 8/8] MAINTAINERS: Add entry for PENSANDO Brad Larson
2021-03-04  3:41   ` Brad Larson

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=CAK8P3a1dwtXqneyNdNNdG4f03o3a+SCUXCb5ESDap+mjyG3Ohg@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=adrian.hunter@intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=brad@pensando.io \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=ulf.hansson@linaro.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 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.