linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v6 00/17] Support AMD Pensando Elba SoC
@ 2022-08-20 19:57 Brad Larson
  2022-08-20 19:57 ` [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards Brad Larson
                   ` (16 more replies)
  0 siblings, 17 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

This series enables support for AMD Pensando Elba SoC based platforms.

The Elba SoC has the following features:
- Sixteen ARM64 A72 cores
- Dual DDR 4/5 memory controllers
- 32 lanes of PCIe Gen3/4 to the Host
- Network interfaces: Dual 200GE, Quad 100GE, 50GE, 25GE, 10GE and
  also a single 1GE management port.
- Storage/crypto offloads and 144 programmable P4 cores.
- QSPI and EMMC for SoC storage
- Two SPI interfaces for peripheral management
- I2C bus for platform management

== V6 changes ==
- Updated copyright and SPDX

v6-0001-dt-bindings-arm-add-AMD-Pensando-boards
- Delete 'Device Tree Bindings' in title

v6-0002-dt-bindings-mmc-cdns-Add-AMD-Pensando-Elba-SoC
- Change if/then for Elba which has a second reg for byte-lane control

v6-0003-dt-bindings-spi-cdns-Add-compatible-for-AMD-Pensa
- no change

v6-0004-dt-bindings-spi-dw-Add-AMD-Pensando-Elba-SoC-SPI-
- Add amd,pensando-elba-syscon

v6-0005-dt-bindings-mfd-syscon-Add-amd-pensando-elba-sysc
- no change

v6-0006-dt-bindings-mfd-amd-pensando-elbasr-Add-AMD-Pensa
- Expand description, rename nodes and change compatible usage

v6-0007-dt-bindings-reset-amd-pensando-elbasr-reset-Add-A
- Delete nodename pattern and changed spi0 to spi
- File amd,pensando-elba-reset.h is deleted as there is only
  one reset used.
- Update example

v6-0008-MAINTAINERS-Add-entry-for-AMD-PENSANDO
- no change

v6-0009-arm64-Add-config-for-AMD-Pensando-SoC-platforms
- no change

v6-0010-arm64-dts-Add-AMD-Pensando-Elba-SoC-support
- Update node names and add amd,pensando-elba-syscon
- Delete use of amd,pensando-elba-reset.h which had a single definition

v6-0011-spi-cadence-quadspi-Add-compatible-for-AMD-Pensan
- Remove (void) cast

v6-0012-spi-dw-Add-support-for-AMD-Pensando-Elba-SoC
- Update use of amd,pensando-elba-syscon

v6-0013-mmc-sdhci-cadence-Enable-device-specific-override
- Change this patch to add a priv_writel() callback where all
  existing designs use writel().  This separates the Elba
  support into three patches.  The second patch is added
  to the end of the sequence for Elba support.  The third
  patch enables mmc hardware reset.

v6-0014-mfd-pensando-elbasr-Add-AMD-Pensando-Elba-System-
- Updates from review comments
- Use spi_message_init_with_transfers instead of init/add_tail API

v6-0015-reset-elbasr-Add-AMD-Pensando-Elba-SR-Reset-Contr
- Remove use of amd,pensando-elba-reset.h and use BIT()

v6-0016-mmc-sdhci-cadence-Add-AMD-Pensando-Elba-SoC-suppo
- Elba sdhci-cadence.c support added in this patch to build on
  0013 which just adds a callback to override priv_writel()

v6-0017-mmc-sdhci-cadence-Support-mmc-hardware-reset
- New patch where Elba has a reset-controller for mmc hardware
  reset.  The reset is implemented by a register in the cpld.

== V5 changes ==
- Change to AMD Pensando instead of Pensando.
- No reference to spidev in the device tree.  Add multi-function driver
  pensando-elbasr and sub-device reset-elbasr which provides mfd and
  /dev interface to the cpld.
- Rebase to linux-next tag next-20220609 5.19.0-rc1
- Redo the email list after rebase and using scripts/get_maintainer.pl

== V4 changes ==
The version of dtschema used is 2022.3.2.

v4-0001-dt-bindings-arm-add-Pensando-boards.patch
- Add description and board compatible

v4-0003-dt-bindings-mmc-Add-Pensando-Elba-SoC-binding.patch
- Change from elba-emmc to elba-sd4hc to match file convention
- Use minItems: 1 and maxItems: 2 to pass schema check

v4-0005-dt-bindings-spi-dw-Add-Pensando-Elba-SoC-SPI-Control.patch
- Add required property pensando,syscon-spics to go with
  pensando,elba-spi

v4-0006-MAINTAINERS-Add-entry-for-PENSANDO.patch
- Change Maintained to Supported

v4-0007-arm64-Add-config-for-Pensando-SoC-platforms.patch
- Fix a typo on interface max speed

v4-0008-spi-cadence-quadspi-Add-compatible-for-Pensando-Elba.patch
- Update due to spi-cadence-quadspi.c changes

v4-0009-mmc-sdhci-cadence-Add-Pensando-Elba-SoC-support.patch
- Change from elba-emmc to elba-sd4hc to match file convention

v4-0010-spi-dw-Add-support-for-Pensando-Elba-SoC.patch
- Use more descriptive dt property pensando,syscon-spics
- Minor changes from review input

v4-0011-arm64-dts-Add-Pensando-Elba-SoC-support.patch
- Changed to dual copyright (GPL-2.0+ OR MIT)
- Minor changes from review input

== V3 changes ==
v3-0001-gpio-Add-Elba-SoC-gpio-driver-for-spi-cs-control.patch
- This patch is deleted.  Elba SOC specific gpio spics control is
  integrated into spi-dw-mmio.c.

v3-0002-spi-cadence-quadspi-Add-QSPI-support-for-Pensando-El.patch
- Changed compatible to "pensando,elba-qspi" to be more descriptive
  in spi-cadence-quadspi.c.

- Arnd wondered if moving to DT properties for quirks may be the
  way to go.  Feedback I've received on other patches was don't
  mix two efforts in one patch so I'm currently just adding the
  Elba support to the current design.

v3-0003-spi-dw-Add-support-for-Pensando-Elba-SoC-SPI.patch
- Changed the implementation to use existing dw_spi_set_cs() and
  integrated Elba specific CS control into spi-dw-mmio.c.  The
  native designware support is for two chip-selects while Elba
  provides 4 chip-selects.  Instead of adding a new file for
  this support in gpio-elba-spics.c the support is in one
  file (spi-dw-mmio.c).

v3-0004-spidev-Add-Pensando-CPLD-compatible.patch
- This patch is deleted.  The addition of compatible "pensando,cpld"
  to spidev.c is not added and an existing compatible is used 
  in the device tree to enable.

v3-0005-mmc-sdhci-cadence-Add-Pensando-Elba-SoC-support.patch
- Ulf and Yamada-san agreed the amount of code for this support
  is not enough to need a new file.  The support is added into
  sdhci-cadence.c and new files sdhci-cadence-elba.c and
  sdhci-cadence.h are deleted.
- Redundant defines are removed (e.g. use SDHCI_CDNS_HRS04 and
  remove SDIO_REG_HRS4).
- Removed phy init function sd4_set_dlyvr() and used existing
  sdhci_cdns_phy_init(). Init values are from DT properties.
- Replace  devm_ioremap_resource(&pdev->dev, iomem)
     with  devm_platform_ioremap_resource(pdev, 1)
- Refactored the elba priv_writ_l() and elba_write_l() to
  remove a little redundant code.
- The config option CONFIG_MMC_SDHCI_CADENCE_ELBA goes away.
- Only C syntax and Elba functions are prefixed with elba_

v3-0006-arm64-Add-config-for-Pensando-SoC-platforms.patch
- Added a little more info to the platform help text to assist
  users to decide on including platform support or not.

v3-0007-arm64-dts-Add-Pensando-Elba-SoC-support.patch
- Node names changed to DT generic names
- Changed from using 'spi@' which is reserved
- The elba-flash-parts.dtsi is kept separate as
  it is included in multiple dts files.
- SPDX license tags at the top of each file
- The compatible = "pensando,elba" and 'model' are
  now together in the board file.
- UIO nodes removed
- Ordered nodes by increasing unit address
- Removed an unreferenced container node.
- Dropped deprecated 'device_type' for uart0 node.

v3-0010-dt-bindings-spi-cadence-qspi-Add-support-for-Pensand.patch
- Updated since the latest documentation has been converted to yaml

v3-0011-dt-bindings-gpio-Add-Pensando-Elba-SoC-support.patch
- This patch is deleted since the Elba gpio spics is added to
  the spi dw driver and documented there.

Because of the deletion of patches and merging of code
the new patchset is not similar.  A changelog is added into
the patches for merged code to be helpful on the history.

== V2 changes ==
- 01    Fix typo, return code value and log message.
- 03    Remove else clause, intrinsic DW chip-select is never used.
- 08-11 Split out dts and bindings to sub-patches
- 10    Converted existing cadence-quadspi.txt to YAML schema
- 13    New driver should use <linux/gpio/driver.h>


Brad Larson (17):
  dt-bindings: arm: add AMD Pensando boards
  dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC
  dt-bindings: spi: cdns: Add compatible for AMD Pensando Elba SoC
  dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller
    bindings
  dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible
  dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System
    Resource chip
  dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR
    Reset Controller bindings
  MAINTAINERS: Add entry for AMD PENSANDO
  arm64: Add config for AMD Pensando SoC platforms
  arm64: dts: Add AMD Pensando Elba SoC support
  spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC
  spi: dw: Add support for AMD Pensando Elba SoC
  mmc: sdhci-cadence: Enable device specific override of writel()
  mfd: pensando-elbasr: Add AMD Pensando Elba System Resource chip
  reset: elbasr: Add AMD Pensando Elba SR Reset Controller
  mmc: sdhci-cadence: Add AMD Pensando Elba SoC support
  mmc: sdhci-cadence: Support mmc hardware reset

 .../devicetree/bindings/arm/amd,pensando.yaml |  26 +
 .../bindings/mfd/amd,pensando-elbasr.yaml     |  97 ++
 .../devicetree/bindings/mfd/syscon.yaml       |   1 +
 .../devicetree/bindings/mmc/cdns,sdhci.yaml   |  13 +-
 .../reset/amd,pensando-elbasr-reset.yaml      |  57 ++
 .../bindings/spi/cdns,qspi-nor.yaml           |  12 +
 .../bindings/spi/snps,dw-apb-ssi.yaml         |  11 +
 MAINTAINERS                                   |   9 +
 arch/arm64/Kconfig.platforms                  |  12 +
 arch/arm64/boot/dts/amd/Makefile              |   1 +
 arch/arm64/boot/dts/amd/elba-16core.dtsi      | 189 ++++
 arch/arm64/boot/dts/amd/elba-asic-common.dtsi | 101 +++
 arch/arm64/boot/dts/amd/elba-asic.dts         |  28 +
 arch/arm64/boot/dts/amd/elba-flash-parts.dtsi | 106 +++
 arch/arm64/boot/dts/amd/elba.dtsi             | 192 ++++
 drivers/mfd/Kconfig                           |  14 +
 drivers/mfd/Makefile                          |   1 +
 drivers/mfd/pensando-elbasr.c                 | 854 ++++++++++++++++++
 drivers/mmc/host/Kconfig                      |   1 +
 drivers/mmc/host/sdhci-cadence.c              | 179 +++-
 drivers/reset/Kconfig                         |   9 +
 drivers/reset/Makefile                        |   1 +
 drivers/reset/reset-elbasr.c                  |  77 ++
 drivers/spi/spi-cadence-quadspi.c             |  19 +
 drivers/spi/spi-dw-mmio.c                     |  77 ++
 include/linux/mfd/pensando-elbasr.h           |  78 ++
 26 files changed, 2149 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amd,pensando.yaml
 create mode 100644 Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
 create mode 100644 Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.yaml
 create mode 100644 arch/arm64/boot/dts/amd/elba-16core.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/elba-asic-common.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/elba-asic.dts
 create mode 100644 arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/elba.dtsi
 create mode 100644 drivers/mfd/pensando-elbasr.c
 create mode 100644 drivers/reset/reset-elbasr.c
 create mode 100644 include/linux/mfd/pensando-elbasr.h


base-commit: 3cc40a443a04d52b0c95255dce264068b01e9bfe
-- 
2.17.1


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-22 18:15   ` Krzysztof Kozlowski
  2022-08-20 19:57 ` [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC Brad Larson
                   ` (15 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Document the compatible for AMD Pensando Elba SoC boards.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 .../devicetree/bindings/arm/amd,pensando.yaml | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/amd,pensando.yaml

diff --git a/Documentation/devicetree/bindings/arm/amd,pensando.yaml b/Documentation/devicetree/bindings/arm/amd,pensando.yaml
new file mode 100644
index 000000000000..e5c2591834a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amd,pensando.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/amd,pensando.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Pensando SoC Platforms
+
+maintainers:
+  - Brad Larson <blarson@amd.com>
+
+properties:
+  $nodename:
+    const: "/"
+  compatible:
+    oneOf:
+
+      - description: Boards with Pensando Elba SoC
+        items:
+          - enum:
+              - amd,pensando-elba-ortano
+          - const: amd,pensando-elba
+
+additionalProperties: true
+
+...
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
  2022-08-20 19:57 ` [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-22 21:29   ` Rob Herring
  2022-08-20 19:57 ` [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for " Brad Larson
                   ` (14 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

AMD Pensando Elba ARM 64-bit SoC is integrated with this IP and
explicitly controls byte-lane enables.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 .../devicetree/bindings/mmc/cdns,sdhci.yaml         | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
index 4207fed62dfe..964b610eeef2 100644
--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -17,12 +17,14 @@ properties:
   compatible:
     items:
       - enum:
+          - amd,pensando-elba-sd4hc
           - microchip,mpfs-sd4hc
           - socionext,uniphier-sd4hc
       - const: cdns,sd4hc
 
   reg:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   interrupts:
     maxItems: 1
@@ -118,6 +120,15 @@ required:
   - interrupts
   - clocks
 
+if:
+  properties:
+    compatible:
+      const: amd,pensando-elba-sd4hc
+then:
+  properties:
+    reg:
+      minItems: 2
+
 unevaluatedProperties: false
 
 examples:
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for AMD Pensando Elba SoC
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
  2022-08-20 19:57 ` [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards Brad Larson
  2022-08-20 19:57 ` [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-22 18:22   ` Krzysztof Kozlowski
  2022-08-20 19:57 ` [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings Brad Larson
                   ` (13 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Document the cadence qspi controller compatible for AMD Pensando
Elba SoC boards.  The Elba qspi fifo size is 1024.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 .../devicetree/bindings/spi/cdns,qspi-nor.yaml       | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index 4707294d8f59..b9e49e90e280 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -20,11 +20,23 @@ allOf:
       required:
         - power-domains
 
+  - if:
+      properties:
+        compatible:
+          enum:
+            - amd,pensando-elba-qspi
+    then:
+      properties:
+        cdns,fifo-depth:
+          enum: [ 128, 256, 1024 ]
+          default: 1024
+
 properties:
   compatible:
     oneOf:
       - items:
           - enum:
+              - amd,pensando-elba-qspi
               - ti,k2g-qspi
               - ti,am654-ospi
               - intel,lgm-qspi
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (2 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for " Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-21 17:49   ` Serge Semin
  2022-08-22 18:19   ` Krzysztof Kozlowski
  2022-08-20 19:57 ` [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible Brad Larson
                   ` (12 subsequent siblings)
  16 siblings, 2 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

The AMD Pensando Elba SoC has integrated the DW APB SPI Controller

Signed-off-by: Brad Larson <blarson@amd.com>
---
 .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
index 37c3c272407d..403d6416f7ac 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -37,6 +37,15 @@ allOf:
     else:
       required:
         - interrupts
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - amd,pensando-elba-spi
+    then:
+      required:
+        - amd,pensando-elba-syscon
 
 properties:
   compatible:
@@ -75,6 +84,8 @@ properties:
               - renesas,r9a06g032-spi # RZ/N1D
               - renesas,r9a06g033-spi # RZ/N1S
           - const: renesas,rzn1-spi   # RZ/N1
+      - description: AMD Pensando Elba SoC SPI Controller
+        const: amd,pensando-elba-spi
 
   reg:
     minItems: 1
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (3 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-22 18:23   ` Krzysztof Kozlowski
  2022-08-20 19:57 ` [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
                   ` (11 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add the AMD Pensando Elba SoC system registers compatible.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index c10f0b577268..b6ae68851752 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -38,6 +38,7 @@ properties:
               - allwinner,sun8i-h3-system-controller
               - allwinner,sun8i-v3s-system-controller
               - allwinner,sun50i-a64-system-controller
+              - amd,pensando-elba-syscon
               - brcm,cru-clkset
               - freecom,fsg-cs2-system-controller
               - hisilicon,dsa-subctrl
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (4 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-21 20:21   ` Rob Herring
  2022-08-22 14:25   ` Rob Herring
  2022-08-20 19:57 ` [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings Brad Larson
                   ` (10 subsequent siblings)
  16 siblings, 2 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add support for the AMD Pensando Elba SoC System Resource chip
using the SPI interface.  The Elba SR is a Multi-function Device
supporting device register access using CS0, smbus interface for
FRU and board peripherals using CS1, dual Lattice I2C masters for
transceiver management using CS2, and CS3 for flash access.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 .../bindings/mfd/amd,pensando-elbasr.yaml     | 97 +++++++++++++++++++
 1 file changed, 97 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml

diff --git a/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
new file mode 100644
index 000000000000..ded347c3352c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/amd,pensando-elbasr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Pensando Elba SoC Resource Controller bindings
+
+description: |
+  AMD Pensando Elba SoC Resource Controller is a set of
+  miscellaneous control/status registers accessed on CS0,
+  a designware i2c master/slave on CS1, a Lattice rd1173
+  dual i2c master on CS2, and flash on CS3.  The /dev interfaces
+  created are /dev/pensr0.<CS>.  Hardware reset of the eMMC
+  is implemented by a sub-device reset-controller which accesses
+  a CS0 control register.
+
+maintainers:
+  - Brad Larson <blarson@amd.com>
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - amd,pensando-elbasr
+
+  spi-max-frequency:
+    description: Maximum SPI frequency of the device in Hz.
+
+  reg:
+    maxItems: 1
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  interrupts:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - spi-max-frequency
+
+patternProperties:
+  '^reset-controller@[a-f0-9]+$':
+    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        num-cs = <4>;
+
+        sysc: system-controller@0 {
+            compatible = "amd,pensando-elbasr";
+            reg = <0>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            spi-max-frequency = <12000000>;
+
+            rstc: reset-controller@0 {
+                compatible = "amd,pensando-elbasr-reset";
+                reg = <0>;
+                #reset-cells = <1>;
+            };
+        };
+
+        i2c1: i2c@1 {
+            compatible = "amd,pensando-elbasr";
+            reg = <1>;
+            spi-max-frequency = <12000000>;
+        };
+
+        i2c2: i2c@2 {
+            compatible = "amd,pensando-elbasr";
+            reg = <2>;
+            spi-max-frequency = <12000000>;
+            interrupt-parent = <&porta>;
+            interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+        };
+
+        flash@3 {
+            compatible = "amd,pensando-elbasr";
+            reg = <3>;
+            spi-max-frequency = <12000000>;
+        };
+    };
+
+...
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (5 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-21 20:21   ` Rob Herring
  2022-08-20 19:57 ` [PATCH v6 08/17] MAINTAINERS: Add entry for AMD PENSANDO Brad Larson
                   ` (9 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Document bindings for AMD Pensando Elba SR Reset Controller

Signed-off-by: Brad Larson <blarson@amd.com>
---
 .../reset/amd,pensando-elbasr-reset.yaml      | 57 +++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.yaml

diff --git a/Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.yaml b/Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.yaml
new file mode 100644
index 000000000000..0fdc6cc5ecdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/amd,pensando-elbasr-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Pensando Elba SoC Reset Controller
+
+maintainers:
+  - Brad Larson <blarson@amd.com>
+
+description: |
+  AMD Pensando Elba SoC reset controller driver which supports a resource
+  controller connected to the Elba SoC over a SPI bus.  The Elba reset
+  controller must be defined as a child node of the Elba SPI bus
+  chip-select 0 node.
+
+properties:
+  compatible:
+    const: amd,pensando-elbasr-reset
+
+  reg:
+    const: 0
+
+  '#reset-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        num-cs = <4>;
+
+        spi@0 {
+            compatible = "amd,pensando-elbasr";
+            reg = <0>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            spi-max-frequency = <12000000>;
+
+            rstc: reset-controller@0 {
+                compatible = "amd,pensando-elbasr-reset";
+                reg = <0>;
+                #reset-cells = <1>;
+            };
+        };
+    };
+
+...
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 08/17] MAINTAINERS: Add entry for AMD PENSANDO
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (6 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-20 19:57 ` [PATCH v6 09/17] arm64: Add config for AMD Pensando SoC platforms Brad Larson
                   ` (8 subsequent siblings)
  16 siblings, 0 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add entry for AMD PENSANDO maintainer and files

Signed-off-by: Brad Larson <blarson@amd.com>
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f512b430c7cb..b46379a15a86 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1802,6 +1802,15 @@ N:	allwinner
 N:	sun[x456789]i
 N:	sun50i
 
+ARM/AMD PENSANDO ARM64 ARCHITECTURE
+M:	Brad Larson <blarson@amd.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	Documentation/devicetree/bindings/*/amd,pensando*
+F:	arch/arm64/boot/dts/amd/elba*
+F:	drivers/mfd/pensando*
+F:	drivers/reset/reset-elbasr.c
+
 ARM/Amlogic Meson SoC CLOCK FRAMEWORK
 M:	Neil Armstrong <narmstrong@baylibre.com>
 M:	Jerome Brunet <jbrunet@baylibre.com>
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 09/17] arm64: Add config for AMD Pensando SoC platforms
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (7 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 08/17] MAINTAINERS: Add entry for AMD PENSANDO Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-20 19:57 ` [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
                   ` (7 subsequent siblings)
  16 siblings, 0 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add ARCH_PENSANDO configuration option for AMD Pensando
SoC based platforms.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 arch/arm64/Kconfig.platforms | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 74e9e9de3759..4de253974544 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -225,6 +225,18 @@ config ARCH_NPCM
 	  General support for NPCM8xx BMC (Arbel).
 	  Nuvoton NPCM8xx BMC based on the Cortex A35.
 
+config ARCH_PENSANDO
+	bool "AMD Pensando Platforms"
+	help
+	  This enables support for the ARMv8 based AMD Pensando SoC
+	  family to include the Elba SoC.
+
+	  AMD Pensando SoCs support a range of Distributed Services
+	  Cards in PCIe format installed into servers.  The Elba
+	  SoC includes 16 A-72 CPU cores, 144 programmable P4
+	  cores for a minimal latency/jitter datapath, and network
+	  interfaces up to 200 Gb/s.
+
 config ARCH_QCOM
 	bool "Qualcomm Platforms"
 	select GPIOLIB
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (8 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 09/17] arm64: Add config for AMD Pensando SoC platforms Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-09-30  7:27   ` Krzysztof Kozlowski
  2022-08-20 19:57 ` [PATCH v6 11/17] spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC Brad Larson
                   ` (6 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add AMD Pensando common and Elba SoC specific device nodes

Signed-off-by: Brad Larson <blarson@amd.com>
---
 arch/arm64/boot/dts/amd/Makefile              |   1 +
 arch/arm64/boot/dts/amd/elba-16core.dtsi      | 189 +++++++++++++++++
 arch/arm64/boot/dts/amd/elba-asic-common.dtsi | 101 +++++++++
 arch/arm64/boot/dts/amd/elba-asic.dts         |  28 +++
 arch/arm64/boot/dts/amd/elba-flash-parts.dtsi | 106 ++++++++++
 arch/arm64/boot/dts/amd/elba.dtsi             | 192 ++++++++++++++++++
 6 files changed, 617 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amd/elba-16core.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/elba-asic-common.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/elba-asic.dts
 create mode 100644 arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/elba.dtsi

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index 68103a8b0ef5..8502cc2afbc5 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_PENSANDO) += elba-asic.dtb
 dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
diff --git a/arch/arm64/boot/dts/amd/elba-16core.dtsi b/arch/arm64/boot/dts/amd/elba-16core.dtsi
new file mode 100644
index 000000000000..37aadd442db8
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/elba-16core.dtsi
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+/*
+ * Copyright 2020-2022 Advanced Micro Devices, Inc.
+ */
+
+/ {
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 { cpu = <&cpu0>; };
+				core1 { cpu = <&cpu1>; };
+				core2 { cpu = <&cpu2>; };
+				core3 { cpu = <&cpu3>; };
+			};
+
+			cluster1 {
+				core0 { cpu = <&cpu4>; };
+				core1 { cpu = <&cpu5>; };
+				core2 { cpu = <&cpu6>; };
+				core3 { cpu = <&cpu7>; };
+			};
+
+			cluster2 {
+				core0 { cpu = <&cpu8>; };
+				core1 { cpu = <&cpu9>; };
+				core2 { cpu = <&cpu10>; };
+				core3 { cpu = <&cpu11>; };
+			};
+
+			cluster3 {
+				core0 { cpu = <&cpu12>; };
+				core1 { cpu = <&cpu13>; };
+				core2 { cpu = <&cpu14>; };
+				core3 { cpu = <&cpu15>; };
+			};
+		};
+
+		/* CLUSTER 0 */
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x0>;
+			next-level-cache = <&l2_0>;
+			enable-method = "psci";
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x1>;
+			next-level-cache = <&l2_0>;
+			enable-method = "psci";
+		};
+
+		cpu2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x2>;
+			next-level-cache = <&l2_0>;
+			enable-method = "psci";
+		};
+
+		cpu3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x3>;
+			next-level-cache = <&l2_0>;
+			enable-method = "psci";
+		};
+
+		l2_0: l2-cache0 {
+			compatible = "cache";
+		};
+
+		/* CLUSTER 1 */
+		cpu4: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x100>;
+			next-level-cache = <&l2_1>;
+			enable-method = "psci";
+		};
+
+		cpu5: cpu@101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x101>;
+			next-level-cache = <&l2_1>;
+			enable-method = "psci";
+		};
+
+		cpu6: cpu@102 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x102>;
+			next-level-cache = <&l2_1>;
+			enable-method = "psci";
+		};
+
+		cpu7: cpu@103 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x103>;
+			next-level-cache = <&l2_1>;
+			enable-method = "psci";
+		};
+
+		l2_1: l2-cache1 {
+			compatible = "cache";
+		};
+
+		/* CLUSTER 2 */
+		cpu8: cpu@200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x200>;
+			next-level-cache = <&l2_2>;
+			enable-method = "psci";
+		};
+
+		cpu9: cpu@201 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x201>;
+			next-level-cache = <&l2_2>;
+			enable-method = "psci";
+		};
+
+		cpu10: cpu@202 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x202>;
+			next-level-cache = <&l2_2>;
+			enable-method = "psci";
+		};
+
+		cpu11: cpu@203 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x203>;
+			next-level-cache = <&l2_2>;
+			enable-method = "psci";
+		};
+
+		l2_2: l2-cache2 {
+			compatible = "cache";
+		};
+
+		/* CLUSTER 3 */
+		cpu12: cpu@300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x300>;
+			next-level-cache = <&l2_3>;
+			enable-method = "psci";
+		};
+
+		cpu13: cpu@301 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x301>;
+			next-level-cache = <&l2_3>;
+			enable-method = "psci";
+		};
+
+		cpu14: cpu@302 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x302>;
+			next-level-cache = <&l2_3>;
+			enable-method = "psci";
+		};
+
+		cpu15: cpu@303 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0 0x303>;
+			next-level-cache = <&l2_3>;
+			enable-method = "psci";
+		};
+
+		l2_3: l2-cache3 {
+			compatible = "cache";
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/amd/elba-asic-common.dtsi b/arch/arm64/boot/dts/amd/elba-asic-common.dtsi
new file mode 100644
index 000000000000..b0d6ec1953ab
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/elba-asic-common.dtsi
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+/*
+ * Copyright 2020-2022 Advanced Micro Devices, Inc.
+ */
+
+&ahb_clk {
+	clock-frequency = <400000000>;
+};
+
+&emmc_clk {
+	clock-frequency = <200000000>;
+};
+
+&flash_clk {
+	clock-frequency = <400000000>;
+};
+
+&ref_clk {
+	clock-frequency = <156250000>;
+};
+
+&qspi {
+	status = "okay";
+	flash0: flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+		spi-rx-bus-width = <2>;
+		m25p,fast-read;
+		cdns,read-delay = <0>;
+		cdns,tshsl-ns = <0>;
+		cdns,tsd2d-ns = <0>;
+		cdns,tchsh-ns = <0>;
+		cdns,tslch-ns = <0>;
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&emmc {
+	bus-width = <8>;
+	cap-mmc-hw-reset;
+	reset-names = "hw";
+	resets = <&rstc 0>;
+	status = "okay";
+};
+
+&wdt0 {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+	status = "okay";
+	rtc@51 {
+		compatible = "nxp,pcf85263";
+		reg = <0x51>;
+	};
+};
+
+&spi0 {
+	num-cs = <4>;
+	cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
+		   <&porta 7 GPIO_ACTIVE_LOW>;
+	status = "okay";
+	sysc: system-controller@0 {
+		compatible = "amd,pensando-elbasr";
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		spi-max-frequency = <12000000>;
+
+		rstc: reset-controller@0 {
+			compatible = "amd,pensando-elbasr-reset";
+			reg = <0>;
+			#reset-cells = <1>;
+		};
+	};
+
+	i2c1: i2c@1 {
+		compatible = "amd,pensando-elbasr";
+		reg = <1>;
+		spi-max-frequency = <12000000>;
+	};
+
+	i2c2: i2c@2 {
+		compatible = "amd,pensando-elbasr";
+		reg = <2>;
+		spi-max-frequency = <12000000>;
+		interrupt-parent = <&porta>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	flash@3 {
+		compatible = "amd,pensando-elbasr";
+		reg = <3>;
+		spi-max-frequency = <12000000>;
+	};
+};
diff --git a/arch/arm64/boot/dts/amd/elba-asic.dts b/arch/arm64/boot/dts/amd/elba-asic.dts
new file mode 100644
index 000000000000..c3f4da2f7449
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/elba-asic.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+/*
+ * Device Tree file for AMD Pensando Elba Board.
+ *
+ * Copyright 2020-2022 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+#include "elba.dtsi"
+#include "elba-16core.dtsi"
+#include "elba-asic-common.dtsi"
+#include "elba-flash-parts.dtsi"
+
+/ {
+	model = "AMD Pensando Elba Board";
+	compatible = "amd,pensando-elba-ortano", "amd,pensando-elba";
+
+	aliases {
+		serial0 = &uart0;
+		spi0 = &spi0;
+		spi1 = &qspi;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
diff --git a/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
new file mode 100644
index 000000000000..734893fef2c3
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+/*
+ * Copyright 2020-2022 Advanced Micro Devices, Inc.
+ */
+
+&flash0 {
+	partitions {
+		compatible = "fixed-partitions";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "flash";
+			reg = <0x10000 0xfff0000>;
+		};
+
+		partition@f0000 {
+			label = "golduenv";
+			reg = <0xf0000 0x10000>;
+		};
+
+		partition@100000 {
+			label = "boot0";
+			reg = <0x100000 0x80000>;
+		};
+
+		partition@180000 {
+			label = "golduboot";
+			reg = <0x180000 0x200000>;
+		};
+
+		partition@380000 {
+			label = "brdcfg0";
+			reg = <0x380000 0x10000>;
+		};
+
+		partition@390000 {
+			label = "brdcfg1";
+			reg = <0x390000 0x10000>;
+		};
+
+		partition@400000 {
+			label = "goldfw";
+			reg = <0x400000 0x3c00000>;
+		};
+
+		partition@4010000 {
+			label = "fwmap";
+			reg = <0x4010000 0x20000>;
+		};
+
+		partition@4030000 {
+			label = "fwsel";
+			reg = <0x4030000 0x20000>;
+		};
+
+		partition@4090000 {
+			label = "bootlog";
+			reg = <0x4090000 0x20000>;
+		};
+
+		partition@40b0000 {
+			label = "panicbuf";
+			reg = <0x40b0000 0x20000>;
+		};
+
+		partition@40d0000 {
+			label = "uservars";
+			reg = <0x40d0000 0x20000>;
+		};
+
+		partition@4200000 {
+			label = "uboota";
+			reg = <0x4200000 0x400000>;
+		};
+
+		partition@4600000 {
+			label = "ubootb";
+			reg = <0x4600000 0x400000>;
+		};
+
+		partition@4a00000 {
+			label = "mainfwa";
+			reg = <0x4a00000 0x1000000>;
+		};
+
+		partition@5a00000 {
+			label = "mainfwb";
+			reg = <0x5a00000 0x1000000>;
+		};
+
+		partition@6a00000 {
+			label = "diaguboot";
+			reg = <0x6a00000 0x400000>;
+		};
+
+		partition@8000000 {
+			label = "diagfw";
+			reg = <0x8000000 0x7fe0000>;
+		};
+
+		partition@ffe0000 {
+			label = "ubootenv";
+			reg = <0xffe0000 0x10000>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/amd/elba.dtsi b/arch/arm64/boot/dts/amd/elba.dtsi
new file mode 100644
index 000000000000..285d776aa67b
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/elba.dtsi
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+/*
+ * Copyright 2020-2022 Advanced Micro Devices, Inc.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include "dt-bindings/interrupt-controller/arm-gic.h"
+
+/ {
+	model = "Elba ASIC Board";
+	compatible = "amd,pensando-elba";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	dma-coherent;
+
+	ahb_clk: oscillator0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	emmc_clk: oscillator2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	flash_clk: oscillator3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	ref_clk: oscillator4 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a72-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	soc: soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		i2c0: i2c@400 {
+			compatible = "snps,designware-i2c";
+			reg = <0x0 0x400 0x0 0x100>;
+			clocks = <&ahb_clk>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			i2c-sda-hold-time-ns = <480>;
+			snps,sda-timeout-ms = <750>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		wdt0: watchdog@1400 {
+			compatible = "snps,dw-wdt";
+			reg = <0x0 0x1400 0x0 0x100>;
+			clocks = <&ahb_clk>;
+			interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		qspi: spi@2400 {
+			compatible = "amd,pensando-elba-qspi", "cdns,qspi-nor";
+			reg = <0x0 0x2400 0x0 0x400>,
+			      <0x0 0x7fff0000 0x0 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&flash_clk>;
+			cdns,fifo-depth = <1024>;
+			cdns,fifo-width = <4>;
+			cdns,trigger-address = <0x7fff0000>;
+			status = "disabled";
+		};
+
+		spi0: spi@2800 {
+			compatible = "amd,pensando-elba-spi";
+			reg = <0x0 0x2800 0x0 0x100>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			amd,pensando-elba-syscon = <&syscon>;
+			clocks = <&ahb_clk>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			num-cs = <2>;
+			status = "disabled";
+		};
+
+		gpio0: gpio@4000 {
+			compatible = "snps,dw-apb-gpio";
+			reg = <0x0 0x4000 0x0 0x78>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+
+			porta: gpio-port@0 {
+				compatible = "snps,dw-apb-gpio-port";
+				reg = <0>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				ngpios = <8>;
+				interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				interrupt-parent = <&gic>;
+				#interrupt-cells = <2>;
+			};
+
+			portb: gpio-port@1 {
+				compatible = "snps,dw-apb-gpio-port";
+				reg = <1>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				ngpios = <8>;
+			};
+		};
+
+		uart0: serial@4800 {
+			compatible = "ns16550a";
+			reg = <0x0 0x4800 0x0 0x100>;
+			clocks = <&ref_clk>;
+			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+		};
+
+		gic: interrupt-controller@800000 {
+			compatible = "arm,gic-v3";
+			reg = <0x0 0x800000 0x0 0x200000>,	/* GICD */
+			      <0x0 0xa00000 0x0 0x200000>,	/* GICR */
+			      <0x0 0x60000000 0x0 0x2000>,	/* GICC */
+			      <0x0 0x60010000 0x0 0x1000>,	/* GICH */
+			      <0x0 0x60020000 0x0 0x2000>;	/* GICV */
+			#address-cells = <2>;
+			#size-cells = <2>;
+			#interrupt-cells = <3>;
+			ranges;
+			interrupt-controller;
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+			/*
+			 * Elba specific pre-ITS is enabled using the
+			 * existing property socionext,synquacer-pre-its
+			 */
+			gic_its: msi-controller@820000 {
+				compatible = "arm,gic-v3-its";
+				reg = <0x0 0x820000 0x0 0x10000>;
+				msi-controller;
+				#msi-cells = <1>;
+				socionext,synquacer-pre-its =
+							<0xc00000 0x1000000>;
+			};
+		};
+
+		emmc: mmc@30440000 {
+			compatible = "amd,pensando-elba-sd4hc", "cdns,sd4hc";
+			reg = <0x0 0x30440000 0x0 0x10000>,
+			      <0x0 0x30480044 0x0 0x4>;	/* byte-lane ctrl */
+			clocks = <&emmc_clk>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			cdns,phy-input-delay-sd-highspeed = <0x4>;
+			cdns,phy-input-delay-legacy = <0x4>;
+			cdns,phy-input-delay-sd-uhs-sdr50 = <0x6>;
+			cdns,phy-input-delay-sd-uhs-ddr50 = <0x16>;
+			mmc-ddr-1_8v;
+			status = "disabled";
+		};
+
+		syscon: syscon@307c0000 {
+			compatible = "amd,pensando-elba-syscon", "syscon";
+			reg = <0x0 0x307c0000 0x0 0x3000>;
+		};
+	};
+};
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 11/17] spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (9 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-20 19:57 ` [PATCH v6 12/17] spi: dw: Add support " Brad Larson
                   ` (5 subsequent siblings)
  16 siblings, 0 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

The AMD Pensando Elba SoC has the Cadence QSPI controller integrated.

The quirk CQSPI_NEEDS_APB_AHB_HAZARD_WAR is added and if enabled
a dummy readback from the controller is performed to ensure
synchronization.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/spi/spi-cadence-quadspi.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 72b1a5a2298c..fe1e96e93091 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -39,6 +39,7 @@
 #define CQSPI_DISABLE_DAC_MODE		BIT(1)
 #define CQSPI_SUPPORT_EXTERNAL_DMA	BIT(2)
 #define CQSPI_NO_SUPPORT_WR_COMPLETION	BIT(3)
+#define CQSPI_NEEDS_APB_AHB_HAZARD_WAR	BIT(4)
 
 /* Capabilities */
 #define CQSPI_SUPPORTS_OCTAL		BIT(0)
@@ -87,6 +88,7 @@ struct cqspi_st {
 	bool			use_dma_read;
 	u32			pd_dev_id;
 	bool			wr_completion;
+	bool			apb_ahb_hazard;
 };
 
 struct cqspi_driver_platdata {
@@ -952,6 +954,13 @@ static int cqspi_indirect_write_execute(struct cqspi_flash_pdata *f_pdata,
 	if (cqspi->wr_delay)
 		ndelay(cqspi->wr_delay);
 
+	/*
+	 * If a hazard exists between the APB and AHB interfaces, perform a
+	 * dummy readback from the controller to ensure synchronization.
+	 */
+	if (cqspi->apb_ahb_hazard)
+		readl(reg_base + CQSPI_REG_INDIRECTWR);
+
 	while (remaining > 0) {
 		size_t write_words, mod_bytes;
 
@@ -1667,6 +1676,8 @@ static int cqspi_probe(struct platform_device *pdev)
 			cqspi->use_dma_read = true;
 		if (ddata->quirks & CQSPI_NO_SUPPORT_WR_COMPLETION)
 			cqspi->wr_completion = false;
+		if (ddata->quirks & CQSPI_NEEDS_APB_AHB_HAZARD_WAR)
+			cqspi->apb_ahb_hazard = true;
 
 		if (of_device_is_compatible(pdev->dev.of_node,
 					    "xlnx,versal-ospi-1.0"))
@@ -1789,6 +1800,10 @@ static const struct cqspi_driver_platdata versal_ospi = {
 	.get_dma_status = cqspi_get_versal_dma_status,
 };
 
+static const struct cqspi_driver_platdata pen_cdns_qspi = {
+	.quirks = CQSPI_NEEDS_APB_AHB_HAZARD_WAR | CQSPI_DISABLE_DAC_MODE,
+};
+
 static const struct of_device_id cqspi_dt_ids[] = {
 	{
 		.compatible = "cdns,qspi-nor",
@@ -1814,6 +1829,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
 		.compatible = "intel,socfpga-qspi",
 		.data = &socfpga_qspi,
 	},
+	{
+		.compatible = "amd,pensando-elba-qspi",
+		.data = &pen_cdns_qspi,
+	},
 	{ /* end of table */ }
 };
 
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 12/17] spi: dw: Add support for AMD Pensando Elba SoC
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (10 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 11/17] spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-21 18:18   ` Serge Semin
  2022-08-20 19:57 ` [PATCH v6 13/17] mmc: sdhci-cadence: Enable device specific override of writel() Brad Larson
                   ` (4 subsequent siblings)
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

The AMD Pensando Elba SoC includes a DW apb_ssi v4 controller
with device specific chip-select control.  The Elba SoC
provides four chip-selects where the native DW IP supports
two chip-selects.  The Elba DW_SPI instance has two native
CS signals that are always overridden.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/spi/spi-dw-mmio.c | 77 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index 26c40ea6dd12..36b8c5e10bb3 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -53,6 +53,24 @@ struct dw_spi_mscc {
 	void __iomem        *spi_mst; /* Not sparx5 */
 };
 
+struct dw_spi_elba {
+	struct regmap *syscon;
+};
+
+/*
+ * Elba SoC does not use ssi, pin override is used for cs 0,1 and
+ * gpios for cs 2,3 as defined in the device tree.
+ *
+ * cs:  |       1               0
+ * bit: |---3-------2-------1-------0
+ *      |  cs1   cs1_ovr   cs0   cs0_ovr
+ */
+#define ELBA_SPICS_REG			0x2468
+#define ELBA_SPICS_SHIFT(cs)		(2 * (cs))
+#define ELBA_SPICS_MASK(cs)		(0x3 << ELBA_SPICS_SHIFT(cs))
+#define ELBA_SPICS_SET(cs, val)	\
+			((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))
+
 /*
  * The Designware SPI controller (referred to as master in the documentation)
  * automatically deasserts chip select when the tx fifo is empty. The chip
@@ -237,6 +255,64 @@ static int dw_spi_canaan_k210_init(struct platform_device *pdev,
 	return 0;
 }
 
+static void dw_spi_elba_override_cs(struct dw_spi_elba *dwselba, int cs, int enable)
+{
+	regmap_update_bits(dwselba->syscon, ELBA_SPICS_REG, ELBA_SPICS_MASK(cs),
+			   ELBA_SPICS_SET(cs, enable));
+}
+
+static void dw_spi_elba_set_cs(struct spi_device *spi, bool enable)
+{
+	struct dw_spi *dws = spi_master_get_devdata(spi->master);
+	struct dw_spi_mmio *dwsmmio = container_of(dws, struct dw_spi_mmio, dws);
+	struct dw_spi_elba *dwselba = dwsmmio->priv;
+	u8 cs;
+
+	cs = spi->chip_select;
+	if (cs < 2)
+		dw_spi_elba_override_cs(dwselba, spi->chip_select, enable);
+
+	/*
+	 * The DW SPI controller needs a native CS bit selected to start
+	 * the serial engine.
+	 */
+	spi->chip_select = 0;
+	dw_spi_set_cs(spi, enable);
+	spi->chip_select = cs;
+}
+
+static int dw_spi_elba_init(struct platform_device *pdev,
+			    struct dw_spi_mmio *dwsmmio)
+{
+	const char *syscon_name = "amd,pensando-elba-syscon";
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *node;
+	struct dw_spi_elba *dwselba;
+	struct regmap *regmap;
+
+	node = of_parse_phandle(np, syscon_name, 0);
+	if (!node) {
+		dev_err(&pdev->dev, "failed to find %s\n", syscon_name);
+		return -ENODEV;
+	}
+
+	regmap = syscon_node_to_regmap(node);
+	if (IS_ERR(regmap)) {
+		dev_err(&pdev->dev, "syscon regmap lookup failed\n");
+		return PTR_ERR(regmap);
+	}
+
+	dwselba = devm_kzalloc(&pdev->dev, sizeof(*dwselba), GFP_KERNEL);
+	if (!dwselba)
+		return -ENOMEM;
+
+	dwselba->syscon = regmap;
+	dwsmmio->priv = dwselba;
+	dwsmmio->dws.set_cs = dw_spi_elba_set_cs;
+
+	return 0;
+}
+
 static int dw_spi_mmio_probe(struct platform_device *pdev)
 {
 	int (*init_func)(struct platform_device *pdev,
@@ -352,6 +428,7 @@ static const struct of_device_id dw_spi_mmio_of_match[] = {
 	{ .compatible = "intel,thunderbay-ssi", .data = dw_spi_intel_init},
 	{ .compatible = "microchip,sparx5-spi", dw_spi_mscc_sparx5_init},
 	{ .compatible = "canaan,k210-spi", dw_spi_canaan_k210_init},
+	{ .compatible = "amd,pensando-elba-spi", .data = dw_spi_elba_init},
 	{ /* end of table */}
 };
 MODULE_DEVICE_TABLE(of, dw_spi_mmio_of_match);
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 13/17] mmc: sdhci-cadence: Enable device specific override of writel()
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (11 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 12/17] spi: dw: Add support " Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-20 19:57 ` [PATCH v6 14/17] mfd: pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
                   ` (3 subsequent siblings)
  16 siblings, 0 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

SoCs with device specific Cadence implementation, such as setting
byte-enables before the write, need to override writel().  Add a
callback where the default is writel() for all existing chips.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/mmc/host/sdhci-cadence.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 6f2de54a5987..708d4297f241 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -67,6 +67,7 @@ struct sdhci_cdns_phy_param {
 struct sdhci_cdns_priv {
 	void __iomem *hrs_addr;
 	bool enhanced_strobe;
+	void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
 	unsigned int nr_phy_params;
 	struct sdhci_cdns_phy_param phy_params[];
 };
@@ -90,6 +91,12 @@ static const struct sdhci_cdns_phy_cfg sdhci_cdns_phy_cfgs[] = {
 	{ "cdns,phy-dll-delay-strobe", SDHCI_CDNS_PHY_DLY_STROBE, },
 };
 
+static inline void cdns_writel(struct sdhci_cdns_priv *priv, u32 val,
+			       void __iomem *reg)
+{
+	writel(val, reg);
+}
+
 static int sdhci_cdns_write_phy_reg(struct sdhci_cdns_priv *priv,
 				    u8 addr, u8 data)
 {
@@ -104,17 +111,17 @@ static int sdhci_cdns_write_phy_reg(struct sdhci_cdns_priv *priv,
 
 	tmp = FIELD_PREP(SDHCI_CDNS_HRS04_WDATA, data) |
 	      FIELD_PREP(SDHCI_CDNS_HRS04_ADDR, addr);
-	writel(tmp, reg);
+	priv->priv_writel(priv, tmp, reg);
 
 	tmp |= SDHCI_CDNS_HRS04_WR;
-	writel(tmp, reg);
+	priv->priv_writel(priv, tmp, reg);
 
 	ret = readl_poll_timeout(reg, tmp, tmp & SDHCI_CDNS_HRS04_ACK, 0, 10);
 	if (ret)
 		return ret;
 
 	tmp &= ~SDHCI_CDNS_HRS04_WR;
-	writel(tmp, reg);
+	priv->priv_writel(priv, tmp, reg);
 
 	ret = readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS04_ACK),
 				 0, 10);
@@ -191,7 +198,7 @@ static void sdhci_cdns_set_emmc_mode(struct sdhci_cdns_priv *priv, u32 mode)
 	tmp = readl(priv->hrs_addr + SDHCI_CDNS_HRS06);
 	tmp &= ~SDHCI_CDNS_HRS06_MODE;
 	tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_MODE, mode);
-	writel(tmp, priv->hrs_addr + SDHCI_CDNS_HRS06);
+	priv->priv_writel(priv, tmp, priv->hrs_addr + SDHCI_CDNS_HRS06);
 }
 
 static u32 sdhci_cdns_get_emmc_mode(struct sdhci_cdns_priv *priv)
@@ -223,7 +230,7 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
 	 */
 	for (i = 0; i < 2; i++) {
 		tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
-		writel(tmp, reg);
+		priv->priv_writel(priv, tmp, reg);
 
 		ret = readl_poll_timeout(reg, tmp,
 					 !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
@@ -386,6 +393,7 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
 	priv->nr_phy_params = nr_phy_params;
 	priv->hrs_addr = host->ioaddr;
 	priv->enhanced_strobe = false;
+	priv->priv_writel = cdns_writel;
 	host->ioaddr += SDHCI_CDNS_SRS_BASE;
 	host->mmc_host_ops.hs400_enhanced_strobe =
 				sdhci_cdns_hs400_enhanced_strobe;
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 14/17] mfd: pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (12 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 13/17] mmc: sdhci-cadence: Enable device specific override of writel() Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-20 19:57 ` [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller Brad Larson
                   ` (2 subsequent siblings)
  16 siblings, 0 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add support for the AMD Pensando Elba SoC System Resource chip
using the SPI interface.  The Elba SR is a Multi-function Device
supporting device register access using CS0, Designware I2C
interface for FRU and board peripherals using CS1, dual Lattice
rd1173 I2C masters for transceiver management using CS2, and CS3
for flash access.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/mfd/Kconfig                 |  14 +
 drivers/mfd/Makefile                |   1 +
 drivers/mfd/pensando-elbasr.c       | 854 ++++++++++++++++++++++++++++
 include/linux/mfd/pensando-elbasr.h |  78 +++
 4 files changed, 947 insertions(+)
 create mode 100644 drivers/mfd/pensando-elbasr.c
 create mode 100644 include/linux/mfd/pensando-elbasr.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index abb58ab1a1a4..902c33386c52 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1051,6 +1051,20 @@ config UCB1400_CORE
 	  To compile this driver as a module, choose M here: the
 	  module will be called ucb1400_core.
 
+config MFD_PENSANDO_ELBASR
+	bool "AMD Pensando Elba System Resource chip"
+	depends on SPI_MASTER=y
+	depends on (ARCH_PENSANDO && OF) || COMPILE_TEST
+	select REGMAP_SPI
+	select MFD_CORE
+	select MFD_SYSCON
+	help
+	  Support for the AMD Pensando Elba SoC System Resource chip using the
+	  SPI interface.  This driver provides userspace access to four device
+	  functions to include CS0 device registers, CS1 smbus interface for
+	  FRU and board peripherals, CS2 dual Lattice I2C masters for
+	  transceiver management, and CS3 flash for firmware update.
+
 config MFD_PM8XXX
 	tristate "Qualcomm PM8xxx PMIC chips driver"
 	depends on (ARM || HEXAGON || COMPILE_TEST)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 858cacf659d6..917b128abe5b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -212,6 +212,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS_PCI)	+= intel-lpss-pci.o
 obj-$(CONFIG_MFD_INTEL_LPSS_ACPI)	+= intel-lpss-acpi.o
 obj-$(CONFIG_MFD_INTEL_PMC_BXT)	+= intel_pmc_bxt.o
 obj-$(CONFIG_MFD_PALMAS)	+= palmas.o
+obj-$(CONFIG_MFD_PENSANDO_ELBASR)	+= pensando-elbasr.o
 obj-$(CONFIG_MFD_VIPERBOARD)    += viperboard.o
 obj-$(CONFIG_MFD_NTXEC)		+= ntxec.o
 obj-$(CONFIG_MFD_RC5T583)	+= rc5t583.o rc5t583-irq.o
diff --git a/drivers/mfd/pensando-elbasr.c b/drivers/mfd/pensando-elbasr.c
new file mode 100644
index 000000000000..7cc02d44c5b9
--- /dev/null
+++ b/drivers/mfd/pensando-elbasr.c
@@ -0,0 +1,854 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * AMD Pensando Elba System Resource MFD Driver
+ *
+ * Userspace interface and reset driver support for SPI connected
+ * Pensando Elba System Resource Chip.
+ *
+ * Adapted from spidev.c
+ *
+ * Copyright (C) 2006 SWAPP
+ *	Andrea Paterniani <a.paterniani@swapp-eng.it>
+ * Copyright (C) 2007 David Brownell (simplification, cleanup)
+ * Copyright 2022 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/compat.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/ioctl.h>
+#include <linux/list.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/pensando-elbasr.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spidev.h>
+#include <linux/types.h>
+
+#define ELBASR_SPI_CMD_REGRD	0x0b
+#define ELBASR_SPI_CMD_REGWR	0x02
+#define ELBASR_MAX_DEVS		4
+
+/*
+ * The main reason to have this class is to make mdev/udev create the
+ * /dev/pensrB.C character device nodes exposing our userspace API.
+ * It also simplifies memory management.  The device nodes
+ * /dev/pensrB.C are used for backward compatibility.
+ */
+static struct class *elbasr_class;
+
+static dev_t elbasr_devt;
+static DECLARE_BITMAP(minors, ELBASR_MAX_DEVS);
+static unsigned int bufsiz = 4096;
+
+static LIST_HEAD(device_list);
+static DEFINE_MUTEX(device_list_lock);
+
+static const struct mfd_cell pensando_elbasr_subdev_info[] = {
+	{
+		.name = "pensando_elbasr_reset",
+		.of_compatible = "amd,pensando-elbasr-reset",
+	},
+};
+
+/*
+ * Bit masks for spi_device.mode management.  Note that incorrect
+ * settings for some settings can cause *lots* of trouble for other
+ * devices on a shared bus:
+ *
+ *  - CS_HIGH ... this device will be active when it shouldn't be
+ *  - 3WIRE ... when active, it won't behave as it should
+ *  - NO_CS ... there will be no explicit message boundaries; this
+ *	is completely incompatible with the shared bus model
+ *  - READY ... transfers may proceed when they shouldn't.
+ */
+#define SPI_MODE_MASK		(SPI_CPHA | SPI_CPOL | SPI_CS_HIGH \
+				| SPI_LSB_FIRST | SPI_3WIRE | SPI_LOOP \
+				| SPI_NO_CS | SPI_READY | SPI_TX_DUAL \
+				| SPI_TX_QUAD | SPI_TX_OCTAL | SPI_RX_DUAL \
+				| SPI_RX_QUAD | SPI_RX_OCTAL)
+
+static ssize_t
+elbasr_spi_sync(struct elbasr_data *elbasr_spi, struct spi_message *message)
+{
+	int status;
+	struct spi_device *spi;
+
+	spin_lock_irq(&elbasr_spi->spi_lock);
+	spi = elbasr_spi->spi;
+	spin_unlock_irq(&elbasr_spi->spi_lock);
+	if (!spi)
+		return -ESHUTDOWN;
+
+	status = spi_sync(spi, message);
+	if (status)
+		return status;
+
+	return message->actual_length;
+}
+
+static inline ssize_t elbasr_spi_sync_write(struct elbasr_data *elbasr, size_t len)
+{
+	struct spi_transfer t[] = {
+		{
+			.tx_buf	= elbasr->tx_buffer,
+			.len = len,
+			.speed_hz = elbasr->speed_hz,
+		},
+	};
+	struct spi_message m;
+
+	spi_message_init_with_transfers(&m, t, ARRAY_SIZE(t));
+	return elbasr_spi_sync(elbasr, &m);
+}
+
+static inline ssize_t elbasr_spi_sync_read(struct elbasr_data *elbasr, size_t len)
+{
+	struct spi_transfer t[] = {
+		{
+			.rx_buf	= elbasr->rx_buffer,
+			.len = len,
+			.speed_hz = elbasr->speed_hz,
+		},
+	};
+	struct spi_message m;
+
+	spi_message_init_with_transfers(&m, t, ARRAY_SIZE(t));
+	return elbasr_spi_sync(elbasr, &m);
+}
+
+/* Read-only message with current device setup */
+static ssize_t
+elbasr_spi_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos)
+{
+	struct elbasr_data *elbasr;
+	ssize_t status;
+
+	/* chipselect only toggles at start or end of operation */
+	if (count > bufsiz)
+		return -EMSGSIZE;
+
+	elbasr = filp->private_data;
+
+	mutex_lock(&elbasr->buf_lock);
+	status = elbasr_spi_sync_read(elbasr, count);
+	if (status > 0) {
+		unsigned long missing;
+
+		missing = copy_to_user(buf, elbasr->rx_buffer, status);
+		if (missing == status)
+			status = -EFAULT;
+		else
+			status = status - missing;
+	}
+	mutex_unlock(&elbasr->buf_lock);
+
+	return status;
+}
+
+/* Write-only message with current device setup */
+static ssize_t elbasr_spi_write(struct file *filp, const char __user *buf,
+				size_t count, loff_t *f_pos)
+{
+	struct elbasr_data *elbasr;
+	ssize_t status;
+	unsigned long missing;
+
+	/* chipselect only toggles at start or end of operation */
+	if (count > bufsiz)
+		return -EMSGSIZE;
+
+	elbasr = filp->private_data;
+
+	mutex_lock(&elbasr->buf_lock);
+	missing = copy_from_user(elbasr->tx_buffer, buf, count);
+	if (missing == 0)
+		status = elbasr_spi_sync_write(elbasr, count);
+	else
+		status = -EFAULT;
+	mutex_unlock(&elbasr->buf_lock);
+
+	return status;
+}
+
+static int elbasr_spi_message(struct elbasr_data *elbasr,
+			      struct spi_ioc_transfer *u_xfers,
+			      unsigned int n_xfers)
+{
+	struct spi_message msg;
+	struct spi_transfer *k_xfers;
+	struct spi_transfer *k_tmp;
+	struct spi_ioc_transfer *u_tmp;
+	unsigned int n, total, tx_total, rx_total;
+	u8 *tx_buf, *rx_buf;
+	int status = -EFAULT;
+
+	spi_message_init(&msg);
+	k_xfers = kcalloc(n_xfers, sizeof(*k_tmp), GFP_KERNEL);
+	if (k_xfers == NULL)
+		return -ENOMEM;
+
+	/*
+	 * Construct spi_message, copying any tx data to bounce buffer.
+	 * We walk the array of user-provided transfers, using each one
+	 * to initialize a kernel version of the same transfer.
+	 */
+	tx_buf = elbasr->tx_buffer;
+	rx_buf = elbasr->rx_buffer;
+	total = 0;
+	tx_total = 0;
+	rx_total = 0;
+	for (n = n_xfers, k_tmp = k_xfers, u_tmp = u_xfers;
+			n;
+			n--, k_tmp++, u_tmp++) {
+		/*
+		 * Ensure that also following allocations from rx_buf/tx_buf will meet
+		 * DMA alignment requirements.
+		 */
+		unsigned int len_aligned = ALIGN(u_tmp->len,
+						 ARCH_KMALLOC_MINALIGN);
+
+		k_tmp->len = u_tmp->len;
+
+		total += k_tmp->len;
+		/*
+		 * Since the function returns the total length of transfers
+		 * on success, restrict the total to positive int values to
+		 * avoid the return value looking like an error.  Also check
+		 * each transfer length to avoid arithmetic overflow.
+		 */
+		if (total > INT_MAX || k_tmp->len > INT_MAX) {
+			status = -EMSGSIZE;
+			goto done;
+		}
+
+		if (u_tmp->rx_buf) {
+			/* this transfer needs space in RX bounce buffer */
+			rx_total += len_aligned;
+			if (rx_total > bufsiz) {
+				status = -EMSGSIZE;
+				goto done;
+			}
+			k_tmp->rx_buf = rx_buf;
+			rx_buf += len_aligned;
+		}
+		if (u_tmp->tx_buf) {
+			/* this transfer needs space in TX bounce buffer */
+			tx_total += len_aligned;
+			if (tx_total > bufsiz) {
+				status = -EMSGSIZE;
+				goto done;
+			}
+			k_tmp->tx_buf = tx_buf;
+			if (copy_from_user(tx_buf, (const u8 __user *)
+						(uintptr_t) u_tmp->tx_buf,
+					u_tmp->len))
+				goto done;
+			tx_buf += len_aligned;
+		}
+
+		k_tmp->cs_change = !!u_tmp->cs_change;
+		k_tmp->tx_nbits = u_tmp->tx_nbits;
+		k_tmp->rx_nbits = u_tmp->rx_nbits;
+		k_tmp->bits_per_word = u_tmp->bits_per_word;
+		k_tmp->delay.value = u_tmp->delay_usecs;
+		k_tmp->delay.unit = SPI_DELAY_UNIT_USECS;
+		k_tmp->speed_hz = u_tmp->speed_hz;
+		k_tmp->word_delay.value = u_tmp->word_delay_usecs;
+		k_tmp->word_delay.unit = SPI_DELAY_UNIT_USECS;
+		if (!k_tmp->speed_hz)
+			k_tmp->speed_hz = elbasr->speed_hz;
+#ifdef VERBOSE
+		dev_dbg(&elbasr->spi->dev,
+			" xfer len %u %s%s%s%dbits %u usec %u usec %uHz (%u)\n",
+			k_tmp->len,
+			k_tmp->rx_buf ? "rx " : "",
+			k_tmp->tx_buf ? "tx " : "",
+			k_tmp->cs_change ? "cs " : "",
+			k_tmp->bits_per_word ? : elbasr->spi->bits_per_word,
+			k_tmp->delay.value,
+			k_tmp->word_delay.value,
+			k_tmp->speed_hz ? : elbasr->spi->max_speed_hz);
+#endif
+		spi_message_add_tail(k_tmp, &msg);
+	}
+
+	status = elbasr_spi_sync(elbasr, &msg);
+	if (status < 0)
+		goto done;
+
+	/* copy any rx data out of bounce buffer */
+	for (n = n_xfers, k_tmp = k_xfers, u_tmp = u_xfers;
+			n;
+			n--, k_tmp++, u_tmp++) {
+		if (u_tmp->rx_buf) {
+			if (copy_to_user((u8 __user *)
+					(uintptr_t) u_tmp->rx_buf, k_tmp->rx_buf,
+					u_tmp->len)) {
+				status = -EFAULT;
+				goto done;
+			}
+		}
+	}
+	status = total;
+
+done:
+	kfree(k_xfers);
+	return status;
+}
+
+static struct spi_ioc_transfer *
+elbasr_spi_get_ioc_message(unsigned int cmd,
+			   struct spi_ioc_transfer __user *u_ioc,
+			   unsigned int *n_ioc)
+{
+	u32 tmp;
+
+	/* Check type, command number and direction */
+	if (_IOC_TYPE(cmd) != SPI_IOC_MAGIC
+			|| _IOC_NR(cmd) != _IOC_NR(SPI_IOC_MESSAGE(0))
+			|| _IOC_DIR(cmd) != _IOC_WRITE)
+		return ERR_PTR(-ENOTTY);
+
+	tmp = _IOC_SIZE(cmd);
+	if ((tmp % sizeof(struct spi_ioc_transfer)) != 0)
+		return ERR_PTR(-EINVAL);
+	*n_ioc = tmp / sizeof(struct spi_ioc_transfer);
+	if (*n_ioc == 0)
+		return NULL;
+
+	/* copy into scratch area */
+	return memdup_user(u_ioc, tmp);
+}
+
+static long
+elbasr_spi_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+	int retval = 0;
+	struct elbasr_data *elbasr;
+	struct spi_device *spi;
+	u32 tmp;
+	unsigned int n_ioc;
+	struct spi_ioc_transfer	*ioc;
+
+	/* Check type and command number */
+	if (_IOC_TYPE(cmd) != SPI_IOC_MAGIC)
+		return -ENOTTY;
+
+	/*
+	 * guard against device removal before, or while,
+	 * we issue this ioctl.
+	 */
+	elbasr = filp->private_data;
+	spin_lock_irq(&elbasr->spi_lock);
+	spi = spi_dev_get(elbasr->spi);
+	spin_unlock_irq(&elbasr->spi_lock);
+
+	if (spi == NULL)
+		return -ESHUTDOWN;
+
+	/*
+	 * use the buffer lock here for triple duty:
+	 *  - prevent I/O (from us) so calling spi_setup() is safe;
+	 *  - prevent concurrent SPI_IOC_WR_* from morphing
+	 *    data fields while SPI_IOC_RD_* reads them;
+	 *  - SPI_IOC_MESSAGE needs the buffer locked "normally".
+	 */
+	mutex_lock(&elbasr->buf_lock);
+
+	switch (cmd) {
+	/* read requests */
+	case SPI_IOC_RD_MODE:
+		retval = put_user(spi->mode & SPI_MODE_MASK,
+					(__u8 __user *)arg);
+		break;
+	case SPI_IOC_RD_MODE32:
+		retval = put_user(spi->mode & SPI_MODE_MASK,
+					(__u32 __user *)arg);
+		break;
+	case SPI_IOC_RD_LSB_FIRST:
+		retval = put_user((spi->mode & SPI_LSB_FIRST) ?  1 : 0,
+					(__u8 __user *)arg);
+		break;
+	case SPI_IOC_RD_BITS_PER_WORD:
+		retval = put_user(spi->bits_per_word, (__u8 __user *)arg);
+		break;
+	case SPI_IOC_RD_MAX_SPEED_HZ:
+		retval = put_user(elbasr->speed_hz, (__u32 __user *)arg);
+		break;
+
+	/* write requests */
+	case SPI_IOC_WR_MODE:
+	case SPI_IOC_WR_MODE32:
+		if (cmd == SPI_IOC_WR_MODE)
+			retval = get_user(tmp, (u8 __user *)arg);
+		else
+			retval = get_user(tmp, (u32 __user *)arg);
+		if (retval == 0) {
+			struct spi_controller *ctlr = spi->controller;
+			u32	save = spi->mode;
+
+			if (tmp & ~SPI_MODE_MASK) {
+				retval = -EINVAL;
+				break;
+			}
+
+			if (ctlr->use_gpio_descriptors && ctlr->cs_gpiods &&
+			    ctlr->cs_gpiods[spi->chip_select])
+				tmp |= SPI_CS_HIGH;
+
+			tmp |= spi->mode & ~SPI_MODE_MASK;
+			spi->mode = (u16)tmp;
+			retval = spi_setup(spi);
+			if (retval < 0)
+				spi->mode = save;
+			else
+				dev_dbg(&spi->dev, "spi mode %x\n", tmp);
+		}
+		break;
+	case SPI_IOC_WR_LSB_FIRST:
+		retval = get_user(tmp, (__u8 __user *)arg);
+		if (retval == 0) {
+			u32	save = spi->mode;
+
+			if (tmp)
+				spi->mode |= SPI_LSB_FIRST;
+			else
+				spi->mode &= ~SPI_LSB_FIRST;
+			retval = spi_setup(spi);
+			if (retval < 0)
+				spi->mode = save;
+			else
+				dev_dbg(&spi->dev, "%csb first\n",
+						tmp ? 'l' : 'm');
+		}
+		break;
+	case SPI_IOC_WR_BITS_PER_WORD:
+		retval = get_user(tmp, (__u8 __user *)arg);
+		if (retval == 0) {
+			u8	save = spi->bits_per_word;
+
+			spi->bits_per_word = tmp;
+			retval = spi_setup(spi);
+			if (retval < 0)
+				spi->bits_per_word = save;
+			else
+				dev_dbg(&spi->dev, "%d bits per word\n", tmp);
+		}
+		break;
+	case SPI_IOC_WR_MAX_SPEED_HZ:
+		retval = get_user(tmp, (__u32 __user *)arg);
+		if (retval == 0) {
+			u32	save = spi->max_speed_hz;
+
+			spi->max_speed_hz = tmp;
+			retval = spi_setup(spi);
+			if (retval == 0) {
+				elbasr->speed_hz = tmp;
+				dev_dbg(&spi->dev, "%d Hz (max)\n",
+					elbasr->speed_hz);
+			}
+			spi->max_speed_hz = save;
+		}
+		break;
+
+	default:
+		/*
+		 * Segmented and/or full-duplex I/O request.
+		 * Check message and copy into scratch area.
+		 */
+		ioc = elbasr_spi_get_ioc_message(cmd,
+				(struct spi_ioc_transfer __user *)arg, &n_ioc);
+		if (IS_ERR(ioc)) {
+			retval = PTR_ERR(ioc);
+			break;
+		}
+		if (!ioc)
+			break;	/* n_ioc is also 0 */
+
+		/* translate to spi_message, execute */
+		retval = elbasr_spi_message(elbasr, ioc, n_ioc);
+		kfree(ioc);
+		break;
+	}
+
+	mutex_unlock(&elbasr->buf_lock);
+	spi_dev_put(spi);
+	return retval;
+}
+
+static long
+elbasr_spi_compat_ioc_message(struct file *filp, unsigned int cmd,
+			      unsigned long arg)
+{
+	struct spi_ioc_transfer __user *u_ioc;
+	int retval = 0;
+	struct elbasr_data *elbasr;
+	struct spi_device *spi;
+	unsigned int n_ioc, n;
+	struct spi_ioc_transfer *ioc;
+
+	u_ioc = (struct spi_ioc_transfer __user *) compat_ptr(arg);
+
+	/*
+	 * Guard against device removal before, or while,
+	 * we issue this ioctl.
+	 */
+	elbasr = filp->private_data;
+	spin_lock_irq(&elbasr->spi_lock);
+	spi = spi_dev_get(elbasr->spi);
+	spin_unlock_irq(&elbasr->spi_lock);
+
+	if (spi == NULL)
+		return -ESHUTDOWN;
+
+	/* SPI_IOC_MESSAGE needs the buffer locked "normally" */
+	mutex_lock(&elbasr->buf_lock);
+
+	/* Check message and copy into scratch area */
+	ioc = elbasr_spi_get_ioc_message(cmd, u_ioc, &n_ioc);
+	if (IS_ERR(ioc)) {
+		retval = PTR_ERR(ioc);
+		goto done;
+	}
+	if (!ioc)
+		goto done;	/* n_ioc is also 0 */
+
+	/* Convert buffer pointers */
+	for (n = 0; n < n_ioc; n++) {
+		ioc[n].rx_buf = (uintptr_t) compat_ptr(ioc[n].rx_buf);
+		ioc[n].tx_buf = (uintptr_t) compat_ptr(ioc[n].tx_buf);
+	}
+
+	/* translate to spi_message, execute */
+	retval = elbasr_spi_message(elbasr, ioc, n_ioc);
+	kfree(ioc);
+
+done:
+	mutex_unlock(&elbasr->buf_lock);
+	spi_dev_put(spi);
+	return retval;
+}
+
+static long
+elbasr_spi_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+	if (_IOC_TYPE(cmd) == SPI_IOC_MAGIC
+			&& _IOC_NR(cmd) == _IOC_NR(SPI_IOC_MESSAGE(0))
+			&& _IOC_DIR(cmd) == _IOC_WRITE)
+		return elbasr_spi_compat_ioc_message(filp, cmd, arg);
+
+	return elbasr_spi_ioctl(filp, cmd, (unsigned long)compat_ptr(arg));
+}
+
+static int elbasr_spi_open(struct inode *inode, struct file *filp)
+{
+	struct elbasr_data *elbasr;
+	int status = -ENXIO;
+
+	mutex_lock(&device_list_lock);
+
+	list_for_each_entry(elbasr, &device_list, device_entry) {
+		if (elbasr->devt == inode->i_rdev) {
+			status = 0;
+			break;
+		}
+	}
+
+	if (status)
+		goto err_find_dev;
+
+	if (!elbasr->tx_buffer) {
+		elbasr->tx_buffer = kmalloc(bufsiz, GFP_KERNEL);
+		if (!elbasr->tx_buffer) {
+			status = -ENOMEM;
+			goto err_find_dev;
+		}
+	}
+
+	if (!elbasr->rx_buffer) {
+		elbasr->rx_buffer = kmalloc(bufsiz, GFP_KERNEL);
+		if (!elbasr->rx_buffer) {
+			status = -ENOMEM;
+			goto err_alloc_rx_buf;
+		}
+	}
+
+	elbasr->users++;
+	filp->private_data = elbasr;
+	stream_open(inode, filp);
+
+	mutex_unlock(&device_list_lock);
+	return 0;
+
+err_alloc_rx_buf:
+	kfree(elbasr->tx_buffer);
+	elbasr->tx_buffer = NULL;
+err_find_dev:
+	mutex_unlock(&device_list_lock);
+	return status;
+}
+
+static int elbasr_spi_release(struct inode *inode, struct file *filp)
+{
+	struct elbasr_data *elbasr;
+	int dofree;
+
+	mutex_lock(&device_list_lock);
+	elbasr = filp->private_data;
+	filp->private_data = NULL;
+
+	spin_lock_irq(&elbasr->spi_lock);
+	/* ... after we unbound from the underlying device? */
+	dofree = (elbasr->spi == NULL);
+	spin_unlock_irq(&elbasr->spi_lock);
+
+	/* last close? */
+	elbasr->users--;
+	if (!elbasr->users) {
+
+		kfree(elbasr->tx_buffer);
+		elbasr->tx_buffer = NULL;
+
+		kfree(elbasr->rx_buffer);
+		elbasr->rx_buffer = NULL;
+
+		if (dofree)
+			kfree(elbasr);
+		else
+			elbasr->speed_hz = elbasr->spi->max_speed_hz;
+	}
+#ifdef CONFIG_SPI_SLAVE
+	if (!dofree)
+		spi_slave_abort(elbasr->spi);
+#endif
+	mutex_unlock(&device_list_lock);
+
+	return 0;
+}
+
+static const struct file_operations elbasr_spi_fops = {
+	.owner =	THIS_MODULE,
+	.write =	elbasr_spi_write,
+	.read =		elbasr_spi_read,
+	.unlocked_ioctl = elbasr_spi_ioctl,
+	.compat_ioctl = elbasr_spi_compat_ioctl,
+	.open =		elbasr_spi_open,
+	.release =	elbasr_spi_release,
+	.llseek =	no_llseek,
+};
+
+static bool elbasr_reg_readable(struct device *dev, unsigned int reg)
+{
+	return reg <= ELBASR_MAX_REG;
+}
+
+static bool elbasr_reg_writeable(struct device *dev, unsigned int reg)
+{
+	return reg <= ELBASR_MAX_REG;
+}
+
+static int elbasr_regs_read(void *ctx, u32 reg, u32 *val)
+{
+	struct elbasr_data *elbasr = dev_get_drvdata(ctx);
+	struct spi_message m;
+	struct spi_transfer t[2] = { 0 };
+	int ret;
+	u8 txbuf[3];
+	u8 rxbuf[1];
+
+	txbuf[0] = ELBASR_SPI_CMD_REGRD;
+	txbuf[1] = reg;
+	txbuf[2] = 0x0;
+	t[0].tx_buf = (u8 *)txbuf;
+	t[0].len = 3;
+
+	rxbuf[0] = 0x0;
+	t[1].rx_buf = rxbuf;
+	t[1].len = 1;
+
+	spi_message_init_with_transfers(&m, t, ARRAY_SIZE(t));
+	ret = elbasr_spi_sync(elbasr, &m);
+	if (ret == 4) {
+		/* 3 Tx + 1 Rx = 4 */
+		*val = rxbuf[0];
+		return 0;
+	}
+	return -EIO;
+}
+
+static int elbasr_regs_write(void *ctx, u32 reg, u32 val)
+{
+	struct elbasr_data *elbasr = dev_get_drvdata(ctx);
+	struct spi_message m;
+	struct spi_transfer t[1] = { 0 };
+	u8 txbuf[4];
+
+	txbuf[0] = ELBASR_SPI_CMD_REGWR;
+	txbuf[1] = reg;
+	txbuf[2] = val;
+	txbuf[3] = 0;
+
+	t[0].tx_buf = txbuf;
+	t[0].len = 4;
+	spi_message_init_with_transfers(&m, t, ARRAY_SIZE(t));
+	return elbasr_spi_sync(elbasr, &m);
+}
+
+static const struct regmap_config pensando_elbasr_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_NONE,
+	.readable_reg = elbasr_reg_readable,
+	.writeable_reg = elbasr_reg_writeable,
+	.reg_read = elbasr_regs_read,
+	.reg_write = elbasr_regs_write,
+	.max_register = ELBASR_MAX_REG,
+};
+
+/*
+ * Setup Elba SPI access to System Resource Chip registers on CS0
+ */
+static int elbasr_regs_setup(struct spi_device *spi, struct elbasr_data *elbasr)
+{
+	int ret;
+
+	spi->bits_per_word = 8;
+	spi_setup(spi);
+	if (!spi->dev.dma_mask)
+		spi->dev.dma_mask = &spi->dev.coherent_dma_mask;
+
+	elbasr->elbasr_regs = regmap_init(&spi->dev, NULL, spi,
+					  &pensando_elbasr_regmap_config);
+	if (IS_ERR(elbasr->elbasr_regs))
+		return dev_err_probe(&spi->dev, PTR_ERR(elbasr->elbasr_regs),
+				     "Failed to allocate register map");
+
+	ret = mfd_add_devices(&spi->dev, PLATFORM_DEVID_NONE,
+			      pensando_elbasr_subdev_info,
+			      ARRAY_SIZE(pensando_elbasr_subdev_info),
+			      NULL, 0, NULL);
+	if (ret)
+		return dev_err_probe(&spi->dev, ret,
+				     "Failed to register sub-devices\n");
+	return 0;
+}
+
+static int elbasr_spi_probe(struct spi_device *spi)
+{
+	struct elbasr_data *elbasr;
+	unsigned long minor;
+	int status;
+
+	if (spi->chip_select == 0) {
+		status = alloc_chrdev_region(&elbasr_devt, 0, ELBASR_MAX_DEVS,
+					     "elbasr");
+		if (status < 0)
+			return status;
+
+		elbasr_class = class_create(THIS_MODULE, "elbasr");
+		if (IS_ERR(elbasr_class)) {
+			unregister_chrdev(MAJOR(elbasr_devt), "elbasr");
+			return PTR_ERR(elbasr_class);
+		}
+	}
+
+	/* Allocate driver data */
+	elbasr = kzalloc(sizeof(*elbasr), GFP_KERNEL);
+	if (!elbasr)
+		return -ENOMEM;
+
+	/* Initialize the driver data */
+	elbasr->spi = spi;
+	elbasr->speed_hz = spi->max_speed_hz;
+	spin_lock_init(&elbasr->spi_lock);
+	mutex_init(&elbasr->buf_lock);
+
+	INIT_LIST_HEAD(&elbasr->device_entry);
+
+	mutex_lock(&device_list_lock);
+	minor = find_first_zero_bit(minors, ELBASR_MAX_DEVS);
+	if (minor < ELBASR_MAX_DEVS) {
+		struct device *dev;
+
+		elbasr->devt = MKDEV(MAJOR(elbasr_devt), minor);
+		dev = device_create(elbasr_class,
+				    &spi->dev,
+				    elbasr->devt,
+				    elbasr,
+				    "pensr%d.%d",
+				    spi->master->bus_num,
+				    spi->chip_select);
+
+		status = PTR_ERR_OR_ZERO(dev);
+	} else {
+		dev_dbg(&spi->dev, "no minor number available\n");
+		status = -ENODEV;
+		goto minor_failed;
+	}
+
+	set_bit(minor, minors);
+	list_add(&elbasr->device_entry, &device_list);
+	dev_dbg(&spi->dev,
+		"created device for major %d, minor %lu\n",
+		MAJOR(elbasr_devt), minor);
+	mutex_unlock(&device_list_lock);
+
+	/* Create cdev */
+	elbasr->cdev = cdev_alloc();
+	if (!elbasr->cdev) {
+		dev_err(elbasr->dev, "allocation of cdev failed");
+		status = -ENOMEM;
+		goto cdev_failed;
+	}
+	elbasr->cdev->owner = THIS_MODULE;
+	cdev_init(elbasr->cdev, &elbasr_spi_fops);
+
+	status = cdev_add(elbasr->cdev, elbasr->devt, 1);
+	if (status) {
+		dev_err(elbasr->dev, "register of cdev failed");
+		goto cdev_delete;
+	}
+	spi_set_drvdata(spi, elbasr);
+
+	/* Add Elba reset driver sub-device */
+	if (spi->chip_select == 0) {
+		status = elbasr_regs_setup(spi, elbasr);
+		if (status)
+			dev_err(elbasr->dev, "sub-device setup failed");
+	}
+	return 0;
+
+cdev_delete:
+	if (spi->chip_select == 0)
+		cdev_del(elbasr->cdev);
+cdev_failed:
+	if (spi->chip_select == 0)
+		device_destroy(elbasr_class, elbasr->devt);
+minor_failed:
+	kfree(elbasr);
+
+	return status;
+}
+
+static const struct of_device_id elbasr_dt_match[] = {
+	{ .compatible = "amd,pensando-elbasr" },
+	{ /* sentinel */ }
+};
+
+static struct spi_driver elbasr_spi_driver = {
+	.probe = elbasr_spi_probe,
+	.driver = {
+		.name = "pensando-elbasr",
+		.of_match_table = elbasr_dt_match,
+	},
+};
+builtin_driver(elbasr_spi_driver, spi_register_driver)
diff --git a/include/linux/mfd/pensando-elbasr.h b/include/linux/mfd/pensando-elbasr.h
new file mode 100644
index 000000000000..32969397a72d
--- /dev/null
+++ b/include/linux/mfd/pensando-elbasr.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright 2022 Advanced Micro Devices, Inc.
+ *
+ * Declarations for AMD Pensando Elba System Resource Chip
+ */
+
+#ifndef __MFD_AMD_PENSANDO_ELBA_H
+#define __MFD_AMD_PENSANDO_ELBA_H
+
+#include <linux/cdev.h>
+#include <linux/regmap.h>
+
+#define ELBASR_REVISION_REG			0x00
+#define ELBASR_CTRL_REG				0x01
+#define ELBASR_QSFP_CTRL_REG			0x02
+#define ELBASR_INTERRUPT_ENABLE_REG		0x03
+#define ELBASR_INTERRUPT_STATUS_REG		0x04
+#define ELBASR_QSFP_LED_REG			0x05
+#define ELBASR_QSFP_LED_FREQUENCY_REG		0x0F
+#define ELBASR_CTRL0_REG			0x10
+#define ELBASR_CTRL1_REG			0x11
+#define ELBASR_CTRL2_REG			0x12
+#define ELBASR_SYSTEM_LED_REG			0x15
+#define ELBASR_CORE_TEMP_REG			0x16
+#define ELBASR_HBM_TEMP_REG			0x17
+#define ELBASR_BOARD_TEMP_REG			0x18
+#define ELBASR_QSFP_PORT1_TEMP_REG		0x19
+#define ELBASR_QSFP_PORT2_TEMP_REG		0x1a
+#define ELBASR_HBM_WARNING_TEMP_REG		0x1b
+#define ELBASR_HBM_CRITICAL_TEMP_REG		0x1c
+#define ELBASR_HBM_FATAL_TEMP_REG		0x1d
+#define ELBASR_ROT_REG0_CNTL_REG		0x23
+#define ELBASR_PUF_ERROR_LIMITS_REG		0x29
+#define ELBASR_PUF_ERROR_COUNT_REG		0x2a
+#define ELBASR_QSFP_PORT1_ALARM_TEMP_REG	0x34
+#define ELBASR_QSFP_PORT1_WARNING_TEMP_REG	0x35
+#define ELBASR_QSFP_PORT2_ALARM_TEMP_REG	0x36
+#define ELBASR_QSFP_PORT2_WARNING_TEMP_REG	0x37
+#define ELBASR_SYSTEM_HEALTH0_REG		0x38
+#define ELBASR_SYSTEM_HEALTH1_REG		0x39
+#define ELBASR_MAJOR_FW_VER_REG			0x3a
+#define ELBASR_MINOR_FW_VER_REG			0x3b
+#define ELBASR_MAINTANENCE_FW_VER_REG		0x3c
+#define ELBASR_PIPELINE_FW_REG			0x3d
+#define ELBASR_QSFP_PRESENT_REG			0x40
+#define ELBASR_OCP_SLOTID_REG			0x42
+#define ELBASR_OCP_SC_DATA0_REG			0x43
+#define ELBASR_OCP_SC_DATA1_REG			0x44
+#define ELBASR_ID				0x80
+
+#define ELBASR_MAX_REG				0xff
+#define ELBASR_NR_RESETS			1
+
+/*
+ * Pensando Elba System Resource device private data structure
+ */
+struct elbasr_data {
+	dev_t devt;
+	int minor;
+	struct device *dev;
+	struct cdev *cdev;
+	struct spi_device *spi;
+	struct list_head device_entry;
+	spinlock_t spi_lock;
+
+	/* TX/RX buffers are NULL unless this device is open (users > 0) */
+	struct mutex buf_lock;
+	unsigned int users;
+	u8 *tx_buffer;
+	u8 *rx_buffer;
+	u32 speed_hz;
+
+	/* System Resource Chip CS0 register access */
+	struct regmap *elbasr_regs;
+};
+
+#endif /* __MFD_AMD_PENSANDO_ELBA_H */
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (13 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 14/17] mfd: pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-22  7:04   ` Philipp Zabel
  2022-08-20 19:57 ` [PATCH v6 16/17] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support Brad Larson
  2022-08-20 19:57 ` [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
  16 siblings, 1 reply; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

This patch adds the reset controller functionality for the
AMD Pensando Elba System Resource Chip.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/reset/Kconfig        |  9 +++++
 drivers/reset/Makefile       |  1 +
 drivers/reset/reset-elbasr.c | 77 ++++++++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+)
 create mode 100644 drivers/reset/reset-elbasr.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 806773e88832..04b700c90ce4 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -66,6 +66,15 @@ config RESET_BRCMSTB_RESCAL
 	  This enables the RESCAL reset controller for SATA, PCIe0, or PCIe1 on
 	  BCM7216.
 
+config RESET_ELBASR
+	tristate "Pensando Elba System Resource reset controller"
+	depends on MFD_PENSANDO_ELBASR || COMPILE_TEST
+	help
+	  This option enables support for the external reset functions
+	  on the Pensando Elba System Resource Chip.  Reset control
+	  of peripherals is accessed over SPI to the system resource
+	  chip device registers using CS0.
+
 config RESET_HSDK
 	bool "Synopsys HSDK Reset Driver"
 	depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index cd5cf8e7c6a7..9e6b095ee63a 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_BRCMSTB) += reset-brcmstb.o
 obj-$(CONFIG_RESET_BRCMSTB_RESCAL) += reset-brcmstb-rescal.o
+obj-$(CONFIG_RESET_ELBASR) += reset-elbasr.o
 obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
 obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
 obj-$(CONFIG_RESET_INTEL_GW) += reset-intel-gw.o
diff --git a/drivers/reset/reset-elbasr.c b/drivers/reset/reset-elbasr.c
new file mode 100644
index 000000000000..ab5d49f5e6a7
--- /dev/null
+++ b/drivers/reset/reset-elbasr.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2022 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/pensando-elbasr.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+struct elbasr_reset {
+	struct reset_controller_dev rcdev;
+	struct regmap *regmap;
+};
+
+static inline struct elbasr_reset *to_elbasr_rst(struct reset_controller_dev *rc)
+{
+	return container_of(rc, struct elbasr_reset, rcdev);
+}
+
+static int elbasr_reset_assert(struct reset_controller_dev *rcdev,
+			       unsigned long id)
+{
+	struct elbasr_reset *elbar = to_elbasr_rst(rcdev);
+
+	return regmap_update_bits(elbar->regmap, ELBASR_CTRL0_REG, BIT(6), BIT(6));
+}
+
+static int elbasr_reset_deassert(struct reset_controller_dev *rcdev,
+				 unsigned long id)
+{
+	struct elbasr_reset *elbar = to_elbasr_rst(rcdev);
+
+	return regmap_update_bits(elbar->regmap, ELBASR_CTRL0_REG, BIT(6), 0);
+}
+
+static const struct reset_control_ops elbasr_reset_ops = {
+	.assert	= elbasr_reset_assert,
+	.deassert = elbasr_reset_deassert,
+};
+
+static int elbasr_reset_probe(struct platform_device *pdev)
+{
+	struct elbasr_data *elbasr = dev_get_drvdata(pdev->dev.parent);
+	struct elbasr_reset *elbar;
+
+	elbar = devm_kzalloc(&pdev->dev, sizeof(struct elbasr_reset),
+			     GFP_KERNEL);
+	if (!elbar)
+		return -ENOMEM;
+
+	elbar->rcdev.owner = THIS_MODULE;
+	elbar->rcdev.nr_resets = ELBASR_NR_RESETS;
+	elbar->rcdev.ops = &elbasr_reset_ops;
+	elbar->rcdev.of_node = pdev->dev.of_node;
+	elbar->regmap = elbasr->elbasr_regs;
+
+	platform_set_drvdata(pdev, elbar);
+
+	return devm_reset_controller_register(&pdev->dev, &elbar->rcdev);
+}
+
+static const struct of_device_id elba_reset_dt_match[] = {
+	{ .compatible = "amd,pensando-elbasr-reset", },
+	{ /* sentinel */ }
+};
+
+static struct platform_driver elbasr_reset_driver = {
+	.probe	= elbasr_reset_probe,
+	.driver = {
+		.name = "pensando_elbasr_reset",
+		.of_match_table	= elba_reset_dt_match,
+	},
+};
+builtin_platform_driver(elbasr_reset_driver);
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 16/17] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (14 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-20 19:57 ` [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
  16 siblings, 0 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add support for AMD Pensando Elba SoC which explicitly
controls byte-lane enables on writes.

Select MMC_SDHCI_IO_ACCESSORS for MMC_SDHCI_CADENCE which
allows Elba SoC sdhci_elba_ops to overwrite the SDHCI
IO memory accessors.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/mmc/host/Kconfig         |   1 +
 drivers/mmc/host/sdhci-cadence.c | 132 ++++++++++++++++++++++++++++---
 2 files changed, 123 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 10c563999d3d..9af316d5bca4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -244,6 +244,7 @@ config MMC_SDHCI_CADENCE
 	tristate "SDHCI support for the Cadence SD/SDIO/eMMC controller"
 	depends on MMC_SDHCI_PLTFM
 	depends on OF
+	select MMC_SDHCI_IO_ACCESSORS
 	help
 	  This selects the Cadence SD/SDIO/eMMC driver.
 
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 708d4297f241..c662c63d49fa 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -66,6 +66,8 @@ struct sdhci_cdns_phy_param {
 
 struct sdhci_cdns_priv {
 	void __iomem *hrs_addr;
+	void __iomem *ctl_addr;	/* write control */
+	spinlock_t wrlock;	/* write lock */
 	bool enhanced_strobe;
 	void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
 	unsigned int nr_phy_params;
@@ -77,6 +79,11 @@ struct sdhci_cdns_phy_cfg {
 	u8 addr;
 };
 
+struct sdhci_cdns_drv_data {
+	int (*init)(struct platform_device *pdev);
+	const struct sdhci_pltfm_data pltfm_data;
+};
+
 static const struct sdhci_cdns_phy_cfg sdhci_cdns_phy_cfgs[] = {
 	{ "cdns,phy-input-delay-sd-highspeed", SDHCI_CDNS_PHY_DLY_SD_HS, },
 	{ "cdns,phy-input-delay-legacy", SDHCI_CDNS_PHY_DLY_SD_DEFAULT, },
@@ -316,6 +323,92 @@ static void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host,
 		sdhci_set_uhs_signaling(host, timing);
 }
 
+/* Elba control register bits [6:3] are byte-lane enables */
+#define ELBA_BYTE_ENABLE_MASK(x)	((x) << 3)
+
+/*
+ * The Pensando Elba SoC explicitly controls byte-lane enabling on writes
+ * which includes writes to the HRS registers.
+ */
+static void elba_priv_writel(struct sdhci_cdns_priv *priv, u32 val,
+			     void __iomem *reg)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&priv->wrlock, flags);
+	writel(ELBA_BYTE_ENABLE_MASK(0xf), priv->ctl_addr);
+	writel(val, reg);
+	spin_unlock_irqrestore(&priv->wrlock, flags);
+}
+
+static void elba_write_l(struct sdhci_host *host, u32 val, int reg)
+{
+	elba_priv_writel(sdhci_cdns_priv(host), val, host->ioaddr + reg);
+}
+
+static void elba_write_w(struct sdhci_host *host, u16 val, int reg)
+{
+	struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+	u32 byte_enables;
+	unsigned long flags;
+
+	byte_enables = GENMASK(1, 0) << (reg & 0x3);
+	spin_lock_irqsave(&priv->wrlock, flags);
+	writel(ELBA_BYTE_ENABLE_MASK(byte_enables), priv->ctl_addr);
+	writew(val, host->ioaddr + reg);
+	spin_unlock_irqrestore(&priv->wrlock, flags);
+}
+
+static void elba_write_b(struct sdhci_host *host, u8 val, int reg)
+{
+	struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+	u32 byte_enables;
+	unsigned long flags;
+
+	byte_enables = BIT(0) << (reg & 0x3);
+	spin_lock_irqsave(&priv->wrlock, flags);
+	writel(ELBA_BYTE_ENABLE_MASK(byte_enables), priv->ctl_addr);
+	writeb(val, host->ioaddr + reg);
+	spin_unlock_irqrestore(&priv->wrlock, flags);
+}
+
+static const struct sdhci_ops sdhci_elba_ops = {
+	.write_l = elba_write_l,
+	.write_w = elba_write_w,
+	.write_b = elba_write_b,
+	.set_clock = sdhci_set_clock,
+	.get_timeout_clock = sdhci_cdns_get_timeout_clock,
+	.set_bus_width = sdhci_set_bus_width,
+	.reset = sdhci_reset,
+	.set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
+};
+
+static int elba_drv_init(struct platform_device *pdev)
+{
+	struct sdhci_host *host = platform_get_drvdata(pdev);
+	struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+	struct resource *iomem;
+	void __iomem *ioaddr;
+
+	host->mmc->caps |= (MMC_CAP_1_8V_DDR | MMC_CAP_8_BIT_DATA);
+
+	iomem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!iomem)
+		return -ENOMEM;
+
+	/* Byte-lane control register */
+	ioaddr = devm_platform_ioremap_resource(pdev, 1);
+	if (IS_ERR(ioaddr))
+		return PTR_ERR(ioaddr);
+
+	priv->ctl_addr = ioaddr;
+	priv->priv_writel = elba_priv_writel;
+	spin_lock_init(&priv->wrlock);
+	writel(ELBA_BYTE_ENABLE_MASK(0xf), priv->ctl_addr);
+
+	return 0;
+}
+
 static const struct sdhci_ops sdhci_cdns_ops = {
 	.set_clock = sdhci_set_clock,
 	.get_timeout_clock = sdhci_cdns_get_timeout_clock,
@@ -325,13 +418,24 @@ static const struct sdhci_ops sdhci_cdns_ops = {
 	.set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
 };
 
-static const struct sdhci_pltfm_data sdhci_cdns_uniphier_pltfm_data = {
-	.ops = &sdhci_cdns_ops,
-	.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+static const struct sdhci_cdns_drv_data sdhci_cdns_uniphier_drv_data = {
+	.pltfm_data = {
+		.ops = &sdhci_cdns_ops,
+		.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+	},
+};
+
+static const struct sdhci_cdns_drv_data sdhci_elba_drv_data = {
+	.init = elba_drv_init,
+	.pltfm_data = {
+		.ops = &sdhci_elba_ops,
+	},
 };
 
-static const struct sdhci_pltfm_data sdhci_cdns_pltfm_data = {
-	.ops = &sdhci_cdns_ops,
+static const struct sdhci_cdns_drv_data sdhci_cdns_drv_data = {
+	.pltfm_data = {
+		.ops = &sdhci_cdns_ops,
+	},
 };
 
 static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
@@ -357,7 +461,7 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
 static int sdhci_cdns_probe(struct platform_device *pdev)
 {
 	struct sdhci_host *host;
-	const struct sdhci_pltfm_data *data;
+	const struct sdhci_cdns_drv_data *data;
 	struct sdhci_pltfm_host *pltfm_host;
 	struct sdhci_cdns_priv *priv;
 	struct clk *clk;
@@ -376,10 +480,10 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
 
 	data = of_device_get_match_data(dev);
 	if (!data)
-		data = &sdhci_cdns_pltfm_data;
+		data = &sdhci_cdns_drv_data;
 
 	nr_phy_params = sdhci_cdns_phy_param_count(dev->of_node);
-	host = sdhci_pltfm_init(pdev, data,
+	host = sdhci_pltfm_init(pdev, &data->pltfm_data,
 				struct_size(priv, phy_params, nr_phy_params));
 	if (IS_ERR(host)) {
 		ret = PTR_ERR(host);
@@ -388,7 +492,6 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
 
 	pltfm_host = sdhci_priv(host);
 	pltfm_host->clk = clk;
-
 	priv = sdhci_pltfm_priv(pltfm_host);
 	priv->nr_phy_params = nr_phy_params;
 	priv->hrs_addr = host->ioaddr;
@@ -397,6 +500,11 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
 	host->ioaddr += SDHCI_CDNS_SRS_BASE;
 	host->mmc_host_ops.hs400_enhanced_strobe =
 				sdhci_cdns_hs400_enhanced_strobe;
+	if (data->init) {
+		ret = data->init(pdev);
+		if (ret)
+			goto free;
+	}
 	sdhci_enable_v4_mode(host);
 	__sdhci_read_caps(host, &version, NULL, NULL);
 
@@ -461,7 +569,11 @@ static const struct dev_pm_ops sdhci_cdns_pm_ops = {
 static const struct of_device_id sdhci_cdns_match[] = {
 	{
 		.compatible = "socionext,uniphier-sd4hc",
-		.data = &sdhci_cdns_uniphier_pltfm_data,
+		.data = &sdhci_cdns_uniphier_drv_data,
+	},
+	{
+		.compatible = "amd,pensando-elba-sd4hc",
+		.data = &sdhci_elba_drv_data,
 	},
 	{ .compatible = "cdns,sd4hc" },
 	{ /* sentinel */ }
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
  2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
                   ` (15 preceding siblings ...)
  2022-08-20 19:57 ` [PATCH v6 16/17] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support Brad Larson
@ 2022-08-20 19:57 ` Brad Larson
  2022-08-22  7:03   ` Philipp Zabel
  2022-08-22 10:53   ` Ulf Hansson
  16 siblings, 2 replies; 55+ messages in thread
From: Brad Larson @ 2022-08-20 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brad, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

From: Brad Larson <blarson@amd.com>

Add support for mmc hardware reset with a reset-controller
which would need to be enabled in the device tree with
a supporting driver.  The default is disabled for all
existing designs.

Signed-off-by: Brad Larson <blarson@amd.com>
---
 drivers/mmc/host/sdhci-cadence.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index c662c63d49fa..35d37b9aba63 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -12,6 +12,7 @@
 #include <linux/mmc/mmc.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/reset.h>
 
 #include "sdhci-pltfm.h"
 
@@ -70,6 +71,7 @@ struct sdhci_cdns_priv {
 	spinlock_t wrlock;	/* write lock */
 	bool enhanced_strobe;
 	void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
+	struct reset_control *rst_hw;
 	unsigned int nr_phy_params;
 	struct sdhci_cdns_phy_param phy_params[];
 };
@@ -458,6 +460,22 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
 					 SDHCI_CDNS_HRS06_MODE_MMC_HS400);
 }
 
+static void sdhci_mmc_hw_reset(struct mmc_host *mmc)
+{
+	struct sdhci_host *host = mmc_priv(mmc);
+	struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+
+	dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");
+
+	reset_control_assert(priv->rst_hw);
+	/* For eMMC, minimum is 1us but give it 9us for good measure */
+	udelay(9);
+
+	reset_control_deassert(priv->rst_hw);
+	/* For eMMC, minimum is 200us but give it 300us for good measure */
+	usleep_range(300, 1000);
+}
+
 static int sdhci_cdns_probe(struct platform_device *pdev)
 {
 	struct sdhci_host *host;
@@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
 	if (ret)
 		goto free;
 
+	if (host->mmc->caps & MMC_CAP_HW_RESET) {
+		priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");
+		if (IS_ERR(priv->rst_hw)) {
+			ret = PTR_ERR(priv->rst_hw);
+			if (ret == -ENOENT)
+				priv->rst_hw = NULL;
+		} else {
+			host->mmc_host_ops.card_hw_reset = sdhci_mmc_hw_reset;
+		}
+	}
+
 	ret = sdhci_add_host(host);
 	if (ret)
 		goto free;
-- 
2.17.1


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

^ permalink raw reply related	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-08-20 19:57 ` [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings Brad Larson
@ 2022-08-21 17:49   ` Serge Semin
  2022-08-31 18:28     ` Larson, Bradley
  2022-08-22 18:19   ` Krzysztof Kozlowski
  1 sibling, 1 reply; 55+ messages in thread
From: Serge Semin @ 2022-08-21 17:49 UTC (permalink / raw)
  To: Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, suravee.suthikulpanit, thomas.lendacky,
	ulf.hansson, will, devicetree

On Sat, Aug 20, 2022 at 12:57:37PM -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> index 37c3c272407d..403d6416f7ac 100644
> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> @@ -37,6 +37,15 @@ allOf:
>      else:
>        required:
>          - interrupts
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - amd,pensando-elba-spi
> +    then:
> +      required:
> +        - amd,pensando-elba-syscon

Please add the "amd,pensando-elba-syscon" property definition as I
asked here:
https://lore.kernel.org/lkml/20220704131810.kabkuy6e4qmhfm3n@mobilestation/

-Sergey

>  
>  properties:
>    compatible:
> @@ -75,6 +84,8 @@ properties:
>                - renesas,r9a06g032-spi # RZ/N1D
>                - renesas,r9a06g033-spi # RZ/N1S
>            - const: renesas,rzn1-spi   # RZ/N1
> +      - description: AMD Pensando Elba SoC SPI Controller
> +        const: amd,pensando-elba-spi
>  
>    reg:
>      minItems: 1
> -- 
> 2.17.1
> 

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 12/17] spi: dw: Add support for AMD Pensando Elba SoC
  2022-08-20 19:57 ` [PATCH v6 12/17] spi: dw: Add support " Brad Larson
@ 2022-08-21 18:18   ` Serge Semin
  2022-08-31 18:04     ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Serge Semin @ 2022-08-21 18:18 UTC (permalink / raw)
  To: Brad Larson, Andy Shevchenko
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, suravee.suthikulpanit, thomas.lendacky,
	ulf.hansson, will, devicetree

On Sat, Aug 20, 2022 at 12:57:45PM -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> The AMD Pensando Elba SoC includes a DW apb_ssi v4 controller
> with device specific chip-select control.  The Elba SoC
> provides four chip-selects where the native DW IP supports
> two chip-selects.  The Elba DW_SPI instance has two native
> CS signals that are always overridden.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  drivers/spi/spi-dw-mmio.c | 77 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
> 
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 26c40ea6dd12..36b8c5e10bb3 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -53,6 +53,24 @@ struct dw_spi_mscc {
>  	void __iomem        *spi_mst; /* Not sparx5 */
>  };
>  
> +struct dw_spi_elba {
> +	struct regmap *syscon;
> +};
> +
> +/*
> + * Elba SoC does not use ssi, pin override is used for cs 0,1 and
> + * gpios for cs 2,3 as defined in the device tree.
> + *
> + * cs:  |       1               0
> + * bit: |---3-------2-------1-------0
> + *      |  cs1   cs1_ovr   cs0   cs0_ovr
> + */
> +#define ELBA_SPICS_REG			0x2468
> +#define ELBA_SPICS_SHIFT(cs)		(2 * (cs))
> +#define ELBA_SPICS_MASK(cs)		(0x3 << ELBA_SPICS_SHIFT(cs))
> +#define ELBA_SPICS_SET(cs, val)	\
> +			((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))

Please take the @Andy' notes into account:
https://lore.kernel.org/lkml/CAHp75Vex0VkECYd=kY0m6=jXBYSXg2UFu7vn271+Q49WZn22GA@mail.gmail.com/

One more nitpick below.

> +
>  /*
>   * The Designware SPI controller (referred to as master in the documentation)
>   * automatically deasserts chip select when the tx fifo is empty. The chip
> @@ -237,6 +255,64 @@ static int dw_spi_canaan_k210_init(struct platform_device *pdev,
>  	return 0;
>  }
>  
> +static void dw_spi_elba_override_cs(struct dw_spi_elba *dwselba, int cs, int enable)
> +{
> +	regmap_update_bits(dwselba->syscon, ELBA_SPICS_REG, ELBA_SPICS_MASK(cs),
> +			   ELBA_SPICS_SET(cs, enable));
> +}
> +
> +static void dw_spi_elba_set_cs(struct spi_device *spi, bool enable)
> +{
> +	struct dw_spi *dws = spi_master_get_devdata(spi->master);
> +	struct dw_spi_mmio *dwsmmio = container_of(dws, struct dw_spi_mmio, dws);
> +	struct dw_spi_elba *dwselba = dwsmmio->priv;
> +	u8 cs;
> +
> +	cs = spi->chip_select;
> +	if (cs < 2)
> +		dw_spi_elba_override_cs(dwselba, spi->chip_select, enable);
> +
> +	/*
> +	 * The DW SPI controller needs a native CS bit selected to start
> +	 * the serial engine.
> +	 */
> +	spi->chip_select = 0;
> +	dw_spi_set_cs(spi, enable);
> +	spi->chip_select = cs;
> +}
> +
> +static int dw_spi_elba_init(struct platform_device *pdev,
> +			    struct dw_spi_mmio *dwsmmio)
> +{
> +	const char *syscon_name = "amd,pensando-elba-syscon";
> +	struct device_node *np = pdev->dev.of_node;

> +	struct device_node *node;
> +	struct dw_spi_elba *dwselba;

Please, use the reverse xmas tree order of the local variables
as the rest of the driver mainly implies.

-Sergey

> +	struct regmap *regmap;
> +
> +	node = of_parse_phandle(np, syscon_name, 0);
> +	if (!node) {
> +		dev_err(&pdev->dev, "failed to find %s\n", syscon_name);
> +		return -ENODEV;
> +	}
> +
> +	regmap = syscon_node_to_regmap(node);
> +	if (IS_ERR(regmap)) {
> +		dev_err(&pdev->dev, "syscon regmap lookup failed\n");
> +		return PTR_ERR(regmap);
> +	}
> +
> +	dwselba = devm_kzalloc(&pdev->dev, sizeof(*dwselba), GFP_KERNEL);
> +	if (!dwselba)
> +		return -ENOMEM;
> +
> +	dwselba->syscon = regmap;
> +	dwsmmio->priv = dwselba;
> +	dwsmmio->dws.set_cs = dw_spi_elba_set_cs;
> +
> +	return 0;
> +}
> +
>  static int dw_spi_mmio_probe(struct platform_device *pdev)
>  {
>  	int (*init_func)(struct platform_device *pdev,
> @@ -352,6 +428,7 @@ static const struct of_device_id dw_spi_mmio_of_match[] = {
>  	{ .compatible = "intel,thunderbay-ssi", .data = dw_spi_intel_init},
>  	{ .compatible = "microchip,sparx5-spi", dw_spi_mscc_sparx5_init},
>  	{ .compatible = "canaan,k210-spi", dw_spi_canaan_k210_init},
> +	{ .compatible = "amd,pensando-elba-spi", .data = dw_spi_elba_init},
>  	{ /* end of table */}
>  };
>  MODULE_DEVICE_TABLE(of, dw_spi_mmio_of_match);
> -- 
> 2.17.1
> 

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings
  2022-08-20 19:57 ` [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings Brad Larson
@ 2022-08-21 20:21   ` Rob Herring
  0 siblings, 0 replies; 55+ messages in thread
From: Rob Herring @ 2022-08-21 20:21 UTC (permalink / raw)
  To: Brad Larson
  Cc: linux-kernel, yamada.masahiro, fancer.lancer, krzk, piotrs,
	devicetree, samuel, catalin.marinas, gsomlo, lee.jones,
	krzysztof.kozlowski+dt, arnd, linux-mmc, suravee.suthikulpanit,
	gerg, thomas.lendacky, will, linux-arm-kernel, broonie, p.yadav,
	brijeshkumar.singh, blarson, adrian.hunter, p.zabel,
	andy.shevchenko, ulf.hansson, alcooperx, rdunlap, robh+dt

On Sat, 20 Aug 2022 12:57:40 -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Document bindings for AMD Pensando Elba SR Reset Controller
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  .../reset/amd,pensando-elbasr-reset.yaml      | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/reset/amd,pensando-elbasr-reset.example.dtb:0:0: /example-0/spi/spi@0: failed to match any schema with compatible: ['amd,pensando-elbasr']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-08-20 19:57 ` [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
@ 2022-08-21 20:21   ` Rob Herring
  2022-08-22 14:25   ` Rob Herring
  1 sibling, 0 replies; 55+ messages in thread
From: Rob Herring @ 2022-08-21 20:21 UTC (permalink / raw)
  To: Brad Larson
  Cc: catalin.marinas, gerg, gsomlo, adrian.hunter, linux-mmc,
	thomas.lendacky, krzk, rdunlap, alcooperx, brijeshkumar.singh,
	yamada.masahiro, linux-arm-kernel, broonie, ulf.hansson, piotrs,
	p.yadav, lee.jones, andy.shevchenko, suravee.suthikulpanit,
	krzysztof.kozlowski+dt, blarson, will, arnd, p.zabel, samuel,
	linux-kernel, robh+dt, devicetree, fancer.lancer

On Sat, 20 Aug 2022 12:57:39 -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Add support for the AMD Pensando Elba SoC System Resource chip
> using the SPI interface.  The Elba SR is a Multi-function Device
> supporting device register access using CS0, smbus interface for
> FRU and board peripherals using CS1, dual Lattice I2C masters for
> transceiver management using CS2, and CS3 for flash access.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  .../bindings/mfd/amd,pensando-elbasr.yaml     | 97 +++++++++++++++++++
>  1 file changed, 97 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml: Unable to find schema file matching $id: http://devicetree.org/schemas/reset/amd,pensando-elbasr-reset.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.example.dtb: system-controller@0: reset-controller@0: False schema does not allow {'compatible': ['amd,pensando-elbasr-reset'], 'reg': [[0]], '#reset-cells': [[1]]}
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.example.dtb:0:0: /example-0/spi/system-controller@0/reset-controller@0: failed to match any schema with compatible: ['amd,pensando-elbasr-reset']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
  2022-08-20 19:57 ` [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
@ 2022-08-22  7:03   ` Philipp Zabel
  2022-08-31 22:49     ` Larson, Bradley
  2022-08-22 10:53   ` Ulf Hansson
  1 sibling, 1 reply; 55+ messages in thread
From: Philipp Zabel @ 2022-08-22  7:03 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, piotrs, p.yadav, rdunlap,
	robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

Hi Brad,

On Sa, 2022-08-20 at 12:57 -0700, Brad Larson wrote:
[...]
> +static void sdhci_mmc_hw_reset(struct mmc_host *mmc)
> +{
> +	struct sdhci_host *host = mmc_priv(mmc);
> +	struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> +
> +	dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");
> +
> +	reset_control_assert(priv->rst_hw);
> +	/* For eMMC, minimum is 1us but give it 9us for good measure */
> +	udelay(9);

At a glance, this seems excessive. Is there a reason 9 us is better
than, say, 2 or 3?

[...]
> @@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto free;
>  
> 
> 
> 
> +	if (host->mmc->caps & MMC_CAP_HW_RESET) {
> +		priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");

This should be described in cdns,sdhci.yaml first.

regards
Philipp

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller
  2022-08-20 19:57 ` [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller Brad Larson
@ 2022-08-22  7:04   ` Philipp Zabel
  0 siblings, 0 replies; 55+ messages in thread
From: Philipp Zabel @ 2022-08-22  7:04 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, piotrs, p.yadav, rdunlap,
	robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On Sa, 2022-08-20 at 12:57 -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> This patch adds the reset controller functionality for the
> AMD Pensando Elba System Resource Chip.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>

Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>


regards
Philipp

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
  2022-08-20 19:57 ` [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
  2022-08-22  7:03   ` Philipp Zabel
@ 2022-08-22 10:53   ` Ulf Hansson
  2022-08-22 12:25     ` Mark Brown
  2022-08-31 23:29     ` Larson, Bradley
  1 sibling, 2 replies; 55+ messages in thread
From: Ulf Hansson @ 2022-08-22 10:53 UTC (permalink / raw)
  To: Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, will, devicetree

On Sat, 20 Aug 2022 at 21:58, Brad Larson <brad@pensando.io> wrote:
>
> From: Brad Larson <blarson@amd.com>
>
> Add support for mmc hardware reset with a reset-controller
> which would need to be enabled in the device tree with
> a supporting driver.  The default is disabled for all
> existing designs.
>
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  drivers/mmc/host/sdhci-cadence.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
> index c662c63d49fa..35d37b9aba63 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -12,6 +12,7 @@
>  #include <linux/mmc/mmc.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/reset.h>
>
>  #include "sdhci-pltfm.h"
>
> @@ -70,6 +71,7 @@ struct sdhci_cdns_priv {
>         spinlock_t wrlock;      /* write lock */
>         bool enhanced_strobe;
>         void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
> +       struct reset_control *rst_hw;
>         unsigned int nr_phy_params;
>         struct sdhci_cdns_phy_param phy_params[];
>  };
> @@ -458,6 +460,22 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
>                                          SDHCI_CDNS_HRS06_MODE_MMC_HS400);
>  }
>
> +static void sdhci_mmc_hw_reset(struct mmc_host *mmc)

Nitpick: Probably better to be consistent with the prefixes for
function names. So, I suggest changing this to
"sdhci_cdns_mmc_hw_reset".

> +{
> +       struct sdhci_host *host = mmc_priv(mmc);
> +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> +
> +       dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");

Maybe it's sufficient with dev_dbg?

> +
> +       reset_control_assert(priv->rst_hw);
> +       /* For eMMC, minimum is 1us but give it 9us for good measure */
> +       udelay(9);
> +
> +       reset_control_deassert(priv->rst_hw);
> +       /* For eMMC, minimum is 200us but give it 300us for good measure */
> +       usleep_range(300, 1000);
> +}
> +
>  static int sdhci_cdns_probe(struct platform_device *pdev)
>  {
>         struct sdhci_host *host;
> @@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>         if (ret)
>                 goto free;
>
> +       if (host->mmc->caps & MMC_CAP_HW_RESET) {
> +               priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");
> +               if (IS_ERR(priv->rst_hw)) {
> +                       ret = PTR_ERR(priv->rst_hw);
> +                       if (ret == -ENOENT)
> +                               priv->rst_hw = NULL;
> +               } else {
> +                       host->mmc_host_ops.card_hw_reset = sdhci_mmc_hw_reset;
> +               }
> +       }
> +
>         ret = sdhci_add_host(host);
>         if (ret)
>                 goto free;
> --

Other than the comments above, I wonder about what merging strategy we
should use for the series. I believe it looks fine for me to pick up
the mmc related patches, thus we can apply patches on a per subsystem
basis, right?

Kind regards
Uffe

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
  2022-08-22 10:53   ` Ulf Hansson
@ 2022-08-22 12:25     ` Mark Brown
  2022-08-31 23:29     ` Larson, Bradley
  1 sibling, 0 replies; 55+ messages in thread
From: Mark Brown @ 2022-08-22 12:25 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Brad Larson, linux-arm-kernel, linux-kernel, linux-mmc,
	adrian.hunter, alcooperx, andy.shevchenko, arnd, blarson,
	brijeshkumar.singh, catalin.marinas, gsomlo, gerg, krzk,
	krzysztof.kozlowski+dt, lee.jones, yamada.masahiro, p.zabel,
	piotrs, p.yadav, rdunlap, robh+dt, samuel, fancer.lancer,
	suravee.suthikulpanit, thomas.lendacky, will, devicetree


[-- Attachment #1.1: Type: text/plain, Size: 488 bytes --]

On Mon, Aug 22, 2022 at 12:53:22PM +0200, Ulf Hansson wrote:

> Other than the comments above, I wonder about what merging strategy we
> should use for the series. I believe it looks fine for me to pick up
> the mmc related patches, thus we can apply patches on a per subsystem
> basis, right?

Yes, if there's no relationship between the different subsystem
components (which looks like the case?) they should probably just go
separately - they can probably be submitted separately too.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-08-20 19:57 ` [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
  2022-08-21 20:21   ` Rob Herring
@ 2022-08-22 14:25   ` Rob Herring
  2022-08-31 23:01     ` Larson, Bradley
  1 sibling, 1 reply; 55+ messages in thread
From: Rob Herring @ 2022-08-22 14:25 UTC (permalink / raw)
  To: Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On Sat, Aug 20, 2022 at 12:57:39PM -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Add support for the AMD Pensando Elba SoC System Resource chip
> using the SPI interface.  The Elba SR is a Multi-function Device
> supporting device register access using CS0, smbus interface for
> FRU and board peripherals using CS1, dual Lattice I2C masters for
> transceiver management using CS2, and CS3 for flash access.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  .../bindings/mfd/amd,pensando-elbasr.yaml     | 97 +++++++++++++++++++
>  1 file changed, 97 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> new file mode 100644
> index 000000000000..ded347c3352c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/amd,pensando-elbasr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD Pensando Elba SoC Resource Controller bindings
> +
> +description: |
> +  AMD Pensando Elba SoC Resource Controller is a set of
> +  miscellaneous control/status registers accessed on CS0,
> +  a designware i2c master/slave on CS1, a Lattice rd1173
> +  dual i2c master on CS2, and flash on CS3.  The /dev interfaces
> +  created are /dev/pensr0.<CS>.  Hardware reset of the eMMC

/dev is a Linux thing and not relevant for the bindings.

> +  is implemented by a sub-device reset-controller which accesses
> +  a CS0 control register.
> +
> +maintainers:
> +  - Brad Larson <blarson@amd.com>
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - amd,pensando-elbasr
> +
> +  spi-max-frequency:
> +    description: Maximum SPI frequency of the device in Hz.

No need for generic descriptions of common properties.
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  interrupts:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - spi-max-frequency
> +
> +patternProperties:
> +  '^reset-controller@[a-f0-9]+$':
> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    spi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        num-cs = <4>;
> +
> +        sysc: system-controller@0 {
> +            compatible = "amd,pensando-elbasr";
> +            reg = <0>;
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +            spi-max-frequency = <12000000>;
> +
> +            rstc: reset-controller@0 {
> +                compatible = "amd,pensando-elbasr-reset";
> +                reg = <0>;

What does 0 represent here? A register address within 'elbasr' device?

Why do you need a child node for this? Are there other sub-devices and 
your binding is incomplete? Just put '#reset-cells' in the parent.

> +                #reset-cells = <1>;
> +            };
> +        };
> +
> +        i2c1: i2c@1 {
> +            compatible = "amd,pensando-elbasr";

You can't reuse the same compatible to represent different things.


> +            reg = <1>;
> +            spi-max-frequency = <12000000>;
> +        };
> +
> +        i2c2: i2c@2 {
> +            compatible = "amd,pensando-elbasr";

As this is a Lattice RD1173, I would expect a compatible based on that.


> +            reg = <2>;
> +            spi-max-frequency = <12000000>;
> +            interrupt-parent = <&porta>;
> +            interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +        };
> +
> +        flash@3 {
> +            compatible = "amd,pensando-elbasr";

Isn't this a flash device?

> +            reg = <3>;
> +            spi-max-frequency = <12000000>;
> +        };
> +    };
> +
> +...
> -- 
> 2.17.1
> 
> 

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards
  2022-08-20 19:57 ` [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards Brad Larson
@ 2022-08-22 18:15   ` Krzysztof Kozlowski
  2022-08-31 22:40     ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-08-22 18:15 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On 20/08/2022 22:57, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Document the compatible for AMD Pensando Elba SoC boards.

Didn't you get here tags?

Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540

If a tag was not added on purpose, please state why and what changed.

Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-08-20 19:57 ` [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings Brad Larson
  2022-08-21 17:49   ` Serge Semin
@ 2022-08-22 18:19   ` Krzysztof Kozlowski
  2022-08-31 18:45     ` Larson, Bradley
  1 sibling, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-08-22 18:19 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On 20/08/2022 22:57, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> index 37c3c272407d..403d6416f7ac 100644
> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> @@ -37,6 +37,15 @@ allOf:
>      else:
>        required:
>          - interrupts
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - amd,pensando-elba-spi
> +    then:
> +      required:
> +        - amd,pensando-elba-syscon

There is no such property. You cannot make it required without first
defining it.

>  
>  properties:
>    compatible:
> @@ -75,6 +84,8 @@ properties:
>                - renesas,r9a06g032-spi # RZ/N1D
>                - renesas,r9a06g033-spi # RZ/N1S
>            - const: renesas,rzn1-spi   # RZ/N1
> +      - description: AMD Pensando Elba SoC SPI Controller
> +        const: amd,pensando-elba-spi

Don't add stuff at the end, but in some logical (usually alphabetical)
place. The order is already broken as everyone likes to add stuff in
conflict-style, so just add it before baikal, for example.


Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for AMD Pensando Elba SoC
  2022-08-20 19:57 ` [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for " Brad Larson
@ 2022-08-22 18:22   ` Krzysztof Kozlowski
  2022-08-31 18:37     ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-08-22 18:22 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On 20/08/2022 22:57, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Document the cadence qspi controller compatible for AMD Pensando
> Elba SoC boards.  The Elba qspi fifo size is 1024.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>

Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540

If a tag was not added on purpose, please state why and what changed.



Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible
  2022-08-20 19:57 ` [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible Brad Larson
@ 2022-08-22 18:23   ` Krzysztof Kozlowski
  2022-08-31 18:35     ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-08-22 18:23 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On 20/08/2022 22:57, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Add the AMD Pensando Elba SoC system registers compatible.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>

Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540

If a tag was not added on purpose, please state why and what changed.



Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC
  2022-08-20 19:57 ` [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC Brad Larson
@ 2022-08-22 21:29   ` Rob Herring
  2022-08-31 22:36     ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Rob Herring @ 2022-08-22 21:29 UTC (permalink / raw)
  To: Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On Sat, Aug 20, 2022 at 12:57:35PM -0700, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> AMD Pensando Elba ARM 64-bit SoC is integrated with this IP and
> explicitly controls byte-lane enables.
> 
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  .../devicetree/bindings/mmc/cdns,sdhci.yaml         | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index 4207fed62dfe..964b610eeef2 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> @@ -17,12 +17,14 @@ properties:
>    compatible:
>      items:
>        - enum:
> +          - amd,pensando-elba-sd4hc
>            - microchip,mpfs-sd4hc
>            - socionext,uniphier-sd4hc
>        - const: cdns,sd4hc
>  
>    reg:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
>  
>    interrupts:
>      maxItems: 1
> @@ -118,6 +120,15 @@ required:
>    - interrupts
>    - clocks
>  
> +if:
> +  properties:
> +    compatible:
> +      const: amd,pensando-elba-sd4hc
> +then:
> +  properties:
> +    reg:
> +      minItems: 2

else:
  properties:
    reg:
      maxItems: 1

> +
>  unevaluatedProperties: false
>  
>  examples:
> -- 
> 2.17.1
> 
> 

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 12/17] spi: dw: Add support for AMD Pensando Elba SoC
  2022-08-21 18:18   ` Serge Semin
@ 2022-08-31 18:04     ` Larson, Bradley
  2022-09-11 18:20       ` Serge Semin
  0 siblings, 1 reply; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 18:04 UTC (permalink / raw)
  To: Serge Semin, Brad Larson, Andy Shevchenko
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, arnd, brijeshkumar.singh, catalin.marinas, gsomlo,
	gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap, robh+dt,
	samuel, Suthikulpanit, Suravee, Lendacky, Thomas, ulf.hansson,
	will, devicetree

On 8/21/22 11:18 AM, Serge Semin wrote:
> On Sat, Aug 20, 2022 at 12:57:45PM -0700, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> The AMD Pensando Elba SoC includes a DW apb_ssi v4 controller
>> with device specific chip-select control.  The Elba SoC
>> provides four chip-selects where the native DW IP supports
>> two chip-selects.  The Elba DW_SPI instance has two native
>> CS signals that are always overridden.
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
>> ---
>>   drivers/spi/spi-dw-mmio.c | 77 +++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 77 insertions(+)
>>
>> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
>> index 26c40ea6dd12..36b8c5e10bb3 100644
>> --- a/drivers/spi/spi-dw-mmio.c
>> +++ b/drivers/spi/spi-dw-mmio.c
>> @@ -53,6 +53,24 @@ struct dw_spi_mscc {
>>        void __iomem        *spi_mst; /* Not sparx5 */
>>   };
>>
>> +struct dw_spi_elba {
>> +     struct regmap *syscon;
>> +};
>> +
>> +/*
>> + * Elba SoC does not use ssi, pin override is used for cs 0,1 and
>> + * gpios for cs 2,3 as defined in the device tree.
>> + *
>> + * cs:  |       1               0
>> + * bit: |---3-------2-------1-------0
>> + *      |  cs1   cs1_ovr   cs0   cs0_ovr
>> + */
>> +#define ELBA_SPICS_REG                       0x2468
>> +#define ELBA_SPICS_SHIFT(cs)         (2 * (cs))
>> +#define ELBA_SPICS_MASK(cs)          (0x3 << ELBA_SPICS_SHIFT(cs))
>> +#define ELBA_SPICS_SET(cs, val)      \
>> +                     ((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))
> Please take the @Andy' notes into account:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHp75Vex0VkECYd%3DkY0m6%3DjXBYSXg2UFu7vn271%2BQ49WZn22GA%40mail.gmail.com%2F&amp;data=05%7C01%7CBradley.Larson%40amd.com%7C25d0f17dfcbd44f661c808da83a19a98%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967027418603429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=VFI%2FptM79YYbZm%2FyQmtssLsNIQ75AOU05ronZ1QStlU%3D&amp;reserved=0

Yes, I had a tested change for this but missed adding to the patch update.
This is the change and I'll resend just this patch.

--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -66,10 +66,6 @@ struct dw_spi_elba {
   *      |  cs1   cs1_ovr   cs0   cs0_ovr
   */
  #define ELBA_SPICS_REG 0x2468
-#define ELBA_SPICS_SHIFT(cs)           (2 * (cs))
-#define ELBA_SPICS_MASK(cs)            (0x3 << ELBA_SPICS_SHIFT(cs))
-#define ELBA_SPICS_SET(cs, val)        \
-                       ((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))

  /*
   * The Designware SPI controller (referred to as master in the 
documentation)
@@ -257,8 +253,9 @@ static int dw_spi_canaan_k210_init(struct 
platform_device *pdev,

  static void dw_spi_elba_override_cs(struct dw_spi_elba *dwselba, int 
cs, int enable)
  {
- regmap_update_bits(dwselba->syscon, ELBA_SPICS_REG, ELBA_SPICS_MASK(cs),
-                          ELBA_SPICS_SET(cs, enable));
+ regmap_update_bits(dwselba->syscon, ELBA_SPICS_REG,
+                          (GENMASK(1, 0) << ((cs) << 1)),
+                          ((enable) << 1 | BIT(0)) << ((cs) << 1));

  }

> One more nitpick below.
>
> +static int dw_spi_elba_init(struct platform_device *pdev,
> +                         struct dw_spi_mmio *dwsmmio)
> +{
> +     const char *syscon_name = "amd,pensando-elba-syscon";
> +     struct device_node *np = pdev->dev.of_node;
>> +     struct device_node *node;
>> +     struct dw_spi_elba *dwselba;
> Please, use the reverse xmas tree order of the local variables
> as the rest of the driver mainly implies.
Changed to reverse xmas tree ordering.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-08-21 17:49   ` Serge Semin
@ 2022-08-31 18:28     ` Larson, Bradley
  2022-09-11 18:34       ` Serge Semin
  0 siblings, 1 reply; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 18:28 UTC (permalink / raw)
  To: Serge Semin, Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, Suthikulpanit, Suravee, Lendacky,
	Thomas, ulf.hansson, will, devicetree

On 8/21/22 10:49 AM, Serge Semin wrote:
> On Sat, Aug 20, 2022 at 12:57:37PM -0700, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
>> ---
>>   .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> index 37c3c272407d..403d6416f7ac 100644
>> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> @@ -37,6 +37,15 @@ allOf:
>>       else:
>>         required:
>>           - interrupts
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - amd,pensando-elba-spi
>> +    then:
>> +      required:
>> +        - amd,pensando-elba-syscon
> Please add the "amd,pensando-elba-syscon" property definition as I
> asked here:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20220704131810.kabkuy6e4qmhfm3n%40mobilestation%2F&amp;data=05%7C01%7Cbradley.larson%40amd.com%7C1c4f822c81424048873508da839d90fc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967010019245894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xl9OU9P9QK3wLHc25hQZK393ylULd41qc4HB2Zt%2F0BQ%3D&amp;reserved=0

Proposing this addition:

--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -148,6 +148,15 @@ properties:
        of the designware controller, and the upper limit is also subject to
        controller configuration.

+  amd,pensando-elba-syscon:
+    $ref: "/schemas/types.yaml#/definitions/phandle-array"
+    maxItems: 1
+    description:
+      A phandle to syscon used to access the spi chip-select override 
register.
+    items:
+      - items:
+        - description: phandle to the syscon node
+
  patternProperties:
    "^.*@[0-9a-f]+$":
      type: object

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible
  2022-08-22 18:23   ` Krzysztof Kozlowski
@ 2022-08-31 18:35     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 18:35 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brijeshkumar.singh, catalin.marinas,
	gsomlo, gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap, robh+dt,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 8/22/22 11:23 AM, Krzysztof Kozlowski wrote:
> [CAUTION: External Email]
>
> On 20/08/2022 22:57, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> Add the AMD Pensando Elba SoC system registers compatible.
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.17%2Fsource%2FDocumentation%2Fprocess%2Fsubmitting-patches.rst%23L540&amp;data=05%7C01%7CBradley.Larson%40amd.com%7C43bad93f5b30418cd08908da846b7c8b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967894461003057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=QGnM9pbt6%2BJWeLjGN52grx3J%2FUFlwRJQML7UbJagFdY%3D&amp;reserved=0
>
> If a tag was not added on purpose, please state why and what changed.
Will do and thanks for the reminder.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for AMD Pensando Elba SoC
  2022-08-22 18:22   ` Krzysztof Kozlowski
@ 2022-08-31 18:37     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 18:37 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brijeshkumar.singh, catalin.marinas,
	gsomlo, gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap, robh+dt,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 8/22/22 11:22 AM, Krzysztof Kozlowski wrote:
> [CAUTION: External Email]
>
> On 20/08/2022 22:57, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> Document the cadence qspi controller compatible for AMD Pensando
>> Elba SoC boards.  The Elba qspi fifo size is 1024.
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.17%2Fsource%2FDocumentation%2Fprocess%2Fsubmitting-patches.rst%23L540&amp;data=05%7C01%7Cbradley.larson%40amd.com%7C7a8308d2320d4eafede508da846b4928%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967893569184991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=OKKvpkwM8VvTY6YhhKrmkqSLAOYRHxx8H90UFg4FupM%3D&amp;reserved=0
>
> If a tag was not added on purpose, please state why and what changed.

Will do and thanks for the reminder.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-08-22 18:19   ` Krzysztof Kozlowski
@ 2022-08-31 18:45     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 18:45 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brijeshkumar.singh, catalin.marinas,
	gsomlo, gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap, robh+dt,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 8/22/22 11:19 AM, Krzysztof Kozlowski wrote:
> On 20/08/2022 22:57, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
>> ---
>>   .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> index 37c3c272407d..403d6416f7ac 100644
>> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> @@ -37,6 +37,15 @@ allOf:
>>       else:
>>         required:
>>           - interrupts
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - amd,pensando-elba-spi
>> +    then:
>> +      required:
>> +        - amd,pensando-elba-syscon
> There is no such property. You cannot make it required without first
> defining it.

Added the definition of 'amd,pensando-elba-syscon' to snps,dw-apb-ssi.yaml

>>   properties:
>>     compatible:
>> @@ -75,6 +84,8 @@ properties:
>>                 - renesas,r9a06g032-spi # RZ/N1D
>>                 - renesas,r9a06g033-spi # RZ/N1S
>>             - const: renesas,rzn1-spi   # RZ/N1
>> +      - description: AMD Pensando Elba SoC SPI Controller
>> +        const: amd,pensando-elba-spi
> Don't add stuff at the end, but in some logical (usually alphabetical)
> place. The order is already broken as everyone likes to add stuff in
> conflict-style, so just add it before baikal, for example.

Yes, tried to follow existing style.  Will add it before baikal.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC
  2022-08-22 21:29   ` Rob Herring
@ 2022-08-31 22:36     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 22:36 UTC (permalink / raw)
  To: Rob Herring, Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky,
	Thomas, ulf.hansson, will, devicetree

On 8/22/22 2:29 PM, Rob Herring wrote:
> On Sat, Aug 20, 2022 at 12:57:35PM -0700, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> AMD Pensando Elba ARM 64-bit SoC is integrated with this IP and
>> explicitly controls byte-lane enables.
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
>> ---
>>   .../devicetree/bindings/mmc/cdns,sdhci.yaml         | 13 ++++++++++++-
>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
>> index 4207fed62dfe..964b610eeef2 100644
>> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
>> @@ -17,12 +17,14 @@ properties:
>>     compatible:
>>       items:
>>         - enum:
>> +          - amd,pensando-elba-sd4hc
>>             - microchip,mpfs-sd4hc
>>             - socionext,uniphier-sd4hc
>>         - const: cdns,sd4hc
>>
>>     reg:
>> -    maxItems: 1
>> +    minItems: 1
>> +    maxItems: 2
>>
>>     interrupts:
>>       maxItems: 1
>> @@ -118,6 +120,15 @@ required:
>>     - interrupts
>>     - clocks
>>
>> +if:
>> +  properties:
>> +    compatible:
>> +      const: amd,pensando-elba-sd4hc
>> +then:
>> +  properties:
>> +    reg:
>> +      minItems: 2
> else:
>    properties:
>      reg:
>        maxItems: 1

Added this change.

Regards,
Brad


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards
  2022-08-22 18:15   ` Krzysztof Kozlowski
@ 2022-08-31 22:40     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 22:40 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brijeshkumar.singh, catalin.marinas,
	gsomlo, gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap, robh+dt,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 8/22/22 11:15 AM, Krzysztof Kozlowski wrote:
> On 20/08/2022 22:57, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> Document the compatible for AMD Pensando Elba SoC boards.
> Didn't you get here tags?
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.17%2Fsource%2FDocumentation%2Fprocess%2Fsubmitting-patches.rst%23L540&amp;data=05%7C01%7CBradley.Larson%40amd.com%7Cfa3c2a618534479c3b2b08da846a5ebd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967889666777949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=VFHPfGftpiEGiolO5C1ySDvLseXZHkZZEwSoGr7o1UM%3D&amp;reserved=0
>
> If a tag was not added on purpose, please state why and what changed.

I should have added/carried forward the tags, thanks for the reminder.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
  2022-08-22  7:03   ` Philipp Zabel
@ 2022-08-31 22:49     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 22:49 UTC (permalink / raw)
  To: Philipp Zabel, Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brijeshkumar.singh, catalin.marinas,
	gsomlo, gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, piotrs, p.yadav, rdunlap, robh+dt, samuel,
	fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 8/22/22 12:03 AM, Philipp Zabel wrote:
> Hi Brad,
>
> On Sa, 2022-08-20 at 12:57 -0700, Brad Larson wrote:
> [...]
>> +static void sdhci_mmc_hw_reset(struct mmc_host *mmc)
>> +{
>> +     struct sdhci_host *host = mmc_priv(mmc);
>> +     struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
>> +
>> +     dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");
>> +
>> +     reset_control_assert(priv->rst_hw);
>> +     /* For eMMC, minimum is 1us but give it 9us for good measure */
>> +     udelay(9);
> At a glance, this seems excessive. Is there a reason 9 us is better
> than, say, 2 or 3?

Yes, 3x the minimum should be fine. Changed to 3 usec.


> [...]
>> @@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>>        if (ret)
>>                goto free;
>>
>>
>>
>>
>> +     if (host->mmc->caps & MMC_CAP_HW_RESET) {
>> +             priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");
> This should be described in cdns,sdhci.yaml first.

Adding this to cdns,sdhci.yaml and running through schema checker.

--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -114,6 +114,16 @@ properties:
      minimum: 0
      maximum: 0x7f

+  reset-names:
+    items:
+      - const: hw
+
+  resets:
+    description:
+      optional. phandle to the system reset controller with line index
+      for mmc hw reset line if exists.
+    maxItems: 1
+
  required:
    - compatible


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-08-22 14:25   ` Rob Herring
@ 2022-08-31 23:01     ` Larson, Bradley
  2022-09-01  7:20       ` Krzysztof Kozlowski
  0 siblings, 1 reply; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 23:01 UTC (permalink / raw)
  To: Rob Herring, Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky,
	Thomas, ulf.hansson, will, devicetree

On 8/22/22 7:25 AM, Rob Herring wrote:
> On Sat, Aug 20, 2022 at 12:57:39PM -0700, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> Add support for the AMD Pensando Elba SoC System Resource chip
>> using the SPI interface.  The Elba SR is a Multi-function Device
>> supporting device register access using CS0, smbus interface for
>> FRU and board peripherals using CS1, dual Lattice I2C masters for
>> transceiver management using CS2, and CS3 for flash access.
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
>> ---
>>   .../bindings/mfd/amd,pensando-elbasr.yaml     | 97 +++++++++++++++++++
>>   1 file changed, 97 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
>> new file mode 100644
>> index 000000000000..ded347c3352c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
>> @@ -0,0 +1,97 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fmfd%2Famd%2Cpensando-elbasr.yaml%23&amp;data=05%7C01%7CBradley.Larson%40amd.com%7Cd02c183f9a29492180fb08da844a3458%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967751571358185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=WHkA6tPbaDanQuMSaAiWUG3fBTfDVlWXMdeaO5t%2F3Ok%3D&amp;reserved=0
>> +$schema: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=05%7C01%7CBradley.Larson%40amd.com%7Cd02c183f9a29492180fb08da844a3458%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967751571358185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=FDig31luqeo4pOZXfuOAGiOLi0kVqFU8ExnBi5gorlY%3D&amp;reserved=0
>> +
>> +title: AMD Pensando Elba SoC Resource Controller bindings
>> +
>> +description: |
>> +  AMD Pensando Elba SoC Resource Controller is a set of
>> +  miscellaneous control/status registers accessed on CS0,
>> +  a designware i2c master/slave on CS1, a Lattice rd1173
>> +  dual i2c master on CS2, and flash on CS3.  The /dev interfaces
>> +  created are /dev/pensr0.<CS>.  Hardware reset of the eMMC
> /dev is a Linux thing and not relevant for the bindings.
>

Removed mention of the dev interfaces


>> +  is implemented by a sub-device reset-controller which accesses
>> +  a CS0 control register.
>> +
>> +maintainers:
>> +  - Brad Larson <blarson@amd.com>
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - enum:
>> +          - amd,pensando-elbasr
>> +
>> +  spi-max-frequency:
>> +    description: Maximum SPI frequency of the device in Hz.
> No need for generic descriptions of common properties.

Changed to "spi-max-frequency: true" and moved to end of properties.

>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  '#address-cells':
>> +    const: 1
>> +
>> +  '#size-cells':
>> +    const: 0
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - spi-max-frequency
>> +
>> +patternProperties:
>> +  '^reset-controller@[a-f0-9]+$':
>> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +    spi {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +        num-cs = <4>;
>> +
>> +        sysc: system-controller@0 {
>> +            compatible = "amd,pensando-elbasr";
>> +            reg = <0>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            spi-max-frequency = <12000000>;
>> +
>> +            rstc: reset-controller@0 {
>> +                compatible = "amd,pensando-elbasr-reset";
>> +                reg = <0>;
> What does 0 represent here? A register address within 'elbasr' device?

Removed, I recall a check threw a warning or error without reg.

> Why do you need a child node for this? Are there other sub-devices and
> your binding is incomplete? Just put '#reset-cells' in the parent.

Without a reset-controller node and booting the function 
__of_reset_control_get(...) fails to find a match in the list here

         list_for_each_entry(r, &reset_controller_list, list) {
                 if (args.np == r->of_node) {
                         rcdev = r;
                         break;
                 }
         }

where in sdhci_cdns_probe(...) this lookup fails

         priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, 
"hw");

which results in a non-functioning mmc hardware reset.


>> +                #reset-cells = <1>;
>> +            };
>> +        };
>> +
>> +        i2c1: i2c@1 {
>> +            compatible = "amd,pensando-elbasr";
> You can't reuse the same compatible to represent different things.


Changed to system-controller@1 and adjusted description above


>> +            reg = <1>;
>> +            spi-max-frequency = <12000000>;
>> +        };
>> +
>> +        i2c2: i2c@2 {
>> +            compatible = "amd,pensando-elbasr";
> As this is a Lattice RD1173, I would expect a compatible based on that.
>

Same as above, changed this to system-controller@2


>> +            reg = <2>;
>> +            spi-max-frequency = <12000000>;
>> +            interrupt-parent = <&porta>;
>> +            interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> +        };
>> +
>> +        flash@3 {
>> +            compatible = "amd,pensando-elbasr";
> Isn't this a flash device?


A userspace utility understands how to program this internal flash.  
Changed to system-controller@3

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
  2022-08-22 10:53   ` Ulf Hansson
  2022-08-22 12:25     ` Mark Brown
@ 2022-08-31 23:29     ` Larson, Bradley
  1 sibling, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-08-31 23:29 UTC (permalink / raw)
  To: Ulf Hansson, Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, Suthikulpanit, Suravee,
	Lendacky, Thomas, will, devicetree

On 8/22/22 3:53 AM, Ulf Hansson wrote:
> On Sat, 20 Aug 2022 at 21:58, Brad Larson <brad@pensando.io> wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> Add support for mmc hardware reset with a reset-controller
>> which would need to be enabled in the device tree with
>> a supporting driver.  The default is disabled for all
>> existing designs.
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
>> ---
>>   drivers/mmc/host/sdhci-cadence.c | 29 +++++++++++++++++++++++++++++
>>   1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
>> index c662c63d49fa..35d37b9aba63 100644
>> --- a/drivers/mmc/host/sdhci-cadence.c
>> +++ b/drivers/mmc/host/sdhci-cadence.c
>> @@ -12,6 +12,7 @@
>>   #include <linux/mmc/mmc.h>
>>   #include <linux/of.h>
>>   #include <linux/of_device.h>
>> +#include <linux/reset.h>
>>
>>   #include "sdhci-pltfm.h"
>>
>> @@ -70,6 +71,7 @@ struct sdhci_cdns_priv {
>>          spinlock_t wrlock;      /* write lock */
>>          bool enhanced_strobe;
>>          void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
>> +       struct reset_control *rst_hw;
>>          unsigned int nr_phy_params;
>>          struct sdhci_cdns_phy_param phy_params[];
>>   };
>> @@ -458,6 +460,22 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
>>                                           SDHCI_CDNS_HRS06_MODE_MMC_HS400);
>>   }
>>
>> +static void sdhci_mmc_hw_reset(struct mmc_host *mmc)
> Nitpick: Probably better to be consistent with the prefixes for
> function names. So, I suggest changing this to
> "sdhci_cdns_mmc_hw_reset".

Changing to sdhci_cdns_mmc_hw_reset().


>> +{
>> +       struct sdhci_host *host = mmc_priv(mmc);
>> +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
>> +
>> +       dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");
> Maybe it's sufficient with dev_dbg?

Changing to dev_dbg().


>> +
>> +       reset_control_assert(priv->rst_hw);
>> +       /* For eMMC, minimum is 1us but give it 9us for good measure */
>> +       udelay(9);
>> +
>> +       reset_control_deassert(priv->rst_hw);
>> +       /* For eMMC, minimum is 200us but give it 300us for good measure */
>> +       usleep_range(300, 1000);
>> +}
>> +
>>   static int sdhci_cdns_probe(struct platform_device *pdev)
>>   {
>>          struct sdhci_host *host;
>> @@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>>          if (ret)
>>                  goto free;
>>
>> +       if (host->mmc->caps & MMC_CAP_HW_RESET) {
>> +               priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");
>> +               if (IS_ERR(priv->rst_hw)) {
>> +                       ret = PTR_ERR(priv->rst_hw);
>> +                       if (ret == -ENOENT)
>> +                               priv->rst_hw = NULL;
>> +               } else {
>> +                       host->mmc_host_ops.card_hw_reset = sdhci_mmc_hw_reset;
>> +               }
>> +       }
>> +
>>          ret = sdhci_add_host(host);
>>          if (ret)
>>                  goto free;
>> --
> Other than the comments above, I wonder about what merging strategy we
> should use for the series. I believe it looks fine for me to pick up
> the mmc related patches, thus we can apply patches on a per subsystem
> basis, right?


Yes I think so and I'll be looking for guidance on this.


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-08-31 23:01     ` Larson, Bradley
@ 2022-09-01  7:20       ` Krzysztof Kozlowski
  2022-09-01 20:37         ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-09-01  7:20 UTC (permalink / raw)
  To: Larson, Bradley, Rob Herring, Brad Larson
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 01/09/2022 02:01, Larson, Bradley wrote:
> 
>>> +  is implemented by a sub-device reset-controller which accesses
>>> +  a CS0 control register.
>>> +
>>> +maintainers:
>>> +  - Brad Larson <blarson@amd.com>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    items:
>>> +      - enum:
>>> +          - amd,pensando-elbasr
>>> +
>>> +  spi-max-frequency:
>>> +    description: Maximum SPI frequency of the device in Hz.
>> No need for generic descriptions of common properties.
> 
> Changed to "spi-max-frequency: true" and moved to end of properties.

Then you should rather reference spi-peripheral-props just like other
SPI devices.

> 
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  '#address-cells':
>>> +    const: 1
>>> +
>>> +  '#size-cells':
>>> +    const: 0
>>> +
>>> +  interrupts:
>>> +    maxItems: 1
>>> +
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +  - spi-max-frequency
>>> +
>>> +patternProperties:
>>> +  '^reset-controller@[a-f0-9]+$':
>>> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +
>>> +    spi {
>>> +        #address-cells = <1>;
>>> +        #size-cells = <0>;
>>> +        num-cs = <4>;
>>> +
>>> +        sysc: system-controller@0 {
>>> +            compatible = "amd,pensando-elbasr";
>>> +            reg = <0>;
>>> +            #address-cells = <1>;
>>> +            #size-cells = <0>;
>>> +            spi-max-frequency = <12000000>;
>>> +
>>> +            rstc: reset-controller@0 {
>>> +                compatible = "amd,pensando-elbasr-reset";
>>> +                reg = <0>;
>> What does 0 represent here? A register address within 'elbasr' device?
> 
> Removed, I recall a check threw a warning or error without reg.
> 
>> Why do you need a child node for this? Are there other sub-devices and
>> your binding is incomplete? Just put '#reset-cells' in the parent.
> 
> Without a reset-controller node and booting the function 
> __of_reset_control_get(...) fails to find a match in the list here

That's not actually the answer to the question. There was no concerns
whether you need or not reset controller. The question was why do you
need a child device instead of elbasr being the reset controller.

Your answer does not cover this at all, so again - why do you need a
child for this?

Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-09-01  7:20       ` Krzysztof Kozlowski
@ 2022-09-01 20:37         ` Larson, Bradley
  2022-09-08 11:27           ` Krzysztof Kozlowski
  0 siblings, 1 reply; 55+ messages in thread
From: Larson, Bradley @ 2022-09-01 20:37 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Larson, Bradley, Rob Herring
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 9/1/22 12:20 AM, Krzysztof Kozlowski wrote:
> On 01/09/2022 02:01, Larson, Bradley wrote:
>>>> +  is implemented by a sub-device reset-controller which accesses
>>>> +  a CS0 control register.
>>>> +
>>>> +maintainers:
>>>> +  - Brad Larson <blarson@amd.com>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    items:
>>>> +      - enum:
>>>> +          - amd,pensando-elbasr
>>>> +
>>>> +  spi-max-frequency:
>>>> +    description: Maximum SPI frequency of the device in Hz.
>>> No need for generic descriptions of common properties.
>> Changed to "spi-max-frequency: true" and moved to end of properties.
> Then you should rather reference spi-peripheral-props just like other
> SPI devices.


Will look at this dependent on the result of below


>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  '#address-cells':
>>>> +    const: 1
>>>> +
>>>> +  '#size-cells':
>>>> +    const: 0
>>>> +
>>>> +  interrupts:
>>>> +    maxItems: 1
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +  - spi-max-frequency
>>>> +
>>>> +patternProperties:
>>>> +  '^reset-controller@[a-f0-9]+$':
>>>> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> +
>>>> +    spi {
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +        num-cs = <4>;
>>>> +
>>>> +        sysc: system-controller@0 {
>>>> +            compatible = "amd,pensando-elbasr";
>>>> +            reg = <0>;
>>>> +            #address-cells = <1>;
>>>> +            #size-cells = <0>;
>>>> +            spi-max-frequency = <12000000>;
>>>> +
>>>> +            rstc: reset-controller@0 {
>>>> +                compatible = "amd,pensando-elbasr-reset";
>>>> +                reg = <0>;
>>> What does 0 represent here? A register address within 'elbasr' device?
>> Removed, I recall a check threw a warning or error without reg.
>>
>>> Why do you need a child node for this? Are there other sub-devices and
>>> your binding is incomplete? Just put '#reset-cells' in the parent.
>> Without a reset-controller node and booting the function
>> __of_reset_control_get(...) fails to find a match in the list here
> That's not actually the answer to the question. There was no concerns
> whether you need or not reset controller. The question was why do you
> need a child device instead of elbasr being the reset controller.
>
> Your answer does not cover this at all, so again - why do you need a
> child for this?
>

If the parent becomes a reset-controller compatible with
"amd,pensando-elbasr-reset" then the /dev node will not be created
as there is no match to "amd,pensando-elbasr" for cs0.  For cs0 internal
to linux the reset-controller manages one register bit to hardware reset
the mmc device.  A userspace application opens the device node to manage
transceiver leds, system leds, reporting temps to host, other reset
controls, etc.  Looking at future requirements there likely will be other
child devices.

Going down this path with one compatible should reset-elbasr.c just be
deleted and fold it into the parent driver pensando-elbasr.c? Then I
wonder if it even belongs in drivers/mfd and should just be modified
and put in drivers/spi.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-09-01 20:37         ` Larson, Bradley
@ 2022-09-08 11:27           ` Krzysztof Kozlowski
  2022-09-13 21:57             ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-09-08 11:27 UTC (permalink / raw)
  To: Larson, Bradley, Rob Herring
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 01/09/2022 22:37, Larson, Bradley wrote:
> On 9/1/22 12:20 AM, Krzysztof Kozlowski wrote:
>> On 01/09/2022 02:01, Larson, Bradley wrote:
>>>>> +  is implemented by a sub-device reset-controller which accesses
>>>>> +  a CS0 control register.
>>>>> +
>>>>> +maintainers:
>>>>> +  - Brad Larson <blarson@amd.com>
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    items:
>>>>> +      - enum:
>>>>> +          - amd,pensando-elbasr
>>>>> +
>>>>> +  spi-max-frequency:
>>>>> +    description: Maximum SPI frequency of the device in Hz.
>>>> No need for generic descriptions of common properties.
>>> Changed to "spi-max-frequency: true" and moved to end of properties.
>> Then you should rather reference spi-peripheral-props just like other
>> SPI devices.
> 
> 
> Will look at this dependent on the result of below
> 
> 
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  '#address-cells':
>>>>> +    const: 1
>>>>> +
>>>>> +  '#size-cells':
>>>>> +    const: 0
>>>>> +
>>>>> +  interrupts:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +  - spi-max-frequency
>>>>> +
>>>>> +patternProperties:
>>>>> +  '^reset-controller@[a-f0-9]+$':
>>>>> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> +  - |
>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +
>>>>> +    spi {
>>>>> +        #address-cells = <1>;
>>>>> +        #size-cells = <0>;
>>>>> +        num-cs = <4>;
>>>>> +
>>>>> +        sysc: system-controller@0 {
>>>>> +            compatible = "amd,pensando-elbasr";
>>>>> +            reg = <0>;
>>>>> +            #address-cells = <1>;
>>>>> +            #size-cells = <0>;
>>>>> +            spi-max-frequency = <12000000>;
>>>>> +
>>>>> +            rstc: reset-controller@0 {
>>>>> +                compatible = "amd,pensando-elbasr-reset";
>>>>> +                reg = <0>;
>>>> What does 0 represent here? A register address within 'elbasr' device?
>>> Removed, I recall a check threw a warning or error without reg.
>>>
>>>> Why do you need a child node for this? Are there other sub-devices and
>>>> your binding is incomplete? Just put '#reset-cells' in the parent.
>>> Without a reset-controller node and booting the function
>>> __of_reset_control_get(...) fails to find a match in the list here
>> That's not actually the answer to the question. There was no concerns
>> whether you need or not reset controller. The question was why do you
>> need a child device instead of elbasr being the reset controller.
>>
>> Your answer does not cover this at all, so again - why do you need a
>> child for this?
>>
> 
> If the parent becomes a reset-controller compatible with
> "amd,pensando-elbasr-reset" then the /dev node will not be created

Why /dev node will not be created? How bindings affect having or not
having something in /dev ?

> as there is no match to "amd,pensando-elbasr" for cs0.  For cs0 internal
> to linux the reset-controller manages one register bit to hardware reset
> the mmc device.  A userspace application opens the device node to manage
> transceiver leds, system leds, reporting temps to host, other reset
> controls, etc.  Looking at future requirements there likely will be other
> child devices.

You mean "amd,pensando-elbasr" will instantiate some more devices? Why
you cannot add the binding for them now? This is actually important
because earlier we agreed you remove unit address from children.

> 
> Going down this path with one compatible should reset-elbasr.c just be
> deleted and fold it into the parent driver pensando-elbasr.c? Then I
> wonder if it even belongs in drivers/mfd and should just be modified
> and put in drivers/spi.

How is it related to bindings?

Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 12/17] spi: dw: Add support for AMD Pensando Elba SoC
  2022-08-31 18:04     ` Larson, Bradley
@ 2022-09-11 18:20       ` Serge Semin
  2022-09-14 17:03         ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Serge Semin @ 2022-09-11 18:20 UTC (permalink / raw)
  To: Larson, Bradley
  Cc: Brad Larson, Andy Shevchenko, linux-arm-kernel, linux-kernel,
	linux-mmc, adrian.hunter, alcooperx, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, Suthikulpanit, Suravee, Lendacky,
	Thomas, ulf.hansson, will, devicetree

On Wed, Aug 31, 2022 at 06:04:02PM +0000, Larson, Bradley wrote:
> On 8/21/22 11:18 AM, Serge Semin wrote:
> > On Sat, Aug 20, 2022 at 12:57:45PM -0700, Brad Larson wrote:
> >> From: Brad Larson <blarson@amd.com>
> >>
> >> The AMD Pensando Elba SoC includes a DW apb_ssi v4 controller
> >> with device specific chip-select control.  The Elba SoC
> >> provides four chip-selects where the native DW IP supports
> >> two chip-selects.  The Elba DW_SPI instance has two native
> >> CS signals that are always overridden.
> >>
> >> Signed-off-by: Brad Larson <blarson@amd.com>
> >> ---
> >>   drivers/spi/spi-dw-mmio.c | 77 +++++++++++++++++++++++++++++++++++++++
> >>   1 file changed, 77 insertions(+)
> >>
> >> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> >> index 26c40ea6dd12..36b8c5e10bb3 100644
> >> --- a/drivers/spi/spi-dw-mmio.c
> >> +++ b/drivers/spi/spi-dw-mmio.c
> >> @@ -53,6 +53,24 @@ struct dw_spi_mscc {
> >>        void __iomem        *spi_mst; /* Not sparx5 */
> >>   };
> >>
> >> +struct dw_spi_elba {
> >> +     struct regmap *syscon;
> >> +};
> >> +
> >> +/*
> >> + * Elba SoC does not use ssi, pin override is used for cs 0,1 and
> >> + * gpios for cs 2,3 as defined in the device tree.
> >> + *
> >> + * cs:  |       1               0
> >> + * bit: |---3-------2-------1-------0
> >> + *      |  cs1   cs1_ovr   cs0   cs0_ovr
> >> + */
> >> +#define ELBA_SPICS_REG                       0x2468
> >> +#define ELBA_SPICS_SHIFT(cs)         (2 * (cs))
> >> +#define ELBA_SPICS_MASK(cs)          (0x3 << ELBA_SPICS_SHIFT(cs))
> >> +#define ELBA_SPICS_SET(cs, val)      \
> >> +                     ((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))
> > Please take the @Andy' notes into account:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHp75Vex0VkECYd%3DkY0m6%3DjXBYSXg2UFu7vn271%2BQ49WZn22GA%40mail.gmail.com%2F&amp;data=05%7C01%7CBradley.Larson%40amd.com%7C25d0f17dfcbd44f661c808da83a19a98%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967027418603429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=VFI%2FptM79YYbZm%2FyQmtssLsNIQ75AOU05ronZ1QStlU%3D&amp;reserved=0
> 
> Yes, I had a tested change for this but missed adding to the patch update.
> This is the change and I'll resend just this patch.
> 
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -66,10 +66,6 @@ struct dw_spi_elba {
>    *      |  cs1   cs1_ovr   cs0   cs0_ovr
>    */
>   #define ELBA_SPICS_REG 0x2468

> -#define ELBA_SPICS_SHIFT(cs)           (2 * (cs))
> -#define ELBA_SPICS_MASK(cs)            (0x3 << ELBA_SPICS_SHIFT(cs))
> -#define ELBA_SPICS_SET(cs, val)        \
> -                       ((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))

Why do you remove these macros? Just replace 0x3 with GENMASM(1, 0),
0x1 with BIT(0), (2 * (cs)) statement with ((cs) << 1) as Andy
suggested. Using macros for such complex statement is a good practice.

Also please rename ELBA_SPICS_SHIFT() to ELBA_SPICS_OFFSET() so to
have a more coherent CSR-related macros naming in the driver.

-Sergey

> 
>   /*
>    * The Designware SPI controller (referred to as master in the 
> documentation)
> @@ -257,8 +253,9 @@ static int dw_spi_canaan_k210_init(struct 
> platform_device *pdev,
> 
>   static void dw_spi_elba_override_cs(struct dw_spi_elba *dwselba, int 
> cs, int enable)
>   {
> - regmap_update_bits(dwselba->syscon, ELBA_SPICS_REG, ELBA_SPICS_MASK(cs),
> -                          ELBA_SPICS_SET(cs, enable));
> + regmap_update_bits(dwselba->syscon, ELBA_SPICS_REG,
> +                          (GENMASK(1, 0) << ((cs) << 1)),
> +                          ((enable) << 1 | BIT(0)) << ((cs) << 1));
> 
>   }
> 
> > One more nitpick below.
> >
> > +static int dw_spi_elba_init(struct platform_device *pdev,
> > +                         struct dw_spi_mmio *dwsmmio)
> > +{
> > +     const char *syscon_name = "amd,pensando-elba-syscon";
> > +     struct device_node *np = pdev->dev.of_node;
> >> +     struct device_node *node;
> >> +     struct dw_spi_elba *dwselba;
> > Please, use the reverse xmas tree order of the local variables
> > as the rest of the driver mainly implies.
> Changed to reverse xmas tree ordering.
> 
> Regards,
> Brad

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-08-31 18:28     ` Larson, Bradley
@ 2022-09-11 18:34       ` Serge Semin
  2022-09-14 18:47         ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Serge Semin @ 2022-09-11 18:34 UTC (permalink / raw)
  To: Larson, Bradley
  Cc: Brad Larson, linux-arm-kernel, linux-kernel, linux-mmc,
	adrian.hunter, alcooperx, andy.shevchenko, arnd,
	brijeshkumar.singh, catalin.marinas, gsomlo, gerg, krzk,
	krzysztof.kozlowski+dt, lee.jones, broonie, yamada.masahiro,
	p.zabel, piotrs, p.yadav, rdunlap, robh+dt, samuel,
	Suthikulpanit, Suravee, Lendacky, Thomas, ulf.hansson, will,
	devicetree

On Wed, Aug 31, 2022 at 06:28:46PM +0000, Larson, Bradley wrote:
> On 8/21/22 10:49 AM, Serge Semin wrote:
> > On Sat, Aug 20, 2022 at 12:57:37PM -0700, Brad Larson wrote:
> >> From: Brad Larson <blarson@amd.com>
> >>
> >> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
> >>
> >> Signed-off-by: Brad Larson <blarson@amd.com>
> >> ---
> >>   .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
> >>   1 file changed, 11 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> >> index 37c3c272407d..403d6416f7ac 100644
> >> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> >> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> >> @@ -37,6 +37,15 @@ allOf:
> >>       else:
> >>         required:
> >>           - interrupts
> >> +  - if:
> >> +      properties:
> >> +        compatible:
> >> +          contains:
> >> +            enum:
> >> +              - amd,pensando-elba-spi
> >> +    then:
> >> +      required:
> >> +        - amd,pensando-elba-syscon
> > Please add the "amd,pensando-elba-syscon" property definition as I
> > asked here:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20220704131810.kabkuy6e4qmhfm3n%40mobilestation%2F&amp;data=05%7C01%7Cbradley.larson%40amd.com%7C1c4f822c81424048873508da839d90fc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637967010019245894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xl9OU9P9QK3wLHc25hQZK393ylULd41qc4HB2Zt%2F0BQ%3D&amp;reserved=0
> 

> Proposing this addition:
> 
> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> @@ -148,6 +148,15 @@ properties:
>         of the designware controller, and the upper limit is also subject to
>         controller configuration.
> 
> +  amd,pensando-elba-syscon:
> +    $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +    maxItems: 1
> +    description:
> +      A phandle to syscon used to access the spi chip-select override 
> register.
> +    items:
> +      - items:
> +        - description: phandle to the syscon node
> +

No. What Krzysztof and I asked was to add the property definition
into the allOf: [ if ...,  ] statement. Please read more carefully my
last comment:
https://lore.kernel.org/lkml/20220704131810.kabkuy6e4qmhfm3n@mobilestation/
The definition is supposed to look like this:

> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: amd,pensando-elba-spi
> +    then:
  +      properties:
  +        amd,pensando-elba-syscon
  +          $ref: /schemas/types.yaml#/definitions/phandle
  +          description: AMD Pensando Elba SoC system controller
> +      required:
> +        - amd,pensando-elba-syscon

* Please also note that I've replaced "enum:" with "const:" in the if
statement above.

The difference with what you suggested is that my version is
applicable for the Pensando ELBA SPI controller only, while your
update will cause applying the "amd,pensando-elba-syscon" property
constraints for all DW SSI controllers which isn't what we would want.

-Sergey

>   patternProperties:
>     "^.*@[0-9a-f]+$":
>       type: object
> 
> Regards,
> Brad

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-09-08 11:27           ` Krzysztof Kozlowski
@ 2022-09-13 21:57             ` Larson, Bradley
  2022-09-16  9:56               ` Krzysztof Kozlowski
  0 siblings, 1 reply; 55+ messages in thread
From: Larson, Bradley @ 2022-09-13 21:57 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Larson, Bradley, Rob Herring
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 9/8/22 4:27 AM, Krzysztof Kozlowski wrote:
> On 01/09/2022 22:37, Larson, Bradley wrote:
>> On 9/1/22 12:20 AM, Krzysztof Kozlowski wrote:
>>> On 01/09/2022 02:01, Larson, Bradley wrote:
>>>>>> +  is implemented by a sub-device reset-controller which accesses
>>>>>> +  a CS0 control register.
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Brad Larson <blarson@amd.com>
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    items:
>>>>>> +      - enum:
>>>>>> +          - amd,pensando-elbasr
>>>>>> +
>>>>>> +  spi-max-frequency:
>>>>>> +    description: Maximum SPI frequency of the device in Hz.
>>>>> No need for generic descriptions of common properties.
>>>> Changed to "spi-max-frequency: true" and moved to end of properties.
>>> Then you should rather reference spi-peripheral-props just like other
>>> SPI devices.
>>
>> Will look at this dependent on the result of below
>>
>>
>>>>>> +
>>>>>> +  reg:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  '#address-cells':
>>>>>> +    const: 1
>>>>>> +
>>>>>> +  '#size-cells':
>>>>>> +    const: 0
>>>>>> +
>>>>>> +  interrupts:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +required:
>>>>>> +  - compatible
>>>>>> +  - reg
>>>>>> +  - spi-max-frequency
>>>>>> +
>>>>>> +patternProperties:
>>>>>> +  '^reset-controller@[a-f0-9]+$':
>>>>>> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
>>>>>> +
>>>>>> +additionalProperties: false
>>>>>> +
>>>>>> +examples:
>>>>>> +  - |
>>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>>> +
>>>>>> +    spi {
>>>>>> +        #address-cells = <1>;
>>>>>> +        #size-cells = <0>;
>>>>>> +        num-cs = <4>;
>>>>>> +
>>>>>> +        sysc: system-controller@0 {
>>>>>> +            compatible = "amd,pensando-elbasr";
>>>>>> +            reg = <0>;
>>>>>> +            #address-cells = <1>;
>>>>>> +            #size-cells = <0>;
>>>>>> +            spi-max-frequency = <12000000>;
>>>>>> +
>>>>>> +            rstc: reset-controller@0 {
>>>>>> +                compatible = "amd,pensando-elbasr-reset";
>>>>>> +                reg = <0>;
>>>>> What does 0 represent here? A register address within 'elbasr' device?
>>>> Removed, I recall a check threw a warning or error without reg.
>>>>
>>>>> Why do you need a child node for this? Are there other sub-devices and
>>>>> your binding is incomplete? Just put '#reset-cells' in the parent.
>>>> Without a reset-controller node and booting the function
>>>> __of_reset_control_get(...) fails to find a match in the list here
>>> That's not actually the answer to the question. There was no concerns
>>> whether you need or not reset controller. The question was why do you
>>> need a child device instead of elbasr being the reset controller.
>>>
>>> Your answer does not cover this at all, so again - why do you need a
>>> child for this?
>>>
>> If the parent becomes a reset-controller compatible with
>> "amd,pensando-elbasr-reset" then the /dev node will not be created
> Why /dev node will not be created? How bindings affect having or not
> having something in /dev ?
>
>> as there is no match to "amd,pensando-elbasr" for cs0.  For cs0 internal
>> to linux the reset-controller manages one register bit to hardware reset
>> the mmc device.  A userspace application opens the device node to manage
>> transceiver leds, system leds, reporting temps to host, other reset
>> controls, etc.  Looking at future requirements there likely will be other
>> child devices.
> You mean "amd,pensando-elbasr" will instantiate some more devices? Why
> you cannot add the binding for them now? This is actually important
> because earlier we agreed you remove unit address from children.
>
>> Going down this path with one compatible should reset-elbasr.c just be
>> deleted and fold it into the parent driver pensando-elbasr.c? Then I
>> wonder if it even belongs in drivers/mfd and should just be modified
>> and put in drivers/spi.
> How is it related to bindings?
The compatible "amd,pensando-elbasr" is matched in 
drivers/mfd/pensando-elbasr.c
which creates /dev/pensr0.<cs> for spi chip-selects defined in the 
parent node as:

         num-cs = <4>;
         cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
                    <&porta 7 GPIO_ACTIVE_LOW>;

The compatible "amd,pensando-elbasr-reset" is in 
drivers/reset/reset-elbasr.c
which uses regmap to control one bit in the function at cs0 to hardware 
reset the eMMC.
This is the reason for the reset-controller child and the two driver 
files.  The
probe in drivers/mfd/pensando-elbasr.c is called 4 times, once per spi 
chip-select
and for cs0 mfd_add_devices() is called for the reset controller.

I'll change "rstc: reset-controller@0" to "rstc: reset-controller".

Maybe I've gotten off track following what looked like an appropriate model
to follow ("altr,a10sr") that was initially added in 2017 and has the same
device topology which is SoC <= spi => CPLD/FPGA where a10sr has a 3rd 
driver
file for a gpio controller resulting in two child nodes.

In our case its not one function its four in the device where the function
at chip-select 0 is where the hardware team provided the bit to control
eMMC hardware reset.  Is this a bad approach to follow and if so please
recommend an acceptable approach.  Also, "amd,pensando-elbasr" will not
instantiate more devices.

Snippets below for a10sr in linux-next: Device on other end of spi,
one chip select, two child devices and 3 driver files in mfd, reset, and 
gpio.

FILE: arch/arm/boot/dts/socfpga_arria10_socdk.dtsi:
&spi1 {
         status = "okay";

         resource-manager@0 {
                 compatible = "altr,a10sr";
                 reg = <0>;
                 spi-max-frequency = <100000>;
                 /* low-level active IRQ at GPIO1_5 */
                 interrupt-parent = <&portb>;
                 interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
                 interrupt-controller;
                 #interrupt-cells = <2>;

                 a10sr_gpio: gpio-controller {
                         compatible = "altr,a10sr-gpio";
                         gpio-controller;
                         #gpio-cells = <2>;
                 };

                 a10sr_rst: reset-controller {
                         compatible = "altr,a10sr-reset";
                         #reset-cells = <1>;
                 };
         };
};

FILE: drivers/mfd/altera-a10sr.c (parent)
static const struct mfd_cell altr_a10sr_subdev_info[] = {
         {
                 .name = "altr_a10sr_gpio",
                 .of_compatible = "altr,a10sr-gpio",
         },
         {
                 .name = "altr_a10sr_reset",
                 .of_compatible = "altr,a10sr-reset",
         },
};

static const struct of_device_id altr_a10sr_spi_of_match[] = {
         { .compatible = "altr,a10sr" },
         { },
};

FILE: drivers/reset/reset-a10sr.c (reset driver)
static const struct of_device_id a10sr_reset_of_match[] = {
         { .compatible = "altr,a10sr-reset" },
         { },
};

FILE: ./drivers/gpio/gpio-altera-a10sr.c (gpio driver)
static const struct of_device_id altr_a10sr_gpio_of_match[] = {
         { .compatible = "altr,a10sr-gpio" },
         { },
};

In comparision, the pensando device is also on the other end of spi,
four chip selects with /dev created for each for userspace control,
and one child device on cs0 for hw reset emmc that the Linux block
layer controls (single bit managed only by kernel).

Pensando:
&spi0 {
         num-cs = <4>;
         cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
                    <&porta 7 GPIO_ACTIVE_LOW>;
         status = "okay";
         system-controller@0 {
                 compatible = "amd,pensando-elbasr";
                 reg = <0>;
                 #address-cells = <1>;
                 #size-cells = <0>;
                 spi-max-frequency = <12000000>;

                 rstc: reset-controller {
                         compatible = "amd,pensando-elbasr-reset";
                         #reset-cells = <1>;
                 };
         };

         system-controller@1 {
                 compatible = "amd,pensando-elbasr";
                 reg = <1>;
                 spi-max-frequency = <12000000>;
         };

         system-controller@2 {
                 compatible = "amd,pensando-elbasr";
                 reg = <2>;
                 spi-max-frequency = <12000000>;
                 interrupt-parent = <&porta>;
                 interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
         };

         system-controller@3 {
                 compatible = "amd,pensando-elbasr";
                 reg = <3>;
                 spi-max-frequency = <12000000>;
         };
};

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 12/17] spi: dw: Add support for AMD Pensando Elba SoC
  2022-09-11 18:20       ` Serge Semin
@ 2022-09-14 17:03         ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-09-14 17:03 UTC (permalink / raw)
  To: Serge Semin, Larson, Bradley
  Cc: Brad Larson, Andy Shevchenko, linux-arm-kernel, linux-kernel,
	linux-mmc, adrian.hunter, alcooperx, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, Suthikulpanit, Suravee, Lendacky,
	Thomas, ulf.hansson, will, devicetree

On 9/11/22 11:20 AM, Serge Semin wrote:
> On Wed, Aug 31, 2022 at 06:04:02PM +0000, Larson, Bradley wrote:
>> On 8/21/22 11:18 AM, Serge Semin wrote:
>>> On Sat, Aug 20, 2022 at 12:57:45PM -0700, Brad Larson wrote:
>>>> From: Brad Larson <blarson@amd.com>
>>>>
>>>> The AMD Pensando Elba SoC includes a DW apb_ssi v4 controller
>>>> with device specific chip-select control.  The Elba SoC
>>>> provides four chip-selects where the native DW IP supports
>>>> two chip-selects.  The Elba DW_SPI instance has two native
>>>> CS signals that are always overridden.
>>>>
>>>> Signed-off-by: Brad Larson <blarson@amd.com>
>>>> ---
>>>>    drivers/spi/spi-dw-mmio.c | 77 +++++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 77 insertions(+)
>>>>
>>>> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
>>>> index 26c40ea6dd12..36b8c5e10bb3 100644
>>>> --- a/drivers/spi/spi-dw-mmio.c
>>>> +++ b/drivers/spi/spi-dw-mmio.c
>>>> @@ -53,6 +53,24 @@ struct dw_spi_mscc {
>>>>         void __iomem        *spi_mst; /* Not sparx5 */
>>>>    };
>>>>
>>>> +struct dw_spi_elba {
>>>> +     struct regmap *syscon;
>>>> +};
>>>> +
>>>> +/*
>>>> + * Elba SoC does not use ssi, pin override is used for cs 0,1 and
>>>> + * gpios for cs 2,3 as defined in the device tree.
>>>> + *
>>>> + * cs:  |       1               0
>>>> + * bit: |---3-------2-------1-------0
>>>> + *      |  cs1   cs1_ovr   cs0   cs0_ovr
>>>> + */
>>>> +#define ELBA_SPICS_REG                       0x2468
>>>> +#define ELBA_SPICS_SHIFT(cs)         (2 * (cs))
>>>> +#define ELBA_SPICS_MASK(cs)          (0x3 << ELBA_SPICS_SHIFT(cs))
>>>> +#define ELBA_SPICS_SET(cs, val)      \
>>>> +                     ((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))
>>> Please take the @Andy' notes into account:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHp75Vex0VkECYd%3DkY0m6%3DjXBYSXg2UFu7vn271%2BQ49WZn22GA%40mail.gmail.com%2F&amp;data=05%7C01%7Cbradley.larson%40amd.com%7C9e7cade823344b72f34608da94224dc6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637985172338293739%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=usQHWyOxaoD6iasP2R9VL5i0ZkSzBbdpsPljExHemfE%3D&amp;reserved=0
>> Yes, I had a tested change for this but missed adding to the patch update.
>> This is the change and I'll resend just this patch.
>>
>> --- a/drivers/spi/spi-dw-mmio.c
>> +++ b/drivers/spi/spi-dw-mmio.c
>> @@ -66,10 +66,6 @@ struct dw_spi_elba {
>>     *      |  cs1   cs1_ovr   cs0   cs0_ovr
>>     */
>>    #define ELBA_SPICS_REG 0x2468
>> -#define ELBA_SPICS_SHIFT(cs)           (2 * (cs))
>> -#define ELBA_SPICS_MASK(cs)            (0x3 << ELBA_SPICS_SHIFT(cs))
>> -#define ELBA_SPICS_SET(cs, val)        \
>> -                       ((((val) << 1) | 0x1) << ELBA_SPICS_SHIFT(cs))
> Why do you remove these macros? Just replace 0x3 with GENMASM(1, 0),
> 0x1 with BIT(0), (2 * (cs)) statement with ((cs) << 1) as Andy
> suggested. Using macros for such complex statement is a good practice.
>
> Also please rename ELBA_SPICS_SHIFT() to ELBA_SPICS_OFFSET() so to
> have a more coherent CSR-related macros naming in the driver.


Yes, will add back/rename macros with usage of BIT()/GENMASK() and 
resend just this patch.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings
  2022-09-11 18:34       ` Serge Semin
@ 2022-09-14 18:47         ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-09-14 18:47 UTC (permalink / raw)
  To: Serge Semin, Larson, Bradley
  Cc: Brad Larson, linux-arm-kernel, linux-kernel, linux-mmc,
	adrian.hunter, alcooperx, andy.shevchenko, arnd,
	brijeshkumar.singh, catalin.marinas, gsomlo, gerg, krzk,
	krzysztof.kozlowski+dt, lee.jones, broonie, yamada.masahiro,
	p.zabel, piotrs, p.yadav, rdunlap, robh+dt, samuel,
	Suthikulpanit, Suravee, Lendacky, Thomas, ulf.hansson, will,
	devicetree

On 9/11/22 11:34 AM, Serge Semin wrote:
> On Wed, Aug 31, 2022 at 06:28:46PM +0000, Larson, Bradley wrote:
>> On 8/21/22 10:49 AM, Serge Semin wrote:
>>> On Sat, Aug 20, 2022 at 12:57:37PM -0700, Brad Larson wrote:
>>>> From: Brad Larson <blarson@amd.com>
>>>>
>>>> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
>>>>
>>>> Signed-off-by: Brad Larson <blarson@amd.com>
>>>> ---
>>>>    .../devicetree/bindings/spi/snps,dw-apb-ssi.yaml      | 11 +++++++++++
>>>>    1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>>>> index 37c3c272407d..403d6416f7ac 100644
>>>> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>>>> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>>>> @@ -37,6 +37,15 @@ allOf:
>>>>        else:
>>>>          required:
>>>>            - interrupts
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            enum:
>>>> +              - amd,pensando-elba-spi
>>>> +    then:
>>>> +      required:
>>>> +        - amd,pensando-elba-syscon
>>> Please add the "amd,pensando-elba-syscon" property definition as I
>>> asked here:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20220704131810.kabkuy6e4qmhfm3n%40mobilestation%2F&amp;data=05%7C01%7CBradley.Larson%40amd.com%7C5f61c8f8130c47fa814208da94243e17%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637985180686357705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uzcSBjuxs1JZFXiRGFVLGojAsipJACXEGskYdGmr7qA%3D&amp;reserved=0
>> Proposing this addition:
>>
>> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> @@ -148,6 +148,15 @@ properties:
>>          of the designware controller, and the upper limit is also subject to
>>          controller configuration.
>>
>> +  amd,pensando-elba-syscon:
>> +    $ref: "/schemas/types.yaml#/definitions/phandle-array"
>> +    maxItems: 1
>> +    description:
>> +      A phandle to syscon used to access the spi chip-select override
>> register.
>> +    items:
>> +      - items:
>> +        - description: phandle to the syscon node
>> +
> No. What Krzysztof and I asked was to add the property definition
> into the allOf: [ if ...,  ] statement. Please read more carefully my
> last comment:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20220704131810.kabkuy6e4qmhfm3n%40mobilestation%2F&amp;data=05%7C01%7CBradley.Larson%40amd.com%7C5f61c8f8130c47fa814208da94243e17%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637985180686357705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uzcSBjuxs1JZFXiRGFVLGojAsipJACXEGskYdGmr7qA%3D&amp;reserved=0
> The definition is supposed to look like this:
>
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: amd,pensando-elba-spi
>> +    then:
>    +      properties:
>    +        amd,pensando-elba-syscon
>    +          $ref: /schemas/types.yaml#/definitions/phandle
>    +          description: AMD Pensando Elba SoC system controller
>> +      required:
>> +        - amd,pensando-elba-syscon
> * Please also note that I've replaced "enum:" with "const:" in the if
> statement above.
>
> The difference with what you suggested is that my version is
> applicable for the Pensando ELBA SPI controller only, while your
> update will cause applying the "amd,pensando-elba-syscon" property
> constraints for all DW SSI controllers which isn't what we would want.


Yes, I see by moving this property into the allOf its only applicable 
for compatible "amd,pensando-elba-spi". Also changing "enum:" to 
"const:" as shown.  Yes on the DT-bindings check. Rob Herring's bot 
indicated an error but I had none in checking V6 patchset.  I did a 
dtschema update and it went from dtschema 2022.3.2 to dtschema-2022.8.3 
and will see if that is the reason.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-09-13 21:57             ` Larson, Bradley
@ 2022-09-16  9:56               ` Krzysztof Kozlowski
  2022-09-29 22:50                 ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-09-16  9:56 UTC (permalink / raw)
  To: Larson, Bradley, Rob Herring
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 13/09/2022 22:57, Larson, Bradley wrote:
> On 9/8/22 4:27 AM, Krzysztof Kozlowski wrote:
>> On 01/09/2022 22:37, Larson, Bradley wrote:
>>> On 9/1/22 12:20 AM, Krzysztof Kozlowski wrote:
>>>> On 01/09/2022 02:01, Larson, Bradley wrote:
>>>>>>> +  is implemented by a sub-device reset-controller which accesses
>>>>>>> +  a CS0 control register.
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Brad Larson <blarson@amd.com>
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    items:
>>>>>>> +      - enum:
>>>>>>> +          - amd,pensando-elbasr
>>>>>>> +
>>>>>>> +  spi-max-frequency:
>>>>>>> +    description: Maximum SPI frequency of the device in Hz.
>>>>>> No need for generic descriptions of common properties.
>>>>> Changed to "spi-max-frequency: true" and moved to end of properties.
>>>> Then you should rather reference spi-peripheral-props just like other
>>>> SPI devices.
>>>
>>> Will look at this dependent on the result of below
>>>
>>>
>>>>>>> +
>>>>>>> +  reg:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  '#address-cells':
>>>>>>> +    const: 1
>>>>>>> +
>>>>>>> +  '#size-cells':
>>>>>>> +    const: 0
>>>>>>> +
>>>>>>> +  interrupts:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +required:
>>>>>>> +  - compatible
>>>>>>> +  - reg
>>>>>>> +  - spi-max-frequency
>>>>>>> +
>>>>>>> +patternProperties:
>>>>>>> +  '^reset-controller@[a-f0-9]+$':
>>>>>>> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
>>>>>>> +
>>>>>>> +additionalProperties: false
>>>>>>> +
>>>>>>> +examples:
>>>>>>> +  - |
>>>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>>>> +
>>>>>>> +    spi {
>>>>>>> +        #address-cells = <1>;
>>>>>>> +        #size-cells = <0>;
>>>>>>> +        num-cs = <4>;
>>>>>>> +
>>>>>>> +        sysc: system-controller@0 {
>>>>>>> +            compatible = "amd,pensando-elbasr";
>>>>>>> +            reg = <0>;
>>>>>>> +            #address-cells = <1>;
>>>>>>> +            #size-cells = <0>;
>>>>>>> +            spi-max-frequency = <12000000>;
>>>>>>> +
>>>>>>> +            rstc: reset-controller@0 {
>>>>>>> +                compatible = "amd,pensando-elbasr-reset";
>>>>>>> +                reg = <0>;
>>>>>> What does 0 represent here? A register address within 'elbasr' device?
>>>>> Removed, I recall a check threw a warning or error without reg.
>>>>>
>>>>>> Why do you need a child node for this? Are there other sub-devices and
>>>>>> your binding is incomplete? Just put '#reset-cells' in the parent.
>>>>> Without a reset-controller node and booting the function
>>>>> __of_reset_control_get(...) fails to find a match in the list here
>>>> That's not actually the answer to the question. There was no concerns
>>>> whether you need or not reset controller. The question was why do you
>>>> need a child device instead of elbasr being the reset controller.
>>>>
>>>> Your answer does not cover this at all, so again - why do you need a
>>>> child for this?
>>>>
>>> If the parent becomes a reset-controller compatible with
>>> "amd,pensando-elbasr-reset" then the /dev node will not be created
>> Why /dev node will not be created? How bindings affect having or not
>> having something in /dev ?

I repeat - why?

>>
>>> as there is no match to "amd,pensando-elbasr" for cs0.  For cs0 internal
>>> to linux the reset-controller manages one register bit to hardware reset
>>> the mmc device.  A userspace application opens the device node to manage
>>> transceiver leds, system leds, reporting temps to host, other reset
>>> controls, etc.  Looking at future requirements there likely will be other
>>> child devices.
>> You mean "amd,pensando-elbasr" will instantiate some more devices? Why
>> you cannot add the binding for them now? This is actually important
>> because earlier we agreed you remove unit address from children.
>>
>>> Going down this path with one compatible should reset-elbasr.c just be
>>> deleted and fold it into the parent driver pensando-elbasr.c? Then I
>>> wonder if it even belongs in drivers/mfd and should just be modified
>>> and put in drivers/spi.
>> How is it related to bindings?
> The compatible "amd,pensando-elbasr" is matched in 
> drivers/mfd/pensando-elbasr.c

Does not matter really... We do not talk about driver, but about
hardware and bindings.

> which creates /dev/pensr0.<cs> for spi chip-selects defined in the 
> parent node as:

Wait, can we skip the driver entirely? I am not reviewing your driver
and what it creates under /dev.

> 
>          num-cs = <4>;
>          cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
>                     <&porta 7 GPIO_ACTIVE_LOW>;
> 
> The compatible "amd,pensando-elbasr-reset" is in 
> drivers/reset/reset-elbasr.c

Again, why does it matter for the bindings?

> which uses regmap to control one bit in the function at cs0 to hardware 
> reset the eMMC.
> This is the reason for the reset-controller child and the two driver 
> files.  

You did not provide reason. You described Linux driver implementation
which we do not talk about. We talk about bindings, which are not really
related to implementation (at least in most cases).

> The
> probe in drivers/mfd/pensando-elbasr.c is called 4 times, once per spi 
> chip-select
> and for cs0 mfd_add_devices() is called for the reset controller.
> 
> I'll change "rstc: reset-controller@0" to "rstc: reset-controller".
> 
> Maybe I've gotten off track following what looked like an appropriate model
> to follow ("altr,a10sr") that was initially added in 2017 and has the same
> device topology which is SoC <= spi => CPLD/FPGA where a10sr has a 3rd 
> driver
> file for a gpio controller resulting in two child nodes.
> 
> In our case its not one function its four in the device where the function
> at chip-select 0 is where the hardware team provided the bit to control
> eMMC hardware reset.  Is this a bad approach to follow and if so please
> recommend an acceptable approach.  Also, "amd,pensando-elbasr" will not
> instantiate more devices.
> 
> Snippets below for a10sr in linux-next: Device on other end of spi,
> one chip select, two child devices and 3 driver files in mfd, reset, and 
> gpio.
> 
> FILE: arch/arm/boot/dts/socfpga_arria10_socdk.dtsi:
> &spi1 {
>          status = "okay";
> 
>          resource-manager@0 {
>                  compatible = "altr,a10sr";
>                  reg = <0>;
>                  spi-max-frequency = <100000>;
>                  /* low-level active IRQ at GPIO1_5 */
>                  interrupt-parent = <&portb>;
>                  interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
>                  interrupt-controller;
>                  #interrupt-cells = <2>;
> 
>                  a10sr_gpio: gpio-controller {
>                          compatible = "altr,a10sr-gpio";
>                          gpio-controller;
>                          #gpio-cells = <2>;
>                  };
> 
>                  a10sr_rst: reset-controller {
>                          compatible = "altr,a10sr-reset";
>                          #reset-cells = <1>;
>                  };
>          };
> };
> 
> FILE: drivers/mfd/altera-a10sr.c (parent)
> static const struct mfd_cell altr_a10sr_subdev_info[] = {
>          {
>                  .name = "altr_a10sr_gpio",
>                  .of_compatible = "altr,a10sr-gpio",
>          },
>          {
>                  .name = "altr_a10sr_reset",
>                  .of_compatible = "altr,a10sr-reset",
>          },

I know Linux drivers. No need to paste them here. They are unrelated to
this talk.

> };
> 
> static const struct of_device_id altr_a10sr_spi_of_match[] = {
>          { .compatible = "altr,a10sr" },
>          { },
> };
> 
> FILE: drivers/reset/reset-a10sr.c (reset driver)
> static const struct of_device_id a10sr_reset_of_match[] = {
>          { .compatible = "altr,a10sr-reset" },
>          { },
> };
> 
> FILE: ./drivers/gpio/gpio-altera-a10sr.c (gpio driver)
> static const struct of_device_id altr_a10sr_gpio_of_match[] = {
>          { .compatible = "altr,a10sr-gpio" },
>          { },
> };
> 
> In comparision, the pensando device is also on the other end of spi,
> four chip selects with /dev created for each for userspace control,
> and one child device on cs0 for hw reset emmc that the Linux block
> layer controls (single bit managed only by kernel).
> 
> Pensando:
> &spi0 {
>          num-cs = <4>;
>          cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
>                     <&porta 7 GPIO_ACTIVE_LOW>;
>          status = "okay";
>          system-controller@0 {
>                  compatible = "amd,pensando-elbasr";
>                  reg = <0>;
>                  #address-cells = <1>;
>                  #size-cells = <0>;
>                  spi-max-frequency = <12000000>;
> 
>                  rstc: reset-controller {
>                          compatible = "amd,pensando-elbasr-reset";
>                          #reset-cells = <1>;
>                  };
>          };
> 
>          system-controller@1 {
>                  compatible = "amd,pensando-elbasr";
>                  reg = <1>;
>                  spi-max-frequency = <12000000>;
>          };
> 
>          system-controller@2 {
>                  compatible = "amd,pensando-elbasr";
>                  reg = <2>;
>                  spi-max-frequency = <12000000>;
>                  interrupt-parent = <&porta>;
>                  interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>          };
> 
>          system-controller@3 {
>                  compatible = "amd,pensando-elbasr";
>                  reg = <3>;
>                  spi-max-frequency = <12000000>;
>          };
> };

You replied with quite a response of which 90% is unrelated talk about
driver. Please be specific. We talk here only about hardware.

Your last DTS might be the answer, but you never explicitly wrote it...
So let's check if I understand it correctly. Only some of elbasr block
contain reset control?

This however does not answer my questions before.... You keep ignoring
them. So please answer yes or no:

"Are there other sub-devices?"
" and your binding is incomplete?"

and a new question:
"Is reset block (amd,pensando-elbasr-reset) re-usable so it will appear
in different device (not in amd,pensando-elbasr)?"

Because from what you wrote you should just put reset-cells in the parent...



Best regards,
Krzysztof

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-09-16  9:56               ` Krzysztof Kozlowski
@ 2022-09-29 22:50                 ` Larson, Bradley
  2022-10-07 15:53                   ` Krzysztof Kozlowski
  0 siblings, 1 reply; 55+ messages in thread
From: Larson, Bradley @ 2022-09-29 22:50 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Larson, Bradley, Rob Herring
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 9/16/22 2:56 AM, Krzysztof Kozlowski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 13/09/2022 22:57, Larson, Bradley wrote:
>> On 9/8/22 4:27 AM, Krzysztof Kozlowski wrote:
>>> On 01/09/2022 22:37, Larson, Bradley wrote:
>>>> On 9/1/22 12:20 AM, Krzysztof Kozlowski wrote:
>>>>> On 01/09/2022 02:01, Larson, Bradley wrote:
>>>>>
> Wait, can we skip the driver entirely? I am not reviewing your driver 
> and what it creates under /dev. 

Yes, see precise answer requested below.

>> In comparision, the pensando device is also on the other end of spi,
>> four chip selects with /dev created for each for userspace control,
>> and one child device on cs0 for hw reset emmc that the Linux block
>> layer controls (single bit managed only by kernel).
>>
>> Pensando:
>> &spi0 {
>>           num-cs = <4>;
>>           cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
>>                      <&porta 7 GPIO_ACTIVE_LOW>;
>>           status = "okay";
>>           system-controller@0 {
>>                   compatible = "amd,pensando-elbasr";
>>                   reg = <0>;
>>                   #address-cells = <1>;
>>                   #size-cells = <0>;
>>                   spi-max-frequency = <12000000>;
>>
>>                   rstc: reset-controller {
>>                           compatible = "amd,pensando-elbasr-reset";
>>                           #reset-cells = <1>;
>>                   };
>>           };
>>
>>           system-controller@1 {
>>                   compatible = "amd,pensando-elbasr";
>>                   reg = <1>;
>>                   spi-max-frequency = <12000000>;
>>           };
>>
>>           system-controller@2 {
>>                   compatible = "amd,pensando-elbasr";
>>                   reg = <2>;
>>                   spi-max-frequency = <12000000>;
>>                   interrupt-parent = <&porta>;
>>                   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>           };
>>
>>           system-controller@3 {
>>                   compatible = "amd,pensando-elbasr";
>>                   reg = <3>;
>>                   spi-max-frequency = <12000000>;
>>           };
>> };
> You replied with quite a response of which 90% is unrelated talk about 
> driver. Please be specific. We talk here only about hardware.
> Your last DTS might be the answer, but you never explicitly wrote 
> it... So let's check if I understand it correctly. Only some of elbasr 
> block contain reset control?

Yes, only the elbasr block accessed on CS0 provides reset control.  The 
other 3 blocks don't have any reset control and never will.

> This however does not answer my questions before.... You keep ignoring 
> them. So please answer yes or no: "Are there other sub-devices?"

No

> " and your binding is incomplete?"

No

> and a new question: "Is reset block (amd,pensando-elbasr-reset) 
> re-usable so it will appear in different device (not in 
> amd,pensando-elbasr)?"

No its not re-usable

Regards,
Brad


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support
  2022-08-20 19:57 ` [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
@ 2022-09-30  7:27   ` Krzysztof Kozlowski
  2022-10-04 19:46     ` Larson, Bradley
  0 siblings, 1 reply; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-09-30  7:27 UTC (permalink / raw)
  To: Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, blarson, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzk, krzysztof.kozlowski+dt,
	lee.jones, broonie, yamada.masahiro, p.zabel, piotrs, p.yadav,
	rdunlap, robh+dt, samuel, fancer.lancer, suravee.suthikulpanit,
	thomas.lendacky, ulf.hansson, will, devicetree

On 20/08/2022 21:57, Brad Larson wrote:
> From: Brad Larson <blarson@amd.com>
> 
> Add AMD Pensando common and Elba SoC specific device nodes
> 
> Signed-off-by: Brad Larson <blarson@amd.com>

(...)

> +
> +&ahb_clk {
> +	clock-frequency = <400000000>;
> +};
> +
> +&emmc_clk {
> +	clock-frequency = <200000000>;
> +};
> +
> +&flash_clk {
> +	clock-frequency = <400000000>;
> +};
> +
> +&ref_clk {
> +	clock-frequency = <156250000>;
> +};
> +
> +&qspi {
> +	status = "okay";

Blank line between properties and device nodes.

> +	flash0: flash@0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <40000000>;
> +		spi-rx-bus-width = <2>;
> +		m25p,fast-read;
> +		cdns,read-delay = <0>;
> +		cdns,tshsl-ns = <0>;
> +		cdns,tsd2d-ns = <0>;
> +		cdns,tchsh-ns = <0>;
> +		cdns,tslch-ns = <0>;
> +	};
> +};
> +
> +&gpio0 {
> +	status = "okay";
> +};
> +
> +&emmc {
> +	bus-width = <8>;
> +	cap-mmc-hw-reset;
> +	reset-names = "hw";
> +	resets = <&rstc 0>;
> +	status = "okay";
> +};
> +
> +&wdt0 {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <100000>;
> +	status = "okay";

Blank line between properties and device nodes.

> +	rtc@51 {
> +		compatible = "nxp,pcf85263";
> +		reg = <0x51>;
> +	};
> +};
> +
> +&spi0 {
> +	num-cs = <4>;
> +	cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
> +		   <&porta 7 GPIO_ACTIVE_LOW>;
> +	status = "okay";

Blank line between properties and device nodes.

> +	sysc: system-controller@0 {
> +		compatible = "amd,pensando-elbasr";

Best regards,
Krzysztof


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support
  2022-09-30  7:27   ` Krzysztof Kozlowski
@ 2022-10-04 19:46     ` Larson, Bradley
  0 siblings, 0 replies; 55+ messages in thread
From: Larson, Bradley @ 2022-10-04 19:46 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Brad Larson, linux-arm-kernel
  Cc: linux-kernel, linux-mmc, adrian.hunter, alcooperx,
	andy.shevchenko, arnd, brijeshkumar.singh, catalin.marinas,
	gsomlo, gerg, krzk, krzysztof.kozlowski+dt, lee.jones, broonie,
	yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap, robh+dt,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 9/30/22 12:27 AM, Krzysztof Kozlowski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 20/08/2022 21:57, Brad Larson wrote:
>> From: Brad Larson <blarson@amd.com>
>>
>> Add AMD Pensando common and Elba SoC specific device nodes
>>
>> Signed-off-by: Brad Larson <blarson@amd.com>
> (...)
>
>> +
>> +&ahb_clk {
>> +     clock-frequency = <400000000>;
>> +};
>> +
>> +&emmc_clk {
>> +     clock-frequency = <200000000>;
>> +};
>> +
>> +&flash_clk {
>> +     clock-frequency = <400000000>;
>> +};
>> +
>> +&ref_clk {
>> +     clock-frequency = <156250000>;
>> +};
>> +
>> +&qspi {
>> +     status = "okay";
> Blank line between properties and device nodes. 

Added blank line.


>> +
>> +&wdt0 {
>> +     status = "okay";
>> +};
>> +
>> +&i2c0 {
>> +     clock-frequency = <100000>;
>> +     status = "okay";
> Blank line between properties and device nodes.

Added blank line.


>> +     rtc@51 {
>> +             compatible = "nxp,pcf85263";
>> +             reg = <0x51>;
>> +     };
>> +};
>> +
>> +&spi0 {
>> +     num-cs = <4>;
>> +     cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
>> +                <&porta 7 GPIO_ACTIVE_LOW>;
>> +     status = "okay";
> Blank line between properties and device nodes.


Added blank line.


>> +     sysc: system-controller@0 {
>> +             compatible = "amd,pensando-elbasr";


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip
  2022-09-29 22:50                 ` Larson, Bradley
@ 2022-10-07 15:53                   ` Krzysztof Kozlowski
  0 siblings, 0 replies; 55+ messages in thread
From: Krzysztof Kozlowski @ 2022-10-07 15:53 UTC (permalink / raw)
  To: Larson, Bradley, Rob Herring
  Cc: linux-arm-kernel, linux-kernel, linux-mmc, adrian.hunter,
	alcooperx, andy.shevchenko, arnd, brijeshkumar.singh,
	catalin.marinas, gsomlo, gerg, krzysztof.kozlowski+dt, lee.jones,
	broonie, yamada.masahiro, p.zabel, piotrs, p.yadav, rdunlap,
	samuel, fancer.lancer, Suthikulpanit, Suravee, Lendacky, Thomas,
	ulf.hansson, will, devicetree

On 30/09/2022 00:50, Larson, Bradley wrote:
> On 9/16/22 2:56 AM, Krzysztof Kozlowski wrote:
>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>
>>
>> On 13/09/2022 22:57, Larson, Bradley wrote:
>>> On 9/8/22 4:27 AM, Krzysztof Kozlowski wrote:
>>>> On 01/09/2022 22:37, Larson, Bradley wrote:
>>>>> On 9/1/22 12:20 AM, Krzysztof Kozlowski wrote:
>>>>>> On 01/09/2022 02:01, Larson, Bradley wrote:
>>>>>>
>> Wait, can we skip the driver entirely? I am not reviewing your driver 
>> and what it creates under /dev. 
> 
> Yes, see precise answer requested below.
> 
>>> In comparision, the pensando device is also on the other end of spi,
>>> four chip selects with /dev created for each for userspace control,
>>> and one child device on cs0 for hw reset emmc that the Linux block
>>> layer controls (single bit managed only by kernel).
>>>
>>> Pensando:
>>> &spi0 {
>>>           num-cs = <4>;
>>>           cs-gpios = <0>, <0>, <&porta 1 GPIO_ACTIVE_LOW>,
>>>                      <&porta 7 GPIO_ACTIVE_LOW>;
>>>           status = "okay";
>>>           system-controller@0 {
>>>                   compatible = "amd,pensando-elbasr";
>>>                   reg = <0>;
>>>                   #address-cells = <1>;
>>>                   #size-cells = <0>;
>>>                   spi-max-frequency = <12000000>;
>>>
>>>                   rstc: reset-controller {
>>>                           compatible = "amd,pensando-elbasr-reset";
>>>                           #reset-cells = <1>;
>>>                   };
>>>           };
>>>
>>>           system-controller@1 {
>>>                   compatible = "amd,pensando-elbasr";
>>>                   reg = <1>;
>>>                   spi-max-frequency = <12000000>;
>>>           };
>>>
>>>           system-controller@2 {
>>>                   compatible = "amd,pensando-elbasr";
>>>                   reg = <2>;
>>>                   spi-max-frequency = <12000000>;
>>>                   interrupt-parent = <&porta>;
>>>                   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>>           };
>>>
>>>           system-controller@3 {
>>>                   compatible = "amd,pensando-elbasr";
>>>                   reg = <3>;
>>>                   spi-max-frequency = <12000000>;
>>>           };
>>> };
>> You replied with quite a response of which 90% is unrelated talk about 
>> driver. Please be specific. We talk here only about hardware.
>> Your last DTS might be the answer, but you never explicitly wrote 
>> it... So let's check if I understand it correctly. Only some of elbasr 
>> block contain reset control?
> 
> Yes, only the elbasr block accessed on CS0 provides reset control.  The 
> other 3 blocks don't have any reset control and never will.

I see, that could explain the subnode. However:
1. You still do not use any resources in the subnode (it does not have
any in DT).

2. Your driver instantiates subdevice not based on existing of subnode
or characteristics of a device (e.g. compatible), but on hard-coded
chip-select line. The reset driver directly takes parent's regmap - no
other resources.

Therefore this does not look like dedicated piece of hardware and should
be just part of parent node.

> 
>> This however does not answer my questions before.... You keep ignoring 
>> them. So please answer yes or no: "Are there other sub-devices?"
> 
> No
> 
>> " and your binding is incomplete?"
> 
> No
> 
>> and a new question: "Is reset block (amd,pensando-elbasr-reset) 
>> re-usable so it will appear in different device (not in 
>> amd,pensando-elbasr)?"
> 
> No its not re-usable

So squash it with parent node.

Best regards,
Krzysztof


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

^ permalink raw reply	[flat|nested] 55+ messages in thread

end of thread, other threads:[~2022-10-07 15:54 UTC | newest]

Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
2022-08-20 19:57 ` [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards Brad Larson
2022-08-22 18:15   ` Krzysztof Kozlowski
2022-08-31 22:40     ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC Brad Larson
2022-08-22 21:29   ` Rob Herring
2022-08-31 22:36     ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for " Brad Larson
2022-08-22 18:22   ` Krzysztof Kozlowski
2022-08-31 18:37     ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings Brad Larson
2022-08-21 17:49   ` Serge Semin
2022-08-31 18:28     ` Larson, Bradley
2022-09-11 18:34       ` Serge Semin
2022-09-14 18:47         ` Larson, Bradley
2022-08-22 18:19   ` Krzysztof Kozlowski
2022-08-31 18:45     ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible Brad Larson
2022-08-22 18:23   ` Krzysztof Kozlowski
2022-08-31 18:35     ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
2022-08-21 20:21   ` Rob Herring
2022-08-22 14:25   ` Rob Herring
2022-08-31 23:01     ` Larson, Bradley
2022-09-01  7:20       ` Krzysztof Kozlowski
2022-09-01 20:37         ` Larson, Bradley
2022-09-08 11:27           ` Krzysztof Kozlowski
2022-09-13 21:57             ` Larson, Bradley
2022-09-16  9:56               ` Krzysztof Kozlowski
2022-09-29 22:50                 ` Larson, Bradley
2022-10-07 15:53                   ` Krzysztof Kozlowski
2022-08-20 19:57 ` [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings Brad Larson
2022-08-21 20:21   ` Rob Herring
2022-08-20 19:57 ` [PATCH v6 08/17] MAINTAINERS: Add entry for AMD PENSANDO Brad Larson
2022-08-20 19:57 ` [PATCH v6 09/17] arm64: Add config for AMD Pensando SoC platforms Brad Larson
2022-08-20 19:57 ` [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
2022-09-30  7:27   ` Krzysztof Kozlowski
2022-10-04 19:46     ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 11/17] spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC Brad Larson
2022-08-20 19:57 ` [PATCH v6 12/17] spi: dw: Add support " Brad Larson
2022-08-21 18:18   ` Serge Semin
2022-08-31 18:04     ` Larson, Bradley
2022-09-11 18:20       ` Serge Semin
2022-09-14 17:03         ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 13/17] mmc: sdhci-cadence: Enable device specific override of writel() Brad Larson
2022-08-20 19:57 ` [PATCH v6 14/17] mfd: pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
2022-08-20 19:57 ` [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller Brad Larson
2022-08-22  7:04   ` Philipp Zabel
2022-08-20 19:57 ` [PATCH v6 16/17] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support Brad Larson
2022-08-20 19:57 ` [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
2022-08-22  7:03   ` Philipp Zabel
2022-08-31 22:49     ` Larson, Bradley
2022-08-22 10:53   ` Ulf Hansson
2022-08-22 12:25     ` Mark Brown
2022-08-31 23:29     ` Larson, Bradley

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).